systemd
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
1. What exactly is systemd?
2. Why is it bad?
3. Is it open source?
4. Will Trisquel, gNewSense, or Debian be implementing it?
5. If it's safe, why does chkrootkit detect a rootkit in it?
1. Init system
2. It's not, it just annoys BSD users that their init system is far slower. Systemd optimises its code for GNU/Linux
3. Yes.
4. Yes, Ubuntu and Debian have both transferred
5. lol
>>42942811
>1. What exactly is systemd?
system management daemon
>2. Why is it bad?
Practically, it isn't. Philosophically, a bunch of retards are going >muh unigz
>3. Is it open source?
Yes
>4. Will Trisquel, gNewSense, or Debian be implementing it?
Yes, all three of these distros are implementing it.
>5. If it's safe, why does chkrootkit detect a rootkit in it?
no clue, I don't use chkrootkit
Why should it be bad?
>>42942910
It's not, it's by far the best init system ever coded
>>42942811
1. It's the devil. See boycottsystemd.org
2. Because it's its nature.
3. It's an open source cancer.
4. Hopefully not.
5. It's not safe.
>>42943020
> It's the devil
nice argument
Daily reminder that systemd is FOSS software and it's good FOSS software that
has attracted over 500 people to contribute code to it since 2010, more than
every other init or hackjob service bolt on garbage combined.
There are BSD losers actively trying to cripple GNU/Linux by spreading lies and
FUD against systemd project because if GNU/Linux uses systemd and relies on
Linux kernel only features exposed by systemd these "people" cannot continue to
leach and steal all the GPL work done by GNU/Linux users and developers which
fills BSD ports (software). Many are also thought to be on the payroll of
Microsoft to try and sabotage powerful FOSS projects with strong powerful
community.
>>42943161
>20x as many lines as OpenRC
>less comments
>>42944312
Can I bitch and moan about PulseAudio for a minute? Because I recently reinstalled and it's only offering HDMI audio with no headphone audio selectable. If I switch profiles it lists HDMI and headphones but HDMI doesn't actually work, and switching back doesn't even correct the issue.
>>42944312
It only really has comments for the really long functions that you can't instantly figure out what it is doing
>>42943161
Yes, systemd is the future.
>>42942811
Systemd is a malicious exploitive virus that exposes security holes in your Linux PC. You can remove systemd by running the following command and then rebooting:sudo rm -f /sbin/init
>>42943161
You can write like 10 line init.
Why would init need constant updates anyway?
>>42943161
500,000+ fucking lines of code.
Are we coding an Enterprise-level ERP system complete with database API, or a piece of software that has just two jobs: kickstart the system (through another program) and sit around reaping zombie processes.
Systemd is a solution in search of a problem. The only measurable benefit that it will give is "it boots fast". Every other fucking issue has been done over and over again, in many different ways, with just as good (if not better) results.
Fuck systemd. Fuck Poettering. Fuck you and the horse you rode in on.
/thread
>>42945590
I doubt all of that is the init process, but it's undoubtedly a lot of it. On Debian, contents of /lib/systemd, and yes systemd is what /sbin/init points to.$ ls -Ssh1
total 2.6M
1008K systemd
244K systemd-logind
188K systemd-journald
88K systemd-bootchart
80K systemd-timedated
80K systemd-localed
72K systemd-shutdown
68K systemd-hostnamed
60K systemd-sleep
56K systemd-readahead
52K systemd-cryptsetup
48K systemd-modules-load
48K systemd-shutdownd
44K systemd-fsck
44K systemd-sysctl
44K systemd-user-sessions
44K systemd-update-utmp
40K systemd-binfmt
40K systemd-activate
36K systemd-initctl
32K systemd-quotacheck
32K systemd-remount-fs
32K systemd-random-seed
28K systemd-cgroups-agent
28K systemd-multi-seat-x
24K systemd-reply-password
20K systemd-ac-power
20K systemd-timestamp
12K system
4.0K system-generators
4.0K system-shutdown
4.0K system-sleep
4.0K debian-fixup
4.0K systemd-logind-launch
It also links to udev and dbus and a lot more than classic sysvinit.
>>42945698
My current plan for systemd8.0K -rwxr-xr-x 1 root root 6.9K Jan 16 2011 /sbin/runit-init
>>42942811
1. A redhat/nsa sponsored program to implement backdoors and spyware on linux
2. see above
3. yes
4. yes
5. it isn't
>>42942811
It's an alternative to openrc
speed tests I've done in the past make it appear a bit faster than openrc but there's more than just speed in the equation
Who the fuck cares how fast boot is, as long as it doesn't take over 5 minutes? People actually shut down their computers? I thought that was part of the greatness of linux, no more needing to restart.
>>42945932
It has come in mind when we are talking about desktops: Computers we are turning off and on constantly. In servers it does not matter.
>>42946015
>not sending your desktop to sleep
>not using hibernate
Systemd is trying to introduce security flaws.
Considering switching to OpenBSD.
>>42946070
this also debian has flaws in it already
>>42946070
Why not just contribute to the development of OpenRC?
There are Linux distributions that will not change to systemd.
>>42946070
This is the very definition of FUD
As is all this unix way/muh bloat wankery perpetuated by idiots that haven't written a line of UNIX system code in their fucking lives, who, predictably, do not contribute to alternative projects and are totally uninterested in the openBSD foundation's initiative to make OS-agnostic daemons that provide systemd interfaces
Because anyone who's actually programmer either sees this very /g/-tier paranoia as complete bullshit. The only thing that ever mattered was "systemd lock in" which openBSD is working to eliminate without telling everyone to hold themselves back to shitty ancient software (odd for openbsd, but good for them!)
>>42946803
>either
Always remember to resize the text entry box before editing your post, kids
>>42945932
Fast boot is a side effect of socket activation
>>42946715
you already have to use systemd if you want to use gnome on gentoo
every time systemd breaks compatibility with their way of doing things, they bitch to lennart and he tells them to write something that provides the same features as systemd.
they ignore his advice and mark systemd as a dependency of whatever depends on a feature of systemd.
>>42946890
Not every likes GNOME
Also stop with you your propaganda of system, is pathetic.
systemd is a bloated clusterfuck but no one on /g/ will understand why as they've never tried to actually code for the mess they're bringing in (e.g., dbus). Try it some time. Grab something like d-feet to get an understanding of what's there, read some python-dbus tutorials, and try scripting something up that listens to NetworkManager in an event loop, takes an action on dbus in response to a condition and checks for the action having taken place. Then step back and evaluate the huge blob of shit you've produced and question what the edge cases are that you've not covered and if they're even solvable given the architecture. Then make a bare debootstrap install and see how many megs of useless dependencies you have to pull in to actually use your solution. It's fucking terrible and it's why we've avoided using it for much for a decade.
>>42947088
It was either dbus or 9p, and 9p wasn't enterprise enough
What are you going to do, avoid all useful software?
>>42947142
>dbus
>useful
You've not used it I see. It /sounds/ useful. It /sounds/ like it should be what we need. It isn't. It makes the problem worse in many cases as there's no reliable way to get confirmation of an action having taken place, and we did have ways to do that with the shitty shellscripts that it's trying to replace. Trying to make a box enterprise-levels of reliable with it is a no-go.
Stop complaining, faggots. Fork your distro and keep that other outdated shit.
>>42943161
>three times the line count
Why? Doesn't it do the same thing?
>>42947162
It sounds useful, which is why useful software ends up depending on it
Does wicd support using more than one interface at a time yet? No? Tell me about the convoluted process you use to manage your networks
>>42942903
I thought that site was serious for a minute.
What do Stallman and Linus think of it?
>>42947200
None of the network devices I've worked on or seen use dbus/networkmanager at the core because they're a toy. You can't even do things transactionally with dbus, how the fuck do you make a real network device with that without having to re-write a network manager on top of NetworkManager? That's worse than useless, that's just getting in the way.
>>42946803
You know what I hate about systemd? It fucked up the permissions on Debian wheezy. The solution to my problem?
Sudo apt-get purge systems
Then I installed wicd and everything worked flawlessly. It's the next pulseaudio, and to every bodies surprise, Pottering wrote both of them!
>>42947182
>Doesn't it do the same thing?
systemd has an http server
systemd generates colored SVG charts outlining your boot sequence
systemd has a network manager
systemd does much more than a normal init system would
>>42945932
Nope, systemd requires restarts. Welcome to your Windows 9 PC.
>>42948277
Systemd is not an init system, systemd is a collection of independent system daemons and the init system is just one of those. Hence the name.
shit
my laptop would occasionally lock up at boot for no reason using it
logs showed no problems
no hardware problems
switched to debian with openrc and it hasn't happened once
that and it's probably a backdoor
>>42948277
>systemd has an http server
wtf? for real?
how do I use it? does it have an FTP server too?
much rather use that
>>42942960
NSA pls
>>42948568
I heard people say it comes with some QR thing too. I don't know what it uses it for.
>>42945590
I agreed with you and was all "fuck yeah fuck him" until you /threaded your own post
>>42948568
how do you expect it to send your personal data to nsa servers?
Absolute cancer, quite literally. Enjoy it when this becomes a second kernel and locks everything to it and causes the death of pretty much all distros because, as they have said themselves, they see no point to the differences in distros and are trying to create one master OS.
>>42948949
>a post must not only contain information that seems reasonable to my knowledge, but be properly formatted in a very specific way for me to acknowledge the information it contains does indeed represent my anonymous point of view
the face of autism
>1. What exactly is systemd?
Gigantic complexity and incompetent development to the extreme.
>2. Why is it bad?
A thousand reasons. The biggest reason(s) are the assclowns behind it's development.
These people all hate systemd and have clearly outlined why it is a bag of commercialized shit: Spender from GrSecurity, Linus Torvalds, Theodore T'so (maintains /dev/urandom), Thegrugq, @pof a security researcher, Matthew D Green another crypto engineer and security researcher, and most other kernel developers. Slackware distro will have nothing to do with it either.
>3. Is it open source?
DEERP
>4. Will blah blah implement it?
Depends how commercial the release is. Fedora already did.
>5. If it's safe..
It's not safe. It's a shitshow.
Linux is now a bag of shit, almost on microsoft levels. The kernel development is sabotaged by corporations, who make up a majority on the Linux Foundation board. Their for-profit decisions will determine the future of Linux development.
Platforms are increasingly commercial as well, numerous corps are buying their way onto technical committees to oversee bullshit like the rush implementation of systemd to satisfy some performance increase their sales team can jack off to.
>>42949136
I guess I'm not allowed to use GNU/Linux as a hobby anymore. Might as well get an old mac and use MorphOS then.
>>42949181
You can use openRC if your distro supports it or use one of the few that refuse it, which is hardly any now.
>>42947617
Too much contrast.
FTFY
>>42949181
OpenBSD remains free as in you are free to do whatever you want with the kernel and system. No 'intelligent process' will come along and rewrite your /etc changes and shit is actually documented so there will be no surprise undocumented defaults.
Slackware is perfect for a hobby system, since you can easily drop in a vanilla kernel and patch it with tons of awesome shit to try out released to arxiv.org or GrSecurity/Pax
Plan9 you should check out too.
>>42949203
I'm guessing life with those distros will get harder when applications start to depend on systemd, or on libraries that does. I'm guessing I'll be fine for a few more years, and that systemd will be replaced by yet another new great thing and break everything one day. Seems to me stuff like happens all the time.
I already use CRUX, it is a nice distro, but all those kids going from Arch to CRUX because of system d is pretty annoying.
the developer is the problem
>>42949203
>mfw slackware will be the only systemd safe distro because gentoo got fucked on the udev shit
>>42942811
It is the first of many millennial's attempt to thwart the unix philosophy
>>42949291
you think? How does slackware get around the problem?
(i'm completely ignorant about slackware)
>>42949291
What happened to gentoo?
>>42949267
Is it weird that I went from CRUX to Arch?
>>42949351
It's weird enough that you're running linux already.
>>42949351
You're not the only thing that went CRUX to Arch.
>>42949267
Yeah you're probably right although there are lots of openrc packages that normally require systemd so I suppose it just depends if people can be bothered to hack pretty much every fucking package...which they probably will.
I wish I could be as hopeful as you about something replacing it but I don't think that will happen. Systemd itself may change and evolve but it will just be bigger and more controlling, as they make it impossible to fork, and as you say everything will depend on it sooner or later, no one will have any change of creating a replacement of the same calibre. The sad thing about systemd is that I don't think it will follow the usual way of being forked or replaced, it will become a beast and a whole operating system, which is exactly what they want.
>>42945534
because it tries to do literally everything involved with booting.
>>42949379
you know how shitty gnome 3 was at launch? and you know the gnome team's "fuck the users" attitude? guess who's behind systemd.
Oh, and unlike Gnome where you can just use a different DE or WM, have fun using a different init system when half your distro's packages depend on it.
>>42949521
Yeap and that's the scary thing...then look at what the connection/support is between gnome 3 and systemd. Follow the money works every time.
>>42949566
hell, they've even tried throwing their weight around against Linus. Didn't go too well for them but still they tried.
>>42942811
>1. What exactly is systemd?
Innovative init system by Red Hat employees, with many tools surrounding it.
>2. Why is it bad?
While being built on useful ideas, it is monolithic (so-called systemd modules are impossible to swap, impossible to use without systemd). Because of all tools being bound together by a rapidly-changing poorly-documented internal API (in contrast to stable external API).
Used by Red Hat as a means to exercise it's control over OS development.
Transition to systemd is being forced by various Red-Hat-allied projects becoming hard-dependent on it, also by making crucial system components that in the past were stand-alone, integral part of systemd.
> 3. Is it open source?
Yes, but because of the monolithic design, the number of tools it incorporates, and the rapid development by hundreds of corporate employees, it is impossible to fork one of systemd parts (for example, journald) while retaining compatibility with internal systemd API (to be not confused with external API).
You can only fork everything at once.
>4. Will Trisquel, gNewSense, or Debian be implementing it?
Yes. Debian has already moved to systemd as a default init system.
>5. If it's safe, why does chkrootkit detect a rootkit in it?
It is safe. chkrootkit uses too broad method to detect "Suckit" rootkit:strings /sbin/init | grep HOME
The systemd binary contains the string "HOME".
systemd is about control over competition, not vulnerabilities.
Also, there is no need for Red Hat to put vulnerabilities in systemd itself, because when everybody will be using it, it would be able to dictate 3rd-party software choices.
>>42949521
So use other packages that don't depend on systemd. Problem solved.
>>42951240
>systemd binary contains the string "HOME"
See bug #636231 at Red Hat bugzilla.
>>42951240
>You can only fork everything at once.
Why don't people take the effort to fork everything at one if they find Redhat's stewardship so offensive?
>>42951240
>systemd is about control over competition, not vulnerabilities.
How? It's open source and open source means no control
>>42951308
>Open source means no control
If you control broad-enough range of crucial software, you are being able to influence competitors software development and undermine their success by rapidly changing interfaces on top of which competition builds their products.
>>42942811
Linus hates it but is holding his tongue. He had a row with one of its lead developers, though.
>>42951565
Come again? I'm having trouble understand what this means.
>>42942811
1. Variously a system management daemon, a basic userspace building block to make an OS from and other explanations. It's initd, inetd, crond, atd, syslogd, NetworkManager, pm-utils, udevd (udev's a part of systemd now) and much more.
2. Binary syslog implementation that has no transaction consistency (AKA it corrupts a lot) and can't be disabled by default, huge feature creep (it now goes on to handle stateless boot, which is something that belongs in configuration management), declarative unit syntax is fundamentally limited, coredumps saved to fragile binary logs by default, huge weight and code paths in PID1, incompatible with different kernels, doesn't work on non-glibc, developers openly bragging and using components that can't be uncoupled like logind or the kdbus transport layer for udev to force the whole ecosystem into adopting systemd.
3. Yes. LGPL 2.1+.
4. Yes.
5. chkrootkit is some poorly written script that hasn't been updated in forever. It assumes lots of antiquated stuff.
>>42951602
When Ubuntu popularity was growing, Canonical started to get more and more corporate customers that might've come to Red Hat instead.
The source of Canonical popularity was the growing usability of desktop Linux and it's main selling point was expertise in this area. Because Canonical was building on top of existing tools, some of which were controlled by Red Hat, RH was able to cripple these tools in a constant process of change for the sake of change and feature removal.
This is why Canonical was forced to move away from GNOME.
>>42951700
>This is why Canonical was forced to move away from GNOME.
What are you talking about? Canonical started and published their Unity program long before Gnome 3 began using systemd. Ubuntu stopped using Gnome 2 as their desktop because they had a unique vision for their own Ubuntu UI. Gnome 3 and Gnome 2 did not fulfill their vision for Ubuntu on the tablet, the phone and the desktop so they designed Unity to make it happen. Unity was published many months before Gnome 3.0 was published.
>>42951783
>Ubuntu stopped using Gnome 2 as their desktop because they had a unique vision for their own Ubuntu UI.
And because not only Red Hat made it impossible for them to implement this vision on top of GNOME, it introduced "shifting sands" policy so that Canonical was forced to constantly adapt to pointless changes just to keep existing functionality.
> "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
>>42951836
>not only Red Hat made it impossible for them to implement this vision on top of GNOME
>it introduced "shifting sands" policy so that Canonical was forced to constantly adapt to pointless changes just to keep existing functionality.
I don't think you understand what happened at all, Canonical did not stop using Gnome technology. From the first release of Ubuntu until today, Ubuntu makes heavy use of Gnome technolgy; Canonical have never made any complaint about Gnome's direction for Gnome technology; Canonical have never made any complaint about systemd's internal programming to be unstable. I don't know where you're getting your news from but I would really like to read some citations about this.
>>42951308
>It's open source and open source means no control
Watch NSA operation ORCHESTRA
https://www.youtube.com/watch?v=fwcl17Q0bpk
and apply the described approach not to NSA operations, but to corporate influence in opensource world. If you have enough of your employees or allies on a board of "independent" project, this means that de facto it is the project under your control.
Keep the tensions just below the forking threshold, have enough projects under your influence, and you are king. Red Hat is able to afford this because of it's vast government contracts. It is Microsoft of the Linux world.
>>42951882
>Canonical have never made any complaint about systemd's internal programming to be unstable
Not directly, but it's pretty obvious Shuttleworth was pissed at how the Linux landscape was making Upstart harder and harder to maintain on their end: http://www.markshuttleworth.com/archives/1295
Only after he realized the costs of fighting the Red Hat hegemony and having to constantly update their compat shims (which they had plenty of), did he, very reluctantly, relent and admit defeat: http://www.markshuttleworth.com/archives/1316
>>42951882
>From the first release of Ubuntu until today, Ubuntu makes heavy use of Gnome technolgy;
So why has it started to build on top of Qt if the GNOME technology is so friendly and accepting patches?
>>42951927
> it's pretty obvious Shuttleworth was pissed at how the Linux landscape was making Upstart harder and harder to maintain on their end
This was not obvious to me from reading that, I did not even learn anything about upstart there. Here is what I did learn:
developing Ubuntu 13.10 was difficult but it was a job well done.
There is still plenty more work to do, it's not yet completed
>Only after he realized the costs of fighting the Red Hat hegemony and having to constantly update their compat shims (which they had plenty of), did he, very reluctantly, relent and admit defeat
I didn't learn that at all. Here is what I did learn:
Debian chose systemd as their init system
Shuttleworth is happy about the state of affairs, there are no hard feelings that Upstart was not chosen
I'm not yet convinced that Canonical felt crippled as a result of Red Hat control. All I learned was that a lot of good work was done and that there is plenty more hard work ongoing.
>>42952256
>there are no hard feelings that Upstart was not chosen
This is the political-correctness of the language of opensource world. One has to assume good faith of another party even if knows pretty well that it is using shady tactics.
>>42949344
except for them deciding to fork udev to make their systemd free eudev and lennard acting like a prick on their presentation.. nothing much. If eudev will be usefull and maintainable then gentoo will be easily systemd (right now udev is installing systemd libraries even though I am using openrc)
>>42952325
You sure those aren't actually Gentoo's independent reimplementations? OpenRC-settingsd, in particular.
eudev's biggest challenge will be replacing the kdbus transport layer that udev will move to, soon.
Working as intended: making everything a headache.
And who the fuck uses ini files in 2014? They pretty much died with DOS, thankfully. Unfortunately MS replaced them with a tendency to use the registry and XML. I wouldn't be surprised if systemd gets a registry and starts using XML like launchd does.
>>42952256
>Shuttleworth is happy about the state of affairs, there are no hard feelings that Upstart was not chosen
Hahaha, no. Shuttleworth has always been very insistent on rolling his own solutions for Ubuntu. This is evidenced particularly by Mir, and you could see him getting pissed at what he describes as the "open source tea party" (Red Hat, freedesktop.org and co., though with Poettering and Sievers as informal figureheads) in the former article I linked.
He then got a lot of flak, and only *after* the init debate was settled, did he finally swallow his pride for systemd. It's purely a strategic business decision. The hard feelings are plenty, but he isn't gonna b'aww over it and sacrifice his (already injured) reputation.
>>42952421
204 is pretty old, to be fair. Starting from 209, they've actually migrated from pure libdbus to their own homebrew sd-bus API built on top of kdbus semantics. This means less XML than before.
INI files are still used by GNOME to describe desktop icons. A registry already exists: dconf. Wouldn't be surprised if they started logging to it, honestly.
>>42952389
well systemd flag was removed from newest udev package so -systemd doesnt work on that anymore and it is pulling some systemd shit (same as pm-utils, had to install upower-pm-utils which is fork of that without systemd dependencies, systemd is realy a spreading cancer)
>>42952453
Madness.
>>42952421
ini files are better than registry you fucking idiot
>>42952476
Well, that's that. I still don't know why the fuck they can't just isolate it to a separate library, like let's say libsdbus, so that applications can use it independently for where it's needed (udev and probably in the future, udisks2, upower and other shit).
And yet people will keep insisting that there is absolutely *no* takeover attempt.
>>42952429
I did not see Shuttleworth getting pissed at anything. Shuttleworth was happy. If you want to show Shuttleworth being pissed at something, you'll have to point to something else because he was not angry at anything.
>>42952498
>there is absolutely *no* takeover attempt.
We come in peace.
>>42952498
You can't have dbus functions as a library. Dbus communication are something that happens all the time and these functions must live in the system as a never ending demon program or even within the kernel.
>>42951596
>Linus hates it but is holding his tongue.
Do you know Linux personally or have some citation for that? As far as I can see he can't hate it that much since hes been using Fedora since they moved to it in Feb 2011 and used OpenSUSE whilst they had it too and has not yet once complained.
So unless you know him persnoally and can prove that or have some actual citation for technical claims he has made about systemd: shut your mouth, you do not speak on Linus' behalf.
>>42945932
>no more needing to restart.
>he actually believes that
On linux you need to restart if you haven't properly formatted a fucking flash drive.
>>42953142
Only YOU have to restart Linux if YOU haven't properly formatted a flash drive. The rest of us can leave it running when we make mistakes.
>>42953088
>hes been using Fedora
Do you know Linux personally or have some citation for that? To my knowledge, he got terminally fed up with Fedora for using GNOME.
Also systemd's presence would be immaterial regardless whether he liked it or not, because he'd seldom interact with it (as it should be).
>>42952923
>>42947162
>You've not used it I see. It /sounds/ useful. It /sounds/ like it should be what we need. It isn't. It makes the problem worse in many cases as there's no reliable way to get confirmation of an action having taken place, and we did have ways to do that with the shitty shellscripts that it's trying to replace. Trying to make a box enterprise-levels of reliable with it is a no-go.
You aren't using it for its intended purpose. Dbus is a messaging protocol with a Object interface. That implies that most of the messages you will want to pass through it will be the kind of "Tell, don't ask". The abstraction here is that you're talking with Object instead of messages which make a certain paradigm of IPC possible. See the whole analogy here
http://www.freedesktop.org/wiki/IntroductionToDBus/
Not every abstraction has to fit your use-case.
>>42951240
I'm very much in love with systemd on first sight. The future looks towards it.
It is all you need these days. Everything else is overhead./etc/systemd/system/ignoresystemdhaters.service
>>42947262
>What do Stallman and Linus think of it?
They don't care, because as the programmers they are they can disable it and use other things.
Seriously the publicity department of open-source propaganda got it all wrong with the word _user_. It doesn't mean the end-user of the software is free to do what he want without effort, it means the user OF THE CODE is free to adapt it for it's use cases.
That is why people opposed with the transition of GPLv2 -> GPLv3, because it changed implicitly the word user from "user of the code" to "end-user of the program"
>>42953545
In other words, D-Bus is an inflexible exercise in NIH syndrome that is being shoehorned into everything (including the bloody kernel).
A common theme in the Freedesktop/Red Hat/GNOME bubble.
>>42953592
Yes, we're just haterzzzzzz.
>>42948402
[citation needed]
>>42953610
>muh Object abstraction that is useless except in the GNOME ecosystem
>muh horrible faux-filesystem of sockets
>>42953647
>you run a new PID1 image, and see the changes thereof, without restarting the system as a whole
[citation needed]
>>42953654
>that is useless except in the GNOME ecosystem
udev?
>>42953671
What of udev? devfs was robust and Greg is a childish twat.
>>42953598
>In other words, D-Bus is an inflexible exercise in NIH syndrome that is being shoehorned into everything (including the bloody kernel).
You just have to learn to use the right tool for the job. Do you complain that a toothbrush doesn't paint a house properly? If you do, don't use the toothbrush for the purposes of painting your house.
>>42953669
How do you know that PID1 needs updating any more than Linux needs updating? Can you cite any historical git data as to how regularly PID1 is updated?
>>42942811
Systemd is a remarkable development that has contributed to GNU/Linux a big improvement in performance, with startup and shutdown becoming very fast, and also noticeable simplification in system administration.
Seeing this picture, the large and abrupt changes proposed by Lennart Poettering may be too much for many computer scientists, and incredibly, can be totally misunderstood. Why? Because sysvinit works, no more, no less.
>>42953598
>In other words, D-Bus is an inflexible exercise in NIH syndrome that is being shoehorned into everything (including the bloody kernel).
Let for the sake of the argument that the above is true (it isn't), if is an example of NIH, what is the IPC mechanism is replacing? As far I know these are the following alternatives for IPC on modern unix.
shared files: a mess without some common names and without write/read barriers. Doesn't scale to more than 2 users.
shared memory: the same above only at memory level.
Pipes: they are unidirectional by nature and synchronous, same with named pipes
SIGNALS: Asynchronous, but limited to 30 such signals, consultkill -l
Semaphores, Message queue, SYSV IPC: more useful for threads than for processes.
Unix domain sockets. NOW YOU'RE TALKING. you can send datagrams and streams bidirectionally and on a asynchronous manner, but at the end of the day you're usingsendmsg() and recvmsg()to give messages from 1:1 or 1 to many (as this is IPC), plus all the applications you want to interact with need to agree before hand on a common file to represent the socket.
See the last one? it gives you a Mechanism but not a policy that is useful for you problem, which is support IPC communication asyncronously from 1:1 and 1 to many. Enter DBus, which is just a policy for Unix domain sockets with a common file on/var/run/dbus/system_bus_socketwith a policy on the names of the applications that is inferable by both server and consumers.
Is NIH? no more than TCP is NIH to IP. Sure TCP is built on IP but has different semantics. That is why people write for TCP and not pure IP and is useful to have.
>>42951300
Because systemd is a humongous project, and forking it is almost pointless. At this point it is better to start from scratch if you want to combat Red Hat and systemd.
>install systemd on a machine
>reboot
>mount a company network share
>reboot
>systemd first brings down network interfaces then tries to umount network shares
>computer frozen
Good job Lennart
Systemd is the future
>>42953734
There exists a dogmatic universal maxim: if it works, do not touch. This has led many companies and programmers to continue with outdated methodologies and tools and to not replacing them even as the news show clear improvements.
>>42953847
[install systemd]
no reboots since, sans power outage
maybe your system is just fukked
>>42953866
>maybe your system is just fukked
https://bbs.archlinux.org/viewtopic.php?id=162236
https://bugs.archlinux.org/task/35671?dev=162
https://bugs.freedesktop.org/show_bug.cgi?id=59152
Of course it is. PEBKAC as always?
I feel sorry for some of you. You don't understand what Poettering and Red Hat are doing and you eat the bait of systemd just being boot time improvements.
Pulse Audio was an experiment to see how deep they could push something no one wanted into Linux. Now, swapping to PA or removing it in Gentoo means you have to recompile a lot of programs. I uninstalled it and there is stil a package that depends on it and portage won't shut up about wanting to reinstall PA.
Red Hat is doing this with init now. They will have complete control over a lot of how Linux OSes function. And it will bring linux from a diverse ecosystem with lots of developers from different projects into one big corporate entity. And Red Hat has already done a fantastic job showing us they don't care about users with gnome and PA.
>systemd flies in the face of the Unix philosophy
But Gnu's Not Unix.
>>42953715
Why on earth would I use D-Bus at all, though, when more general protocols for locally and efficiently and cleanly getting data from A to B (and the reverse) exist? That's the question. D-Bus's existence is pointless because it is less general and more complex than prior art, therefore being inferior in all aspects.
>>42953734
Don't move the goalposts. You either can update all parts of systemd without rebooting, or you cannot. The rest of the Linux system does not require a reboot for updates to take effect, so don't pretend that it does (or that it would excuse systemd from requiring restarts to update).
>>42953796
Remarkable is the word.
>noticeable simplification in system administration
It's as much as headache as sysvinit, if not more (it's the only piece of software that breaks on Debian-testing updates, which is exceptional).
>Because sysvinit works,
Barely. That is not to say it shouldn't be thrown out and set on fire. That is, at the same time, not to say that just any alternative (systemd, upstart...) should proliferate instead regardless of merit.
>>42953822
9P. No special API needed for clients (unlike Unix domain sockets) -- you just use the normal file open/close/read/write operations from stdio. File servers appear on the file system, synthesizing the file names to a scheme that the author sees fit.
9P is what D-Bus would have mimicked if the authors had been aware of it, which would have been much preferable. An in-kernel implementation of 9P would be fine.
>>42953886
Putting all this information on the table makes me a little skeptical with the reception of the new technologies that Red Hat has made available on the server and the desktop, that cost them blood, sweat and tears consolidating so many services in a synergistic way.
>>42953654
>>muh Object abstraction that is useless except in the GNOME ecosystem
And KDE, and much of the things currently X does that really should belong to something like DBus and wayland will set straight. Seriously try to implement a systray and tell me X should be doing this. Or inform a file-manager that a new device is added (what? do you want the program to poll every 5 second to see if there anything new?).
>>muh horrible faux-filesystem of sockets
Faux filesytems are awesome, Procfs and sysfs are fine examples of this. Remember that sockets on unix are files too, you can check them on the respective /proc files.
Next time try to make an _actual_ argument kiddo.
>>42953919
Actual filesystems like procfs and sysfs and devfs and netfs are awesome. D-Bus clients' view of the filesystem is not consistent with the view of other programs. D-Bus clients get special knowledge of the D-Bus hierarchy after initialization. It's a broken abstraction.
>Seriously try to implement a systray and tell me X should be doing this. Or inform a file-manager that a new device is added (what? do you want the program to poll every 5 second to see if there anything new?).
notify(3)
>>42953895
> You don't understand what Poettering and Red Hat are doing and you eat the bait of systemd just being boot time improvements.
Maybe it's because you're just a paranoid neckbeard. It's open source. This means that anybody can take it and change it. It's now a matter of "will you take responsibility" or "you're content to be lazy and bitch about how everybody is working while you're not doing work".
>>42953905
>That is not to say it shouldn't be thrown out and set on fire.
Why should developers support outdated or inferior technologies when there is a clear leader? Remember, some of them are maintaining packages in their free time.
Made Linux too mainstream
>>42953993
So you disagree that sysvinit should be thrown out? I think you misread that part.
>>42953905
>9P. No special API needed for clients (unlike Unix domain sockets) -- you just use the normal file open/close/read/write operations from stdio. File servers appear on the file system, synthesizing the file names to a scheme that the author sees fit.
>9P is what D-Bus would have mimicked if the authors had been aware of it, which would have been much preferable. An in-kernel implementation of 9P would be fine.
Sure 9P is the better dog in the fight, you can also add it the kernel modules as 9P2000 which is neat by the way. But the argument doesn't account for the history and the legacy of the application at that point in time. People loved the TCP/IP through sockets on unix, and on socket it doesn't make sense write/read because you're dealing with packets. So the pressure force for the inclussion on AF_UNIX which used the same interface as the rest of sockets. So unix domain sockets don't win by technology win by legacy, this a good thing.
And remember that even plan9 had Plumber https://en.wikipedia.org/wiki/Plumber_%28Plan_9%29 which is analogous which it's heuristics to what DBus currently does.
The inner workings are a little different, I sincerely don't see much point to offering a read/write interface for network files. But the user dealing code is pretty much the same.
>>42954052
>So unix domain sockets don't win by technology win by legacy, this a good thing.
Yet the whole argument of systemd and D-Bus proponents is 'out with old antiquated crap'. When compared to prior art, however, D-Bus and friends really do look like arcane old crap.
>>42954119
Mate, the important matter is that it works and people can use it. D-bus works and that's the fact.
>>42953955
>D-Bus clients' view of the filesystem is not consistent with the view of other programs.
sure it is. Do you know what a proxy view is? you can make different names to the same thing and get sane result!. Plus is perfectly couple with the principle of least information. Why would Thunderbird need to know when a new headphone was connected?
Sure, notify (inotify in linux) is implementation specific, while DBus only requires unix domain sockets which are on the POSIX standard
I cant wait to reboot after updating just like windows!
>>42954019
>So you disagree that sysvinit should be thrown out? I think you misread that part.
What I'm arguing is that openrc and upstart should also be thrown out. There is a trio: one is outdated, another being phased out by Canonical. Logically, the third one going to become deprecated after kdbus will put Gentoo on the path of abandoning eudev and embracing systemd.
So, systemd is here to stay. Whether it is good or bad, get over it and continue with your happy life.
>>42954119
>Yet the whole argument of systemd and D-Bus proponents is 'out with old antiquated crap'.
I can't speak for systemd, but D-Bus is really portable and only uses 'old antiquated crap'
Also 9P had practical problems, theoretically is great, but you had to code you application specifically for it and that restricted you on the tons of legacy application that you could use to solve problems better. The fact that you had to reinvent your whole toolchain to be 9P specific made it not practical.
>>42954275
Great, enjoy your rebooting.
>>42954335
>>42954275
Either you have an integrated system with software depending on shared versioned resources that can't have each component upgraded independently, or you have a set of component loosely coupled not integrated between each other.
The last one works, but is not good enough for desktop and mobile phone users. Plus is not just fault of systemd and friend, they are just the messenger, the trend has been dictated by the market.
I for one don't care. And the ones that care don't even use the connected components and can disable them.
>>42953831
People have forked much larger projects over catastrophic management, most famously eglibc from glibc.
>>42954335
>Great, enjoy your rebooting.
With the introduction of Docker, updates are now delivered as complete images. So, in the cloud reboots are becoming a non-issue. The future is in virtualization.
Desktops and tablets? They are being rebooted any way!
>>42954688
This is what I figured. There's no need to update an outdated systemd with security bugs running on a server when an attacker won't ever reach that from a virtual machine.
>>42954520
>People have forked much larger projects over catastrophic management, most famously eglibc from glibc.
Why fork if original is great?
>>42954814
redhat pls go
>>42954814
The project maintainers have a certain direction and vision for the project. Some other people do not appreciate this vision for the project. As a result, the project forkers take responsibility and fork the project with a different vision in mind.
>>42942811
>What exactly is systemd?
Botnet from redhat and nsa
>Why is it bad?
Bloatware, lock-in, not (A)GPLv3, botnet, retarded creator, ignores standard
>>42953895
>And it will bring linux from a diverse ecosystem with lots of developers from different projects into one big corporate entity.
opensource will route around the damage. It is organic.
>>42953895
I'm with you. There is a great reality-distortion field around this. Everyone sits in his own personal bubble and thinks that the world at large has gone insane. This is wrong. What we need is to break through the bubble. How? HAISTK?
If systemd is so terrible why is everybody switching to it except genpoop?
>>42955312
Because as it turns out, distro maintainers are actually better at determining what software is good than random /g/ users are.
>>42955331
>>42955312
inb4 conspiracy theories of redhat spies that force distro leaders to adopt systemd
Someone post that Snowden slide that shows systemd
Or was that just a shoop?
>>42955331
I kind of figured. I mean if Angstrom (distro for embedded devices) uses it then I can't really see the "bloat" issue. Not that anyone on /g/ ever specifies what is bloated though...
>>42955312
Because they know many of their users will want to be able to run GNOME a year from now.
>>42955445
That doesn't explain the need to have systemd by default. If you ever need Gnome 3 with full features, why can't the package manager download systemd as part of the Gnome 3 install?
>>42955445
>opensuse
>gnome
>being this mad
>>42954334
>The fact that you had to reinvent your whole toolchain to be 9P specific made it not practical.
>reinvent
>whole toolchain
>9P specific
It looks like you've had no experience with it. Remember that only file servers have any 9P-specific code - the code to present the file server.
>>42955312
Because of the increasing amount of user-space software (especially GNOME and other Freedesktop things) that has come to depend on systemd being installed, funnily enough. Offering an API and encouraging their buddies to quickly adopt it was a shrewd move.
>>42955466
Why would distro maintainers want to maintain the presence two init systems/'core infrastructures' if only one is actually necessary for certain popular programs to work? They'd have to write both init scripts and unit files. It is simpler to drop the one you don't need anymore.
>>42955512
>Because of the increasing amount of user-space software (especially GNOME and other Freedesktop things) that has come to depend on systemd being installed
That doesn't answer anything it just moves the goal posts. So why do user-land stuff like systemd so much?
>>42955512
>Offering an API and encouraging their buddies to quickly adopt it was a shrewd move.
The guys who invented this operation are geniuses of sorts. Evil, but damn smart. )
>>42955567
Gnome is a desktop environment. It has to talk to Linux (or other Unix kernels) to deal with hardware and user logins. WIthout systemd, Gnome would have needed to write a lot of code to make those things happen. With systemd, systemd takes care of user logins and system services and hardware abstraction. This is a win for Gnome as they get access to many powerful features and they don't do any work to make it happen.
>>42955662
So why is coreos, opensuse and angstrom switching to it?
>>42955709
Systemd provides powerful features that the OS maintainers like to see. They use systemd because it's more useful or convenient that the alternatives.
>>42955709
Because, there is good stuff in systemd. But you need to see the bigger picture. The broad implications of the monopoly of this suite of components are horrible.
>>42955752
There are only implications for people too lazy to write code to replace it. They only whine and complain that "Redhat is forcing this on everybody" when the people who actually write the software happily adopt it because it's actually useful.
>>42955709
CoreOS is a pro-systemd project from the getgo, however. networkd was specifically designed for the needs of CoreOS in the first place.
>>42955752
And the alternative is that everyone keeps their own shitty and incompatible implementation of the same functionality around because heaven forbid someone would actually try and consolidate basic basic stuff like setting the system time?
>>42955421
Embedded devices have gone a long way. Simply saying "embedded" doesn't imply much where system specs are concerned. And for something to be bloated doesn't mean it necessarily hogs a ton of resources [though for what it intends to do, it does].
>>42955818
No, we need systemd alternative that is truly modular, as opposed to false modularity of systemd. >>42951240 Also the one preferably developed by independent community.
>>42944862
>Lennart Poettering
Because breaking your audio set up isn't enough
I hate this man
>>42955819
So bloated means "it does what I don't like"? What a fantastic definition of bloated.
>>42948277
Why the fuck? Isn't an init system supposed to you know init the system? Why does it need charts and an http server?
>>42955818
Setting the system time? Are you serious?
POSIX settimeofday(2) doesn't exist anymore? Linux doesn't have /dev/rtc and hwclock(8)? GNU coreutils don't have date(8), standardized by SUS?
I know systemd offers some solutions for more specific problems, but your example is awful and nothing but a blatant wheel reinvention of the squarest magnitude.
>>42955863
>>42955863
>>42944862
Before PA, I had to restart ALSA every time I wanted to change my audio sink configuration. After PA, if would change the configuration on the fly. If you plug in a USB DAC, systemd udev and Pulseaudio will get audio running through it automagically.
PA also exposed many bugs in ALSA allowing that team to hunt down the bugs and improve the drivers.
>>42955910
It doesn't need them at all. They are optional extras for you to profile and analyze your system.
>>42955312
>enabled by default
Can you just disable it?
>>42955910
>Isn't an init system supposed to you know init the system?
Yes, and systemd does that. It isn't *just* an init system though. It was named "systemd" and not "initd" for a reason, and that's because it's supposed to be your gateway to your system. It does that by including many useful and optional features that may or may not be actually related to an init system.
>>42942811
>>42955910
systemd isn't just an init system, it's:
>init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, and console managment
From a GNOME Asia presentation covered here: http://www.phoronix.com/scan.php?page=news_item&px=MTczNDk
>>42955910
It needs a http server so it can do remote logging. It needs charts because they're useful. It can be compiled without them.
>>42955935
before PA: everything worked perfectly fine
after PA: CPU usage skyrockets for all audio applications, sometimes resulting in crashes
>>42955956
You can use an alternative init system. However, there are many programs that depend on systemd features and wouldn't work to its full capacity without systemd running as the init.
So if systemd is actually open source, where is this supposed NSA backdoor then?
>>42955988
Actually no. I had hardware that was affected by ALSA driver bugs. It worked okay but also had horrible cracking on occasion. PA came along and totally broke ALSA. A few months later, the updates to ALSA drivers finally reached my computer and I got perfect audio ever since. I don't think the ALSA drivers would have been updated without PA because the drivers worked well enough.
>paid ms troll anti-systemd thread
EVERY DAY
DO NOT REPLY
REPORT THESE THREADS AS PAID ADVERTISING
TELL MOOT THE INVASION OF PAID MS TROLLS ON /g/ CONTINUES 24/7 AND HE REFUSES TO STOP IT
>>42956029
http://www.computerworld.com/s/article/9201220/Former_contractor_says_FBI_put_back_door_in_OpenBSD?taxonomyId=17
>>42955922
>what is ntp
>>42956029
People claim that systemd is "too complex" and "too ugly". They claim because of its complexity, code contributors can now add code and it would take a massive audit to find it hidden within the complex nest of code.
>>42956055
>A former government contractor says that the FBI installed a number of back doors into the encryption software used by the OpenBSD operating system.
>encryption software
Does systemd make use of encryption software?
>>42956043
I was talking about me.
Glad PA helped improving ALSA drivers, but PA shouldn't be forced upon distro installation.
Even iPhones/iPads use systemd... it must be good
>>42955863
It's funny because right now my audio is fucked up
>>42956057
ntpd and ntpdate have existed for a while, plus libs.
>>42956029
>open source guarantees immunity from backdoors and fuck ups
>>42956177
Open source guarantees that the dirty laundry is always available for show. It's up to the community to take responsibility and be vigilant about misfeatures. This means taking the time to audit the code.
>>42956226
It also means you can take invasive action when a catastrophe is coming ahead (i.e. fork it).
We are still too fragmented. If we ever want to see Year of the Linux Desktop, Linux must be unified. Systemd is one way to contribute to that goal.
>>42956329
>systemd will unite us, goyim
>>42956329
>Linux must be unified
wcpgw?
>>42956252
Let's hope that Canonical will fork it. Who else, after all?
If systemd is such cancer, there will be Linux distros that don't use it. All you retards are making such a big deal out of this, when the moment systemd becomes more trouble than it's worth, some group will probably write something that is compatible and yet less bloated.
Or we'll just return to init which will probably be still supported for a while to come by a lot of software.
I don't really understand the complaints about programs often using features from systemd in order to function properly. Nobody complains about programs using Xorg to function, for example.
Want to get rid of systemd?telinit 0
>>42956722
This. Until it's too late.
>>42954405
>And the ones that care don't even use the connected components and can disable them
Geting real tired of this "if you want to retain the convenience you used to have, you can just do a lot of work" bullshit.
>>42957039
Why should others do the work for you?
>>42957084
Why should others make more work for me?
>>42957097
Because software evolves. Some ways of doing things become outdated.
>>42957128
Linux is by design modular, and forcing everything to depend on one developer's choice (excepting Linus obv) makes the point of using Linux change from "modular and use-adaptable" to "not using Windows or OS X because I'm a neckbear"
>>42957214
> forcing everything to depend on one developer's choice
This is why we need to get our shit together and create a modular fork of systemd.
>>42957301
Ones who are capable of forking are on systemd's side. Others are on the side of systemd-haters.
>>42957301
No, what you need to do is support reimplementations of the D-Bus APIs, like OpenBSD is doing right now.
>>42957622
ubus looks really neat. Fuck dbus. Bloated shit.
>>42957622
Yeah but this is /g/
To us, choice isn't choice. Choice is having options laid out in front of us right in the AUR.
We installed linux so we could install pre-made rice not so we could participate in open source. We installed linux so we could piggyback off it.
>>42956055
Even openBSD is compromised?
>>42957214
'cept it's still modular
do you really want poettering to hold back systemd to maintain compatibility with your ancient unix shit? fuck no, we dealt with enough of that with posix. write your compatibility layers, don't force people who want to improve to stick to your shitty way of doing things.
>BUT CODE BLOAT
this is for the users, not the programmers
>>42957663
Read >>42951240
systemd is monolithic not because it needs to.
>>42957663
systemd is not modular. Sure it is different binaries, but they all depend on systemd being pid 1.
That is not modularity. The pieces have to be independent.
Fuck Poettering. Smug little twat.
just because it's unix doesn't make it good
just because it's the unix philosophy doesn't make it correct
you can't just say 'unix' and have your shitty taste in technology become externally ratified by the ghost of dennis ritchie
>>42957705
It's partially modular, but also monolithic. systemd is pretty selective about what components can and can't be swapped out. Some technically optional generators and utilities are left in.
Everyone who cares!!! Please install OpenBSD and help test D-Bus API reimplementation!
http://www.openbsdfoundation.org/gsoc2014.html#systemd
You do not have to be a developer to do this!!!
>>42957859
>Knowledge prerequisite: [...] perl.
Welp, it's shit. Fixing bloat by requiring the language that the Linuxes factored out of base installs because of bloat.
>>42957859
>OpenBSD
GNU hater gtfo.
>>42957893
The repository is here: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systemd-utl.git
They don't seem to have any Perl code yet. Even if they do write some, it'll be for helper scripts used in development, not as part of the software distribution itself. For this, Perl isn't a bad choice: it's awk on steroids.
Git uses a lot of Perl, btw.
>>42957893
There is also systemd-shim by Serge Hallyn.
https://lists.debian.org/debian-devel/2014/07/msg00371.html
You can help him out if you don't like perl or OpenBSD.
>Systemd
>not touching it with a ten foot pole
>>42957969
The D-Bus API reimplementation is going to be os-agnostic. What is it that you don't like?
Licence? Well, if you care so much, BSD allows future relicensing to GPL.
EVERYONE PLEASE HELP TEST D-Bus API REIMPLEMENTATION!
IN THE FUTURE YOU WILL BE ABLE TO USE IT ON LINUX TOO!!
it could make linux an actual competitor on the desktop market
>>42958155
Having a choice still won't hurt!
>>42958155
It sure will compete with Windows in instability.
>>42958155
I don't understand *how*, though. Desktop users don't care about what their initd does, and this includes most of systemd's functionality. It's irrelevant to them.
>>42958259
http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
Linux is such a clusterfuck and you people wonder why it has no mainstream appeal. This thread is proof enough
>>42958310
Yeah, but that's kdbus + Wayland + gconf. I don't see how systemd factors directly into this.
Also, their justifications for GNOME sandboxing are really based on the fact that GTK+ maintainers are careless and keep breaking core functionality with every release. Docker will probably eat this concept's lunch.
>>42943020
>I gotta hide my kiddy porn, guys! Systemd isnt safe the nsa cares so much about my porn and not terrorists!!!!
>Using software written by the same idiot that introduced PulseAudio
>>42958762
Actually, your porn habits are very important to us. You will be identified by your individual porn signature for the rest of your life.
>>42942811
systemd is the best thing to happen to Linux in my opinion. No longer can linuxtards come whining about their "muh free software" "muh no NSA" "muh freedumbs" after having this shit forcefed on them.
This will finally stop the RMS gnulike neckbears and autists crying baby tiers about proprietary software and maybe Linux can finally move away from being a server OS.
>>42958976
Uh..yeah no. People are just going to fork distros, remove systemd, and carry on with life.
I'll continue to use my systemd free Debian Wheezy for a good long while.
>>42949409
sounds like it should be called a boot system rather than an init system
>>42959507
It is also monitors processes, mounts devices, etc. etc. etc.
All of this is hell. This is why you should help in testing of dbus-api compatible systemd-daemon replacements by OpenBSD.
>>42959507
Or an operating system. That's the goal.
Linus sure has a lot of confidence on Poettering & Co.
>>42959588
operating system allocates system resources, systemd does a lot of things, but it does not do that
yet
>>42955989
systemd is not an init, it just happens to contain one
much like emacs is not a text editor
>>42958155
You can be sure that systemd colonialism is not motivated by charity, benevolence or humanitarianism. Everything has a price.
>>42958310
>http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
>Currently, shipping applications for GNOME is hard.
- Poettering
"Math is hard, let's go shopping!"
- Malibu Stacy
