Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

311–320 of 464 posts

Re: Systemd redux: The end of Linux

#311
post #46

Earlier quoted context omitted.

You mean this Kay Sievers? http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus... - It's basically the buddy of Lennart at Red Hat - at least that is my impression from far away.. systemd may be nice but it's coming from Redhat and cgroups are changed due to because systemd folks wanted it that way as far as I followed that debate...

look at how many people actually contribute to systemd. It's far more than just redhat folks

And if you run gitstats on systemd, you'll see that just 10 people are responsible for over 90% of the code.

Re: Systemd redux: The end of Linux

#312
post #20
post #7

Everything I read about SystemD is negative. Negative on the technology, negative on the people who created it. Nothing positive. How is it that SystemD is about to dominate the market? Who is driving SystemD adoption, and why?

> Everything I read about SystemD is negative May be a bias in action. People who like it, or who really don't care much about it (I dislike journalctl, but, apart from that, I'm mostly OK with it) don't waste time writing how not much changed for them and how things continue to work as expected.

There does appear to be a lot of negativity around systemd, such as people giving out about binary logging. I'm sure there's got to be a way to enable text logging along with binary logging.

This lad seems really enthusiastic about systemd logging and systemctl:

http://0pointer.de/blog/projects/journalctl.html

There are a lot of interesting features, but personally I'd prefer to have both binary and text logging. Text logging is in cases where a system goes tits up and you may only have access to some basic tools such as grep, vi etc.

Re: Systemd redux: The end of Linux

#313
post #245

Earlier quoted context omitted.

Absolutely no idea. It just went away spontaneously which is even more worrying as that suggests the system is non-deterministic. I don't have the error on my phone which I'm on at the moment but it threw a dbus error with no debug info.

It must be a hardware problem on your side, dude. Simple as that. I imagine 10 years ago you would be the person complaining that GCC segfaults randomly during compiling Linux kernel, complaining that it's not "tested completely". While the segfault was caused by CPU overheating (not cooled properly) and flaky memory (causing bits to flip).

Dude, prove it. The system should be able to exonerate itself by detecting and reporting those problems (and other systems do). At the very least, point to some actual evidence. This is the "engineering" process that the parent poster referred to elsewhere.

Just because a problem is unusual, intermittent, or only affects one person doesn't mean it's not a regular old software bug. And in my experience, it almost always is. And once you do debug it, you often (but not always) understand why it was intermittent, under what conditions it happened, and why you were the only person that saw it.

Re: Systemd redux: The end of Linux

#314
post #183

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…

> Systemd is offering a more compelling solution than anyone else, and if you don't like it, well, you should submit a patch, write some code, or implement it yourself. Or go back to using windows for general use and software development which is in fact what I've done. It's amazingly sad after many years of being a strong linux supported but this has killed linux for me. I see no point in continuing to use it.

"Fuck you guys and your cider, I've been drinking ale for years, but now I'm going to only drink my own pee because you like something different"

That's what you sound like.

Re: Systemd redux: The end of Linux

#315

Earlier quoted context omitted.

Wow, great comment -- and one that all who endeavor to innovate in systems should take to heart. As my former colleague Bart Smaalders was fond of saying, "the hardest software to upgrade is the software in our brains"; when inventing new abstraction, it must be done so sparingly and (as much as reasonable) by leveraging extant notions. This isn't merely to allow a technology to be readily understood (though that too…

I think it is a perceived lack of this kind of humility in systemd that has been so alienating for those who have a long history with Unix: it's not as if other approaches are being rejected so much as they are not being considered at all. I really have the feeling that people are using double standards here, especially when suggesting Solaris or Solaris-derived systems. Since systemd is implementing pretty much what…

SMF is a pita - far, far worse than the process management stuff in systemd.

SMF does not seem to want to own every bit of my Linux machine, however.

Re: Systemd redux: The end of Linux

#316

Earlier quoted context omitted.

Wow, great comment -- and one that all who endeavor to innovate in systems should take to heart. As my former colleague Bart Smaalders was fond of saying, "the hardest software to upgrade is the software in our brains"; when inventing new abstraction, it must be done so sparingly and (as much as reasonable) by leveraging extant notions. This isn't merely to allow a technology to be readily understood (though that too…

I think it is a perceived lack of this kind of humility in systemd that has been so alienating for those who have a long history with Unix: it's not as if other approaches are being rejected so much as they are not being considered at all. I really have the feeling that people are using double standards here, especially when suggesting Solaris or Solaris-derived systems. Since systemd is implementing pretty much what…

SMF is a pita - far, far worse than the process management stuff in systemd.

SMF does not seem to want to own every bit of my Linux machine, however.

Re: Systemd redux: The end of Linux

#317
post #58
post #56

Earlier quoted context omitted.

Here's a though: try remembering you don't speak for "sysadmins", you speak for yourself.

I think he speaks for sysadmins. If you are using cgroups at the moment you can write scripts for them. It's a mounted filesystem. The change forces you to use systemd for cgroups as only systemd is able to write to cgroups. The argument is: If you don't like systemd implement an alternative that does this for you. Some for kdbus and udev, netlink... The article is right - it's not Linux as we know it anymore for bet…

> The change forces you to use systemd for cgroups as only systemd is able to write to cgroups. The argument is: If you don't like systemd implement an alternative that does this for you.

And from the looks of it, this has been done: https://cgmanager.linuxcontainers.org/ as reported at http://lwn.net/Articles/618411/

Re: Systemd redux: The end of Linux

#318
post #304

Earlier quoted context omitted.

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.

That's exactly my point. It's not limited to the Linux core team. We divide into working groups of 2-3 people max to avoid this. Works quite well.

Re: Systemd redux: The end of Linux

#319

Earlier quoted context omitted.

You realize that you're just talking in ad hominem circles? You acknowledge that there are reasons that a "reasonable and technically competent person might choose an illumos system"; is it as least possible that someone advocating that choice might not be merely "a random crank on the Internet"? And given that this is potentially a reasonable choice, how does advocating it represent "a very poor grasp of [...] every…

Yes, I find the whole article so full of wrong that I didn't think it needed more than simply calling it "wrong". Though seeing how many upvotes it now has, I guess I was wrong. But, if you insist, let's break it down a bit: "...FreeBSD...also ships with ZFS as part of the kernel and has a jails which is a much more baked technology and implementation than LXC." Which is an assertion that would require significant ci…

"That paragraph clearly is recommending Solaris, specifically."

He says, as he quotes a paragraph that specifically calls out SmartOS and OmniOS -- both of which are under the IllumOS branch of OpenSolaris.

"So, CoreOS is the Linux option he recommends? The same CoreOS that uses SystemD?"

The problem he's raising isn't that linux is going to be different, and if you think it is you need to re-read. Try doing it with your --with-reading-comprehension switch. It being different is just a statement of fact, the problem statement was separate.

CoreOS is not a distribution in the classic sense. It is a platform for deploying containers, and in the use-case they've setup the author clearly believes it will allow you to still be successful in spite of systemd.

Re: Systemd redux: The end of Linux

#320

Earlier quoted context omitted.

Maybe it was a hardware problem on your end? My rule of thumb is "search for the problem on Google. If nothing comes up, maybe something is wrong on my end". Did you find any results or reported bugs similar to what you experienced?

The hardware is known good on CentOS 6.5. In fact it was high end HP kit that we pulled out of production. Yes there were other mentions of it with notes to it being fixed in a later systemd drop, which we can't deploy because RH/CentOS don't ship it. I think one of our guys raised a case with RH but I was dragged off onto something else then.

To be fair, pulseaudio did expose bugs in alsa-drivers, so a "known good" configuration could stop working when "upgraded" to use PA.

I have my share of reservations about systemd (and PA), but thought that it might be worth pointing out that "known good" hardware A with software X, doesn't have to mean hardware A is all good, just that A has no bugs/errors not exposed when running X. So Y comes along (new kernel, drivers?) with entirely new code - and suddenly things behave erratically.

Post reply on HN