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

301–310 of 464 posts

Re: Systemd redux: The end of Linux

#301

Post by badgersandjam »

diltonm wrote: post #290
badgersandjam wrote: post #164

Earlier quoted context omitted.

No it's not just one data point. This is the final straw to use the old phrase. After a few years of serious problems, our most recent being CIFS VFS problems causing panics and mounts locking up on CentOS 6.5, hard locks on RH certified hardware, power management hell and so much incredible churn with no progress and the sudden "fuck POSIX" approach, it paints a really bad picture of the current state of things. The…

Hmm, I don't see any of that, odd isn't it?

Not really odd. You just haven't poked the bits I have.

Re: Systemd redux: The end of Linux

#302

Post by jude- »

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…

> 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 create PID files in it, but when they die, the filesystem automatically removes them.

Code: https://github.com/jcnelson/runfs

Re: Systemd redux: The end of Linux

#303

Post by anonbanker »

davexunit wrote: post #19

I'm quite happy to be a part of the development team for GNU Guix, a distro that is not using systemd. I'm not a systemd hater, but it's definitely not for me and I'm not thrilled with the direction that development is going. It's a shame that sysvinit and friends are so bad that using systemd is the best option we have right now. Maybe GNU dmd will be able to stand up to it someday.

I'm looking forward to switching to Guix as soon as it reaches beta. All this POSIX breakage and LGPL exploitation is making me double down on GNU.

Re: Systemd redux: The end of Linux

#304

Post by jazzyk »

badgersandjam wrote: post #174
devcpp wrote: post #150

Earlier quoted context omitted.

Linux developers are generally very smart people in my experience. It's consensus of many experienced and smart people that makes it significant.

They are individually I agree, but as a group of people it's not such a good story. It's quite dysfunctional from what I've seen.

I can;t comment specifically on the Linux group, but in general you are absolutely correct. As a consultant, I see it daily in my practice. When I talk to people individually, they seem smart/knowledgeable, but as a group, they often make not-so-smart decisions.

Re: Systemd redux: The end of Linux

#305

Post by phkahler »

The description of systemd - monolithic, taking on function of other things - sounds like the X server. Look what's happening now with Wayland, and look at how hard it's been to get there (hint Wayland is only possible as a result of all the driver architecture changes over the last 5-8 years). It's hard to undo this kind of thing once it's entrenched, but it can be done.

Re: Systemd redux: The end of Linux

#306

Post by mbainter »

XorNot wrote: post #180
rythie wrote: post #166

Earlier quoted context omitted.

You can't realistically submit a patch to change the direction that Systemd's is going in. For example, they won't accept a patch which removes 95% of the code, so a more modular system can be built. Submitting a patch, implies you agree with the general direction but need a bug fixed or a feature added.

You can fork it. You can fork all of Debian. But there's numerous reasons that's going nowhere. Most being: this is not the issue the loudest voices say it is.

Forking a distribution will help by giving an alternative, but it's not as easy as just saying it. Maintaining a distribution is a massive effort that takes a lot of work. Building a team of people with enough time to make that happen isn't something you do overnight. The fact that one hasn't magically appeared since this started has more to do with that than anything else. (Followed closely by people generally waiting to see how this shakes out before they pull the trigger.)

Second - while it will provide an alternative that helps frame the debate, this is not a minor undertaking. With every other distribution caving maintaining a distribution that does not use Systemd will require a lot of work to keep all of the software out there working properly with whatever alternative init system it chooses to use.

This alternative distro is also going to have to deal with how to solve the init problem. We had some good options in play but I don't believe we'd found the best answer to the problem yet when Lennart came bowling through like a bull in a china shop. So any distribution effort is going to have to take on the role of choosing the best of breed alternative and make the effort to ensure it continues to develop and improve.

This isn't something you take on lightly.

Re: Systemd redux: The end of Linux

#307

Post by mbainter »

vidarh wrote: post #197
matthewmacleod wrote: post #105

Really bored of this nonsense at this point. Take this for example: If you absolutely MUST run Linux, my recommendation is to minimize the interaction with the base distro as much as possible. CoreOS (when it’s finally baked and production ready) can bring you an LXC based ecosystem Systemd is absolutely key to how CoreOS works. It's the basis for the distributed init system it provides — a major selling point. Takin…

I agree with that specific advice (minimize the interaction with the base distro). I'm on a quest to isolate every major component of my user experience in containers (including things like browser etc.). But not because I have anything against Systemd. I love Systemd so far. It's hilarious that he's proposing CoreOS as an alternative, given that it's one of the most radical rethinks of a Linux distro out there.

For those with reading comprehension skills this isn't funny but rather a natural conclusion. The problem for you is that you're making assumptions about the author that you haven't verified.

The problem here isn't change, or re-thinking linux. The problem is re-inventing the wheel, and doing it poorly.

CoreOS uses systemd, but it's not a distribution in the classic sense -- rather it's a platform for containers. The narrow use-case for systemd here removes some (most? all?) of the concerns.

Re: Systemd redux: The end of Linux

#308

Post by e7620 »

phkahler wrote: post #305

The description of systemd - monolithic, taking on function of other things - sounds like the X server. Look what's happening now with Wayland, and look at how hard it's been to get there (hint Wayland is only possible as a result of all the driver architecture changes over the last 5-8 years). It's hard to undo this kind of thing once it's entrenched, but it can be done.

Look how many platforms X supports, how many paradigm shifts has survived. systemd already has a less flexible architecture by design that an ancient system, so in the future it'll be difficult to untangle.

Re: Systemd redux: The end of Linux

#309

Post by mercurial »

dredmorbius wrote: post #230
mercurial wrote: post #187

Earlier quoted context omitted.

It's an interesting take, but that's not really how software works. Look at Plan9. It isn't POSIX compliant, but it does a lot of things much better than traditional Unix (or nowadays Linux, for that matter). Traditional Unix is not the philosopher's stone. There are plenty of good things about it, but it also comes with a number of dubious design decisions or what is now irrelevant cruft (why are we leaving with cod…

Plan9 is actually a really good example to bring up, for any number of reasons. I have to admit that I've never used it, though I've read bits about it. There are definitely some ideas in there that I'd like to play with and experience. The most important elements to consider about Plan9 are these: 1. Plan9 wasn't Unix (nor was it Linux). It was its own OS, it was absolutely informed by Unix, and tried to learn from…

It seems that folks outside of Red Hat do contribute to systemd, if that's your concern. What I could imagine is that some projects under the systemd umbrella will live an independent life, once things stabilize a bit.

I must admit the ever-growing scope of systemd is starting to concern me somewhat (though I've been running it with satisfaction more or less since it became available in Debian experimental).

Re: Systemd redux: The end of Linux

#310

Post by protomyth »

badgersandjam wrote: post #228
jmnicolas wrote: post #226

Earlier quoted context omitted.

It seems to me that OpenBSD stands for everything you want in OS dev, except maybe point 3, Theo seems really at the center of everything.

You're 100% correct. In fact my own mail server/web machine uses it. Theo is not right at the centre; there's a large group of people who work together as equals from what I can see. I can't recommend it for our "enterprise use" though because we need some of the more friendly features that FreeBSD offers such as ZFS.

I run a mixed environment right now with OpenBSD, FreeBSD, Red Hat, and Windows. I use Red Hat and Windows because certain software requires it (basically they are single app servers[1]). The OpenBSD servers are all doing basic utilities and the FreeBSD servers are doing stuff the requires a big file system (ZFS). There are a lot of enterprise tasks that OpenBSD is fine with doing, and I just use FreeBSD for tasks that require the file system or really heavy load.

1) government contractors are so fun when they get their software required to deal with certain parts of government

Post reply on HN