|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Home | 2020 | 2019 | 2018 | 2017 | 2016 | 2015 |
For the list of top articles see Recommended Links section
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
Dec 11, 2017, linux.slashdot.org )
 |
 |
 |
Dec 16, 2018 | linux.slashdot.org
ArchieBunker ( 132337 ) , Tuesday October 30, 2018 @07:00PM ( #57565233 ) HomepageNew features include ( Score: 5 , Funny)All of
/etc has been moved to a flat binary database now called REGISTRY.DAT A new configuration tool known as regeditor authored by Poettering himself (accidental deletion of
/home only happens in rare occurrences) In kernel naughty words filter
systemd now includes a virtual userland previously known as busybox
|
|
|
Dec 16, 2018 | lkml.org
Date Tue, 12 Aug 2014 15:38:12 -0400 From Christopher Barry <> Subject OT: Open letter to the Linux World
|
|
|
Dec 16, 2018 | linux.slashdot.org
Futurepower(R) ( 558542 ) writes: < MJennings.USA@NOT_any_of_THISgmail.com > on Tuesday October 30, 2018 @07:38PM ( #57565447 ) HomepageQuestions: 1) SystemD? 2) Effect on IBM? ( Score: 4 , Interesting)SystemD:
Linux: Why do people hate systemd? [infoworld.com] (Jan 18, 2017 )
List of articles critical of systemd [without-systemd.org]
Introducing SystemD without proper extended community discussion seemed to be a way for Red Hat to make money. Problems with SystemD? Pay Red Hat to help.
IBM:
What will be the effect of SystemD on IBM's reputation? Will SystemD damage IBM's reputation? Does IBM see SystemD as a way to make money? Will IBM be as socially dis-functional as Red Hat?
|
|
|
Oct 20, 2015 | forums.funtoo.org
Posted October 20, 2015 I'm still not seeing all these benefits that I'm supposed to have. You took away the little bit of programmability I had with the shell and gave me back a config file and told me its for my own good and now I have to go learn all these new stuff from shifty documentation.
- Advanced Member
- Location: Dallas, TX USA
I never had a problem finding my boot logs. I do have a problem with systemd not letting me get to a true single user mode where I can fsck my partitions, let alone the root partition.
Seriously, exactly what benefit do I get? And don't point me to a website. I've read the propoganda, but in practice, its not there. Instead I have a 1.6MB init instead of the old 36K init, and a directory full of tools (all in the hundreds of K). And I hear I need DBUS just to start a service .... cause I need more dependencies in my startup?
Really, the small program mindset worked for Unix for the same reason OOP works, and why bastardizations of that philosophy are destroying computing. Encapsulation. With small binaries communicating through pipes the kernel enforces encapsulation and your API is stdin/stdout. Breaking encapsulation and enforcing dependencies is WRONG and systemd is all about enforced dependencies. I've been doing this too long not to see that this is a formula for a brittle system.
For what benefit?
I want LESS to break! KISS!
More about me at https://eddon.systems
|
|
|
Dec 11, 2018 | www.ianwelsh.net
S Brennan permalink April 24, 2016
My grandfather, in the early 60's could board a 707 in New York and arrive in LA in far less time than I can today. And no, I am not counting 4 hour layovers with the long waits to be "screened", the jets were 50-70 knots faster, back then your time was worth more, today less.
Not counting longer hours AT WORK, we spend far more time commuting making for much longer work days, back then your time was worth more, today less!
Software "upgrades" require workers to constantly relearn the same task because some young "genius" observed that a carefully thought out interface "looked tired" and glitzed it up. Think about the almost perfect Google Maps driver interface being redesigned by people who take private buses to work. Way back in the '90's your time was worth more than today!
Life is all the "time" YOU will ever have and if we let the elite do so, they will suck every bit of it out of you.
|
|
|
May 29, 2016 | news.ycombinator.com
gpvos on May 29, 2016 Salient comment: "Or somebody could go find the actual problem @keszybz saw here - systemd/systemd#3005 - which is: In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly. fix that, and stop trying to make systemd break the world because somebody's gnome session doesn't currently exit cleanly."
IshKebab on May 29, 2016 Wait are you saying we should rely on processes behaving nicely? That's not how you design a robust system. It's why we have pre-emptive multitasking, not co-operative. And why mobile OSes sandbox applications rather than trusting them to be good.
danudey on May 29, 2016 [-]
Not that we should rely on processes to behave nicely, but that we shouldn't break processes which are because of some which aren't .In particular, if Gnome is starting a ton of background processes that stick around and cause problems, then the fix should be to change Gnome, not to change the default behaviour and break everyone else.
To use the OS sandbox example, this is the reason why OS X added application sandboxing and forced Mac App Store apps to use it, and not anyone else . Systemd's approach is like Apple saying "We're going to start sandboxing everyone's apps, App Store or no, unless you make these changes to your apps.
jfoks on May 30, 2016 [-]
Systemd is the hammer and the problem looks like a nail to the systemd developers.In this case systemd seems to be reinventing process groups, in a totally different way, instead of fixing whatever the reason is why GUI sessions don't use session leaders.
So it's pretty obvious there really is a problem that needs to be fixed, and apparently so far nobody else has made a real or successful attempt to do so.
anonymousab on May 29, 2016 [-]
SIP seemed like an overture in that direction.tremon on May 29, 2016 [-]
I think you're missing the point. Systemd is papering over bugs in other software , and in doing so manages to break unrelated applications.No, we shouldn't need to rely on processes behaving nicely. But when a program is broken, you fix that program, not change the entire system's semantics.
thwarted on May 29, 2016 Not to mention that, with a new interface to keep things running after logout, nothing is going to stop something else misusing that, either purposely or accidentally, to remain running, and we end up right back where we started.
Interestingly enough, none of the bugs in other software that is being papered over are in closed source, so it's not like the original issues are unaddressable in the most direct way possible.
gcb0 on May 29, 2016
I'm not sure I understand, but it seems that systemd is correctly killing processes when the session ends. and that shell managers like screen and tmux had hacks to make them survive sessions ends in the past (remember when you had to use nohup screen?). they seem to simply have asked for tmux to add their flavor of nohup to the start up check too.danudey on May 29, 2016 It depends on what you mean by 'correctly'.
Processes using daemon(3) have been around for 21 years, and are used to certain behaviour. Some of those processes behave badly.
systemd is adding functionality to kill all of a user's process when the session ends, no matter what. The problem is that they don't have any way of telling which processes are behaving badly and which ones aren't, so they're telling everyone (e.g. tmux, screen, etc) that they have to implement changes or they'll be killed too.
Fundamentally, the problem isn't whether the systemd behaviour is right , the problem is that it's a huge breaking change and they're asking everyone else to work around the shortcomings of their approach.
> shell managers like screen and tmux had hacks to make them survive sessions ends in the past
tmux, screen, etc. didn't have hacks to survive sessions; they just did, automatically, because of how things worked. systemd is asking the to add hacks to make them survive session ends from now on, when running specifically on Linux under systemd 230+, because systemd is going to change default behaviour for other people's processes .
justinsaccount on May 29, 2016 [-] > systemd is adding functionality to kill all of a user's process when the session ends
They actually added the functionality over 5 years ago. Which is when the tmux project was approached to accept a patch to support pam (not systemd) in order to not be killed.
http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux
All they did recently was try to change the default configuration to enable the feature by default.
JdeBP on May 29, 2016 [-]
... as well as, as pointed out twice on this page, not answer in all those years the question that Nicholas Marriott posed about why they are not pushing this at GNU libc, so that everyone can benefit from a better daemon() function that escapes the systemd login session as well as the kernel's login session.> Shouldn't this code be part of glibc instead of tmux? -- Nicholas Marriott, 2011
> If you want to change how processes daemonize, why don't you change how daemon() is implemented [...] ? -- Nicholas Marriott, 2016
justinsaccount on May 29, 2016 [-]
Tomorrows systemd hate post:Systemd developer asks libc to add systemd specific code
JdeBP on May 30, 2016 [-]
That's just unfounded silliness. There's no reason to suppose that, and plenty of reason (given that they've actually had systemd-specific stuff, such as subreapers, fairly uncontroversially put into the kernel in years gone past) not to.justinsaccount on May 30, 2016 [-]
It may be silly, but I think there is plenty of reason to think that if systemd developers proposed adding systemd support to daemon(3) there would be an even larger negative response.This whole comment thread is about an optional feature that has existed for 5 years and only recently had its default value changed. You are not affected unless you are running a bleeding edge distribution that has already upgraded to a version of systemd released 5 days ago.
I don't think a more long term solution will present itself in the near future and most likely what will happen is that the default will get changed back to disabled.
MereInterest on June 1, 2016 [-]
This feature has its place in some cases. For example, a public terminal that wants to make sure that users didn't leave anything running. I'm fine with this feature existing. I'm not okay with it becoming the default option. Changing the default behavior implies some endorsement of it for general use, not just in special cases.raverbashing on May 29, 2016 [-]
I would suggest you learn something about Unix before spousing such opinions, because I don't know where to even beginnohup is not a hack
What systemd is offering has nothing to do with nohup, it's not "a flavour" of nohup it's a completely different thing
Systemd is not correctly killing processes, this was NEVER DONE LIKE THIS, they decided this out of a whim because apparently Gnome can't do the right thing (how surprising)
LnxPrgr3 on May 30, 2016 [-]
Heh--it's like nohup(/daemom), except you make a SOAP call through some middleware to beg some more middleware for mercy so you can do the thing your user asked you to do, because everyone's being punished for a few programs' poor use of the old, more portable API. (I exaggerate, slightly.)I'm not looking forward to what comes next when Gnome breaks through the new system.
ASalazarMX on May 30, 2016 [-]
I prefer to keep the mystery and not know all about my opinions from the start. It's the small discoveries that keep the flame of love alight in our marriage.aidenn0 on May 29, 2016 [-]
I do not want systemd to kill processes that have invoked daemon() on session termination. If I wanted it to be killed when I logged out, I wouldn't have invoked daemon()!gaius on May 29, 2016 [-]
When the process is as baked in as systemd wants to be, you have literally no choice but to rely on it behaving nicely. And unfortunately it mirrors the attitude of its developers/sponsors.Twirrim on May 29, 2016 [-]
I don't understand why Redhat is continuing to sponsor work that is desktop focussed and toxic or even flat out breaking the server environment. The latter is their bread and butter. I get that you want to make the desktop a better experience, but you don't do that by breaking your revenue stream and affecting everyone outside your company too that gets lumbered with your stack.MertsA on May 29, 2016 [-]
Robust process management is even more important in server environments. As a sysadmin, systemd is very very useful in my job and it's the building block of things like CoreOS and the like.thwarted on May 29, 2016 [-]
This wording, which appears frequently in defense of whatever changes systemd forces on the Linux ecosystem as a whole, implies that systemd is some kind of savior providing features that are neither offered nor considered anywhere else.As a sysadmin for over 20 years, systemd offers nothing significantly new or different in the areas of process management than any of the other methods to do so, most of which are less intrusive.
A single tool providing a building block for an isolated, specific project says nothing about the general applicability or desirablity of that tool to the wider ecosystem.
dsr_ on May 29, 2016 [-]
Less intrusive and play better with other systems, because they don't believe that they are The Way, The Truth and The Life.thwarted on May 29, 2016 [-]
And this is where I'm most uncomfortable with so many of the ways systemd wants things to be done. So much of what systemd provides could have been done with minimal changes to init and by offering better alternatives than what was there. Uptake might have been slower as people learn, over time, where the new system offers something better. It's not offered as "hey, here's a different way to think about things that you might like, give a try!", it's offered as "everything else is broken, and you need to do it this way right now in order!".emp_zealoth on May 30, 2016 [-]
Except, you've got people squabbling over their tiny patches of turf and hurt feelings instead To me systemd is determined to unfuck linux, despite it screaming and kicking. Yes, it does some stuff that is questionable, but if it wasn't religiously hated just because it dares to step on "someones" turf...People bitch about PulseAudio still and it was what made the fucking sound plug and play instead of massive mess
thwarted on May 30, 2016 [-]
Taking the position that linux needs to be unfucked is saying that it was/is fucked, and that systemd is the Savior that will unfuck it. Many people don't beleive that. But that they don't beleive linux is fucked doesn't mean they think it is perfect, because they know nothing can be. And while it is worthwhile to still strive for perfection, you don't do that by shitting all over what people know, their experience, blaming them for problems they didn't create, and making them do extra work. Especially when they are volunteers.Twirrim on May 30, 2016 [-]
> People bitch about PulseAudio still and it was what made the fucking sound plug and play instead of massive messPulseAudio is still a massive mess. It solved a tiny subset of surface level problems, eventually, and introduced a whole crap load of other ones in the process.
PulseAudio has been around, what, 10 years now, give or take? I think I've only stopped having to fight with it in the last couple of years. When it first landed it was by no means an improvement from OSS, and it took a while until it could realistically compete. It brought a bunch of advantages with it, but it was far from easy.
If you want to see a fun example of how annoying PulseAudio can still be, try and make a linux machine act as a bluetooth audio receiver. It takes only a couple of minutes work installing and configuring the bluetooth side of things. The PulseAudio side of things will suck up hours of your time trying to persuade it to be consistent, running through a godawful series of inconsistent command lines.
It's pretty clear that systemd is determined to unfuck the linux desktop experience. They're not solving problems that exist on the server side. When you look at the justifications for various bits of really breaking stuff, it's almost always (as in this case) coming down to something related to the desktop experience. They've futzed about with stuff, breaking things along the way, because it "speeds up boot." How often do you reboot your servers, and does it really matter that it's 20 seconds quicker?
The goal is admirable (The linux desktop can be a crappy experience, I've been using it as my primary work environment for pushing on 10 years now, and using it in general for closer to 15.) The methodology is not, nor is the attitude of the developers. They continue to approach problems from the perspective of "we know best", "not invented here" and "The only fix is a ground up re-write". Along the way they're making the exact same mistakes existing stable and mature software made decades ago. Worse, they're breaking things that really shouldn't be broken and they're betraying a complete lack of understanding about how linux is run in production environments. This particular case is a perfect example. They've decided that processes should be reaped on all systems, in all environments, when users log off. Not because this was a particular problem anywhere, but because some processes weren't being cleanly stopped when someone logged out of Gnome. It's fixing a minor desktop issue, something that doesn't affect the large majority of the user base, in a fashion that breaks what a large majority of the people actually do.
Here's another classic example: http://www.spinics.net/lists/netdev/msg365477.html systemd developers decided that the way IPv6 route advertisement was processed in the kernel was wrong (despite having been fully functional and stable for a long, long time), and decided that they really should do it themselves in an incorrect fashion.
At its core, the *nix environments core strength has always been that it's composable, focusing on complect over complex behaviour, creating a cohesive whole out of individual and specialised components that have specific tasks. You take a similar when writing software applications. Just as with writing software and using libraries, you use the ones that meet your requirements the best. This flexibility allows people to build platforms and infrastructure that does what they need, and allows people to solve issues developers couldn't have anticipated in the first place.
Systemd's approach is instead a highly opinionated and inflexible "this is the way things will be". It's likely a perfect approach for a desktop environment, but that's not where it's being restricted to. The primary consuming environment is servers where they're 'fixing' things that weren't broken there in the first place.
|
|
|
Nov 18, 2018 | theregister.co.uk
fobobob , Thursday 10th May 2018 18:00 GMT
Might just be a Debian thing as I haven't looked into it, but I have enough suspicion towards systemd that I find it worth mentioning. Until fairly recently (in terms of Debian releases), the default configuration was to murder a user's processes when they log out. This includes things such as screen and tmux, and I seem to recall it also murdering disowned and NOHUPed processes as well.Tim99 , Thursday 10th May 2018 06:26 GMTHow can we make money?ds6 , 6 monthsA dilemma for a Really Enterprise Dependant Huge Applications Technology company - The technology they provide is open, so almost anyone could supply and support it. To continue growing, and maintain a healthy profit they could consider locking their existing customer base in; but they need to stop other suppliers moving in, who might offer a better and cheaper alternative, so they would like more control of the whole ecosystem. The scene: An imaginary high-level meeting somewhere - The agenda: Let's turn Linux into Windows - That makes a lot of money:-
Q: Windows is a monopoly, so how are we going to monopolise something that is free and open, because we will have to supply source code for anything that will do that? A: We make it convoluted and obtuse, then we will be the only people with the resources to offer it commercially; and to make certain, we keep changing it with dependencies to "our" stuff everywhere - Like Microsoft did with the Registry.
Q: How are we going to sell that idea? A: Well, we could create a problem and solve it - The script kiddies who like this stuff, keep fiddling with things and rebooting all of the time. They don't appear to understand the existing systems - Sell the idea they do not need to know why *NIX actually works.
Q: *NIX is designed to be dependable, and go for long periods without rebooting, How do we get around that. A: That is not the point, the kids don't know that; we can sell them the idea that a minute or two saved every time that they reboot is worth it, because they reboot lots of times in every session - They are mostly running single user laptops, and not big multi-user systems, so they might think that that is important - If there is somebody who realises that this is trivial, we sell them the idea of creating and destroying containers or stopping and starting VMs.
Q: OK, you have sold the concept, how are we going to make it happen? A: Well, you know that we contribute quite a lot to "open" stuff. Let's employ someone with a reputation for producing fragile, barely functioning stuff for desktop systems, and tell them that we need a "fast and agile" approach to create "more advanced" desktop style systems - They would lead a team that will spread this everywhere. I think I know someone who can do it - We can have almost all of the enterprise market.
Q: What about the other large players, surely they can foil our plan? A: No, they won't want to, they are all big companies and can see the benefit of keeping newer, efficient competitors out of the market. Some of them sell equipment and system-wide consulting, so they might just use our stuff with a suitable discount/mark-up structure anyway.
Re: How can we make money?DougS , Thursday 10th May 2018 07:30 GMTThis is scarily possible and undeserving of the troll icon.
Harkens easily to non-critical software developers intentionally putting undocumented, buggy code into production systems, forcing the company to keep the guy on payroll to keep the wreck chugging along.
Init did need fixing-tim , Thursday 10th May 2018 07:33 GMTBut replacing it with systemd is akin to "fixing" the restrictions of travel by bicycle (limited speed and range, ending up sweaty at your destination, dangerous in heavy traffic) by replacing it with an Apache helicopter gunship that has a whole new set of restrictions (need for expensive fuel, noisy and pisses off the neighbors, need a crew of trained mechanics to keep it running, local army base might see you as a threat and shoot missiles at you)
Too bad we didn't get the equivalent of a bicycle with an electric motor, or perhaps a moped.
Those who do not understand Unix are condemned to reinvent it, poorly.Herby , Thursday 10th May 2018 07:42 GMT"It sounds super basic, but actually it is much more complex than people think," Poettering said. "Because Systemd knows which service a process belongs to, it can shut down that process."
Poettering and Red Hat,
Please learn about "Process Groups"
Init has had the groundwork for most of the missing features since the early 1980s. For example the "id" field in /etc/inittab was intended for a "makefile" like syntax to fix most of these problems but was dropped in the early days of System V because it wasn't needed.
Process 1 IS complicated.Chronos , Thursday 10th May 2018 09:12 GMTThat is the main problem. With different processes you get different results. For all its faults, SysV init and RC scripts was understandable to some extent. My (cursory) understanding of systemd is that it appears more complicated to UNDERSTAND than the init stuff.
The init scripts are nice text scripts which are executed by a nice well documented shell (bash mostly). Systemd has all sorts of blobs that somehow do things and are totally confusing to me. It suffers from "anti- kiss "
Perhaps a nice book could be written WITH example to show what is going on.
Now let's see does audio come before or after networking (or at the same time)?
LoggingTinslave_the_Barelegged , Thursday 10th May 2018 11:29 GMTIf they removed logging from the systemd core and went back to good ol' plaintext syslog[-ng], I'd have very little bad to say about Lennart's monolithic pet project. Indeed, I much prefer writing unit files than buggering about getting rcorder right in the old SysV init.
Now, if someone wanted to nuke pulseaudio from orbit and do multiplexing in the kernel a la FreeBSD, I'll chip in with a contribution to the warhead fund. Needing a userland daemon just to pipe audio to a device is most certainly a solution in search of a problem.
Re: Logging> If they removed logging from the systemd core
And time syncing
And name resolution
And disk mounting
And logging in
...and...
|
|
|
Nov 18, 2018 | theregister.co.uk
tekHedd , Thursday 10th May 2018 15:28 GMT
Not UNIX-like? SNU!From now on, I will call Systemd-based Linux distros "SNU Linux". Because Systemd's Not Unix-like.
It's not clever, but it's the future. From now on, all major distributions will be called SNU Linux. You can still freely choose to use a non-SNU linux distro, but if you want to use any of the "normal" ones, you will have to call it "SNU" whether you like it or not. It's for your own good. You'll thank me later.
|
|
|
Nov 18, 2018 | theregister.co.uk
jake , Thursday 10th May 2018 20:23 GMT
Re: Bah!Nice rant. Kinda.
However, I don't recall any major agreement that init needed fixing. Between BSD and SysV inits, probably 99.999% of all use cases were covered. In the 1 in 100,000 use case, a little bit of C (stand alone code, or patching init itself) covered the special case. In the case of Slackware's SysV/BSD amalgam, I suspect it was more like one in ten million.
So in all reality, systemd is an answer to a problem that nobody had. There was no reason for it in the first place. There still isn't a reason for it ... especially not in the 999,999 places out of 1,000,000 where it is being used. Throw in the fact that it's sticking its tentacles[0] into places where nobody in their right mind would expect an init as a dependency (disk partitioning software? WTF??), can you understand why us "old guard" might question the sanity of people singing it's praises?
[0] My spall chucker insists that the word should be "testicles". Tempting ...
|
|
|
Nov 18, 2018 | theregister.co.uk
sisk , Thursday 10th May 2018 21:17 GMT
It's a pretty polarizing debate: either you see Systemd as a modern, clean, and coherent management toolkitDazed and Confused , Thursday 10th May 2018 21:43 GMTVery, very few Linux users see it that way.
or an unnecessary burden running roughshod over the engineering maxim: if it ain't broke, don't fix it.
Seen as such by 90% of Linux users because it demonstrably is.
Truthfully Systemd is flawed at a deeply fundamental level. While there are a very few things it can do that init couldn't - the killing off processes owned by a service mentioned as an example in this article is handled just fine by a well written init script - the tradeoffs just aren't worth it. For example: fscking BINARY LOGS. Even if all of Systemd's numerous other problems were fixed that one would keep it forever on my list of things to avoid if at all possible, and the fact that the Systemd team thought it a good idea to make the logs binary shows some very troubling flaws in their thinking at a very fundamental level.
Re: fscking BINARY LOGS.Nate Amsden , Thursday 10th May 2018 23:51 GMTAnd config too
When it comes to logs and config file if you can't grep it then it doesn't belong on Linux/Unix
Re: fscking BINARY LOGS.Tomato42 , Saturday 12th May 2018 08:26 GMTWRT grep and logs I'm the same way which is why I hate json so much. My saying has been along the lines of "if it's not friends with grep/sed then it's not friends with me". I have whipped some some whacky sed stuff to generate a tiny bit of json to read into chef for provisioning systems though.
XML is similar though I like XML a lot more at least the closing tags are a lot easier to follow then trying to count the nested braces in json.
I haven't had the displeasure much of dealing with the systemd binary logs yet myself.
Re: fscking BINARY LOGS.HieronymusBloggs , Saturday 12th May 2018 18:17 GMT> I haven't had the displeasure much of dealing with the systemd binary logs yet myself.
"I have no clue what I'm talking about or what's a robust solution but dear god, that won't stop me!" – why is it that all the people complaining about journald sound like that?
systemd works just fine with regular syslog-ng, without journald (that's the thing that has binary logs) in sight
Re: fscking BINARY LOGS.sisk , Tuesday 15th May 2018 20:22 GMT"systemd works just fine with regular syslog-ng, without journald (that's the thing that has binary logs) in sight"
Journald can't be switched off, only redirected to /dev/null. It still generates binary log data (which has caused me at least one system hang due to the absurd amount of data it was generating on a system that was otherwise functioning correctly) and consumes system resources. That isn't my idea of "works just fine".
""I have no clue what I'm talking about or what's a robust solution but dear god, that won't stop me!" – why is it that all the people complaining about journald sound like that?"
Nice straw man. Most of the complaints I've seen have been from experienced people who do know what they're talking about.
Anonymous Coward , Thursday 10th May 2018 22:30 GMTRe: fscking BINARY LOGS."I have no clue what I'm talking about or what's a robust solution but dear god, that won't stop me!" – why is it that all the people complaining about journald sound like that?
I have had the displeasure of dealing with journald and it is every bit as bad as everyone says and worse.
systemd works just fine with regular syslog-ng, without journald (that's the thing that has binary logs) in sight
Yeah, I've tried that. It caused problems. It wasn't a viable option.
cjcox , Thursday 10th May 2018 22:33 GMTParking U$5bn in redhad for a few months will fix this...So it's now been 4 years since they first tried to force that shoddy desk-top init system into our servers? And yet they still feel compelled to tell everyone, look it really isn't that terrible. That should tell you something. Unless you are tone death like Redhat. Surprised people didn't start walking out when Poettering outlined his plans for the next round of systemD power grabs...
Anyway the only way this farce will end is with shareholder activism. Some hedge fund to buy 10-15 percent of redhat (about the amount you need to make life difficult for management) and force them to sack that "stable genius" Poettering. So market cap is 30bn today. Anyone with 5bn spare to park for a few months wanna step forward and do some good?
He's a painDaggerchild , Friday 11th May 2018 08:27 GMTEarly on I warned that he was trying to solve a very large problem space. He insisted he could do it with his 10 or so "correct" ways of doing things, which quickly became 20, then 30, then 50, then 90, etc.. etc. I asked for some of the features we had in init, he said "no valid use case". Then, much later (years?), he implements it (no use case provided btw).
Interesting fellow. Very bitter. And not a good listener. But you don't need to listen when you're always right.
Spherical wheel is superior.Tomato42 , Saturday 12th May 2018 09:05 GMT@T42
Now, you see, you just summed up the whole problem. Like systemd's author, you think you know better than the admin how to run his machine, without knowing, or caring to ask, what he's trying to achieve. Nobody ever runs a computer, to achieve running systemd do they.
Re: Spherical wheel is superior.Kabukiwookie , Monday 14th May 2018 00:14 GMTI don't claim I know better, but I do know that I never saw a non-distribution provided init script that handled correctly the basic of corner cases – service already running, run file left-over but process dead, service restart – let alone the more obscure ones, like application double forking when it shouldn't (even when that was the failure mode of the application the script was provided with). So maybe, just maybe, you haven't experienced everything there is to experience, so your opinion is subjective?
Yes, the sides of the discussion should talk more, but this applies to both sides. "La, la, la, sysv is working fine on my machine, thankyouverymuch" is not what you can call "participating in discussion". So is quoting well known and long discussed (and disproven) points. (and then downvoting people into oblivion for daring to point this things out).
now in the real world, people that have to deal with init systems on daily basis, as distribution maintainers, by large, have chosen to switch their distributions to systemd, so the whole situation I can sum up one way:
"the dogs may bark, but the caravan moves on"
Re: Spherical wheel is superior.Daggerchild , Monday 14th May 2018 14:10 GMTI do know that I never saw a non-distribution provided init script that handled correctly the basic of corner cases – service already running
This only shows that you don't have much real life experience managing lots of hosts.
like application double forking when it shouldn't
If this is a problem in the init script, this should be fixed in the init script. If this is a problem in the application itself, it should be fixed in the application, not worked around by the init mechanism. If you're suggesting the latter, you should not be touching any production box.
"La, la, la, sysv is working fine on my machine, thankyouverymuch" is not what you can call "participating in discussion".
Shoving down systemd down people's throat as a solution to a non-existing problem, is not a discussion either; it is the very definition of 'my way or the highway' thinking.
now in the real world, people that have to deal with init systems on daily basis
Indeed and having a bunch of sub-par developers, focused on the 'year of the Linux desktop' to decide what the best way is for admins to manage their enterprise environment is not helping.
"the dogs may bark, but the caravan moves on"
Indeed. It's your way or the highway; I thought you were just complaining about the people complaining about systemd not wanting to have a discussion, while all the while it's systemd proponents ignoring and dismissing very valid complaints.
Re: Spherical wheel is superior.Anonymous Coward , Friday 11th May 2018 17:27 GMT"I never saw ... run file left-over but process dead, service restart ..."
Seriously? I wrote one last week! You use an OS atomic lock on the pidfile and exec the service if the lock succeeded. The lock dies with the process. It's a very small shellscript.
I shot a systemd controlled service. Systemd put it into error state and wouldn't restart it unless I used the right runes. That is functionally identical to the thing you just complained about.
"application double forking when it shouldn't"
I'm going to have to guess what that means, and then point you at DJB's daemontools. You leave a FD open in the child. They can fork all they like. You'll still track when the last dies as the FD will cause an event on final close.
"So maybe, just maybe, you haven't experienced everything there is to experience"
You realise that's the conspiracy theorist argument "You don't know everything, therefore I am right". Doubt is never proof of anything.
"La, la, la, sysv is working fine" is not what you can call "participating in discussion".
Well, no.. it's called evidence. Evidence that things are already working fine, thanks. Evidence that the need for discussion has not been displayed. Would you like a discussion about the Earth being flat? Why not? Are you refusing to engage in a constructive discussion? How obstructive!
"now in the real world..."
In the *real* world people run Windows and Android, so you may want to rethink the "we outnumber you, so we must be right" angle. You're claiming an awful lot of highground you don't seem to actually know your way around, while trying to wield arguments you don't want to face yourself...
"(and then downvoting people into oblivion for daring to point this things out)"
It's not some denialist conspiracy to suppress your "daring" Truth - you genuinely deserve those downvotes.
I have no idea how or why systemd ended up on servers. Laptops I can see the appeal for "this is the year of the linux desktop" - for when you want your rebooted machine to just be there as fast as possible (or fail mysteriously as fast as possible). Servers, on the other hand, which take in the order of 10+ minutes to get through POST, initialising whatever LOM, disk controllers, and whatever exotica hardware you may also have connected, I don't see a benefit in Linux starting (or failing to start) a wee bit more quickly. You're only going to reboot those beasts when absolutely necessary. And it should boot the same as it booted last time. PID1 should be as simple as possible.I only use CentOS these days for FreeIPA but now I'm questioning my life decisions even here. That Debian adopted systemd too is a real shame. It's actually put me off the whole game. Time spent learning systemd is time that could have been spent doing something useful that won't end up randomly breaking with a "will not fix" response.
Systemd should be taken out back and put out of our misery.
|
|
|
Nov 18, 2018 | theregister.co.uk
Nate Amsden , Thursday 10th May 2018 16:34 GMT
as a linux user for 22 usersGrumpenKraut , Thursday 10th May 2018 17:52 GMT(20 of which on Debian, before that was Slackware)
I am new to systemd, maybe 3 or 4 months now tops on Ubuntu, and a tiny bit on Debian before that.
I was confident I was going to hate systemd before I used it just based on the comments I had read over the years, I postponed using it as long as I could. Took just a few minutes of using it to confirm my thoughts. Now to be clear, if I didn't have to mess with the systemd to do stuff then I really wouldn't care since I don't interact with it (which is the case on my laptop at least though laptop doesn't have systemd anyway). I manage about 1,000 systems running Ubuntu for work, so I have to mess with systemd, and init etc there. If systemd would just do ONE thing I think it would remove all of the pain that it has inflicted on me over the past several months and I could learn to accept it.
That one thing is, if there is an init script, RUN IT. Not run it like systemd does now. But turn off ALL intelligence systemd has when it finds that script and run it. Don't put it on any special timers, don't try to detect if it is running already, or stopped already or whatever, fire the script up in blocking mode and wait till it exits.
My first experience with systemd was on one of my home servers, I re-installed Debian on it last year, rebuilt the hardware etc and with it came systemd. I believe there is a way to turn systemd off but I haven't tried that yet. The first experience was with bind. I have a slightly custom init script (from previous debian) that I have been using for many years. I copied it to the new system and tried to start bind. Nothing. I looked in the logs and it seems that it was trying to interface with rndc(internal bind thing) for some reason, and because rndc was not working(I never used it so I never bothered to configure it) systemd wouldn't launch bind. So I fixed rndc and systemd would now launch bind, only to stop it within 1 second of launching. My first workaround was just to launch bind by hand at the CLI (no init script), left it running for a few months. Had a discussion with a co-worker who likes systemd and he explained that making a custom unit file and using the type=forking option may fix it.. That did fix the issue.
Next issue came up when dealing with MySQL clusters. I had to initialize the cluster with the "service mysql bootstrap-pxc" command (using the start command on the first cluster member is a bad thing). Run that with systemd, and systemd runs it fine. But go to STOP the service, and systemd thinks the service is not running so doesn't even TRY to stop the service(the service is running). My workaround for my automation for mysql clusters at this point is to just use mysqladmin to shut the mysql instances down. Maybe newer mysql versions have better systemd support though a co-worker who is our DBA and has used mysql for many years says even the new Maria DB builds don't work well with systemd. I am working with Mysql 5.6 which is of course much much older.
Next issue came up with running init scripts that have the same words in them, in the case of most recently I upgraded systems to systemd that run OSSEC. OSSEC has two init scripts for us on the server side (ossec and ossec-auth). Systemd refuses to run ossec-auth because it thinks there is a conflict with the ossec service. I had the same problem with multiple varnish instances running on the same system (varnish instances were named varnish-XXX and varnish-YYY). In the varnish case using custom unit files I got systemd to the point where it would start the service but it still refuses to "enable" the service because of the name conflict (I even changed the name but then systemd was looking at the name of the binary being called in the unit file and said there is a conflict there).
fucking a. Systemd shut up, just run the damn script. It's not hard.
Later a co-worker explained the "systemd way" for handling something like multiple varnish instances on the system but I'm not doing that, in the meantime I just let chef start the services when it runs after the system boots(which means they start maybe 1 or 2 mins after bootup).
Another thing bit us with systemd recently as well again going back to bind. Someone on the team upgraded our DNS systems to systemd and the startup parameters for bind were not preserved because systemd ignores the /etc/default/bind file. As a result we had tons of DNS failures when bind was trying to reach out to IPv6 name servers(ugh), when there is no IPv6 connectivity in the network (the solution is to start bind with a -4 option).
I believe I have also caught systemd trying to mess with file systems(iscsi mount points). I have lots of automation around moving data volumes on the SAN between servers and attaching them via software iSCSI directly to the VMs themselves(before vsphere 4.0 I attached them via fibre channel to the hypervisor but a feature in 4.0 broke that for me). I noticed on at least one occasion when I removed the file systems from a system that SOMETHING (I assume systemd) mounted them again, and it was very confusing to see file systems mounted again for block devices that DID NOT EXIST on the server at the time. I worked around THAT one I believe with the "noauto" option in fstab again. I had to put a lot of extra logic in my automation scripts to work around systemd stuff.
I'm sure I've only scratched the surface of systemd pain. I'm sure it provides good value to some people, I hear it's good with containers (I have been running LXC containers for years now, I see nothing with systemd that changes that experience so far).
But if systemd would just do this one thing and go into dumb mode with init scripts I would be quite happy.
Re: as a linux user for 22 usersNow more seriously: it really strikes me that complaints about systemd come from people managing non-trivial setups like the one you describe. While it might have been a PITA to get this done with the old init mechanism, you could make it work reliably.
If systemd is a solution to any set of problems, I'd love to have those problems back!
|
|
|
Nov 18, 2018 | theregister.co.uk
Will Godfrey , Thursday 10th May 2018 16:30 GMT
Business ModelRed Hat have definitely taken a lurch to the dark side in recent years. It seems to be the way businesses go.
They start off providing a service to customers.
As they grow the customers become users.
Once they reach a certain point the users become consumers, and at this point it is the 'consumers' that provide a service for the business.
SystemD is just a symptom of this regression.
|
|
|
Nov 18, 2018 | theregister.co.uk
The Electron , Thursday 10th May 2018 12:05 GMT
Fudging the start-up and restoring eth0Jay 2 , Thursday 10th May 2018 15:02 GMTI knew systemd was coming thanks to playing with Fedora. The quicker start-up times were welcomed. That was about it! I have had to kickstart many of my CentOS 7 builds to disable IPv6 (NFS complains bitterly), kill the incredibly annoying 'biosdevname' that turns sensible eth0/eth1 into some daftly named nonsense, replace Gnome 3 (shudder) with MATE, and fudge start-up processes. In a previous job, I maintained 2 sets of CentOS 7 'infrastructure' servers that provided DNS, DHCP, NTP, and LDAP to a large number of historical vlans. Despite enabling the systemd-network wait online option, which is supposed to start all networks *before* listening services, systemd would run off flicking all the "on" switches having only set-up a couple of vlans. Result: NTP would only be listening on one or two vlan interfaces. The only way I found to get around that was to enable rc.local and call systemd to restart the NTP daemon after 20 seconds. I never had the time to raise a bug with Red Hat, and I assume the issue still persists as no-one designed systemd to handle 15-odd vlans!?
Re: Predictable namesHieronymusBloggs , Thursday 10th May 2018 16:23 GMTI can't remember if it's HPE or Dell (or both) where you can use set the kernel option biosdevname=0 during build/boot to turn all that renaming stuff off and revert to ethX.
However on (RHEL?)/CentOS 7 I've found that if you build a server like that, and then try to renam/swap the interfaces it will refuse point blank to allow you to swap the interfaces round so that something else can be eth0. In the end we just gave up and renamed everything lanX instead which it was quite happy with.
Re: Predictable namesDazed and Confused , Thursday 10th May 2018 19:21 GMT"I can't remember if it's HPE or Dell (or both) where you can use set the kernel option biosdevname=0 during build/boot to turn all that renaming stuff off and revert to ethX."
I'm using this on my Debian 9 systems. IIRC the option to do so will be removed in Debian 10.
Re: Predictable namesI can't remember if it's HPE or Dell (or both)
It's Dell. I got the impression that much of this work had been done, at least, in conjunction with Dell.
|
|
|
Nov 18, 2018 | theregister.co.uk
Doctor Syntax , Thursday 10th May 2018 10:26 GMT
"The more people learn about it, the more they like it."ROC , Friday 11th May 2018 17:32 GMTTranslation: We define those who don't like it as not have learned enough about it.
Alternate translation:The beatings will continue until morale improves.
|
|
|
Nov 18, 2018 | theregister.co.uk
AJ MacLeod , Thursday 10th May 2018 13:51 GMT
@SheepykinsI'm not really bothered about whether init was perfect from the beginning - for as long as I've been using Linux (20 years) until now, I have never known the init system to be the cause of major issues. Since in my experience it's not been seriously broken for two decades, why throw it out now for something that is orders of magnitude more complex and ridiculously overreaching?
Like many here I bet, I am barely tolerating SystemD on some servers because RHEL/CentOS 7 is the dominant business distro with a decent support life - but this is also the first time I can recall ever having serious unpredictable issues with startup and shutdown on Linux servers.
stiine, Thursday 10th May 2018 15:38 GMTsysV init
I've been using Linux ( RedHat, CentOS, Ubuntu), BSD (Solaris, SunOS, freeBSD) and Unix ( aix, sysv all of the way back to AT&T 3B2 servers) in farms of up to 400 servers since 1988 and I never, ever had issues with eth1 becoming eth0 after a reboot. I also never needed to run ifconfig before configuring an interface just to determine what the inteface was going to be named on a server at this time. Then they hired Poettering... now, if you replace a failed nic, 9 times out of 10, the interface is going to have a randomly different name.
/rant
|
|
|
Nov 18, 2018 | theregister.co.uk
Chronos , Thursday 10th May 2018 13:32 GMT
Re: Logging
And disk mounting
Well, I am compelled to agree with most everything you wrote except one niche area that systemd does better: Remember putzing about with the amd? One line in fstab:
nasbox:/srv/set0 /nas nfs4 _netdev,noauto,nolock,x-systemd.automount,x-systemd.idle-timeout=1min 0 0Bloody thing only works and nobody's system comes grinding to a halt every time some essential maintenance is done on the NAS.
Candour compels me to admit surprise that it worked as advertised, though.
DCFusor , Thursday 10th May 2018 13:58 GMT
Re: LoggingNo worries, as has happened with every workaround to make systemD simply mount cifs or NFS at boot, yours will fail as soon as the next change happens, yet it will remain on the 'net to be tried over and over as have all the other "fixes" for Poettering's arrogant breakages.
The last one I heard from him on this was "don't mount shares at boot, it's not reliable WONTFIX".
Which is why we're all bitching.
Break my stuff.
Web shows workaround.
Break workaround without fixing the original issue, really.
Never ensure one place for current dox on what works now.
Repeat above endlessly.
Fine if all you do is spin up endless identical instances in some cloud (EG a big chunk of RH customers - but not Debian for example). If like me you have 20+ machines customized to purpose...for which one workaround works on some but not others, and every new release of systemD seems to break something new that has to be tracked down and fixed, it's not acceptable - it's actually making proprietary solutions look more cost effective and less blood pressure raising.
The old init scripts worked once you got them right, and stayed working. A new distro release didn't break them, nor did a systemD update (because there wasn't one). This feels more like sabotage.
|
|
|
Nov 18, 2018 | theregister.co.uk
Dabbb , Thursday 10th May 2018 10:16 GMT
Quite understandable that people who don't know anything else would accept systemd. For everyone else it has nothing to do with old school but everything to do with unpredictability of systemd.Today I've kickstarted RHEL7 on a rack of 40 identical servers using same script. On about 25 out of 40 postinstall script added to rc.local failed to run with some obscure error about script being terminated because something unintelligible did not like it. It never ever happened on RHEL6, it happens all the time on RHEL7. And that's exactly the reason I absolutely hate it both RHEL7 and systemd.
|
|
|
Nov 18, 2018 | theregister.co.uk
Anonymous Coward , Thursday 10th May 2018 02:58 GMT
Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.asdf , Thursday 10th May 2018 23:38 GMT"And perhaps, in the process, you may warm up a bit more to the tool"
Like from LNG to Dry Ice? and by tool does he mean Poettering or systemd?
I love the fact that they aren't trying to address the huge and legitimate issues with Systemd, while still plowing ahead adding more things we don't want Systemd to touch into it's ever expanding sprawl.
The root of the issue with Systemd is the problems it causes, not the lack of "enhancements" initd offered. Replacing Init didn't require the breaking changes and incompatibility induced by Poettering's misguided handiwork. A clean init replacement would have made Big Linux more compatible with both it's roots and the other parts of the broader Linux/BSD/Unix world. As a result of his belligerent incompetence, other peoples projects have had to be re-engineered, resulting in incompatibility, extra porting work, and security problems. In short were stuck cleaning up his mess, and the consequences of his security blunders
A worthy Init replacement should have moved to compiled code and given us asynchronous startup, threading, etc, without senselessly re-writing basic command syntax or compatibility. Considering the importance of PID 1, it should have used a formal development process like the BSD world.
Fedora needs to stop enabling his prima donna antics and stop letting him touch things until he admits his mistakes and attempts to fix them. The flame wars not going away till he does.
Re: Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.whitepines , Thursday 10th May 2018 03:47 GMTSystemD is corporate money (Redhat support dollars) triumphing over the long hairs sadly. Enough money can buy a shitload of code and you can overwhelm the hippies with hairball dependencies (the key moment was udev being dependent on systemd) and soon get as much FOSS as possible dependent on the Linux kernel. This has always been the end game as Red Hat makes its bones on Linux specifically not on FOSS in general (that say runs on Solaris or HP-UX). The tighter they can glue the FOSS ecosystem and the Linux kernel together ala Windows lite style the better for their bottom line. Poettering is just being a good employee asshat extraordinaire he is.
Raise your hand if you've been completely locked out of a server or laptop (as in, break out the recovery media and settle down, it'll be a while) because systemd:Daggerchild , Thursday 10th May 2018 11:39 GMT1.) Couldn't raise a network interface
2.) Farted and forgot the UUID for a disk, then refused to give a recovery shell
3.) Decided an unimportant service (e.g. CUPS or avahi) was too critical to start before giving a login over SSH or locally, then that service stalls forever
4.) Decided that no, you will not be network booting your server today. No way to recover and no debug information, just an interminable hang as it raises wrong network interfaces and waits for DHCP addresses that will never come.
And lest the fun be restricted to startup, on shutdown systemd can quite happily hang forever doing things like stopping nonessential services, *with no timeout and no way to interrupt*. Then you have to Magic Sysreq the machine, except that sometimes secure servers don't have that ability, at least not remotely. Cue data loss and general excitement.
And that's not even going into the fact that you need to *reboot the machine* to patch the *network enabled* and highly privileged systemd, or that it seems to have the attack surface of Jupiter.
Upstart was better than this. SysV was better than this. Mac is better than this. Windows is better than this.
Uggh.
Re: Ahhh SystemDTridac , Thursday 10th May 2018 11:53 GMTI honestly would love someone to lay out the problems it solves. Solaris has a similar parallellised startup system, with some similar problems, but it didn't need pid 1.
Re: Ahhh SystemDAgreed, Solaris svcadm and svcs etc are an example of how it should be done. A layered approach maintaining what was already there, while adding functionality for management purposes. Keeps all the old text based log files and uses xml scripts (human readable and editable) for higher level functions. Afaics, systemd is a power grab by red hat and an ego trip for it's primary developer. Dumped bloatware Linux in favour of FreeBSD and others after Suse 11.4, though that was bad enough with Gnome 3...
|
|
|
Nov 06, 2018 | devuan.org
Devuan GNU+Linux is a fork of Debian without systemd. Devuan's stable release is now 2.0.0 ASCII . The 1.0.0 Jessie release (LTS) has moved to oldstable status. Since the declaration of intention to fork in 2014 , infrastructure has been put in place to support Devuan's mission to offer users control over their system. Devuan Jessie provided a safe upgrade path from Debian 7 (Wheezy) and Debian 8 (Jessie). Now Devuan ASCII offers an upgrade from Devuan Jessie as well as a transition from Debian 9 (Stretch) that avoids unnecessary entanglements and ensures Init Freedom .
Devuan aliases its releases using minor planet names as codenames . Devuan file names follow this release naming scheme .
Devuan release Suites Planet nr. Debian release Jessie Oldstable 10464 Jessie ASCII Stable 3568 Stretch Beowulf In development 38086 Buster Ceres Unstable 1 Sid
|
|
|
Oct 31, 2018 | lwn.net
The " systemd question " has roiled Debian multiple times over the years, but things had mostly been quiet on that front of late.
The Devuan distribution is a Debian derivative that has removed systemd; many of the vocal anti-systemd Debian developers have switched, which helps reduce the friction on the Debian mailing lists.
But that seems to have led to support for init system alternatives (and System V init in particular) to bitrot in Debian.
There are signs that a bit of reconciliation between Debian and Devuan will help fix that problem.
|
|
|
Oct 26, 2018 | theregister.co.uk
Hole opens up remote-code execution to miscreants – or a crash, if you're lucky A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box.
The flaw therefore puts Systemd-powered Linux computers – specifically those using systemd-networkd – at risk of remote hijacking: maliciously crafted DHCPv6 packets can try to exploit the programming cockup and arbitrarily change parts of memory in vulnerable systems, leading to potential code execution. This code could install malware, spyware, and other nasties, if successful.
The vulnerability – which was made public this week – sits within the written-from-scratch DHCPv6 client of the open-source Systemd management suite, which is built into various flavors of Linux.
This client is activated automatically if IPv6 support is enabled, and relevant packets arrive for processing. Thus, a rogue DHCPv6 server on a network, or in an ISP, could emit specially crafted router advertisement messages that wake up these clients, exploit the bug, and possibly hijack or crash vulnerable Systemd-powered Linux machines.
Here's the Red Hat Linux summary :
systemd-networkd is vulnerable to an out-of-bounds heap write in the DHCPv6 client when handling options sent by network adjacent DHCP servers. A attacker could exploit this via malicious DHCP server to corrupt heap memory on client machines, resulting in a denial of service or potential code execution.Felix Wilhelm, of the Google Security team, was credited with discovering the flaw, designated CVE-2018-15688 . Wilhelm found that a specially crafted DHCPv6 network packet could trigger "a very powerful and largely controlled out-of-bounds heap write," which could be used by a remote hacker to inject and execute code.
"The overflow can be triggered relatively easy by advertising a DHCPv6 server with a server-id >= 493 characters long," Wilhelm noted.
In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the vulnerable component by default.
Systemd creator Lennart Poettering has already published a security fix for the vulnerable component – this should be weaving its way into distros as we type.
If you run a Systemd-based Linux system, and rely on systemd-networkd, update your operating system as soon as you can to pick up the fix when available and as necessary.
The bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike. Though a number of major admins have in recent years adopted and championed it as the replacement for the old Init era, others within the Linux world seem to still be less than impressed with Systemd and Poettering's occasionally controversial management of the tool. ® Page:
2 3 Next →
MehAnonymous Coward , 6 daysAs anyone who bothers to read my comments (BTW "hi" to both of you) already knows, I despise systemd with a passion, but this one is more an IPv6 problem in general.
Yes this is an actual bug in networkd, but IPv6 seems to be far more bug prone than v4, and problems are rife in all implementations. Whether that's because the spec itself is flawed, or because nobody understands v6 well enough to implement it correctly, or possibly because there's just zero interest in making any real effort, I don't know, but it's a fact nonetheless, and my primary reason for disabling it wherever I find it. Which of course contributes to the "zero interest" problem that perpetuates v6's bug prone condition, ad nauseam.
IPv6 is just one of those tech pariahs that everyone loves to hate, much like systemd, albeit fully deserved IMO.
Oh yeah, and here's the obligatory "systemd sucks". Personally I always assumed the "d" stood for "destroyer". I believe the "IP" in "IPv6" stands for "Idiot Protocol".
Re: MehJay Lenovo , 6 days"nonetheless, and my primary reason for disabling it wherever I find it. "
The very first guide I read to hardening a system recommended disabling services you didn't need and emphasized IPV6 for the reasons you just stated.
Wasn't there a bux in Xorg reported recently as well?
https://www.theregister.co.uk/2018/10/25/x_org_server_vulnerability/
"FreeDesktop.org Might Formally Join Forces With The X.Org Foundation"
https://www.phoronix.com/scan.php?page=news_item&px=FreeDesktop-org-Xorg-Forces
Also, does this mean that Facebook was vulnerable to attack, again?
"Simply put, you could say Facebook loves systemd."
https://www.phoronix.com/scan.php?page=news_item&px=Facebook-systemd-2018
Re: Mehvtcodger , 6 daysIPv6 and SystemD: Forced industry standard diseases that requires most of us to bite our lips and bear it.
Fortunately, IPv6 by lack of adopted use, limits the scope of this bug.
Re: MehDougS , 6 daysFortunately, IPv6 by lack of adopted use, limits the scope of this bug.Yeah, fortunately IPv6 is only used by a few fringe organizations like Google and Microsoft.
Seriously, I personally want nothing to do with either systemd or IPv6. Both seem to me to fall into the bin labeled "If it ain't broke, let's break it" But still it's troubling that things that some folks regard as major system components continue to ship with significant security flaws. How can one trust anything connected to the Internet that is more sophisticated and complex than a TV streaming box?
Re: MehNate Amsden , 6 daysWas going to say the same thing, and I disable IPv6 for the exact same reason. IPv6 code isn't as well tested, as well audited, or as well targeted looking for exploits as IPv4. Stuff like this only proves that it was smart to wait, and I should wait some more.
Re: Mehbombastic bob , 6 daysCount me in the camp of who hates systemd(hates it being "forced" on just about every distro, otherwise wouldn't care about it - and yes I am moving my personal servers to Devuan, thought I could go Debian 7->Devuan but turns out that may not work, so I upgraded to Debian 8 a few weeks ago, and will go to Devuan from there in a few weeks, upgraded one Debian 8 to Devuan already 3 more to go -- Debian user since 1998), when reading this article it reminded me of
https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/
The gift that keeps on giving (systemd) !!!Long John Brass , 6 daysThis makes me glad I'm using FreeBSD. The Xorg version in FreeBSD's ports is currently *slightly* older than the Xorg version that had that vulnerability in it. AND, FreeBSD will *NEVER* have systemd in it!
(and, for Linux, when I need it, I've been using Devuan)
That being said, the whole idea of "let's do a re-write and do a 'systemd' instead of 'system V init' because WE CAN and it's OUR TURN NOW, 'modern' 'change for the sake of change' etc." kinda reminds me of recent "update" problems with Win-10-nic...
Oh, and an obligatory Schadenfreude laugh: HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA!!!!!!!!!!!!!!!!!!!
Re: The gift that keeps on giving (systemd) !!!Dan 55 , 6 daysFinally got all my machines cut over from Debian to Devuan.
Might spin a FreeBSD system up in a VM and have a play.
I suspect that the infestation of stupid into the Linux space won't stop with or be limited to SystemD. I will wait and watch to see what damage the re-education gulag has done to Sweary McSwearFace (Mr Torvalds)
Re: MehOrv , 3 daysI despise systemd with a passion, but this one is more an IPv6 problem in general.
Not really, systemd has its tentacles everywhere and runs as root. Exploits which affect systemd therefore give you the keys to the kingdom.
Re: MehLong John Brass , 3 daysNot really, systemd has its tentacles everywhere and runs as root.Yes, but not really the problem in this case. Any DHCP client is going to have to run at least part of the time as root. There's not enough nuance in the Linux privilege model to allow it to manipulate network interfaces, otherwise.
4 1Re: MehJohnFen , 6 daysYes, but not really the problem in this case. Any DHCP client is going to have to run at least part of the time as root. There's not enough nuance in the Linux privilege model to allow it to manipulate network interfaces, otherwise.Sorry but utter bullshit. You can if you are so inclined you can use the Linux Capabilities framework for this kind of thing. See https://wiki.archlinux.org/index.php/capabilities
3 0Yay for meElReg!comments!Pierre , 2 days"If you run a Systemd-based Linux system"
I remain very happy that I don't use systemd on any of my machines anymore. :)
"others within the Linux world seem to still be less than impressed with Systemd"
Yep, I'm in that camp. I gave it a good, honest go, but it increased the amount of hassle and pain of system management without providing any noticeable benefit, so I ditched it.
Re: Time to trollDestroy All Monsters , 5 days> Just like it's entirely possible to have a Linux system without any GNU in it
Just like it's possible to have a GNU system without Linux on it - ho well as soon as GNU MACH is finally up to the task ;-)
On the systemd angle, I, too, am in the process of switching all my machines from Debian to Devuan but on my personnal(*) network a few systemd-infected machines remain, thanks to a combination of laziness from my part and stubborn "systemd is quite OK" attitude from the raspy foundation. That vuln may be the last straw : one on the aforementionned machines sits on my DMZ, chatting freely with the outside world. Nothing really crucial on it, but i'd hate it if it became a foothold for nasties on my network.
(*) policy at work is RHEL, and that's negociated far above my influence level, but I don't really care as all my important stuff runs on Z/OS anyway ;-) . Ok we have to reboot a few VMs occasionnally when systemd throws a hissy fit -which is surprisingly often for an "enterprise" OS -, but meh.
Re: Not possibleAnonymous Coward , 5 daysThis code is actually pretty bad and should raise all kinds of red flags in a code review.
Re: Not possibleChristian Berger , 5 daysITYM Lennart
Re: Not possiblejake , 6 days"This code is actually pretty bad and should raise all kinds of red flags in a code review."
Yeah, but for that you need people who can do code reviews, and also people who can accept criticism. That also means saying "no" to people who are bad at coding, and saying that repeatedly if they don't learn.
SystemD seems to be the area where people gather who want to get code in for their resumes, not for people who actually want to make the world a better place.
26 1There is a reason ...AdamWill , 6 days... that an init, traditionally, is a small bit of code that does one thing very well. Like most of the rest of the *nix core utilities. All an init should do is start PID1, set run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in plaintext to make troubleshooting as simplistic as possible. Anything else is a vanity project that is best placed elsewhere, in it's own stand-alone code base.
Inventing a clusterfuck init variation that's so big and bulky that it needs to be called a "suite" is just asking for trouble.
IMO, systemd is a cancer that is growing out of control, and needs to be cut out of Linux before it infects enough of the system to kill it permanently.
Re: There is a reason ...Anonymous Coward , 4 daysThat's why systemd-networkd is a separate, optional component, and not actually part of the init daemon at all. Most systemd distros do not use it by default and thus are not vulnerable to this unless the user actively disables the default network manager and chooses to use networkd instead.
Re: There is a reason ...Orv , 3 days"Just go install a default Fedora or Ubuntu system and check for yourself: you'll have systemd, but you *won't* have systemd-networkd running."
Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed itself then! ( and was a fucking pain to remove).
LP is a fucking arsehole.
Re: There is a reason ...AdamWill , 2 daysPardon my ignorance (I don't use a distro with systemd) why bother with networkd in the first place if you don't have to use it.Mostly because the old-style init system doesn't cope all that well with systems that move from network to network. It works for systems with a static IP, or that do a DHCP request at boot, but it falls down on anything more dynamic.
In order to avoid restarting the whole network system every time they switch WiFi access points, people have kludged on solutions like NetworkManager. But it's hard to argue it's more stable or secure than networkd. And this is always going to be a point of vulnerability because anything that manipulates network interfaces will have to be running as root.
These days networking is essential to the basic functionality of most computers; I think there's a good argument that it doesn't make much sense to treat it as a second-class citizen.
Re: There is a reason ...alain williams , 6 days"Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed itself then! ( and was a fucking pain to remove)."
So I looked into it a bit more, and from a few references at least, it seems like Ubuntu has a sort of network configuration abstraction thingy that can use both NM and systemd-networkd as backends; on Ubuntu desktop flavors NM is usually the default, but apparently for recent Ubuntu Server, networkd might indeed be the default. I didn't notice that as, whenever I want to check what's going on in Ubuntu land, I tend to install the default desktop spin...
"LP is a fucking arsehole."
systemd's a lot bigger than Lennart, you know. If my grep fu is correct, out of 1543 commits to networkd, only 298 are from Lennart...
1 0Old is goodoiseau , 4 daysin many respects when it comes to software because, over time, the bugs will have been found and squashed. Systemd brings in a lot of new code which will, naturally, have lots of bugs that will take time to find & remove. This is why we get problems like this DHCP one.
Much as I like the venerable init: it did need replacing. Systemd is one way to go, more flexible, etc, etc. Something event driven is a good approach.
One of the main problems with systemd is that it has become too big, slurped up lots of functionality which has removed choice, increased fragility. They should have concentrated on adding ways of talking to existing daemons, eg dhcpd, through an API/something. This would have reused old code (good) and allowed other implementations to use the API - this letting people choose what they wanted to run.
But no: Poettering seems to want to build a Cathedral rather than a Bazzar.
He appears to want to make it his way or no way. This is bad, one reason that *nix is good is because different solutions to a problem have been able to be chosen, one removed and another slotted in. This encourages competition and the 'best of breed' comes out on top. Poettering is endangering that process.
Also: he refusal to accept patches to let it work on non-Linux Unix is just plain nasty.
Re: Old is goodRich 2 , 4 daysHello:
One of the main problems with systemd is that it has become too big, slurped up lots of functionality which has removed choice, increased fragility.
IMO, there is a striking paralell between systemd and the registry in Windows OSs.
After many years of dealing with the registry (W98 to XPSP3) I ended up seeing the registry as a sort of developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the OS with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what was going on inside your box/the OS.
Years later, when I learned about the existence of systemd (I was already running Ubuntu) and read up on what it did and how it did it, it dawned on me that systemd was nothing more than a registry class virus and it was infecting Linux_land at the behest of the developers involved.
So I moved from Ubuntu to PCLinuxOS and then on to Devuan.
Call me paranoid but I am convinced that there are people both inside and outside IT that actually want this and are quite willing to pay shitloads of money for it to happen.
I don't see this MS cozying up to Linux in various ways lately as a coincidence: these things do not happen just because or on a senior manager's whim.
What I do see (YMMV) is systemd being a sort of convergence of Linux with Windows, which will not be good for Linux and may well be its undoing.
Cheers,
O.
Re: Old is goodMichael Wojcik , 3 days"Also: he refusal to accept patches to let it work on non-Linux Unix is just plain nasty"
Thank goodness this crap is unlikely to escape from Linux!
By the way, for a systemd-free Linux, try void - it's rather good.
Re: Old is goodOrv , 3 daysMuch as I like the venerable init: it did need replacing.
For some use cases, perhaps. Not for any of mine. SysV init, or even BSD init, does everything I need a Linux or UNIX init system to do. And I don't need any of the other crap that's been built into or hung off systemd, either.
Re: Old is goodChairman of the Bored , 6 daysBSD init and SysV init work pretty darn well for their original purpose -- servers with static IP addresses that are rebooted no more than once in a fortnight. Anything more dynamic starts to give it trouble.
Too bad Linus swore off swearingjake , 6 daysSituations like this go beyond a little "golly gee, I screwed up some C"...
Re: Too bad Linus swore off swearingJLV , 6 daysLinus doesn't care. systemd has nothing to do with the kernel ... other than the fact that the lead devs for systemd have been banned from working on the kernel because they don't play nice with others.
how did it get to this?Doctor Syntax , 6 daysI've been using runit, because I am too lazy and clueless to write init scripts reliably. It's very lightweight, runs on a bunch of systems and really does one thing - keep daemons up.
I am not saying it's the best - but it looks like it has a very small codebase, it doesn't do much and generally has not bugged me after I configured each service correctly. I believe other systems also exist to avoid using init scripts directly. Not Monit, as it relies on you configuring the daemon start/stop commands elsewhere.
On the other hand, systemd is a massive sprawl, does a lot of things - some of them useful, like dependencies and generally has needed more looking after. Twice I've had errors on a Django server that, after a lot of looking around ended up because something had changed in the, Chef-related, code that's exposed to systemd and esoteric (not emitted by systemd) errors resulted when systemd could not make sense of the incorrect configuration.
I don't hate it - init scripts look a bit antiquated to me and they seem unforgiving to beginners - but I don't much like it. What I certainly do hate is how, in an OS that is supposed to be all about choice, sometime excessively so as in the window manager menagerie, we somehow ended up with one mandatory daemon scheduler on almost all distributions. Via, of all types of dependencies, the GUI layer. For a window manager that you may not even have installed.
Talk about the antithesis of the Unix philosophy of do one thing, do it well.
Oh, then there are also the security bugs and the project owner is an arrogant twat. That too.
Re: how did it get to this?onefang , 6 days"init scripts look a bit antiquated to me and they seem unforgiving to beginners"
Init scripts are shell scripts. Shell scripts are as old as Unix. If you think that makes them antiquated then maybe Unix-like systems are not for you. In practice any sub-system generally gets its own scripts installed with the rest of the S/W so if being unforgiving puts beginners off tinkering with them so much the better. If an experienced Unix user really needs to modify one of the system-provided scripts their existing shell knowledge will let them do exactly what's needed. In the extreme, if you need to develop a new init script then you can do so in the same way as you'd develop any other script - edit and test from the command line.
33 4Re: how did it get to this?sed gawk , 6 days"Init scripts are shell scripts."
While generally true, some sysv init style inits can handle init "scripts" written in any language.
Re: how did it get to this?AdamWill , 6 daysI personally like openrc as an init system, but systemd is a symptom of the tooling problem.
It's for me a retrograde step but again, it's linux, one can, as you and I do, just remove systemd.
There are a lot of people in the industry now who don't seem able to cope with shell scripts nor are minded to research the arguments for or against shell as part of a unix style of system design.
In conclusion, we are outnumbered, but it will eventually collapse under its own weight and a worthy successor shall rise, perhaps called SystemV, might have to shorten that name a bit.
Just about nothing actually uses networkdChristian Berger , 5 days"In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the vulnerable component by default."
I can tell you for sure that no version of Fedora does, either, and I'm fairly sure that neither does Debian, SLES or Mint. I don't know anything much about CoreOS, but https://coreos.com/os/docs/latest/network-config-with-networkd.html suggests it actually *might* use systemd-networkd.
systemd-networkd is not part of the core systemd init daemon. It's an optional component, and most distros use some other network manager (like NetworkManager or wicd) by default.
The important word here is "still"NLCSGRV , 6 daysI mean commercial distributions seem to be particularly interested in trying out new things that can increase their number of support calls. It's probably just that networkd is either to new and therefore not yet in the release, or still works so badly even the most rudimentary tests fail.
There is no reason to use that NTP daemon of systemd, yet more and more distros ship with it enabled, instead of some sane NTP-server.
The Curse of Poettering strikes again._LC_ , 6 daysNow hang on, please!Ken Hagan , 6 daysSer iss no neet to worry, systemd will becum stable soon after PulseAudio does.
Re: Now hang on, please!Obesrver1 , 5 daysI won't hold my breath, then. I have a laptop at the moment that refuses to boot because (as I've discovered from looking at the journal offline) pulseaudio is in an infinite loop waiting for the successful detection of some hardware that, presumably, I don't have.
I imagine I can fix it by hacking the file-system (offline) so that fuckingpulse is no longer part of the boot configuration, but I shouldn't have to. A decent init system would be able to kick of everything else in parallel and if one particular service doesn't come up properly then it just logs the error. I *thought* that was one of the claimed advantages of systemd, but apparently that's just a load of horseshit.
26 0Reason for disabling IVP6Orv , 3 daysThat it punches thru NAT routers enabling all your little goodies behind them as directly accessible.
MS even supplies tunneling (Ivp4 to Ivp6) so if using Linux in a VM on a MS system you may still have it anyway.
NAT was always recommended to be used in hardening your system, I prefer to keep all my idIoT devices behind one.
As they are just Idiot devices.
In future I will need a NAT that acts as a DNS and offers some sort of solution to keeping Ivp4.
Re: Reason for disabling IVP6dajames , 3 daysMy NAT router statefully firewalls incoming IPv6 by default, which I consider equivalently secure. NAT adds security mostly by accident, because it de-facto adds a firewall that blocks incoming packets. It's not the address translation itself that makes things more secure, it's the inability to route in from the outside.
Re: Reason for disabling IVP6JohnFen , 3 daysYou can use NAT with IPv6.
You can, but why would you want to.
NAT is schtick for connecting a whole LAN to a WAN using a single IPv4 address (useful with IPv4 because most ISPs don't give you a /24 when you sign up). If you have a native IPv6 address you'll have something like 2^64 addresses, so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT.
Using NAT with IPv6 is just missing the point.
Re: Reason for disabling IVP6Destroy All Monsters , 5 days"so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT."
Avoiding that configuration is exactly the use case for using NAT with IPv6. As others have pointed out, you can accomplish the same thing with IPv6 router configuration, but NAT is easier in terms of configuration and maintenance. Given that, and assuming that you don't want to be able to have arbitrary machines open ports that are visible to the internet, then why not use NAT?
Also, if your goal is to make people more likely to move to IPv6, pointing out IPv4 methods that will work with IPv6 (even if you don't consider them optimal) seems like a really, really good idea. It eases the transition.
Please El Reg these stories make ma rage at breakfast, what's this?TheSkunkyMonk , 5 daysThe bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike.
Less against systemd (which should get attacked on the design & implementation level) or against IPv6 than against the use of buffer-overflowable languages in 2018 in code that processes input from the Internet (it's not the middle ages anymore) or at least very hard linting of the same.
But in the end, what did it was a violation of the Don't Repeat Yourself principle and lack of sufficently high-level datastructures. Pointer into buffer, and the remaining buffer length are two discrete variables that need to be updated simultaneously to keep the invariant and this happens in several places. This is just a catastrophe waiting to happen. You forget to update it once, you are out! Use structs and functions updating the structs correctly.
And use assertions in the code , this stuff all seems disturbingly assertion-free.
Excellent explanation by Felix Wilhelm:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921
The function receives a pointer to the option buffer buf, it's remaining size buflen and the IA to be added to the buffer. While the check at (A) tries to ensure that the buffer has enough space left to store the IA option, it does not take the additional 4 bytes from the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow [i.e. you suddenly have a gazillion byte buffer, Ed.] in (D) giving an attacker a very powerful and largely controlled OOB heap write starting at (E).
Init is 1026 lines of code in one file and it works great.Anonymous Coward , 5 days"...and Poettering's occasionally controversial management of the tool."clocKwize , 4 daysShouldn't that be "...Potterings controversial management as a tool."?
Re: Contractor rightsAnonymous Coward , 4 dayswhy don't we stop writing code in languages that make it easy to screw up so easily like this?
There are plenty about nowadays, I'd rather my DHCP client be a little bit slower at processing packets if I had more confidence it would not process then incorrectly and execute code hidden in said packets...
Switch, as easy as thatoiseau , 3 daysThe circus that is called "Linux" have forced me to Devuan and the likes however the circus is getting worse and worse by the day, thus I have switched to the BSD world, I will learn that rather than sit back and watch this unfold As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary, thus I bid the Linux world a farewell after 10 years of support, I will watch the grass dry out from the other side of the fence, It was destined to fail by means of infiltration and screw it up motive(s) on those we do not mention here.
Re: Switch, as easy as thatDave Bell , 4 daysHello:
As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary ...
Indeed, it was rather quick and is very scary.
But there's really no need to dig much, just reason it out.
It's like a follow the money situation of sorts.
I'll try to sum it up in three short questions:
Q1: Hasn't the Linux philosophy (programs that do one thing and do it well) been a success?
A1: Indeed, in spite of the many init systems out there, it has been a success in stability and OS management. And it can easily be tested and debugged, which is an essential requirement.
Q2: So what would Linux need to have the practical equivalent of the registry in Windows for?
A2: So that whatever the registry does in/to Windows can also be done in/to Linux.
Q3: I see. And just who would want that to happen? Makes no sense, it is a huge step backwards.
A3: ....
Cheers,
O.
Reporting weaknessW.O.Frobozz , 3 daysOK, so I was able to check through the link you provided, which says "up to and including 239", but I had just installed a systemd update and when you said there was already a fix written, working it's way through the distro update systems, all I had to do was check my log.
Linux Mint makes it easy.
But why didn't you say something such as "reported to affect systemd versions up to and including 239" and then give the link to the CVE? That failure looks like rather careless journalism.
Hmm./sbin/init never had these problems. But then again /sbin/init didn't pretend to be the entire operating system.
|
|
|
Oct 30, 2018 | theregister.co.uk
So now it becomes Blue Hat. Will systemd become standard on mainframes as well?DCFusor , 15 hrs@DoctorAnonymous Coward , 15 hrsMaybe we get really lucky and they RIF Lennart Poettering or he quits? I hear IBM doesn't tolerate prima donnas and cults of personality quite as much as RH?
I hear IBM doesn't tolerate prima donnas and cults of personality quite as much as RH?Waseem Alkurdi , 18 hrsQuite the contrary. IBM is run and managed by prima donnas and personality cults.
Re: PoetteringGlen Turner 666 , 16 hrsOS/2 and Poettering? Best joke I've ever heard!
(It'd be interesting if somebody locked them both up in an office and see what happens!)
Re: PatentsAnonymous Coward , 1 dayIBM already had access to Red Hat's patents, including for patent defence purposes. Look up "open innovation network".
This acquisition is about: (1) IBM needing growth, or at least a plausible scenario for growth. (2) Red Hat wanting an easy expansion of its sales channels, again for growth. (3) Red Hat stockholders being given an offer they can't refuse.
This acquisition is not about: cultural change at IBM. Which is why the acquisition will 'fail'. The bottom line is that engineering matters at the moment (see: Google, Amazon), and IBM sacked their engineering culture across the past two decades. To be successful IBM need to get that culture back, and acquiring Red Hat gives IBM the opportunity to create a product-building, client-service culture within IBM. Except that IBM aren't taking the opportunity, so there's a large risk the reverse will happen -- the acquisition will destroy Red Hat's engineering- and service-oriented culture.
The kraken versus the container shipSitaram Chamarty , 1 dayThis could be interesting: will the systemd kraken manage to wrap its tentacles around the big blue container ship and bring it to a halt, or will the container ship turn out to be well armed and fatally harpoon the kraken (causing much rejoicing in the rest of the Linux world)?
disappointed...dbtx , 1 dayHonestly, this is a time for optimism: if they manage to get rid of Lennart Poettering, everything else will be tolerable!
*if*tfb , 13 hrsyou can change the past so that a "proper replacement" isn't automatically expected to do lots of things that systemd does. That damage is done. We got "better is worse" and enough people liked it-- good luck trying to go back to "worse is better"
I presume they were waiting to see what happened to Solaris. When Oracle bought Sun (presumably the only other company who might have bought them was IBM) there were really three enterprise unixoid platforms: Solaris, AIX and RHEL (there were some smaller ones and some which were clearly dying like HPUX). It seemed likely at the time, but not yet certain, that Solaris was going to die (I worked for Sun at the time this happened and that was my opinion anyway). If Solaris did die, then if one company owned both AIX and RHEL then that company would own the enterprise unixoid market. If Solaris didn't die on the other hand then RHEL would be a lot less valuable to IBM as there would be meaningful competition. So, obviously, they waited to see what would happen.Well, Solaris is perhaps not technically quite dead yet but certainly is moribund, and IBM now owns both AIX and RHEL & hence the enterprise unixoid market. As an interesting side-note, unless Oracle can keep Solaris on life-support this means that IBM own all-but own Oracle's OS as well ('Oracle Linux' is RHEL with, optionally, some of their own additions to the kernel).
|
|
|
Oct 30, 2018 | linux.slashdot.org
Anonymous Coward , Sunday October 28, 2018 @03:21PM ( #57550457 )systemd ( Score: 4 , Funny)The next version will be branded IBM(R) SystemD/2.
Anonymous Coward , Sunday October 28, 2018 @05:10PM ( #57551035 )Re:Please God No ( Score: 5 , Funny)Look on the bright side: Poettering works for Red Hat. (Reposting because apparently Poettering has mod points.)
Anonymous Coward , Sunday October 28, 2018 @05:09PM ( #57551031 )Re: It all ( Score: 5 , Informative)Lennart already fucked up RHEL, I hope IBM will get rid of him and systemd.
gweihir ( 88907 ) , Sunday October 28, 2018 @07:14PM ( #57551677 )HanzoSpam ( 713251 ) , Sunday October 28, 2018 @10:56PM ( #57552591 )Re: It all ( Score: 4 , Insightful)Indeed. Maybe they will even sack Poettering. If so, they will do a ton of good.
Re: It all ( Score: 5 , Insightful)Indeed. Maybe they will even sack Poettering. If so, they will do a ton of good.Surely you jest. Knowing IBM, as I do, they're more likely to make Poettering the head of the division.
cayenne8 ( 626475 ) , Sunday October 28, 2018 @06:18PM ( #57551371 ) Homepage JournalRe:Lol ( Score: 5 , Interesting)With systemd how can they fuck it up worse than it already is?Well, it *is* IBM....I'm sure they can still make it worse.
|
|
|
Oct 29, 2018 | lxer.com
- The Register; By Shaun Nichols (Posted by the_doctor on Oct 28, 2018 12:18 PM EDT)
- Story Type: News Story , Security ; Groups: Debian , Developer , Distributions , Fedora , Linux , Mint , Red Hat , SUSE , Ubuntu
A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box... Systemd creator Leonard Poettering has already published a security fix for the vulnerable component – this should be weaving its way into distros as we type.
|
|
|
Oct 15, 2018 | theregister.co.uk
You love Systemd – you just don't know it yet, wink Red Hat bods
At the Red Hat confab, Breard admitted that since Systemd was officially introduced as the default init option in Red Hat Enterprise Linux 7 in 2014, the software hasn't always been met with open arms by the community.
"People respond to it with anything from curiosity to rage," Breard mused. "The more people learn about it, the more they like it. We have seen this pan out over the last few years."
Breard and Poettering told attendees that, in many cases, Systemd is able to dramatically simplify the management of processes while at the same time giving administrators tighter control over their machines.
For example, noted Poettering, Systemd can fully track down and kill off all processes associated with a service being shut down, something rival init systems are unable to cleanly do.
"It sounds super basic, but actually it is much more complex than people think," Poettering said. "Because Systemd knows which service a process belongs to, it can shut down that process."
Systemd is pretty good at enforcing security policies, we were told. Because it has the ability to limit services' access to resources, controls can be put in place to effectively sandbox software and lock down code from doing potentially malicious things, such as write to storage or read sensitive data in particular directories.
Sure, you can do all this sort of thing with containers and chroots, and your own shell scripts, but it's there out of the box from Systemd if you need it. That's the pro-Systemd argument, anyway.
Additionally, services' access to processor core time can be regulated, thus tuning system performance as certain programs and servers are given a lot, or fewer, CPU cycles.
Breard and Poettering said they will try to further enhance Systemd by, for instance, extending its ability to manage network connections and containers.
And perhaps, in the process, you may warm up a bit more to the tool
Tinslave_the_Barelegged
Re: Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.SystemD is corporate money (Redhat support dollars) triumphing over the long hairs sadly. Enough money can buy a shitload of code and you can overwhelm the hippies with hairball dependencies (the key moment was udev being dependent on systemd) and soon get as much FOSS as possible dependent on the Linux kernel. This has always been the end game as Red Hat makes its bones on Linux specifically not on FOSS in general (that say runs on Solaris or HP-UX). The tighter they can glue the FOSS ecosystem and the Linux kernel together ala Windows lite style the better for their bottom line. Poettering is just being a good employee asshat extraordinaire he is.
P. LeeRe: Ahhh SystemD> A solution that no one wants for problems no one has.
That's not strictly true - systemd introduces loads of additional problems...
I've just hit another, and the answer was classic. I'm testing OpenSUSE 15.0, and as expected it is already rock solid. But there's an odd error message about vconsole at boot, a known issue for a few years. Systemd's (Poetering's) response is that an upstream application has to change to fit in with what systemd wants to do. It's that attitude, of forcing changes all over the linux ecosphere, that is a genuine cause for concern. We thought that aggression would come from an antagonistic proprietary corporate, but no, it's come from the supposed good guy, Red Hat.
DaggerchildRe: Ahhh SystemD>A solution that no one wants for problems no one has.
Hmmm. I think we should be a little more accurate. There are real problems which it solves. It just appears to have used the worst possible method of solving them.
starbase7Re: Ahhh SystemDI honestly would love someone to lay out the problems it solves. Solaris has a similar parallellised startup system, with some similar problems, but it didn't need pid 1.
Anonymous CowardSMF?As an older timer (on my way but not there yet), I never cared for the init.d startup and I dislike the systemd monolithic architecture. What I do like is Solaris SMF and wish Linux would have adopted a method such as or similar to that. I still think SMF was/is a great comprise to the init.d method or systemd manor. I used SMF professionally, but now I have moved on with Linux professionally as Solaris is, well, dead. I only get to enjoy SMF on my home systems, and savor it. I'm trying to like Linux over all these years, but this systemd thing is a real big road block for me to get enthusiastic. I have a hard time understanding why all the other Linux distros joined hands with Redhat and implemented that thing, systemd. Sigh.
You're not alone in liking SMF and Solaris.
AFAICT everyone followed RedHat because they also dominate Gnome, and chose to make Gnome depend on systemd. Thus if one had any aspirations for your distro supporting Gnome in any way, you have to have systemd underneath it all.
RedHat seem to call the shots these days as to what a Linux distro has. I personally have mixed opinions on this; I think the vast anarchy of Linux is a bad thing for Linux adoption ("this is the year of the Linux desktop" don't make me laugh), and Linux would benefit from a significant culling of the vast number of distros out there. However if that did happen and all that was left was something controlled by RedHat, that would be a bad situation.
CrazyOldCatManRemember who 'owns' SMF... namely Oracle. They may well have made it impossible for anyone to adopt.
That stance is not unknown now is it...?
as for systemd, I have bit my teeth and learned to tolerate it. I'll never be as comfortable with it as I was with the old init system but I did start running into issues especially with shutdown syncing with it on some complex systems.
Still not sure if systemd is the right way forward even after four years.
DaggerchildI have a hard time understanding why all the other Linux distros joined hands with Redhat and implemented that thing, systemd
Several reasons:
A lot of other distros use Redhat (or Fedora) as their base and then customise it.
A lot of other distros include things dependant on systemd (Gnome being the one with biggest dependencies - you can just about to get it to run without systemd but it's a pain and every update will break your fixes).
Redhat has a lot of clout.
onefangSMF should be good, and yet they released it before they'd documented it. Strange priorities...
And XML is *not* a config file format you should let humans at. Finding out the correct order to put the XML elements in to avoid unexplained "parse error", was *not* a fun game.
And someone correct me, but it looks like there are SMF properties of a running service that can only be modified/added by editing the file, reloading *and* restarting the service. A metadata and state/dependency tracking system shouldn't require you to shut down the priority service it's meant to be ensuring... Again, strange priorities...
Chris King"XML is *not* a config file format you should let humans at"
XML is a format you shouldn't let computers at, it was designed to be human readable and writable. It fails totally.
ds6If systemd is the MCP, does that make Poettering Sark ?
"Greetings. The Master Control Program has chosen you to serve your system on the Game Grid. Those of you who continue to profess a belief in the Users will receive the standard substandard training which will result in your eventual elimination. Those of you who renounce this superstitious and hysterical belief will be eligible to join the warrior elite of the MCP. You will each receive an identity disc. Everything you do or learn will be imprinted on this disc. If you lose your disc, or fail to follow commands, you will be subject to immediate de-resolution. That will be all".
Hmm, this explains a lot...
timRe: How can we make money?This is scarily possible and undeserving of the troll icon.
Harkens easily to non-critical software developers intentionally putting undocumented, buggy code into production systems, forcing the company to keep the guy on payroll to keep the wreck chugging along.
HerbyThose who do not understand Unix are condemned to reinvent it, poorly."It sounds super basic, but actually it is much more complex than people think," Poettering said. "Because Systemd knows which service a process belongs to, it can shut down that process."
Poettering and Red Hat,
Please learn about "Process Groups"
Init has had the groundwork for most of the missing features since the early 1980s. For example the "id" field in /etc/inittab was intended for a "makefile" like syntax to fix most of these problems but was dropped in the early days of System V because it wasn't needed.
Anonymous CowardProcess 1 IS complicated.That is the main problem. With different processes you get different results. For all its faults, SysV init and RC scripts was understandable to some extent. My (cursory) understanding of systemd is that it appears more complicated to UNDERSTAND than the init stuff.
The init scripts are nice text scripts which are executed by a nice well documented shell (bash mostly). Systemd has all sorts of blobs that somehow do things and are totally confusing to me. It suffers from "anti- kiss "
Perhaps a nice book could be written WITH example to show what is going on.
Now let's see does audio come before or after networking (or at the same time)?
Frankly, systemD's abominable configuration scheme needs to be thrown away, shot, buried, and replaced with more structured methods, because the thesaurus is running out of synonyms.
Lennart Poettering is a German who can barely articulate himself in English. https://en.wikipedia.org/wiki/Lennart_Poettering
Let's ban Poettering from Linux, and his PulseAudio and SystemD. And let's revert back to MATE, as GNOME3 is butt ugly.
ds6Re: Process 1 IS complicated.A connection to PulseAudio, why am I not surprised. Audio that mysteriously refuses to recognize a browser playing audio as a sound source. "Predictable" network interface names? Not to me. I am fine with "enp" and "wlx", but the seemingly random character strings that follow are not predictable. Oxymoronic. I dropped Gnome when it went 2.0. Ubuntu when it went to Unity. Firefox when it redesigned the theme to just appear different.
onefangRe: Process 1 IS complicated.To digress, I am so, so disappointed in Firefox and Mozilla. A shell of what they once were, now dedicated to the Mozilla "brand" as if they're a clothing company. Why has technology in general gone down the shitter? Why is everything so awful? Will anyone save us from this neverending technohell?Duncan MacdonaldRe: Process 1 IS complicated."Why has technology in general gone down the shitter? Why is everything so awful?"
Coz the most important thing in the world is making more profit than you did last quarter. Nothing else is important. "Will anyone save us from this neverending technohell?" I try, but every one ignores me, coz I don't have the marketing department of the profit makers.
DabbbSystemd seems to me to be an attempt at "Embrace, extend, and extinguish" .
With some time any reasonable competent programmer can follow init scripts and find out where any failures in startup are occurring. As init is purely driven by the scripts there are no hidden interactions to cause unexplained failures. The same is NOT true of systemd.
The source of systemd is 15628582 bytes in size - the source of sysvinit is 224531 bytes (less than 2% of the size). (Both sizes from zips of the sources downloaded today - does not include config files makefiles etc - only the contents of the src directory.)
It is of note that the most widely used Linux kernel of all - (the kernel in Android) does NOT use systemd
Quite understandable that people who don't know anything else would accept systemd. For everyone else it has nothing to do with old school but everything to do with unpredictability of systemd.Doctor SyntaxToday I've kickstarted RHEL7 on a rack of 40 identical servers using same script. On about 25 out of 40 postinstall script added to rc.local failed to run with some obscure error about script being terminated because something unintelligible did not like it. It never ever happened on RHEL6, it happens all the time on RHEL7. And that's exactly the reason I absolutely hate it both RHEL7 and systemd.
the people with the problem with it are more of the Torvalds type, old school who want to use Unix-like systemsJay 2FTFY
I have no problem with Red Hat wanting their semi-proprietary system. Unfortunately, in order to preserve their data centre presence they had to eliminate competition from non-systemd distros by ensuring it got into the likes of Debian.
Ah yes, another systemd (RHEL?) annoyance in that by default the actual rc.local script is not set to be executable and that rc-local.service is disabled. It's almost as if someone doesn't want you to be using it.stiineAlso in systemd, rc.local is no longer the last script/thing to be run. So in order to fudge something to work in rc.local I had to create an override module for rc-local.service that has a dependancy on the network being up before it runs.
HieronymusBloggssysV initI've been using Linux ( RedHat, CentOS, Ubuntu), BSD (Solaris, SunOS, freeBSD) and Unix ( aix, sysv all of the way back to AT&T 3B2 servers) in farms of up to 400 servers since 1988 and I never, ever had issues with eth1 becoming eth0 after a reboot. I also never needed to run ifconfig before configuring an interface just to determine what the inteface was going to be named on a server at this time. Then they hired Poettering... now, if you replace a failed nic, 9 times out of 10, the interface is going to have a randomly different name.
"if only all the people put half the effort of writing the tirades about Pottering and SystemD into writing their SysV init replacement we would have a working alternative"Jay 2Why would I feel the need to write a replacement for something which has been working for me without major problems for two decades?
If I did want to stop using sysvinit there are already several working alternatives apart from systemd, but it seems that pretending otherwise is quite a popular activity.
I can see some (well, one) benefit of systemd in the depandancies. So things may only start when a pre-requisite has been met. Unfortunately that is outwighed by the annoyances.Doctor SyntaxFor me the worst is stuffing everything in a binary log and not telling you any error message when you restart the service. So you have to go hunting for an error message and in some cases just end up running manually what the service was meant to do just to see what it's complaining about. It's time I'd rather spend fixing the problem itself.
Like other commenters I tolerate systemd as it's part of RHEL/CentOS/Oracle Linux etc 7.x and that's what we have to use. Obviously that's no endorsement.
The Electron"The more people learn about it, the more they like it."Translation: We define those who don't like it as not have learned enough about it.
HieronymusBloggsFudging the start-up and restoring eth0I knew systemd was coming thanks to playing with Fedora. The quicker start-up times were welcomed. That was about it!
I have had to kickstart many of my CentOS 7 builds
- to disable IPv6 (NFS complains bitterly),
- kill the incredibly annoying 'biosdevname' that turns sensible eth0/eth1 into some daftly named nonsense
- replace Gnome 3 (shudder) with MATE, and fudge start-up processes.
In a previous job, I maintained 2 sets of CentOS 7 'infrastructure' servers that provided DNS, DHCP, NTP, and LDAP to a large number of historical vlans. Despite enabling the systemd-network wait online option, which is supposed to start all networks *before* listening services, systemd would run off flicking all the "on" switches having only set-up a couple of vlans. Result: NTP would only be listening on one or two vlan interfaces. The only way I found to get around that was to enable rc.local and call systemd to restart the NTP daemon after 20 seconds. I never had the time to raise a bug with Red Hat, and I assume the issue still persists as no-one designed systemd to handle 15-odd vlans!?
tekHeddRe: Fudging the start-up and restoring eth0"no-one designed systemd to handle 15-odd vlans!?"
Why would Lennart's laptop need to handle 15 vlans?
Chris KingNot UNIX-like? SNU!From now on, I will call Systemd-based Linux distros "SNU Linux". Because Systemd's Not Unix-like.
It's not clever, but it's the future. From now on, all major distributions will be called SNU Linux. You can still freely choose to use a non-SNU linux distro, but if you want to use any of the "normal" ones, you will have to call it "SNU" whether you like it or not. It's for your own good. You'll thank me later.
StevieRe: Not UNIX-like? SNU!It's not clever, but it's the future. From now on, all major distributions will be called SNU Linux. You can still freely choose to use a non-SNU linux distro, but if you want to use any of the "normal" ones, you will have to call it "SNU" whether you like it or not. It's for your own good. You'll thank me later.
And if you have a pair of machines go belly-up at the same time because of SystemD, is that Death by Snu-Snu ?
jakeBah!It is fascinating to me how the Unix(like) IT community can agree that "things need fixing" yet sit on their hands until someone leaps in, at which point they all know better.
Massive confirmation bias larded on thick there, but my observation stands.
Coming to Korn Shell almost three decades ago after many years working in a very stable mainframe environment I was appalled that every other man page listed "known bugs" with essential utilities (like grep) which had been there for twenty years and more, with no sign anyone was even slightly interested in fixing them.
So I guess my point is: If you think systemd is a load of dingoes kidneys and care passionately about that, why on earth aren't you organizing and specifying-out an alternative that does all the things needed that don't work right with init, yet avoids all the nasty with systemd?
You can complain the systemd design is poor and the implementation bad all you want, but if there is no better alternative - and for the world at large it seems that init isn't hacking it and, as someone so astutely mentioned, Solaris has now a questionable future so *its* "fix" isn't gong to become a systemd rival any time soon - that is what will be taking the carpet from under your feet.
Welcome to my world. When I started a power user was someone who could read paper tape without feeding it through a Westrex. I've lost count of the paradigm changes and Other People's Bad Choices I Have To Live With I've weathered over the years.
Now absent thyselves from my greensward soonest, varlets!
jakeRe: Bah!Nice rant. Kinda.
However, I don't recall any major agreement that init needed fixing. Between BSD and SysV inits, probably 99.999% of all use cases were covered. In the 1 in 100,000 use case, a little bit of C (stand alone code, or patching init itself) covered the special case. In the case of Slackware's SysV/BSD amalgam, I suspect it was more like one in ten million.
So in all reality, systemd is an answer to a problem that nobody had. There was no reason for it in the first place. There still isn't a reason for it ... especially not in the 999,999 places out of 1,000,000 where it is being used. Throw in the fact that it's sticking its tentacles[0] into places where nobody in their right mind would expect an init as a dependency (disk partitioning software? WTF??), can you understand why us "old guard" might question the sanity of people singing it's praises?
[0] My spall chucker insists that the word should be "testicles". Tempting ...
Nate AmsdenRe: However, I don't recall any major agreement that init needed fixing."Then why did Red Hat commit their resources, time and effort to developing and releasing systemd into the world at large?"
Marketing making engineering decisions would be my guess.
"Are you telling me they decided to change it up for the sake of it?"
Essentially, yes.
"Comments in this very thread show that init is not up to the job of firing up computers that *aren't* single-purpose servers."
Those are exceptions to the rule. In the 35 years since SysV init was released, I think I can count on on both hands the number of times I've had to actually code something that it couldn't handle. And those cases were extreme edge cases (SLAC, Sandia, NASA, USGS, etc.). And note that in none of those cases would systemd have been any help. In a couple of those cases, BSD worked where SysV didn't.
"And considering that every desktop distro I've looked at now comes with a daily FDA requirement of systemd, it would appear as though those building the distros don't agree with you either."
Do they actually not agree with me? Or is it more that they are blindly following Redhat's lead, simply because it's easier to base their distro on somebody else's work than it is to rollout their own?
"saying that the startup can be got to work with some script changes and a little bit of C code is a non-starter. "
Correct. For the vast majority of folks. But then, for the vast majority of folks a box-stock Slackware installation will work quite nicely. They are never going to even know that init exists, much less if it's SysV, BSD or systemd. They don't care, either. Nor should they. All they want to do is B0rk faces, twatter about, and etc. The very concept of PID1 is foreign to people like that. So why make this vast sweeping change THAT DOESN'T HELP THE VAST MAJORITY OF PEOPLE WHO HAVE IT INFLICTED UPON THEM? Especially when it adds complexity and makes the system less secure and less stable?
GrumpenKrautas a linux user for 22 users(20 of which on Debian, before that was Slackware)I am new to systemd, maybe 3 or 4 months now tops on Ubuntu, and a tiny bit on Debian before that.
I was confident I was going to hate systemd before I used it just based on the comments I had read over the years, I postponed using it as long as I could. Took just a few minutes of using it to confirm my thoughts. Now to be clear, if I didn't have to mess with the systemd to do stuff then I really wouldn't care since I don't interact with it (which is the case on my laptop at least though laptop doesn't have systemd anyway). I manage about 1,000 systems running Ubuntu for work, so I have to mess with systemd, and init etc there.
If systemd would just do ONE thing I think it would remove all of the pain that it has inflicted on me over the past several months and I could learn to accept it. That one thing is, if there is an init script, RUN IT. Not run it like systemd does now. But turn off ALL intelligence systemd has when it finds that script and run it. Don't put it on any special timers, don't try to detect if it is running already, or stopped already or whatever, fire the script up in blocking mode and wait till it exits.
My first experience with systemd was on one of my home servers, I re-installed Debian on it last year, rebuilt the hardware etc and with it came systemd. I believe there is a way to turn systemd off but I haven't tried that yet. The first experience was with bind. I have a slightly custom init script (from previous debian) that I have been using for many years. I copied it to the new system and tried to start bind. Nothing. I looked in the logs and it seems that it was trying to interface with rndc(internal bind thing) for some reason, and because rndc was not working(I never used it so I never bothered to configure it) systemd wouldn't launch bind. So I fixed rndc and systemd would now launch bind, only to stop it within 1 second of launching. My first workaround was just to launch bind by hand at the CLI (no init script), left it running for a few months. Had a discussion with a co-worker who likes systemd and he explained that making a custom unit file and using the type=forking option may fix it.. That did fix the issue.
Next issue came up when dealing with MySQL clusters. I had to initialize the cluster with the "service mysql bootstrap-pxc" command (using the start command on the first cluster member is a bad thing). Run that with systemd, and systemd runs it fine. But go to STOP the service, and systemd thinks the service is not running so doesn't even TRY to stop the service(the service is running). My workaround for my automation for mysql clusters at this point is to just use mysqladmin to shut the mysql instances down. Maybe newer mysql versions have better systemd support though a co-worker who is our DBA and has used mysql for many years says even the new Maria DB builds don't work well with systemd. I am working with Mysql 5.6 which is of course much much older.
Next issue came up with running init scripts that have the same words in them, in the case of most recently I upgraded systems to systemd that run OSSEC. OSSEC has two init scripts for us on the server side (ossec and ossec-auth). Systemd refuses to run ossec-auth because it thinks there is a conflict with the ossec service. I had the same problem with multiple varnish instances running on the same system (varnish instances were named varnish-XXX and varnish-YYY). In the varnish case using custom unit files I got systemd to the point where it would start the service but it still refuses to "enable" the service because of the name conflict (I even changed the name but then systemd was looking at the name of the binary being called in the unit file and said there is a conflict there).
fucking a. Systemd shut up, just run the damn script. It's not hard.
Later a co-worker explained the "systemd way" for handling something like multiple varnish instances on the system but I'm not doing that, in the meantime I just let chef start the services when it runs after the system boots(which means they start maybe 1 or 2 mins after bootup).
Another thing bit us with systemd recently as well again going back to bind. Someone on the team upgraded our DNS systems to systemd and the startup parameters for bind were not preserved because systemd ignores the /etc/default/bind file. As a result we had tons of DNS failures when bind was trying to reach out to IPv6 name servers(ugh), when there is no IPv6 connectivity in the network (the solution is to start bind with a -4 option).
I believe I have also caught systemd trying to mess with file systems(iscsi mount points). I have lots of automation around moving data volumes on the SAN between servers and attaching them via software iSCSI directly to the VMs themselves(before vsphere 4.0 I attached them via fibre channel to the hypervisor but a feature in 4.0 broke that for me). I noticed on at least one occasion when I removed the file systems from a system that SOMETHING (I assume systemd) mounted them again, and it was very confusing to see file systems mounted again for block devices that DID NOT EXIST on the server at the time. I worked around THAT one I believe with the "noauto" option in fstab again. I had to put a lot of extra logic in my automation scripts to work around systemd stuff.
I'm sure I've only scratched the surface of systemd pain. I'm sure it provides good value to some people, I hear it's good with containers (I have been running LXC containers for years now, I see nothing with systemd that changes that experience so far).
But if systemd would just do this one thing and go into dumb mode with init scripts I would be quite happy.
Anonymous CowardRe: as a linux user for 22 usersNow more seriously: it really strikes me that complaints about systemd come from people managing non-trivial setups like the one you describe. While it might have been a PITA to get this done with the old init mechanism, you could make it work reliably.
If systemd is a solution to any set of problems, I'd love to have those problems back!
Linux without systemd: Devuan ASCII or Ubuntu 16 LTSIt's time to install Debian without systemd, called Devuan: https://dev1galaxy.org/viewtopic.php?id=2047
Don't use a Linux with systemd! Stay with Ubuntu 14 LTS or Ubuntu 16 LTS, or the new Devuan ASCII (Debian).
And stop supporting Ubuntu 18 LTS, Debian and RedHat. They are sleeping with the evil cancerous corp. MSFT is paying RedHat and Ubuntu to EEE Linux with systemd
doug_bostromRe: What's the alternative?Unfortunately it's not really an option for businesses that need safety of support contract, either from Red Hat or Oracle and majority of environments which actually pay sysadmins money do run either RHEL or OL.
So there's no alternative once RHEL6/OL6 are EOL.
There might be an opportunity for Oracle (the only real vendor that has developers and resources required) to create systemd-less variant of OL7 and put the nail in the coffin of RHEL7 while gaining lots of new customers and significantly grow OL install base, but they don't seem interested doing it.
Systemd is the Linux world's MS Office "ribbon," another of those sad inflection points where developers have crawled up their own asses and lost sight of the light of day.cjcoxKabukiwookieHe's a painEarly on I warned that he was trying to solve a very large problem space. He insisted he could do it with his 10 or so "correct" ways of doing things, which quickly became 20, then 30, then 50, then 90, etc.. etc. I asked for some of the features we had in init, he said "no valid use case". Then, much later (years?), he implements it (no use case provided btw).
Interesting fellow. Very bitter. And not a good listener. But you don't need to listen when you're always right.
Re: Spherical wheel is superior.I do know that I never saw a non-distribution provided init script that handled correctly the basic of corner cases – service already running
This only shows that you don't have much real life experience managing lots of hosts.
like application double forking when it shouldn't
If this is a problem in the init script, this should be fixed in the init script. If this is a problem in the application itself, it should be fixed in the application, not worked around by the init mechanism. If you're suggesting the latter, you should not be touching any production box.
"La, la, la, sysv is working fine on my machine, thankyouverymuch" is not what you can call "participating in discussion".
Shoving down systemd down people's throat as a solution to a non-existing problem, is not a discussion either; it is the very definition of 'my way or the highway' thinking.
now in the real world, people that have to deal with init systems on daily basis
Indeed and having a bunch of sub-par developers, focused on the 'year of the Linux desktop' to decide what the best way is for admins to manage their enterprise environment is not helping.
"the dogs may bark, but the caravan moves on"
Indeed. It's your way or the highway; I thought you were just complaining about the people complaining about systemd not wanting to have a discussion, while all the while it's systemd proponents ignoring and dismissing very valid complaints.
|
|
|
Oct 16, 2018 | n5.nabble.com
On 08/07/14 02:22, Always Learning wrote:
>
> On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
>
>> On 07/07/2014 07:47 PM, Always Learning wrote:
>>> Reading about systemd, it seems it is not well liked and reminiscent of
>>> Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
>>>
>>> Is there a practical alternative to omnipresent, or invasive, systemd ?
>
>> So you are following the thread on the Fedora list? I have been
>> ignoring it.
>
> No. I read some of
> http://www.phoronix.com/scan.php?page=news_topic&q=systemd
>
> The systemd proponent, advocate and chief developer? wants to
> abolish /etc and /var in favour of having the /etc and /var data
> in /usr.
>
> Seems a big revolution is being forced on Linux users when stability and
> the "same old familiar Linux" is desired by many, including me.
> ... [ show rest of quote ]
It's already started. Some configs have already moved from /etc to /usr
under el7.Whilst I'm as resistant to change as the next man, I've learned you can't fight it so best start getting used to it ;-)
|
|
|
Oct 15, 2018 | blog.ungleich.ch
Let's say every car manufacturer recently discovered a new technology named "doord", which lets you open up car doors much faster than before. It only takes 0.05 seconds, instead of 1.2 seconds on average. So every time you open a door, you are much, much faster!
Many of the manufacturers decide to implement doord, because the company providing doord makes it clear that it is beneficial for everyone. And additional to opening doors faster, it also standardises things. How to turn on your car? It is the same now everywhere, it is not necessarily to look for the keyhole anymore.
Unfortunately though, sometimes doord does not stop the engine. Or if it is cold outside, it stops the ignition process, because it takes too long. Doord also changes the way how your navigation system works, because that is totally related to opening doors, but leads to some users being unable to navigate, which is accepted as collateral damage. In the end, you at least have faster door opening and a standard way to turn on the car. Oh, and if you are in a traffic jam and have to restart the engine often, it will stop restarting it after several times, because that's not what you are supposed to do. You can open the engine hood and tune that setting though, but it will be reset once you buy a new car.
|
|
|
Oct 15, 2018 | linux.slashdot.org
AntiSol ( 1329733 ) , Saturday August 29, 2015 @03:52PM ( #50417111 )Re:Approaching the Singularity ( Score: 4 , Funny)Future History of Init Systems
Future History of Init Systems
- 2015: systemd becomes default boot manager in debian.
- 2017: "complete, from-scratch rewrite" [jwz.org]. In order to not have to maintain backwards compatibility, project is renamed to system-e.
- 2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.
- 2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.
- 2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.
- 2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.
- 2029: systemk codebase used as basis for a military project to create a strong AI, known as "project skynet". Software behaves paradoxically and project is terminated.
- 2033: systeml - "system lean" - a "back to basics", from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, "system mean", a fork, used in security-focused distros.
- 2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.
- 2142: systemu project, based on a derivative of systemk, introduces "Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity". Millions die. The survivors declare "thou shalt not make an init system in the likeness of the human mind" as their highest law.
- 2147: systemv - a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of "keep it simple, stupid" and "do one thing, and do it well". People's computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.
|
|
|
Oct 15, 2018 | linux.slashdot.org
thegarbz ( 1787294 ) , Sunday August 30, 2015 @04:08AM ( #50419549 )Re:Hang on a minute... ( Score: 5 , Funny)I honestly, seriously sometimes wonder if systemd is Skynet... or, a way for Skynet to 'waken'.Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. At 2:15am it crashes. No one knows why. The binary log file was corrupted in the process and is unrecoverable.
All anyone could remember is a bug listed in the systemd bug tracker talking about su which was classified as WON'T FIX as the developer thought it was a broken concept.
|
|
|
Oct 15, 2018 | linux.slashdot.org
Anonymous Coward , Saturday August 29, 2015 @11:37AM ( #50415825 )Cryptic command names ( Score: 5 , Funny)Great to see that systemd is finally doing something about all of those cryptic command names that plague the unix ecosystem.
Upcoming systemd re-implementations of standard utilities: ls to be replaced by filectl directory contents [pathname] grep to be replaced by datactl file contents search [plaintext] (note: regexp no longer supported as it's ambiguous) gimp to be replaced by imagectl open file filename draw box [x1,y1,x2,y2] draw line [x1,y1,x2,y2] ...
Anonymous Coward , Saturday August 29, 2015 @11:58AM ( #50415939 )Re: Cryptic command names ( Score: 3 , Funny)Oh look, another Powershell
|
|
|
Oct 15, 2018 | linux.slashdot.org
RabidReindeer ( 2625839 ) , Saturday August 29, 2015 @11:38AM ( #50415833 )What's with all the awkward systemd command names? ( Score: 5 , Insightful)I know systemd sneers at the old Unix convention of keeping it simple, keeping it separate, but that's not the only convention they spit on. God intended Unix (Linux) commands to be cryptic things 2-4 letters long (like "su", for example). Not "systemctl", "machinectl", "journalctl", etc. Might as well just give everything a 47-character long multi-word command like the old Apple commando shell did.
Seriously, though, when you're banging through system commands all day long, it gets old and their choices aren't especially friendly to tab completion. On top of which why is "machinectl" a shell and not some sort of hardware function? They should have just named the bloody thing command.com.
|
|
|
Oct 14, 2018 | linux.slashdot.org
nightfire-unique ( 253895 ) , Monday December 11, 2017 @12:45AM ( #55713823 )Problems with Linux that should have been solved ( Score: 5 , Insightful)Here's a list of actual problems that should have been solved instead of introducing the nightmare of systemd upon the Linux (Debian specifically) world:
- Forceful, unconditional kernel operations. When I say "unmount this filesystem," I'm not asking a question. When I say "terminate this process," I expect the process to be removed from memory and the runqueue, regardless of consequences.
- When I say "reboot" I mean "reboot." Hangs are not okay, ever.
- Actual, real soft NFS failures. Do not hang during boot for any reason unless that share is marked hard,nointr. Do not hang during shutdown/reboot, either.
- Enforce GPL-standard syntax on new incoming utilities. If you want into the package tree, use a GNU parsing library and use it correctly. Perhaps a standardized syntax wrapper available for package maintainers.
- Bolt simple parallelization, triggers and flow control onto init/rc.
- Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
- Standardize and fix bluetooth support ffs.
My $0.02, as a 25-year Linux admin.
gweihir ( 88907 ) , Monday December 11, 2017 @01:56AM ( #55714055 )Re:Problems with Linux that should have been solve ( Score: 5 , Insightful)I disagree on SELinux, not because its interface is well-designed (it is not), but because it is needed for some things.
On the rest, I fully agree. And instead, systemd solves things that were already solved and does it badly. The amount of stupidity in that decision is staggering.
drinkypoo ( 153816 ) writes: < [email protected] > on Monday December 11, 2017 @10:03AM ( #55715515 ) Homepage JournalRe:Problems with Linux that should have been solve ( Score: 5 , Informative)I really struggle to reconcile the Slashdot view that systemd is total crap and the fact that every major Linux distro has switched to it.The Linux ecosystem is not sane . Redhat wanted more control of Linux so they pushed systemd. GNOME developers are easily distracted by shiny things (as proof I submit GNOME 3) so they went ahead and made GNOME dependent on it. And then Debian (which most Linux distributions are based upon) adopted systemd because GNOME depended on it.
There were some other excuses, but that's the biggest reason. You can blame Redhat and Debian for this clusterfuck, and really, only a small handful of people in the Debian community are actually responsible for Debian's involvement.
Debian's leaders were split almost down the middle on whether they should go to systemd. This is why major changes should require a 2/3 vote (or more!)
phantomfive ( 622387 ) , Monday December 11, 2017 @05:43AM ( #55714555 ) JournalRe:Problems with Linux that should have been solve ( Score: 5 , Informative)Can I ask, why don't you and other admins/devs like you start to contribute to systemd?Lennart Poettering has specifically said that he will not accept many important kinds of patches, for example he refuses to merge any patch that improves cross-platform compatibility.
And what's the reason, because people on forums are complaining? Because binary log files break the UNIX philosophy?Here is my analysis of systemd, spread across multiple posts (links towards the bottom) [slashdot.org]. It's poorly written software (the interfaces are bad, you can read through my links for more explanation), and that will only get worse over time if an effort isn't made to isolate it over time. This is basic system architecture.
silentcoder ( 1241496 ) , Monday December 11, 2017 @06:02AM ( #55714599 )Re:Problems with Linux that should have been solve ( Score: 5 , Insightful)>To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better
"Better" is a subjective term. Software (and any product really) does not have some absolute measurable utility. It's utility is specific to an audience. The fact that the major distros switch is probably strong evidence that systemd is "better" for distro developers. But the utility it brings them may not apply to all users, or even any particular user.
A big part of the reason people were upset was exactly that - the key reasons distros had for switching was benefits to people building distros which subsequent users would never experience. These should not have trumped the user experience.All that would still have been fine - we could easily have ended up with a world that had systemd for those who wanted it, and didn't have it for those who didn't want it. Linux systems are supposed to be flexible enough that you can set them up to whatever purpose you desire.
So where the real anger came in was the systemd's obsessive feature-creep made it go into a lots and lots of areas that have nothing to do with it's supposed purpose (boot process management), in that area it's biggest advantages are only useful to people building distributions (who have to maintain thousands of packages and ensure they reliable handle their bootup requirements regardless of what combination of them is actually installed- systemd genuinely did make that easier on them - but no user or admin ever experiences that scenario). But that feature creep itself wasn't even the issue, the issue was that - as it entered into all these unrelated areas (login was the first of many) - it broke compatibility with the existing software to do those jobs. This meant that, if you built a system to support systemd, that same system could not use any alternatives. So now, you had to create hard dependencies on systemd to support it at all - for distros to gain those benefits, they had to remove the capacity for anybody to forgo them, or alternatively provide two versions of every package - even ones that never touch the boot process and get no benefit from systemd's changes there.
And the trouble is - in none of those other areas has it offered anything of significant value to anybody. Logind doesn't actually do anything that good old login didn't do anyway, but it's incompatible so a distro that compiles it's packages around logind can't work with anything else. Replacing the process handler... and not only did it not add any new functionality it broke some existing functionality (granted, in rarer edge cases -but there was no reason for any breakage at all because these were long-solved problems).
Many years ago, I worked as a unix admin for a company that developed for lots of different target unix systems. As such I had to maintain test environments running all the targets. I had several linux systems running about 5 different distros, I had solaris boxes with every version from 8 onwards (yep, actual Sparcs), I had IBM's running AIX, I even had two original (by then 30 year old) DEC Alphas running Tru64... and I had several HPUX boxes.
At the time, while adminning all these disparate unix environments on a day-to-day basis and learning all their various issues and problems - I came to announce routinely that Solaris pre-Version-10 had the worst init system in the word to admin, but the worst Unix in the world was definitely HPUX because HPUX was the only Unix where I could not, with absolute certainty, know that if I kill -9 a process - that process would definitely be gone. WIped out of memory and the process table with absolutely no regard for anything else - it's a nuclear option, and it's supposed to work that way - because sometimes that what you need to keep things running.
SystemD brought to Linux an init system that replicated everything I used to hate about the Solaris 8/9 init system - but what's worse than that, it brought the one breakage that got me to declare HPUX the absolute worst unix system in history: it made kill -9 less than one hundred percent absolutely, infallibly reliable (nothing less than perfect is good enough - because perfect HAS been achieved there, in fact outside of HPUX and SystemD - no other Unix system has ever had anything LESS than absolute perfection on this one).I absolutely despise it. And yet I'm running systemd systems - both professionally and at home, because I'm a grown man now, I have other responsibilities, I don't want to spend all my time working and even my home playing-with-the-computer time is limited so I want to focus on interesting stuff - there is simply not enough time for the amount of effort required to use a non-niche distro. I don't have the time to custom build the many software the small distros simply don't have packages for and deal with the integration issues of not using proper distro-built-and-tested packages.
I live with systemd. I tolerate it. It's not an unsurvivable trainsmash -but I still hate it. It still makes my life harder than it used to be.
It makes my job more difficult and time-consuming. it makes my personal ventures more complicated and annoying. It adds no value whatsoever to my life (seriously - who reboots a Linux system often enough to CARE about boot-time - you only DO that if you have a security patch for the kernel or glibc - anything else is a soft-restart) it just adds hassle and extra effort... the best thing I can say about it is that it adds LESS extra effort than avoiding it does, but that's not because it's superior to me in any way - it's because it's taken over every distro with a decent sized package repository that isn't "built-by-hand" like arch or gentoo.silentcoder ( 1241496 ) , Monday December 11, 2017 @08:49AM ( #55715147 )Re: Problems with Linux that should have been solv ( Score: 4 , Insightful)Tough question. Depends what that functionality is. Compatibility is valuable but sometimes it must be sacrificed to deal with technical debt or make genuine progress. Even Microsoft had a huge compatibility break with Vista which was needed at the time (even if Vista itself was atrocious).
It would depend what those features were, what benefits it gave me. It would be a trade off and should be evaluated as such. A major sacrifice requires an even more major advantage to be worthwhile. I've yet to see any such advantage from anything systemd has added. I'm not saying advantages don't exist, I'm saying whatever they may be they do not benefit me, personally, in any measurable way. The disadvantages however do, and compatibility is the least of them.
Config outside/etc is a major deal - it utterly breaks with a standard around which disk space allocation is done professionally. /use ought to not even need backups because everything there is supposed to be installed and never hand edited. It means modifying backup strategy which is a big, very risky, cange. Logs aren't where I expect them. Boot errors flash on screen and disappear before you can read them so you have to remember to go look in the binary log to figure out if it was something serious. I was never a fan of system V. It was a complicated, slow, mess if code duplication. It needed a replacement. I was championing Richard Gooch's make-init circa 2001 (and his devfs, the forerunner to udev, was in my kernels - I built a powerful hardware autoconfig system on it in 2005 when I built the first installable live CD distribution, the way they all work now: I invented it [I later discovered that pclinuxos had invented the same thing independently at the same time but Ubuntu for example still came on two disks, a live CD and separate text based installation disk and more than once I had machines where the live cd ran great but the installed system broke due to disparate hardware setup systems]). Later I praised upstart - it was a fantastic unit system that solved the issues with system V, retained compatibility but was easy to admin, standards and philosophy compliant and fast. It was even parallel.
That is the system that should have won the unit wars. I'm not a huge fan of Ubuntu's eclectic side, unity has always been a fugly unusable mess of a desktop to me - but upstart was great, that and PPAs are Ubuntu two most amazing accomplishments. Sadly one got lost instead of being the world changing tech it deserved to be and it lost to a wholly inferior technology for no sane reason.
It's the Amiga of the Linux world.
fisted ( 2295862 ) , Monday December 11, 2017 @06:11AM ( #55714613 )Re:Problems with Linux that should have been solve ( Score: 3 )To me, the fact that the major distros have adopted systemd is strong evidence that it is probably better.Raises the question, better for whom? Systemd seems to make some things easier for distro maintainers, at the cost of fucking shit up for users and admins.
That said, Debian's vote on the matter was essentially 50:50, and they're going to keep supporting SysV init. Most distros are descendants of Debian, so there's that. Redhat switched for obvious reasons (having the main systemd developer on their payroll and massively profiting from increased support demands).
With Debian and Redhat removed, what remains on the list of major distros [futurist.se]?
Yeah.. strong evidence...
lkcl ( 517947 ) writes: < [email protected] > on Monday December 11, 2017 @01:01AM ( #55713891 ) Homepagefaster boot time as well ( Score: 5 , Interesting)it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.
Anonymous Coward , Monday December 11, 2017 @01:04AM ( #55713901 )It violates fundamental Unix principles ( Score: 5 , Insightful)Do one thing, and do it well. Systemd has eaten init, udev, inetd, syslog and soon dhcpd. Yes, that is getting ridiculous.
fahrbot-bot ( 874524 ) , Monday December 11, 2017 @01:10AM ( #55713923 )It's the implementation. ( Score: 5 , Insightful)I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example. I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
In short, systemd has too many things stuffed into its kitchen sink -- if you want that, use Emacs
:-)
[ Note, I'm a fan and long-time user of Emacs, so the joke's in good fun. ]
|
|
|
Oct 15, 2018 | linux.slashdot.org
Opportunist ( 166417 ) , Monday December 11, 2017 @05:19AM ( #557 14501 )Systemd moved Linux closer to Windows ( Score: 5 , Interesting)Windows is a very complex system. Not necessarily because it needs to be complex, but rather because of "wouldn't it be great if we could also..." thinking. Take the registry. Good idea in its core, a centralized repository for all configuration files. Great. But wouldn't it be nice if we could also store some states in there? And we could put the device database in there, too. And how about the security settings? And
... And eventually you had the mess you have now, where we're again putting configuration files into the %appdata% directory. But when we have configuration in there already anyway, couldn't we... and we could sync this for roaming, ya know...
Which is the second MS disease. How many users actually need roaming? 2, maybe 3 out of 10? The rest is working on a stationary desktop, never moving, never roaming. But they have to have this feature, needed or not. And if you take a look through the services, you'll notice that a lot of services that you simply know you don't need MUST run because the OS needs them for some freakish reason. Because of "wouldn't it be great if this service did also...".
systemd now brought this to the Linux world. Yes, it can do a lot. But unfortunately it does so, whether you need it or not. And it requires you to take these "features" into account when configuring it, even if you have exactly zero use for them and wouldn't potentially not even know just wtf they're supposed to do.
systemd is as overengineered as many Windows components. And thus of course as error prone. And while it can make things more manageable for huge systems, everything becomes more convoluted and complicated for anyone that has no use for these "wouldn't it be great if it also..." features.
|
|
|
Oct 15, 2018 | linux.slashdot.org
Plus1Entropy ( 4481723 ) , Monday December 11, 2017 @02:34AM ( #55714139 )chaoskitty ( 11449 ) writes: < john AT sixgirls DOT org > on Monday December 11, 2017 @03:14AM ( #55714245 ) HomepageI have no problem with systemd ( Score: 4 , Interesting)Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change". Whether its nostalgia or sunk-cost fallacy, I can't say, but beyond that it seems much more like a philosophical difference than a practical one. It just reminds me of people's refusal to use the metric system, for no better reason than they are unfamiliar with it.
If systemd is so terrible, then why did a lot of the major distros switch over? If they didn't, it would just be a footnote in the history of open source: "Hey remember when they tried to replace sysV and init with that stupid thing with the binary log files? What was it called? SystemP?" The fact that Devaun has not overtaken Debian in any real way (at least from what I've seen, feel free to correct me if I'm wrong) indicates that my experience with systemd is the norm, not the exception. The market has spoken.
I read TFA, there is not one single specific bug or instability mentioned about systemd. What is the "tiny detail" that split the community? I have no idea, because TFA doesn't say what it is. I know that part of the philosophy behind Linux is "figuring it out yourself", but if you don't explain to me these low level kernel details (if that's even what they are; again, I have no idea), then don't expect people like me to be on your side. Linux is just a tool to me, I don't have any emotional attachment to it, so if things are working OK I am not going to start poking around under the hood just because someone posts an article claiming there are problems, but never specifying what those problems are and how they affect me as a user.
Honestly TFA reads like "We are having development problems, therefore systemd sucks." I get that when major changes to the platform happens there are going to be issues and annoyances, but that's the way software development has always been and will always be. Even if systemd was perfect there would still be all kinds of compatibility issues and new conventions that developers would have to adapt to. That's what I would expect to happen whenever any major change is made to a widely used and versatile platform like Linux.
Even Linus doesn't really care [zdnet.com]:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."I'm not saying systemd is "better" or "the right answer". If you want to stick to distros that don't use it, that's up to you. But what I am saying is, get over it.
Re:I have no problem with systemd ( Score: 5 , Insightful)Plus1Entropy ( 4481723 ) writes:Perhaps you have had no problems with systemd because you aren't trying to use it to do much.
Lots of people, myself included, have had issues trying to get things which are trivial in pre-systemd or on other OSes to work properly and consistently on systemd. There are many, many, many examples of issues. If someone asked me for examples, I'd have a hard time deciding where to start because so many things have been gratuitously changed. If you really think there aren't examples, just read this thread.
On the other hand, I have yet to see real technical discussion about problems that systemd apparently is fixing. I honestly and openmindedly am curious about what makes systemd good, so I've tried on several occasions to find these discussions where good technical reasoning is used to explain the motivations behind systemd. If they exist, I haven't found any yet. I'm hoping some will appear as a result of this thread.
But you bring up the idea that the "market has spoken"? You do realize that a majority of users use Windows, right? And people in the United States are constantly electing politicians who directly hurt the people who vote for them more than anyone else. It's called marketing. Just because something has effective marketing doesn't mean it doesn't suck.
Re: ( Score: 3 )amorsen ( 7485 ) writes: < [email protected] > on Monday December 11, 2017 @04:35AM ( #55714405 )Don't let the perfect be the enemy of the good. If you have so many examples that you "don't know where to start", then start anywhere. You don't have to come at me with the best, most perfect example. Any example will do! I'm actually very interested. And I have, out of curiosity, looked a bit. But like you looking for why systemd is better, I came across a similar problem.
Your reply just continues the cycle I spoke of, where people who potentially know better than me, like you, claim there are problems bu
Re:I have no problem with systemd ( Score: 5 , Insightful)systemd fails silently if something is wrong in
/etc/fstab. It just doesn't finish booting. Which is moderately annoying if you have access to the system console and you can guess that an unchanged /etc/fstab from before systemd that worked for a while with systemd is now suddenly toxic If you do not have easy access to the system console or you are not blessed with divine inspiration, that is quite a bit more than annoying. Thanks to the binary log files you cannot even boot something random and read the logs, but at least you aren't missing anything, because nothing pertinent to the error is logged anyway.
The problem is that one camp won't admit that old init is a pile of shit from the 80's whose only virtue is that the stench has faded over time, and the other camp won't admit that their new shiny toy needs to be understandable and debuggable.
A proper init system needs dependencies and service monitoring. init + monit does not cut it today. Systemd does that bit rather impressively well. It's just terrible at actually booting the system, all the early boot stuff that you could depend on old init to get right every time, or at least spit out aggressive messages about why it failed.
marcansoft ( 727665 ) writes: < (moc.tfosnacram) (ta) (rotceh) > on Monday December 11, 2017 @05:25AM ( #55714513 ) HomepageRe:I have no problem with systemd ( Score: 4 , Interesting)Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.
lkcl ( 517947 ) writes: < [email protected] > on Monday December 11, 2017 @05:05AM ( #55714467 ) HomepageRe:I have no problem with systemd ( Score: 5 , Informative)People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change".no, that's not it. people who have been using linux for a long time usually *know the corner-cases better*. in other words, they know *exactly* why it doesn't work and won't work, they know *exactly* the hell that it can and will create, under what circumstances, and they know *precisely* how they've been betrayed by the rail-roaded decisions made by distros without consulting them as to the complexities of the scenario to which they have been (successfully up until that point) deploying a GNU/Linux system.
also they've done the research - looked up systemd vs other init systems on the CVE mitre databases and gone "holy fuck".
also they've seen - perhaps even reported bugs themselves over the years - how well bugs are handled, and how reasonable and welcoming (or in some sad cases not, but generally it's ok) the developers are... then they've looked up the systemd bug database and how pottering abruptly CLOSES LEGITIMATE BUGREPORTS and they've gone "WHAT the fuck??"
also, they've been through the hell that was the "proprietary world", if they're REALLY old they've witnessed first-hand the "Unix Wars" and if they're not that old they experienced the domination of Windows through the 1990s. they know what a monoculture looks like and how dangerous that is for a computing eco-system.
in short, i have to apologise for pointing this out: they can read the danger signs far better than you can. sorry!
:) marcansoft ( 727665 ) writes: < (moc.tfosnacram) (ta) (rotceh) > on Monday December 11, 2017 @05:10AM ( #55714477 ) HomepageRe:I have no problem with systemd ( Score: 4 , Informative)Everyone* switched to systemd because everyone* was using something that was much, much worse. Traditional sysvinit is a joke for service startup, it can't even handle dependencies in a way that actually works reliably (sure, it works until a process fails to start or hangs, then all bets are off, and good luck keeping dependencies starting in the right order as the system changes). Upstart is a mess (with plenty of corner case bugs) and much harder to make sense of and use than systemd. I'm a much happier person writing systemd units than Upstart whatever-you-call-thems on the Ubuntu systems I have to maintain.
The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business. It's a monolithic repo, and it's trying as hard as it can to position itself as a hard dependency for every Linux system on the face of the planet. Distros needed* a new init system, and they got an attempt to take over the Linux ecosystem along with it.
* The exception is Gentoo, which for over 15 years has had an rc-script system (later rewritten as OpenRC) based on sysvinit as PID 1 but with real dependencies, easy to write initscripts, and all the features you might need in a server environment (works great for desktops too). It's the only distro that has had a truly server-worthy init system, with the right balance of features and understandability and ease of maintenance. Gentoo is the only major distro that hasn't switched to systemd, though it does offer systemd as an option for those who want it. OpenRC was proposed as a systemd alternative in the Debian talks, but Gentoo didn't advertise it, and nobody on the Debian side cared to give it a try. Interestingly Poettering seems to be *very* careful to *never, ever* mention OpenRC when he talks about how systemd is better than everything else. I wonder why. Gentoo developers have had to fork multiple things assimilated by systemd (like udev) in order to keep offering OpenRC as an option.
|
|
|
Oct 15, 2018 | linux.slashdot.org
lkcl ( 517947 ) writes: < [email protected] > on Monday December 11, 2017 @01:55AM ( #55714053 ) HomepageRe:It's the implementation. ( Score: 5 , Interesting)I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in
/dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service. then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ [angband.pl] to
/etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN. in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ [angband.pl] is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irrationally closing extremely important bugreports. we may have been shocked that there were people who *literally* wanted to kill him, but those people did not react the way that they did, despite their inability to properly and rationally express themselves, without having a good underlying reason for doing so.
software libre is supposed to be founded on ethical principles. that's what the GPL license is actually about (the four freedoms are a reflection of ETHICAL standards). can you honestly declare that systemd has been developed - and then adopted - in a truly ethical fashion? because everything i see about systemd says the complete and absolute opposite. and that is why i won't allow it on any computers that i run - not just because technically it's an inferior design with no overall redeeming features (mass-adoption is NOT a redeeming feature, it's a monoculture-level microsoft-emulating disaster), but because its developers and its blatant rail-roaded adoption across so many distributions fundamentally violates the ethical principles on which the software libre community is *supposed* to be based.
|
|
|
Oct 15, 2018 | linux.slashdot.org
mysidia ( 191772 ) , Saturday August 29, 2015 @11:34AM ( #50415809 )Bullshit ( Score: 5 , Insightful)Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
RightwingNutjob ( 1302813 ) , Saturday August 29, 2015 @12:38PM ( #50416133 )Re:Hang on a minute... ( Score: 5 , Interesting)I've had a job now for about 10 years where a large fraction of the time I wear a software engineer's hat. Looking back now, I can point to a lot of design decisions in the software I work on that made me go "WTF?" when I first saw them as a young'un, but after having to contend with them for a good number of years, and thinking about how I would do them differently, I've come to the conclusion that the original WTF may be ugly and could use some polish, but the decisionmaking that produced it was fundamentally sound.
The more I hear about LP and systemd, the more it screams out that this guy just hasn't worked with Unix and Linux long enough to understand what it's used for and why it's built the way it is. His pronouncements just sound to me like an echo of my younger, stupider, self (and I just turned 30), and I can't take any of his output seriously. I really hope a critical mass of people are of the same mind with me and this guy can be made to redirect his energies somewhere where it doesn't fuck it up for the rest of us.
magamiako1 ( 1026318 ) , Saturday August 29, 2015 @01:42PM ( #50416503 )TheGratefulNet ( 143330 ) , Saturday August 29, 2015 @02:19PM ( #50416699 )Re:Hang on a minute... ( Score: 5 , Insightful)Welcome to IT. Where the youngin's come in and rip up everything that was built for decades because "oh that's too complicated".
Re:Hang on a minute... ( Score: 5 , Insightful)its the other way around. we used to have small, simple programs that did not take whole systems to build and gigs of mem to run in. things were easier to understand and concepts were not overdone a hundred times, just because 'reasons'.
now, we have software that can't be debugged well, people who are current software eng's have no attention span to fix bugs or do proper design, older guys who DO remember 'why' are no longer being hired and we can't seem to stand on our giants' shoulders anymore. again, because 'reasons'.
|
|
|
Oct 15, 2018 | linux.slashdot.org
rubycodez ( 864176 ) , Saturday August 29, 2015 @11:53AM ( #50415919 )Anonymous Coward writes:Re:Bullshit ( Score: 4 , Interesting)Poettering is so very wrong on many things, having a superficial and shallow understanding of why Unix is designed the way it is. He is just a hobbyist, not a hardened sys admin with years of experience. It's almost time to throw popular Linux distros in the garbage can and just go to BSD
Change for change's sake ( Score: 2 , Insightful)0123456 ( 636235 ) , Saturday August 29, 2015 @12:24PM ( #50416057 )he is the guy who delivers."Delivering" the wrong thing is not an asset, it's a liability.
And that's why Poettering is a liability to the Linux community.
Re:Bullshit ( Score: 4 , Insightful)Anonymous Coward , Saturday August 29, 2015 @12:53PM ( #50416235 )There are plenty of programmers who can spew out hundreds of lines of crap code in a day.
The problem is that others then have to spend years fixing it.
It's even worse when you let the code-spewers actually design the system, because you'll never be allowed to go back and redo things right.
Re:Bullshit ( Score: 5 , Insightful)lucm ( 889690 ) writes:He bring new code, but brings nothing new. That's called re-inventing the wheel, and in Poettering's case, the old wheels worked better and didn't go flat as often, and were easier for average people to fix.
Re: ( Score: 3 )rnturn ( 11092 ) , Saturday August 29, 2015 @04:37PM ( #50417391 )What we're dealing with now is something that neither "average person" nor "master geek" find easy to fix.This is the best summary I've seen of the whole systemd thing. They try to Apple-ize linux but it's half-baked and neither more user-friendly or more reliable than the stuff they replace.
Re:Bullshit ( Score: 4 , Insightful)techno-vampire ( 666512 ) , Saturday August 29, 2015 @04:02PM ( #50417183 ) Homepage``They try to Apple-ize linux but it's half-baked and neither more user-friendly or more reliable than the stuff they replace.I've had the same complaint about CUPS -- Apple's screwball replacement for simple lpd -- for years. (And it's not just the Linux version that, IMHO, sucks. I recently had to live through using CUPS in an Apple shop and getting hard copy of anything was a real time sink.) I have a hard time figuring out what problem CUPS was intended to solve. All I can come up with was that it was shiny and new whereas lpd was old (but reliable). For my trusty, rock-solid HP LaserJet, I keep an old Linux distribution running so I can set it up using LPRng. A couple of lines in a text file and -- Voila! -- I have a print queue. Time spent^Wwasted in CUPS' GUI never seemed to make anything work.
Systemd and well, just about anything Poettering touches is more obtuse than what it replaces, has commands that are difficult to remember, require more typing (making them prone to typos), and don't make much sense. Am I looking for the status of "servicename" or am I looking for the status of "servicename.target"? What's the difference? The guy's pushing me back to Slackware. Or, as someone above mentioned, BSD.
The way this should end ( Score: 4 , Insightful)Kavonte ( 4239129 ) writes:PoetteringOS
In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is, and does his best to shove his version down everybody's throat. And, since his version is far more complex, far more pervasive and much, much harder to use or maintain, the community suffers. I do wish he would get off the pot and start developing the One True (Pottering) kernel so that the rest of the world can go back to ignoring him.
Re: ( Score: 3 , Interesting)rubycodez ( 864176 ) writes:I tried a bunch of them a few years ago. I found that FreeBSD was the best one, even though it doesn't come with a GUI by default, and so you have to install it afterwards. (Seems kind of ridiculous to me, but that's how they package it for some reason.) I don't know if they've changed the documentation since then, but note that you don't have to compile X11 and your window manager, as there is a system that can install pre-compiled packages that they don't bother to mention until after they tell you how
Re: ( Score: 3 )Anonymous Coward , Saturday August 29, 2015 @11:55AM ( #50415925 )But the are distros based on FreeBSD such as PC-BSD that have the UI and other desktop features and apps canned and ready to go
Re:Bullshit ( Score: 5 , Informative)Just like he considers exit statuses, stderr, and syslog "broken concepts." That is why systemd supports them so poorly. He just doesn't understand why those things are critical. An su system that doesn't properly log to syslog is a serious security problem.
phantomfive ( 622387 ) , Saturday August 29, 2015 @01:55PM ( #50416559 ) JournalRe:Bullshit ( Score: 5 , Interesting)ok, I just spent my morning researching the problem, and why the feature got built, starting from here [github.com] (linked to in the article). Essentially, the timeline goes like this:
1) On Linux, the su command uses PAM to manage logins (that's probably ok).
2) systemd wrote their own version of PAM (because containers)
3) Unlike normal su, the systemd-pam su doesn't transfer over all environment variables, which led to:
4) A bug filed by a user, that the XDG_RUNTIME_DIR variable wasn't being maintained when su was run.
5) Lennart said that's because su is confusing, and he wouldn't fix it.
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)It's important to note that there isn't a conspiracy here to destroy su. The process would more accurately be called "design by feature accretion," which doesn't really make you feel better, but it's not malice.
gweihir ( 88907 ) , Saturday August 29, 2015 @12:35PM ( #50416121 )Re:Bullshit ( Score: 5 , Insightful)Deciding what a full login comprises is the shell's responsibility, not your init system's job.And certainly not the job of one Poettering, who still has not produced one piece of good software in his life.
Anonymous Coward , Saturday August 29, 2015 @12:27PM ( #50416069 )Re:Bullshit ( Score: 5 , Interesting)If you want a FULL shell
Oh I dont know 'su bash' usually works pretty fng good...It does if you are fine to only get root privilege, without FULL environment of root. But if you would have to make sure you have FULL root environment, first discarding anything you had in calling user and then executing root users environment (/etc/profile etc.) you better use "su - bash" or "sudo -i". Compare what you get both ways "su bash" vs "su - bash" with runnint "set" and "env" commands, please.
Failing to have FULL root environment, can have security implications (umask, wrong path, wrong path order,
...) which may or may not be critical depending what system you are operating and to whom. Also some commands may fail or misbehave just because of path differences etc. Above is trivial information and should be clear without further explanation anyone running *nix systems for someone else as part of job ie. work professionally on the field. Incase you don't, it's still useful information you should learn about sysadmin of the platform you happen to use.
|
|
|
Oct 15, 2018 | linux.slashdot.org
wnfJv8eC ( 1579097 ) , Saturday August 29, 2015 @12:43PM ( #50416173 )Thinking about leaving any systemd linux behind ( Score: 5 , Insightful)I am really tired of systemd. So really tired of the developers shoving that shit down the linux throat. It's not pretty, it seems to grow out of control, taking on more and more responsibility
.... I don't even have an idea how to look at my logs anymore. Nor how to clear the damn things out! Adding toolkits should make the system as clear to understand as it was, not more complex. If it gets any worse it might as well be Windows 10! init was easy to understand, easy to use. syslog was easy read easy to understand and easy to clear. All this bull about "it's a faster startup" is just ... well bull. I'm using a computer 20 times faster than I was a decade ago. You think 20 seconds off a minute startup is an achievement? It's seconds on a couple of days uptime; big f*cking deal. Redhat, Fedora, turn away from the light and return to your roots! rl117 ( 110595 ) writes: < rleigh@[ ]elibre.net ['cod' in gap] > on Saturday August 29, 2015 @03:57PM ( #50417157 ) HomepageRe:What path have we chosen? ( Score: 5 , Interesting)I can't speak for any distribution, after quitting as a Debian developer some months back, for several reasons one of which was systemd. But speaking for myself, it was quite clear during the several years of "debate" (i.e. flamewars) over systemd that this was the inevitable outcome. The debate over replacing the "init system" was a complete red herring; systemd knows no boundaries and continues to expand its tentacles over the system as it subsumes more and more components.
My problem with this is that once a distribution has adopted systemd, they have to basically just accept whatever crap is shovelled out in the subsequent systemd releases--it's all or nothing and once you're on the train you can't get off it. This was absolutely obvious years ago. Quality software engineering and a solid base system walked out of the door when systemd arrived; I certainly did.
When I commit to a system such as a Linux distribution like Debian, I'm making an investment of my time and effort to use it. I do want to be able to rely on future releases being sane and not too radical a departure from previous releases--I am after all basing my work and livelihood upon it. With systemd, I don't know what I'm going to get with future versions and being able to rely on the distribution being usable and reliable in the future is now an unknown. That's why I got off this particular train before the jessie release. After 18 years, that wasn't an easy decision to make, but I still think it was the right one. And yes, I'm one of the people who moved to FreeBSD. Not because I wanted to move from Debian after having invested so much into it personally, but because I was forced to by this stupidity. And FreeBSD is a good solid dose of sanity.
|
|
|
Oct 15, 2018 | linux.slashdot.org
walterbyrd ( 182728 ) , Saturday August 29, 2015 @11:09PM ( #50418815 )Ever stop and ask why? ( Score: 5 , Insightful)This has been going on for years, and has years more to go. This is a long term strategy.
But why?
Why has Red Hat been replacing standard Linux components with Red Hat components, when the Red Hat stuff is worse?
Why isn't systemd optional? It is just an init replacement, right? Why does Red Hat care which init you use?
Why is systemd being tied to so many other components?
Why binary logging? Who asked for that?
Why throw away POSIX, and the entire UNIX philosophy? Clearly you do not have to do that just to replace init.
Why does Red Hat instantly berate anybody who does not like systemd? Why the barrage of ad hominem attacks systemd critics?
I think there is only one logical answer to all of those questions, and it's glaringly obvious.
|
|
|
Oct 15, 2018 | linux.slashdot.org
sjames ( 1099 ) , Saturday August 29, 2015 @12:55PM ( #50416253 ) Homepage Journalrubycodez ( 864176 ) , Saturday August 29, 2015 @11:55AM ( #50415923 )Re:Is it April 1st already? ( Score: 2 )Actually, the 'magic' in su is in the kernel. Basically, since it's marked suid root, the kernel sets the uid on the new process to root before it even starts running. The program itself just then decides if it is willing to do anything for you.
Re:BSD is looking better all the time ( Score: 2 , Insightful)0123456 ( 636235 ) , Saturday August 29, 2015 @12:25PM ( #50416063 )That's what Poettering has been doing his whole life, getting into good open source projects, squatting and then shitting all over them. The infection, stink and filth then linger for decades. He's a cancer on open source.
Re:BSD is looking better all the time ( Score: 5 , Insightful)el_chicano ( 36361 ) writes:That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.Where 'modernize' is a codeword for 'shit all over'.
Re: ( Score: 2 )phantomfive ( 622387 ) , Saturday August 29, 2015 @12:35PM ( #50416117 ) JournalThat's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.I can see that as being one of his goals but if you want to improve Linux why a new init system plus? I did not hear any system admins asking for this.
He would be considered a saint if he would do something useful like fix the desktop environments so the "Year of the Linux Desktop" finally gets here.
Re:BSD is looking better all the time ( Score: 5 , Insightful)RabidReindeer ( 2625839 ) writes:That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.Yeah, that's true. He sees features people want, and he builds them. For example, Debian distro builders were frustrated writing init scripts, so Poettering made something that filled the need of those distro builders [slashdot.org]. That's why it got adopted, because it contained features they wanted.
The problem of course is that he doesn't understand the Unix way [catb.org], especially when it comes to good interfaces between code [slashdot.org] (IMNSHO).
The people who like systemd tend to like the features.......the people who dislike it, the architecture.
Re: ( Score: 3 )phantomfive ( 622387 ) , Saturday August 29, 2015 @02:32PM ( #50416759 ) JournalI had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Because Poettering doesn't understand "modular", I don't get just the good stuff - it's all or nothing. And because systemd isn't even modular as an overgrown bloated monstrosity, the only way to avoid it is to either run old distros or some other
Re:BSD is looking better all the time ( Score: 4 , Insightful)ezakimak ( 160186 ) , Saturday August 29, 2015 @02:16PM ( #50416681 )I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.Yeah, that's basically the problem. Systemd is really three different things:
1) init system
2) cgroups manager (cgroups architecture is still crap, btw)
3) session managerIt probably does more stuff, but it's hard to keep track of it all
Re:BSD is looking better all the time ( Score: 5 , Informative)Electricity Likes Me ( 1098643 ) writes:OpenRC++
openrc init scripts are fairly straight forward.
Coupled with gentoo's baselayout, and the config file layout is fairly normalized also.Re: ( Score: 3 )menkhaura ( 103150 ) writes: < [email protected] > on Saturday August 29, 2015 @12:39PM ( #50416147 ) Homepage JournalYes and init scripts are just a bastion of race-free stateful design, and service monitoring. Except not at all those things.
Re:BSD is looking better all the time ( Score: 5 , Insightful)Please remember devuan (http://www.devuan.org), a Debian fork which aims to do away with systemd and all that bullcrap. It's picking up steam, and I believe things like these make it more and more worth it to help the new fork.
|
|
|
Oct 15, 2018 | linux.slashdot.org
prefec2 ( 875483 ) , Saturday August 29, 2015 @12:39PM ( #50416149 )Strange path he is taking ( Score: 2 )First of all, there are two types of German engineering. Good engineering and over engineering. And there is a fine line between them. And it looks like Mr. Poettering crossed it. However, it could also be German advertising and that is either bad or worse. In general, you do not build bloated components. In old Unix days these where called programs and could be combined in various ways including pipes and files. In GNU days many of these programs were bundled together in one archive, but stayed separate.
Now with systemd I am puzzled, is he really integrating that thing in the init system?
Integrating something which does not belong to a init system? In that case he is nuts and definitely over engineering. Or he has just created a new program and just bundles it in the same package as systemd.
Then this is acceptable, however, a little weird. It would be like bundling systemd with a sound service.
Session separation or VM separation is a task of the operating system. And you may write any number of tool to call the necessary OS functions, but PLEASE keep them out of components which have nothing to do with that.
|
|
|
Oct 15, 2018 | linux.slashdot.org
0123456 ( 636235 ) , Saturday August 29, 2015 @12:31PM ( #50416085 )Re:Embrace, Extend, Extinguish ( Score: 2 )The feature creep will be fast and merciless, but I'm just a systemd "hater", right?The rumours that vi will become part of systemd are groundless, comrade. Anyone who suggests such a thing is guilty of agitation and propaganda, and will be sent to the re-education camps.
|
|
|
Oct 15, 2018 | linux.slashdot.org
slashways ( 4172247 ) , Saturday August 29, 2015 @11:42AM ( #50415845 )ThorGod ( 456163 ) writes:Security ( Score: 5 , Insightful)Doing everything as systemd do, and adding 'su', is likely a new security threat.
Re: ( Score: 2 )Microlith ( 54737 ) writes:That's a pretty good point I think
Re: ( Score: 3 , Interesting)phantomfive ( 622387 ) , Saturday August 29, 2015 @12:42PM ( #50416169 ) JournalNo offense, but I see lots of attacks like this on systemd. Can you explain how it is "likely a new security threat" or is it simply FUD?
Re:Security ( Score: 5 , Insightful)Can you explain how it is "likely a new security threat" or is it simply FUD?Bruce Schneier (in Cryptography Engineering ) pointed out that to keep something secure, you need to keep it simple (because exploits hide in complexity). When you have a large, complex, system that does a lot of different things, there's a high chance that there are security flaws. If you go to DefCon, speakers will actually say that one of the things they look for when doing 'security research' is a large, complex interface.
So that's the reason. When you see a large complex system running as root, it means hackers will be root.
phantomfive ( 622387 ) , Saturday August 29, 2015 @11:42AM ( #50415853 ) JournalQuietLagoon ( 813062 ) , Saturday August 29, 2015 @12:10PM ( #50415985 )quality engineering ( Score: 4 , Insightful)There is no reason the creation of privileged sessions should depend on a particular init system. It's fairly obvious that is a bad idea from a software design perspective. The only architectural reason to build it like that is because so many distros already include systemd, so they don't have to worry about getting people to adopt this (incidentally, that's the same reason Microsoft tried to deeply embed the browser in their OS.....remember active desktop?)
If there are any systemd fans out there, I would love to hear them justify this from an architectural perspective.
Re:quality engineering ( Score: 5 , Insightful)Poettering is following the philosophy that has created nearly every piece of bloated software that is in existence today: the design is not complete unless there is nothing more than can be added. Bloated software feeds upon the constant influx of new features, regardless of whether those new features are appropriate or not. They are new therefore they are justified.
.
You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.
-- Antoine de Saint-Exuperypenguinoid ( 724646 ) , Saturday August 29, 2015 @11:51AM ( #50415899 ) Homepage JournalQuietLagoon ( 813062 ) , Saturday August 29, 2015 @12:02PM ( #50415953 )Upgrade ( Score: 5 , Funny)You should replace it with the fu command.
systemd is a broken concept ( Score: 5 , Insightful)Anonymous Coward writes:
... So every command that Poettering thinks may be broken is added to the already bloated systemd?
.
How long before there is nothing left to GNU/Linux besides the Linux kernel and systemd?Re: ( Score: 3 , Insightful)Anonymous Coward writes:I'd just like to interject for moment. What you're refering to as GNU/Linux, is in fact, Systemd/Linux, or as I've recently taken to calling it, Systemd plus Linux. GNU is not a modern userland unto itself, but rather another free component of a fully functioning Linux system that needs to be replaced by a shitty nonfunctional init system, broken logging system, and half-assed vital system components comprising a fully broken OS as defined by Lennart Poettering.
Many computer users run a version of the Syste
Seems like a 'while they were at it' sort of thing ( Score: 2 , Interesting)tlambert ( 566799 ) , Saturday August 29, 2015 @12:23PM ( #50416047 )So systemd has ambition of being a container and VM management infrastucture (I have no idea how this should make sense for VMs though.)
machinectl shell looks to be designed to be some way to attach to a container environment with an interactive shell, without said container needing to do anything to provide such a way in. While they were at the task of doing that not too terribly unreasonable thing, they did the same function for what they call '.host', essentially meaning they can use the same syntax for
I, for one, welcome this addition... ( Score: 5 , Insightful)I, for one, welcome this addition... every privilege escalation path you add is good for literally years of paid contract work.
Anonymous Coward , Saturday August 29, 2015 @12:11PM ( #50415997 )Seems like a 'while they were at it' sort of thing ( Score: 2 , Interesting)So systemd has ambition of being a container and VM management infrastucture (I have no idea how this should make sense for VMs though.)
machinectl shell looks to be designed to be some way to attach to a container environment with an interactive shell, without said container needing to do anything to provide such a way in. While they were at the task of doing that not too terribly unreasonable thing, they did the same function for what they call '.host', essentially meaning they can use the same syntax for current container context as guest contexts. A bit superfluous, but so trivial as not to raise any additional eyebrows (at least until Lennart did his usual thing and stated one of the most straightforward, least troublesome parts of UNIX is hopelessly broken and the world desperately needed his precious answer). In short, systemd can have their little 'su' so long as no one proposes removal of su or sudo or making them wrappers over the new and 'improved' systemd behavior.
Funnily enough, they used sudo in the article talking about how awesome an idea this is... I am amused.
tlambert ( 566799 ) , Saturday August 29, 2015 @12:23PM ( #50416047 )I, for one, welcome this addition... ( Score: 5 , Insightful)I, for one, welcome this addition... every privilege escalation path you add is good for literally years of paid contract work.
butlerm ( 3112 ) , Saturday August 29, 2015 @12:25PM ( #50416059 )Only incidentally similar to su ( Score: 5 , Informative)machinectl shell is only incidentally similar to su. Its primary purpose is to establish an su-like session on a different container or VM. Systemd refers to these as 'machines', hence the name machinectl.
http://www.freedesktop.org/sof... [freedesktop.org]
su cannot and does not do that sort of thing. machinectl shell is more like a variant of rsh than a replacement for su.
LVSlushdat ( 854194 ) , Saturday August 29, 2015 @04:09PM ( #50417233 )rl117 ( 110595 ) writes: < rleigh@[ ]elibre.net ['cod' in gap] > on Saturday August 29, 2015 @04:47PM ( #50417429 ) HomepageRe:What path have we chosen? ( Score: 4 , Informative)I currently run Ubuntu 14.04, and see where part of systemd has already begun its encroachment on what *had* been a great Linux distro. My only actual full-on experience so far with systemd is trying to get Virtualbox guest additions installed on a CentOS7 vm... I've installed those additions countless times since I started using VBox, and I think I could almost do the install in my sleep.. Not so with CentOS7.. systemd bitches loudly with strange "errors" and when it tells me to use journalctl to see what the error was, there *is* no error.. But still the additions don't install... I'm soooooo NOT looking forward to the next LTS out of Ubuntu, which I'm told will be infested with this systemd crap... Guess its time to dust off the old Slackware DVD and get acquainted with Pat again... GO FUCK YOURSELF, POETTERING.....
Re:What path have we chosen? ( Score: 4 , Informative)PPH ( 736903 ) , Saturday August 29, 2015 @01:30PM ( #50416429 )The main thing I noticed with Ubuntu 15.04 at work is that rather than startup becoming faster and more deterministic as claimed, it's actually slower and randomly fails due to what looks like some race condition, requiring me to reset the machine. So the general experience is "meh", plus annoyance that it's actually degraded the reliability of booting.
I also suffered from the "we won't allow you to boot if your fstab contains an unmountable filesystem". So I reformatted an ext4 filesystem as NTFS to accomplish some work task on Windows; this really shouldn't be a reason to refuse to start up. I know the justification for doing this, and I think it's as bogus as the first time I saw it. I want my systems to boot, not hang up on a technicality because the configuration or system wasn't "perfect". i.e. a bit of realism and pragmatism rather than absolutionist perfectionism--like we used to have when people like me wrote the init scripts.
Fully isolated? ( Score: 5 , Interesting)alvieboy ( 61292 ) , Saturday August 29, 2015 @02:49PM ( #50416849 ) HomepageI just skimmed TFA (Pottering's rambling really don't make much
sense anyway). By "fully isolated", it sounds like machinectl breaks the audit trail that su has always supported (not being 'fully isolated' by design). Many *NIX systems are configured to prohibit root logins from anything other than the system console. And the reason that su doesn't do a 'full login' either as root or another user is to maintain the audit trail of who (which system user) is actually running what.
Lennart, this UNIX/Linus stuff appears to be way over your head. Sure, it seems neat for lots of gamers who can't be bothered with security and just want all the machine cycles for rendering FPS games. Perhaps you'd be better off playing with an XBox.
What about sandwiches ? ( Score: 3 )lucm ( 889690 ) , Saturday August 29, 2015 @04:03PM ( #50417185 )So, now we have to say "machinectl shell systemd-run do make me a sandwich" ?
Looks way more complicated.
https://xkcd.com/149/ [xkcd.com]
Fountainhead anyone? ( Score: 3 )This systemd guy is just like Ellsworth Toohey. As long as the sheep follow he'll keep pushing things further and further into idiotland and have a good laugh in the process.
"Kill man's sense of values. Kill his capacity to recognise greatness or to achieve it. Great men can't be ruled. We don't want any great men. Don't deny conception of greatness. Destroy it from within. The great is the rare, the difficult, the exceptional. Set up standards of achievement open to all, to the least, to the most inept – and you stop the impetus to effort in men, great or small. You stop all incentive to improvement, to excellence, to perfection. Laugh at Roark and hold Peter Keating as a great architect. You've destroyed architecture. Build Lois Cook and you've destroyed literature. Hail Ike and you've destroyed the theatre. Glorify Lancelot Clankey and you've destroyed the press. Don't set out to raze all shrines – you'll frighten men, Enshrine mediocrity - and the shrines are razed."
-- Ellsworth Toohey
|
|
|
Dec 10, 2017 | blog.ungleich.ch
Good morning,my name is Nico Schottelius, I am the CEO of ungleich glarus ltd . It is a beautiful Sunday morning with the house surrounded by a meter of snow. A perfect time to write about the importance of Devuan to us, but also for the future of Linux.
But first, let me put some warning out here: Dear Devuan friends, while I honor your work, I also have to be very honest with you: in theory, you should not have done this. Looking at creating Devuan, which means splitting of Debian, economically, you caused approximately infinite cost. Additional maintenance to what is being done in Debian already plus the work spent to clean packages of their systemd dependencies PLUS causing headache for everyone else: Should I use Debian? Is it required to use Devuan? What are the advantages of either? Looking at it from a user point of view, you added "a second, almost equal option". That's horrible!
Think of it in real world terms: You are in a supermarket and there is a new variant of a product that you used to buy (let it be razor blades, toilet paper rolls, whiskey, you name it). Instead of instantly buying what you used to buy, you might spend minutes staring at both options, comparing and in the end still being unable to properly choose, because both options are TOO SIMILAR. Yes, dear Devuan community, you have to admit it, you caused this cost for every potential Linux user.
For those who have read until here and actually wonder, why systemd is considered to be a problem, let me give you a real world analogy:
Let's say every car manufacturer recently discovered a new technology named "doord", which lets you open up car doors much faster than before. It only takes 0.05 seconds, instead of 1.2 seconds on average. So every time you open a door, you are much, much faster!
Many of the manufacturers decide to implement doord, because the company providing doord makes it clear that it is beneficial for everyone. And additional to opening doors faster, it also standardises things. How to turn on your car? It is the same now everywhere, it is not necessarily to look for the keyhole anymore.
Unfortunately though, sometimes doord does not stop the engine. Or if it is cold outside, it stops the ignition process, because it takes too long. Doord also changes the way how your navigation system works, because that is totally related to opening doors, but leads to some users being unable to navigate, which is accepted as collateral damage. In the end, you at least have faster door opening and a standard way to turn on the car. Oh, and if you are in a traffic jam and have to restart the engine often, it will stop restarting it after several times, because that's not what you are supposed to do. You can open the engine hood and tune that setting though, but it will be reset once you buy a new car.
Some of you might ask yourselves now "Is systemd THAT bad?". And my answer to it is: No. It is even worse. Systemd developers split the community over a tiny detail that decreases stability significantly and increases complexity for not much real value. And this is not theoretical: We tried to build Data Center Light on Debian and Ubuntu, but servers that don't boot, that don't reboot or systemd-resolved that constantly interferes with our core network configuration made it too expensive to run Debian or Ubuntu.
Yes, you read right: too expensive. While I am writing here in flowery words, the reason to use Devuan is hard calculated costs. We are a small team at ungleich and we simply don't have the time to fix problems caused by systemd on a daily basis. This is even without calculating the security risks that come with systemd. Our objective is to create a great, easy-to-use platform for VM hosting, not to walk a tightrope.
So, coming back to the original title of this essay: the importance of Devuan. Yes, the Devuan community creates infinite economic costs, but it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people.
Yes, you read right: what the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error-prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error-prone complexity and instability.
With systemd the main advantage to use Linux is obsolete.
So what is the importance of Devuan? It is not only crucial to Linux users, but to everyone who is running servers. Or rockets. Or watches. Or anything that actually depends on a stable operating system.
Thus I would like to urge every reader who made it until here: Do what we do:
Support Devuan.
Support the future with stability.
|
|
|
Oct 14, 2018 | linux.slashdot.org
drinkypoo ( 153816 ) writes: < [email protected] > on Sunday May 27, 2018 @11:14AM ( #56683018 ) Homepage JournalRe:That would break scripts which use the UI ( Score: 5 , Informative)In general, it's better for application programs, including scripts to use an application programming interface (API) such as/proc, rather than a user interface such as ifconfig, but in reality tons of scripts do use ifconfig and such. ...and they have no other choice, and shell scripting is a central feature of UNIX.
The problem isn't so much new tools as new tools that suck. If I just type ifconfig it will show me the state of all the active interfaces on the system. If I type ifconfig interface I get back pretty much everything I want to know about it. If I want to get the same data back with the ip tool, not only can't I, but I have to type multiple commands, with far more complex arguments.
The problem isn't new tools. It's crap tools.
gweihir ( 88907 ) , Sunday May 27, 2018 @12:22PM ( #56683440 )Re:That would break scripts which use the UI ( Score: 5 , Insightful)The problem isn't new tools. It's crap tools.Crap tools written by morons with huge egos and rather mediocre skills. Happens time and again an the only sane answer to these people is "no". Good new tools also do not have to be pushed on anybody, they can compete on merit. As soon as there is pressure to use something new though, you can be sure it is inferior.
Anonymous Coward , Sunday May 27, 2018 @02:00PM ( #56684068 )Re:That would break scripts which use the UI ( Score: 5 , Interesting)The problem isn't new tools. It's crap tools.The problem isn't new tools. It's not even crap tools. It's the mindset that we need to get rid of an ~70KB netstat, ~120KB ifconfig, etc. Like others have posted, this has more to do with the ego of the new tools creators and/or their supporters who see the old tools as some sort of competition. Well, that's the real problem, then, isn't it? They don't want to have to face competition and the notion that their tools aren't vastly superior to the user to justify switching completely, so they must force the issue.
Now, it'd be different if this was 5 years down the road, netstat wasn't being maintained*, and most scripts/dependents had already been converted over. At that point there'd be a good, serious reason to consider removing an outdated package. That's obviously not the debate, though.
* Vs developed. If seven year old stable tools are sufficiently bug free that no further work is necessary, that's a good thing.
locofungus ( 179280 ) , Sunday May 27, 2018 @02:46PM ( #56684296 )Re:That would break scripts which use the UI ( Score: 4 , Informative)If I type ifconfig interface I get back pretty much everything I want to know about itHow do you tell in ifconfig output which addresses are deprecated? When I run ifconfig eth0.100 it lists 8 global addreses. I can deduce that the one with fffe in the middle is the permanent address but I have no idea what the address it will use for outgoing connections.
ip addr show dev eth0.100 tells me what I need to know. And it's only a few more keystrokes to type.
Anonymous Coward , Sunday May 27, 2018 @11:13AM ( #56683016 )Re:So ( Score: 5 , Insightful)Following the systemd model, "if it aint broken, you're not trying hard enough"...
Anonymous Coward , Sunday May 27, 2018 @11:35AM ( #56683144 )That's the reason ( Score: 5 , Interesting)It done one thing: Maintain the routing table.
"ip" (and "ip2" and whatever that other candidate not-so-better not-so-replacement of ifconfig was) all have the same problem: They try to be the one tool that does everything "ip". That's "assign ip address somewhere", "route the table", and all that. But that means you still need a complete zoo of other tools, like brconfig, iwconfig/iw/whatever-this-week.
In other words, it's a modeling difference. On sane systems, ifconfig _configures the interface_, for all protocols and hardware features, bridges, vlans, what-have-you. And then route _configures the routing table_. On linux... the poor kids didn't understand what they were doing, couldn't fix their broken ifconfig to save their lives, and so went off to reinvent the wheel, badly, a couple times over.
And I say the blogposter is just as much an idiot.
Per various people, netstat et al operate by reading various files in/proc, and doing this is not the most efficient thing in the world So don't use it. That does not mean you gotta change the user interface too. Sheesh.
However, the deeper issue is the interface that netstat, ifconfig, and company present to users.No, that interface is a close match to the hardware. Here is an interface, IOW something that connects to a radio or a wire, and you can make it ready to talk IP (or back when, IPX, appletalk, and whatever other networks your system supported). That makes those tools hardware-centric. At least on sane systems. It's when you want to pretend shit that it all goes awry. And boy, does linux like to pretend. The linux ifconfig-replacements are IP-only-stack-centric. Which causes problems.
For example because that only does half the job and you still need the aforementioned zoo of helper utilities that do things you can have ifconfig do if your system is halfway sane. Which linux isn't, it's just completely confused. As is this blogposter.
On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example.linux' ifconfig always was enormously shitty here. It outputs lots of stuff I expect to find through netstat and it doesn't output stuff I expect to find out through ifconfig. That's linux, and that is NOT "traditional" compared to, say, the *BSDs.
As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.Was it ever? linux is the great pretender here.
But then, "linux" embraced the idiocy oozing out of poettering-land. Everything out of there so far has caused me problems that were best resolved by getting rid of that crap code. Point in case: "Network-Manager". Another attempt at "replacing ifconfig" with something that causes problems and solves very few.
locofungus ( 179280 ) , Sunday May 27, 2018 @03:27PM ( #56684516 )Anonymous Coward writes:Re:That's the reason ( Score: 4 , Insightful)It done one thing: Maintain the routing table.Should the ip rule stuff be part of route or a separate command?
There are things that could be better with ip. IIRC it's very fussy about where the table selector goes in the argument list but route doesn't support this at all.
I also don't think route has anything like 'nexthop dev $if' which is a godsend for ipv6 configuration.
I stayed with route for years. But ipv6 exposed how incomplete the tool is - and clearly nobody cares enough to add all the missing functionality.
Perhaps ip addr, ip route, ip rule, ip mroute, ip link should be separate commands. I've never looked at the sourcecode to see whether it's mostly common or mostly separate.
Re: That's the reason ( Score: 3 , Informative)DamnOregonian ( 963763 ) , Sunday May 27, 2018 @09:11PM ( #56686032 )^this^
The people who think the old tools work fine don't understand all the advanced networking concepts that are only possible with the new tools: interfaces can have multiple IPs, one IP can be assigned to multiple interfaces, there's more than one routing table, firewall rules can add metadata to packets that affects routing, etc. These features can't be accommodated by the old tools without breaking compatibility.
Re:That's the reason ( Score: 3 )DamnOregonian ( 963763 ) , Monday May 28, 2018 @02:26AM ( #56686960 )Someone cared enough to implement an entirely different tool to do the same old jobs plus some new stuff, it's too bad they didn't do the sane thing and add that functionality to the old tool where it would have made sense.It's not that simple. The iproute2 suite wasn't written to *replace* anything.
It was written to provide a user interface to the rapidly expanding RTNL API.
The net-tools maintainers (or anyone who cared) could have started porting it if they liked. They didn't. iproute2 kept growing to provide access to all the new RTNL interfaces, while net-tools got farther and farther behind.
What happened was organic. If someone brought net-tools up to date tomorrow and everyone liked the interface, iproute2 would be dead in its tracks. As it sits, myself, and most of the more advanced level system and network engineers I know have been using iproute2 for just over a decade now (really, the point where ifconfig became on incomplete and poorly simplified way to manage the networking stack)Re:That's the reason ( Score: 4 , Informative)TeknoHog ( 164938 ) writes:Nope. Kernel authors come up with fancy new netlink interface for better interaction with the kernel's network stack. They don't give two squirts of piss whether or not a user-space interface exists for it yet. Some guy decides to write an interface to it. Initially, it only support things like modifying the routing rule database (something that can't be done with route) and he is trying to make an implementation of this protocal, not try to hack it into software that already has its own framework using different APIs.
This source was always freely available for the net-tools guys to take and add to their own software.
Instead, we get this. [sourceforge.net]
Nobody is giving a positive spin. This is simply how it happened. This is what happens when software isn't maintained, and you don't get to tell other people to maintain it. You're free, right now, today, to port the iproute2 functionality into net-tools. They're unwilling to, however. That's their right. It's also the right of other people to either fork it, or move to more functional software. It's your right to help influence that. Or bitch on slashdot. That probably helps, too.Re: ( Score: 2 )gweihir ( 88907 ) , Sunday May 27, 2018 @12:18PM ( #56683412 )keep the command names the same but rewrite how they function?Well, keep the syntax too, so old scripts would still work. The old command name could just be a script that calls the new commands under the hood. (Perhaps this is just what you meant, but I thought I'd elaborate.)
Re:So ( Score: 4 , Insightful)TheRaven64 ( 641858 ) writes:What was the reason for replacing "route" anyhow? It's worked for decades and done one thing.Idiots that confuse "new" with better and want to put their mark on things. Because they are so much greater than the people that got the things to work originally, right? Same as the systemd crowd. Sometimes, they realize decades later they were stupid, but only after having done a lot of damage for a long time.
Re: ( Score: 2 )zippthorne ( 748122 ) writes:I didn't RTFA (this is Slashdot, after all) but from TFS it sounds like exactly the reason I moved to FreeBSD in the first place: the Linux attitude of 'our implementation is broken, let's completely change the interface'. ALSA replacing OSS was the instance of this that pushed me away. On Linux, back around 2002, I had some KDE and some GNOME apps that talked to their respective sound daemon, and some things like XMMS and BZFlag that used
/dev/dsp directly. Unfortunately, Linux decided to only support s Re: ( Score: 3 )goombah99 ( 560566 ) , Sunday May 27, 2018 @11:08AM ( #56682986 )On the other hand, on most systems, vi is basically an alias to vim....
Bad idea ( Score: 5 , Insightful)goombah99 ( 560566 ) writes:Unix was founded on the ideas of lots os simple command line tools that do one job well and don't depend on system idiosyncracies. If you make the tool have to know the lower layers of the system to exploit them then you break the encapsulation. Polling proc has worked across eons of linux flavors without breaking. when you make everthing integrated it creates paralysis to change down the road for backward compatibility. small speed game now for massive fragility and no portability later.
Re: ( Score: 3 )llamalad ( 12917 ) , Sunday May 27, 2018 @11:46AM ( #56683198 )Gnu may not be unix but it's foundational idea lies in the simple command tool paradigm. It's why GNU was so popular and it's why people even think that Linux is unix. That idea is the character of linux. if you want an marvelously smooth, efficient, consistent integrated system that then after a decade of revisions feels like a knotted tangle of twine in your junk drawer, try Windows.
Re:Bad idea ( Score: 5 , Insightful)The error you're making is thinking that Linux is UNIX.
It's not. It's merely UNIX-like. And with first SystemD and now this nonsense, it's rapidly becoming less UNIX-like. The Windows of the UNIX(ish) world.
Happily, the BSDs seem to be staying true to their UNIX roots.
petes_PoV ( 912422 ) , Sunday May 27, 2018 @12:01PM ( #56683282 )The dislike of support work ( Score: 5 , Interesting)In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.No, it is far simpler than looking for some mythical "political" issues. It is simply that hackers - especially amateur ones, who write code as a hobby - dislike trying to work out how old stuff works. They like writing new stuff, instead.
Partly this is because of the poor documentation: explanations of why things work, what other code was tried but didn't work out, the reasons for weird-looking constructs, techniques and the history behind patches. It could even be that many programmers are wedded to a particular development environment and lack the skill and experience (or find it beyond their capacity) to do things in ways that are alien to it. I feel that another big part is that merely rewriting old code does not allow for the " look how clever I am " element that is present in fresh, new, software. That seems to be a big part of the amateur hacker's effort-reward equation.
One thing that is imperative however is to keep backwards compatibility. So that the same options continue to work and that they provide the same content and format. Possibly Unix / Linux only remaining advantage over Windows for sysadmins is its scripting. If that was lost, there would be little point keeping it around.
DamnOregonian ( 963763 ) , Sunday May 27, 2018 @05:13PM ( #56685074 )Re:The dislike of support work ( Score: 5 , Insightful)iproute2 exists because ifconfig, netstat, and route do not support the full capabilities of the linux network stack.
This is because today's network stack is far more complicated than it was in the past. For very simple networks, the old tools work fine. For complicated ones, you must use the new ones.Your post could not be any more wrong. Your moderation amazes me. It seems that slashdot is full of people who are mostly amateurs.
iproute2 has been the main network management suite for linux amongst higher end sysadmins for a decade. It wasn't written to sate someone's desire to change for the sake of change, to make more complicated, to NIH. It was written because the old tools can't encompass new functionality without being rewritten themselves.Craig Cruden ( 3592465 ) , Sunday May 27, 2018 @12:11PM ( #56683352 )So windowification (making it incompatible) ( Score: 5 , Interesting)So basically there is a proposal to dump existing terminal utilities that are cross-platform and create custom Linux utilities - then get rid of the existing functionality? That would be moronic! I already go nuts remoting into a windows platform and then an AIX and Linux platform and having different command line utilities / directory separators / etc. Adding yet another difference between my Linux and macOS/AIX terminals would absolutely drive me bonkers!
I have no problem with updating or rewriting or adding functionalities to existing utilities (for all 'nix platforms), but creating a yet another incompatible platform would be crazily annoying.
(not a sys admin, just a dev who has to deal with multiple different server platforms)
Anonymous Coward , Sunday May 27, 2018 @12:16PM ( #56683388 )Output for 'ip' is machine readable, not human ( Score: 5 , Interesting)All output for 'ip' is machine readable, not human.
Compare
$ ip route
to
$ route -nWhich is more readable? Fuckers.
Same for
$ ip a
and
$ ifconfig
Which is more readable? Fuckers.The new commands should generally make the same output as the old, using the same options, by default. Using additional options to get new behavior. -m is commonly used to get "machine readable" output. Fuckers.
It is like the systemd interface fuckers took hold of everything. Fuckers.
BTW, I'm a happy person almost always, but change for the sake of change is fucking stupid.
Want to talk about resolv.conf, anyone? Fuckers! Easier just to purge that shit.
SigmundFloyd ( 994648 ) , Sunday May 27, 2018 @12:39PM ( #56683558 )Linux' userland is UNSTABLE ! ( Score: 3 )I'm growing increasingly annoyed with Linux' userland instability. Seriously considering a switch to NetBSD because I'm SICK of having to learn new ways of doing old things.
For those who are advocating the new tools as additions rather than replacements: Remember that this will lead to some scripts expecting the new tools and some other scripts expecting the old tools. You'll need to keep both flavors installed to do ONE thing. I don't know about you, but I HATE to waste disk space on redundant crap.
fluffernutter ( 1411889 ) , Sunday May 27, 2018 @12:46PM ( #56683592 )what about ( 730877 ) , Sunday May 27, 2018 @01:35PM ( #56683874 ) HomepagePiss and vinigar ( Score: 5 , Interesting)What pisses me off is when I go to run ifconfig and it isn't there, and then I Google on it and there doesn't seem to be *any* direct substitute that gives me the same information. If you want to change the command then fine, but allow the same output from the new commands. Furthermore, another bitch I have is most systemd installations don't have an easy substitute for
/etc/rc.local. Let's try hard to break Linux ( Score: 3 , Insightful)Kjella ( 173770 ) writes:It does not make any sense that some people spend time and money replacing what is currently working with some incompatible crap.
Therefore, the only logical alternative is that they are paid (in some way) to break what is working.
Also, if you rewrite tons of systems tools you have plenty of opportunities to insert useful bugs that can be used by the various spying agencies.
You do not think that the current CPU Flaws are just by chance, right ?
Immagine the wonder of being able to spy on any machine, regardless of the level of SW protection.There is no need to point out that I cannot prove it, I know, it just make sense to me.
Re: ( Score: 3 )WaffleMonster ( 969671 ) , Sunday May 27, 2018 @01:52PM ( #56684010 )It does not make any sense that some people spend time and money replacing what is currently working with some incompatible crap. (...) There is no need to point out that I cannot prove it, I know, it just make sense to me.Many developers fix problems like a guy about to lose a two week vacation because he can't find his passport. Rip open every drawer, empty every shelf, spread it all across the tables and floors until you find it, then rush out the door leaving everything in a mess. It solved HIS problem.
Changes for changes sake ( Score: 4 , Informative)DamnOregonian ( 963763 ) , Sunday May 27, 2018 @05:30PM ( #56685130 )TFA is full of shit.
IP aliases have always and still do appear in ifconfig as separate logical interfaces.
The assertion ifconfig only displays one IP address per interface also demonstrably false.
Using these false bits of information to advocate for change seems rather ridiculous.
One change I would love to see... "ping" bundled with most Linux distros doesn't support IPv6. You have to call IPv6 specific analogue which is unworkable. Knowing address family in advance is not a reasonable expectation and works contrary to how all other IPv6 capable software any user would actually run work.
Heck for a while traceroute supported both address families. The one by Olaf Kirch eons ago did then someone decided not invented here and replaced it with one that works like ping6 where you have to call traceroute6 if you want v6.
It seems anymore nobody spends time fixing broken shit... they just spend their time finding new ways to piss me off. Now I have to type journalctl and wait for hell to freeze over just to liberate log data I previously could access nearly instantaneously. It almost feels like Microsoft's event viewer now.
Re:Changes for changes sake ( Score: 4 , Insightful)JustNiz ( 692889 ) , Sunday May 27, 2018 @01:55PM ( #56684030 )TFA is full of shit. IP aliases have always and still do appear in ifconfig as separate logical interfaces.No, you're just ignorant.
Aliases do not appear in ifconfig as separate logical interfaces.
Logical interfaces appear in ifconfig as logical interfaces.
Logical interfaces are one way to add an alias to an interface. A crude way, but a way.The assertion ifconfig only displays one IP address per interface also demonstrably false.Nope. Again, your'e just ignorant.
root@swalker-samtop:~# tunctl
Set 'tap0' persistent and owned by uid 0
root@swalker-samtop:~# ifconfig tap0 10.10.10.1 netmask 255.255.255.0 up
root@swalker-samtop:~# ip addr add 10.10.10.2/24 dev tap0
root@swalker-samtop:~# ifconfig tap0:0 10.10.10.3 netmask 255.255.255.0 up
root@swalker-samtop:~# ip addr add 10.10.1.1/24 scope link dev tap0:0
root@swalker-samtop:~# ifconfig tap0 | grep inet
inet 10.10.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
root@swalker-samtop:~# ifconfig tap0:0 | grep inet
inet 10.10.10.3 netmask 255.255.255.0 broadcast 10.10.10.255
root@swalker-samtop:~# ip addr show dev tap0 | grep inet
inet 10.10.1.1/24 scope link tap0
inet 10.10.10.1/24 brd 10.10.10.255 scope global tap0
inet 10.10.10.2/24 scope global secondary tap0
inet 10.10.10.3/24 brd 10.10.10.255 scope global secondary tap0:0If you don't understand what the differences are, you really aren't qualified to opine on the matter.
Ifconfig is fundamentally incapable of displaying the amount of information that can go with layer-3 addresses, interfaces, and the architecture of the stack in general. This is why iproute2 exists.I propose a new word: ( Score: 5 , Funny)SysD: (v). To force an unnecessary replacement of something that already works well with an alternative that the majority perceive as fundamentally worse.
Example usage: Wow you really SysD'd that up.
|
|
|
Oct 14, 2018 | linux.slashdot.org
guruevi ( 827432 ) writes: < evi&evcircuits,com > on Monday December 11, 2017 @12:46AM ( #55713829 ) HomepageRe: Ah yes the secret to simplicity ( Score: 5 , Insightful)A big ol ball? My init.d was about 13 scripts big which were readable and editable. Ever tried to edit systemd files? Depending on systemd version you have to create overrides, modify symlinks or edit systemd files straight up which can be in about 5 different locations and on top of that, systemd can have overrides on any changes either with an update or just inherited.
Systemd makes every system into a dependency mess.
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
Z00L00K ( 682162 ) , Monday December 11, 2017 @12:52AM ( #55713851 ) HomepageRe: Ah yes the secret to simplicity ( Score: 5 , Insightful)So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
lucm ( 889690 ) , Monday December 11, 2017 @01:33AM ( #55713995 )Re: Ah yes the secret to simplicity ( Score: 5 , Informative)So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time. And getting anything of value out of the log is a pain in the ass.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons. That says a lot about the overal usefulness of systemd.
Nothing has been gained with systemd, at least not on servers.
93 Escort Wagon ( 326346 ) , Monday December 11, 2017 @01:39AM ( #55714017 )Re: Ah yes the secret to simplicity ( Score: 5 , Informative)Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.Not to mention that the damn logs are not plain text, which in itself complicates things before you even have the chance to start troubleshooting.
merky1 ( 83978 ) , Monday December 11, 2017 @07:41AM ( #55714833 ) JournalRe: Ah yes the secret to simplicity ( Score: 5 , Insightful)Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration. So the value for at least my usage of journalctl has been sum negative because I don't see the value in a command that by default truncates log output.
So the answer for systemd is to workaround it by using a "legacy" service to restore decades of functionality.
SMF was the death knell for Solaris (along with the Oracle purchase), and it feels like systemd is going to be the anchor which drags Linux into the abyss.
|
|
|
Oct 14, 2018 | linux.slashdot.org
adosch ( 1397357 ) , Sunday May 27, 2018 @04:04PM ( #56684724 )Thats... the argument? FML ( Score: 4 , Interesting)The OP's argument is that netlink sockets are more efficient in theory so we should abandon anything that uses a pseudo-proc, re-invent the wheel and move even farther from the UNIX tradition and POSIX compliance? And it may be slower on larger systems? Define that for me because I've never experienced that.
I've worked on single stove-pipe x86 systems, to the 'SPARC archteciture' generation where everyone thought Sun/Solaris was the way to go with single entire systems in a 42U rack, IRIX systems, all the way on hundreds of RPM-base linux distro that are physical, hypervised and containered nodes in an HPC which are LARGE compute systems (fat and compute nodes).
That's a total shit comment with zero facts to back it up. This is like Good Will Hunting 'the bar scene' revisited...
OP, if you're an old hat like me, I'd fucking LOVE to know how old? You sound like you've got about 5 days soaking wet under your belt with a Milkshake IPA in your hand. You sound like a millennial developer-turned-sysadmin-for-a-day who's got all but cloud-framework-administration under your belt and are being a complete poser.
Any true sys-admin is going to flip-their-shit just like we ALL did with systemd, and that shit still needs to die. There, I got that off my chest.
I'd say you got two things right, but are completely off on one of them:
- Your description of inefficient is what you got right: you sound like my mother or grandmother describing their computing experiences to look at Pintrest on a web brower at times. You mind as well just said slow without any bearing, education guess or reason. Sigh...
- I would agree that some of these tools need to change, but only to handle deeper kernel containerization being built into Linux. One example that comes to mind is 'hostnamectl' where it's more dev-ops centric in terms of 'what' slice or provision you're referencing. A lot of those tools like ifconfig, route and alike still do work in any Linux environment, containerized or not --- fuck, they work today .
Anymore, I'm just a disgruntled and I'm sure soon-to-be-modded-down voice on
/. that should be taken with a grain of salt. I'm not happy with the way the movements of Linux have gone, and if this doesn't sound old hat I don't know what is: At the end of the day, you have to embrace change. I'd say 0.0001% of any of us are in control of those types of changes, no matter how we feel about is as end-user administrators of those tools we've grown to be complacent about. I got about 15y left and this thing called Linux that I've made a good living on will be the-next-guys steaming pile to deal with.
Greyfox ( 87712 ) , Sunday May 27, 2018 @05:45PM ( #56685218 ) Homepage JournalRe:Thats... the argument? FML ( Score: 3 )Yeah. The other day I set up some demo video streaming on a Linux box. Fire up screen, start my streaming program. Disconnect screen and exit my ssh system, and my streaming freezes. There're a metric fuckton of reports of systemd killing detached/nohup'd processes, but I check my config file and it's not that. Although them being that willing to walk away from expected system behavior is already cause to blow a gasket. But no, something else is going on here. I tweak the streaming code to catch all catchable signals, still nothing. So probably not systemd, but I can't be 100% certain. I'm still testing all the possibilities -- if I start the servers from the console in screen and then detach and exit, I don't have the problem, it's only if I start them from ssh. And if I ssh in later, attach and detach, I still don't have the problem. So I'm looking forward to a couple of days of digging around in the ssh code to see if I can figure out what's going on with it. In the mean time, I have a reasonable workaround.
My point being that I don't think it's unreasonable to expect to know and understand every aspect of my system's behavior, and to expect it to continue to behave in the way that I know it does. I've worked on systems where you had to type the sequence of numbers that was the machine code for the bootstrap sequence in order to boot the system.
I know how the boot sequence works. I know how fork and exec and the default file handles work. I know how my system is supposed to start from the very first process. And I don't mind changing those things, as long as I trust the judgment of the people changing them. And I very much don't, for a lot of this new shit.
Not systemd, not wayland, not the new networking utilities. Still not enough to take matters into my own hands, though.
jgotts ( 2785 ) writes: < [email protected] > on Sunday May 27, 2018 @06:17PM ( #56685380 )Some historical color ( Score: 4 , Interesting)Just to give you guys some color commentary, I was participating quite heavily in Linux development from 1994-1999, and Linus even added me to the CREDITS file while I was at the University of Michigan for my fairly modest contributions to the kernel. [I prefer application development, and I'm still a Linux developer after 24 years. I currently work for the company Internet Brands.]
What I remember about ip and net is that they came about seemingly out of nowhere two decades ago and the person who wrote the tools could barely communicate in English. There was no documentation. net-tools by that time was a well-understood and well-documented package, and many Linux devs at the time had UNIX experience pre-dating Linux (which was announced in 1991 but not very usable until 1994).
We Linux developers virtually created Internet programming, where most of our effort was accomplished online, but in those days everybody still used books and of course the Linux Documentation Project. I have a huge stack of UNIX and Linux books from the 1990's, and I even wrote a mini-HOWTO. There was no Google. People who used Linux back then may seem like wizards today because we had to memorize everything, or else waste time looking it up in a book. Today, even if I'm fairly certain I already know how to do something, I look it up with Google anyway.
Given that, ip and route were downright offensive. We were supposed to switch from a well-documented system to programs written by somebody who can barely speak English (the lingua franca of Linux development)?
Today, the discussion is irrelevant. Solaris, HP-UX, and the other commercial UNIX versions are dead. Ubuntu has the common user and CentOS has the server. Google has complete documentation for these tools at a glance. In my mind, there is now no reason to not switch.
Although, to be fair, I still use ifconfig, even if it is not installed by default.
Hognoxious ( 631665 ) , Sunday May 27, 2018 @04:28PM ( #56684830 ) Homepage JournalRe:Poor reasoning ( Score: 3 )If the output has to change, there can either be a new tool or ifconfig itself changes. Either way, my script has to be changed.Yes. I mean it would be mathematically impossible to introduce a new tool and leave the old one there too .
|
|
|
Dec 11, 2017| linux.slashdot.org
lkcl ( 517947 ) writes: < [email protected] > on Monday December 11, 2017 @05:07AM ( #55714471 ) HomepageRe:Fix ( Score: 3 )apt purge systemdadd http://angband.pl/debian/ [angband.pl] to
/etc/apt/sources.list before doing that and it will actually succeed. okok it's a bit more complex than that, but you can read the instructions online which are neeearly as simple :)
|
|
|
Oct 14, 2018 | linux.slashdot.org
Z00L00K ( 682162 ) , Monday December 11, 2017 @12:52AM ( #55713851 ) Homepagelucm ( 889690 ) , Monday December 11, 2017 @01:33AM ( #55713995 )Re: Ah yes the secret to simplicity ( Score: 5 , Insightful)So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.
That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
Re: Ah yes the secret to simplicity ( Score: 5 , Informative)93 Escort Wagon ( 326346 ) , Monday December 11, 2017 @01:39AM ( #55714017 )So the short answer is: Yes, systemd makes things unnecessarily complex with little benefit.That matches my experience - losing a lot of time trying to figure out why things don't work. The improved boot time is lost several times over.
I completely agree. Troubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time. And getting anything of value out of the log is a pain in the ass.
Quite often I end up writing control shell scripts specifically to be called by systemd, because this junkware is too fragile and capricious to work with actual daemons. That says a lot about the overal usefulness of systemd.
Nothing has been gained with systemd, at least not on servers.
Re: Ah yes the secret to simplicity ( Score: 5 , Informative)merky1 ( 83978 ) , Monday December 11, 2017 @07:41AM ( #55714833 ) JournalTroubleshooting is really a bitch with systemd, much more time-consuming. For instance, often systemctl reports a daemon as failed while it's not, or suddenly decides that it didn't start because of some mysterious arbitrary timeout while the daemon just needs some time to run a maintenance tasks at startup time.Not to mention that the damn logs are not plain text, which in itself complicates things before you even have the chance to start troubleshooting.
Re: Ah yes the secret to simplicity ( Score: 5 , Insightful)coofercat ( 719737 ) writes:Granted, I have never needed any kind of tampering or corruption mitigation in my log files over the last 20 years of Linux administration. So the value for at least my usage of journalctl has been sum negative because I don't see the value in a command that by default truncates log output.
So the answer for systemd is to workaround it by using a "legacy" service to restore decades of functionality.
SMF was the death knell for Solaris (along with the Oracle purchase), and it feels like systemd is going to be the anchor which drags Linux into the abyss.
Re: ( Score: 3 )Junta ( 36770 ) writes:I'd say it is worse having to type something different for one log on the system, when the other 100+ are plain text and so accessible with the old tools we've all learned backwards. It means you don't have the necessary switches or key presses to hand because you don't do it often enough.
"journalctl" might be the best thing since sliced bread, but making it a hard requirement of systemd makes adoption of systemd that much harder. IMHO, systemd should "pick it's battles" and concentrate on managing system p
Re: ( Score: 3 )Junta ( 36770 ) , Monday December 11, 2017 @09:49AM ( #55715423 )The point being that text format is more universally readable, and also should it get corrupted, it has a better shot of still being readable.
On the other hand, pure binary logging was not necessary to achieve what they wanted. In fact, strictly speaking a split format of fixed-size, well aligned binary metadata alongside a text record of the variable length data would have been even *better* performance and still be readable.
Re: Ah yes the secret to simplicity ( Score: 5 , Insightful)Using text processing skills to process a generic text file isn't any harder than using journalctl. The difference is that the former is generically applicable to just about any other software on the planet, and the latter is for journald. It's not that complex to confer the journalctl benefits without ditching *native* text log capability, but they refuse to do so.
Using ForwardToSyslog just means there's an unnecessary middle-man, meaning both services must be functional to complete logging. The problem is the time when you actually want logs is the time when there's something going wrong. A few weeks ago was trying to support someone who did something pretty catastrophic to his system. One of the side effects was that it broke the syslog forwarding (syslog would still work, but nothing from journald would get to it). The other thing that happened would be for the system to lock out all access. I thought 'ok, I'll reboot and use jornalctl', but wait, on CentOS 7, journald defaults to not persisting journald across boot, because you have syslog to do that.
Of course the other problem (not entirely systemd project fault) was the quest to 'simplify' console output so he just saw 'fail' instead of the much more useful error messages that would formerly spam the console on experiencing the sort of problem he hit (because it would be terrible to have an 'ugly' console...). This hints about another source of the systemd controversy, that it's also symbolic of a lot of other design choices that have come out of the distros.
|
|
|
Oct 14, 2018 | linux.slashdot.org
OneHundredAndTen ( 1523865 ) , Monday December 11, 2017 @09:36AM ( #55715351 )Re:Oh stop complaining FFS ( Score: 5 , Interesting)I don't agree. Systemd is the most visible part of a clear trend within Red Hat, consisting in an attempt to make their particular version of Linux THE canonical Linux, to the point that, if you are not using Red Hat, or some derived distribution, things will not work. In essence, Red Hat is attempting to out-MS MS by polluting and warping Linux needlessly but surely. The latest: they have come up with the 'timedatectl' command, which does exactly the same as 'date'. The latter is to be deprecated. Red Hat, the MS wannabee. They will not pull it off, but they are inflicting a lot of damage on Linux in the process.
|
|
|
Apr 01, 2016 | 410gone.click
SyslogLevel=
See syslog(3) for details. This option is only useful when StandardOutput= or StandardError= are set to syslog or kmsg . Note that individual lines output by the daemon might be prefixed with a different log level which can be used to override the default log level specified here.The interpretation of these prefixes may be disabled with SyslogLevelPrefix= , see below. For details, see sd-daemon(3) . Defaults to info .
|
|
|
Apr 01, 2016 | 410gone.click
The Current Log Level
To check the log level of systemd , which are currently set, and then use the show command of systemctl command.
* To set the 'LogLevel' parameter of -p option.
systemctl -pLogLevel show LogLevel=infoHow to Temporarily Change the Log Level
To temporarily change the log level of systemd , use the set-log-level option of systemd-analyze command.
It is an example to change the log level to notice.
systemd-analyze set-log-level noticeHow to Permanently Change the Log Level
To enable the log level you have also changed after a restart of the system , change the ' LogLevel ' of /etc/systemd/system.conf .
It is an example to change the log level to notice.
vi /etc/systemd/system.conf #LogLevel=info LogLevel=notice
|
|
|
Apr 26, 2018 | www.2daygeek.com
For RPM Based Systems , use DNF Command to install chkservice .
How To Use chkservice$ sudo yum install https://github.com/linuxenko/chkservice/releases/download/0.1/chkservice_0.1.0-amd64.rpmJust fire the following command to launch the chkservice tool. The output is split to four parts.
First Part:This part shows about daemons status like, enabled [X] or disabled [] or static [s] or masked -m-Second Part:This part shows daemons status like, started [>] or stopped [=]Third Part:This part shows the unit nameFourth Part:This part showing the unit short description$ sudo chkservice
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 05, 2020
