Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

Post reply on HN
Print view View original

321–330 of 464 posts

Re: Systemd redux: The end of Linux

#321

Post by nyir »

general_failure wrote: post #276
frozenport wrote: post #81

I used Gentoo for 10 years, and I can't figure out how to get a Systemd configuration working with XFCE. Indeed, most of the existing documentation has greatly slowed me down.

Fwiw, my friend runs Ubuntu for 10 years and he cannot understand gentoo for the life of him. He thinks it is absurd people want to keep recompiling stuff.

People don't want to recompile stuff, they want to configure the software to their liking. Basically it's very enjoyable if you're a developer.

And FWIW with Gentoo/Portage you can create and install binary packages.

Re: Systemd redux: The end of Linux

#322

Post by anonbanker »

digi_owl wrote: post #111
simoncion wrote: post #72

Earlier quoted context omitted.

Unless you're ovitters, I never claimed that you claimed that Gnome requires systemd. You did -however- say that "...when Gentoo developers tried integrating OpenRC they ran into too many bugs." Your statement is not true. Stable Gentoo had its default init system switched to OpenRC in mid 2011. OpenRC has been great for Gentoo. "Apparently GDM 3.8 assumes that an init system will also clean up any processes it start…

I find myself reminded of a poster at a school toilet: "your mother does not work here, clean up after yourself".

When unable to provide a cogent response, a parable will be a sufficient substitute.

Re: Systemd redux: The end of Linux

#323

Post by jerven »

jude- wrote: post #302
jerven wrote: post #256

Earlier quoted context omitted.

Simple one PID files. Assume server with lots of processes. Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA. etc... Clean unm…

> Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA. I created a specialized FUSE filesystem to deal with this. Processes creat…

Nice to see a different solution than cgroups for this

The Readme is rather sparse, could you add an example how to use it from a init shell script?

Re: Systemd redux: The end of Linux

#324

Post by zobzu »

jude- wrote: post #38
zobzu wrote: post #32

Earlier quoted context omitted.

you dont have to use journald. you can send back from journald to syslog (eg rsyslog) and that works well/its easy to do. You can even disable the journald logging itself and just have rsyslog (or the logger of your choice). at my place we kept both journald and have rsyslog to redirect logs to the network. ie our /var/log is relatively empty (rsyslog isnt setup to log to disk) so we look at log on the machine via jo…

> you dont have to use journald. you can send back from journald to syslog That's a contradiction. You're running journald even if it's dead weight.

Technically its really just a socket dup

Re: Systemd redux: The end of Linux

#325

Post by justincormack »

seivadmas wrote: post #244
badgersandjam wrote: post #95

Earlier quoted context omitted.

I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never l…

You know this is funny, I remember reading comments EXACTLY like this about 3-4 years ago but with pulseaudio in place of systemd. Pulseaudio was Lennart's previous project. It broke everything in linux sound for a while, everybody moaned and hated it and said it was the worst thing since the crucifixion of Christ. Yet, name one problem you had with sound on linux in the past year? There are very few. Pulseaudio now…

Audio in my Lenovo with Ubuntu is completely erratic. Not going to blame this on Lennart, but it is certainly not a fixed problem. I liked Alsa, though I was working with high end hardware at that point.

Re: Systemd redux: The end of Linux

#327

Post by e12e »

dschiptsov wrote: post #232

Going against the "divide et impera" principle, "do just one thing, and do it well", "everything is a text file" (configurations and logs) and "pipes" which are very natural idiom, in a UNIX-like system which has been built upon these principles , is just bad engineering, shallow understanding and, perhaps, too high ambitions of knowing better how to fix what isn't broken. The question why do we have this project and…

I don't support a switch to systemd at this time (I use Debian, and I'd be happy to live with pretty much any other init system for at least one more release - the obvious choice would be to just stick to systemV init, and see what systemd looks like in a year or so. Down side is that if the distro were to move (for supporting all those people that want Gnome for some reason ;-) -- then we loose out on a year or two of testing systemd).

Anyway:

> Most of the problems systemd is trying to "solve" does not exist. At least not BSD, AIX, Solaris, you name it.

Don't forget that (open) Solaris revamped the init system, not just the disk/filesystem-system. I think there are arguments to be made for integrated systems like the zones/zfs/SMF.

I don't think systemd is a reasonable way to go about it, and I certainly don't think it is a good fit for "Linux in general". My impression is: Systemd is too big -- will fail.

Wasn't it Gnome that at one time tried to mimic the windows registry for settings (because binary data on disk: really fast, lol) -- only to go back to ini-style files? (I might be misremembering that one).

Different designs are fine (see: eg plan9) -- but moving away from fundamental design principles (everything is a (text) file) effectively means abandoning the old system, making a new system.

If systemd was a bit more upfront about "making a new operating system sharing some code with Linux kernel and traditional userland" - rather than trying to sell systemd as "more of the same, just better" -- maybe they'd meet with more positive reception. That a new system is unstable is fine -- just don't expect people to use your new crap in production.

Re: Systemd redux: The end of Linux

#328

Post by justincormack »

jerven wrote: post #256
e40 wrote: post #227

Earlier quoted context omitted.

it's fixing some longstanding bugs with sysvinit Honest question: I've been using sysvinit for a very long time and I have no concept of what those bugs might be.

Simple one PID files. Assume server with lots of processes. Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA. etc... Clean unm…

I still think 64 bit non reused pids are the best long term solution. There are other pid race conditions. (Not having pid files deleted on reboot is a different issue of course).

Although the Capsicum model (in FreeBSD, slowly getting into Linux) where you can have file descriptors for processes is another different model.

Re: Systemd redux: The end of Linux

#329

Post by wtallis »

morganvachon wrote: post #267

I think the article got one thing wrong: That sooner or later every GNU/Linux distro will switch to systemd. I can think of three that most likely will not: Slackware, Crux, and Gentoo. Granted, the more that systemd binds itself to formerly modular userspace utilities and apps, the more pressure on those distros to make the switch, or else either fork every systemd userspace app at the risk of being left behind. But…

I'm also interested to see how things play out with OpenWRT. High-end home routers are starting to get a lot more powerful with the transition to ARM SoCs and NAND flash, but they won't be able to run any software that depends on the systemd ecosystem while OpenWRT is still supporting the massive install base of hardware that systemd can't fit on.

Re: Systemd redux: The end of Linux

#330

Post by SEJeff »

hwh wrote: post #114
zackelan wrote: post #98

Earlier quoted context omitted.

I completely agree with you that Lennart scratched an itch, which is the way all good software gets started, and others picked up on it. Where I think the systemd-naysayers have a valid point is around the tight coupling that has been introduced, and is still being introduced, between systemd and various other components of a fully functional Linux system. To take your "just submit a patch" example - say N years from…

Well, the very distro-specific bunch of scripts in /etc/init.d (or is it /etc/rc.d/init.d/? or /etc/rc.d? or a symlink to ...?) were some kind of tight coupling, too. Plus: This tight coupling did not exactly replace existing communication features. It created new ones. These are made use of. Yes, systemd is bringing lots of new functionality. Under the hood - that is why sysadmins love or loathe it and users mostly…

You forgot /etc/init (upstart) :)
Post reply on HN