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
Systemd redux: The end of Linux
311–320 of 464 posts
Re: Systemd redux: The end of Linux
#312Everything 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.
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
#313Earlier 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).
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
#314Perhaps 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.
That's what you sound like.
Re: Systemd redux: The end of Linux
#315Earlier 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 does not seem to want to own every bit of my Linux machine, however.
Re: Systemd redux: The end of Linux
#316Earlier 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 does not seem to want to own every bit of my Linux machine, however.
Re: Systemd redux: The end of Linux
#317Earlier 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…
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
#318Earlier 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.
Re: Systemd redux: The end of Linux
#319Earlier 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…
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
#320Earlier 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.
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.