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.
- 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.
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
As long as people want new features there will either be new security vulnerabilities or software you can't afford and never gets completed. If SELinux adds enough security to be worth your bother then go for it, if not then disable it.
Selinux sucks. It's either all in or turn it off...
A complex system will have some tools that are selinux ready and others that are not. How about having enforcing levels? Like this user is enforcing free and this one is not? In a simple/etc/selinux/rules file, not some crappy command that adds them to a binary database...
Turning off a bad program is not the solution in Linux has it often becomes so big that ppl will not develop alternatives.
If the kernel starts being buggy and crappy, is the alternativ
Here is your problem, if you want a system to be secure then keep it simple...
And as for the kernel being big and buggy, the vast majority of kernel features are optional - you can compile a minimal kernel to suit your needs and get a more stable, more secure and better performing system.
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
In modern use cases, it's better and simpler to partition with containers instead of SELinux, but even then, once you give them the ability to run code, they can escape from the jail.
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
Wait, what? The specific thing that capabilities-based security does for you is mitigate privilege escalation exploits! If you use capabilities correctly, then even if someone can execute code, that code can't do bad things because it doesn't have the rights to do so.
A good question, I should have written more clearly.
SELinux is focused on preventing privilege escalation between users. However, most modern systems are all run as single-user (to the point that most AWS instances have no root password). SELinux does nothing to prevent privilege escalation when the flaw is in the kernel (so, gaining kernel-level access). Unfortunately almost all privilege escalation exploits you see these days are kernel level exploits, so SELinux does not do anything to stop the (by far
not writing "bad code" isn't an option when even OpenSSL get major holes.
... and that's the reason why you shouldn't replace a bunch of editable and working scripts with some new, large and overly complex program written in C!
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
This reminds me of a New Yorker cartoon where the picture was of two winos laying in a garbage-strewn alley and one turns to the other and slurs "...and that's when I realized failure is an option."
In true New Yorker fashion, it's "funny" because it's true.
audit2allow is an automated rule writer to make usage easier. You're still supposed to use your brain and look at the policy it generates and make sure it's actually sane.
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.
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.
It seems like Lennart is an asshole with no clue about security, but despite that it does seem to offer enough for people who sell Linux, people who offer commercial support for it, seem to think it's better.
Red Hat said it hadn't affected sales when they did an interview here.
And then you could look at why people use Linux and not Windows. And you would not be surprised at the masses willing to run trash and the smaller group that finds it unacceptable.
Seriously, have you thought even one minute about what you just posted?
Sure, just like the tiny group of Slackware users who always argued that it was better because of its "more pure UNIX approach", talking about how package managers are essentially garbage (Slackware's package manager essentially unpacks a tarball and says good luck; removal wasn't a feature last time I saw this argument surface).
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!)
Slashdot bitching is not really a good indication of the Linux community in general. It's certainly not an indication of what people who know what they're doing (like distro maintainers) feel.
That is not true, unfortunately. In some environments you need two effective lines of defense and sometimes SELinux is the only thing that can provide the second one.
Also, any proper engineer knows that mistakes do happen and that the proper way to deal with that is redundancy, in software usually called "dense in depth".
So your solution is that rather than using libraries in a project, that each project should rewrite support for that feature from scratch? And you think this is going to increase security? Dozens of implementations of feature X that are only tested as much as the single project that uses that code. Reimplementation after reimplementation, no one in one project looking at the code in a different project because they don't share any - it's all uniquely written.
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.
It would be really nice to be able to run software without worrying about the amount of damage it could do. Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions, and can do nothing whatsoever after they've been uninstalled. I assume we're a long way off from having the right permission granularity and the good UIs for managing them, but this is a model we should at least explore further.
... assume we're a long way off from having the right permission granularity and the good UIs
The problem is much deeper than that, unfortunately. Android apps are nothing at all like whatever passes for 'apps' in the general world of Linux. Running apt-get can play total havok with your system, due to Linux's obsession with complex dependencies and shared libraries. Android apps, iOS app and Mac OSX apps dispense with this nonsense completely, and imagine apps instead as completely self-contained repositories of code. Apt-get can modify your system's startup process in a way that you can't just "u
That stuff is all interface, not core to the execution of a Linux application. Dependencies aren't an issue because permissions are based on the process or user, not the file. (This is still an issue when a daemon is a dependency, or when a file has effective permissions of another user/group, but those are separate cases.) I don't have a complete solution, but modifying/etc (aside from/etc/$APP_NAME) could be considered a master-level permission, and the package manager would run with rights that don't a
Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions
You're talking about an entirely different security model. Android apps are isolated from each other, and they generally cannot manage the operating system.
In a desktop environment, you typically cannot isolate applications in the same way. Maybe if everyone rewrote their applications to place nice that way---but that's a lot of work and a long time away.
In a server environment, you have applications which monitor/manage other applications, and often applications which monitor/manage the operating system it
It's not completely unworkable, it's just in very early stages. And most desktop application don't need to be rewritten. Web browser: needs a rewrite so its permissions are integrated with file pickers (giving an implicitly granted permission) and prompted permissions. File explorer: needs a minor change to de-escalate permission of launched apps. Terminal: no change (running with permissive permissions, like before selinux). Chat applications: optional change (running with permission to write only to their
And servers are another case. Server applications would definitely need to be rewritten, but until then they can continue running with legacy (user-based) permissions. User-based permissions work better on a server than on a desktop. (On desktop, the user-based permission model is destined to fail, since every application is launched by one user.)
Seriously. It's nearly impossible to troubleshoot issues if messages are just swallowed and not either output to the screen (which systemd has broken completely) or to the journal.
I'm happily running rsyslog on my systemd-containing distribution.
For debugging, though, the journal actually contains far more verbose logging than syslog ever did. And redirecting both standard error and standard out is a good thing, as before systemd a messages that you talk about being swallowed just scrolled off the console, eventually to disappear forever if you didn't happen to catch them at the time.
I'm amused that people would actually prefer the thousands and thousands of lines of buggy bash scri
Thank you! Finally someone actually outlines specific issues instead of just complaining.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Just my $0.02 as well. Not a 25-year Linux admin, I've run my own server for ~5 years, so I didn't have that much experience before the ch
Thank you! Finally someone actually outlines specific issues instead of just complaining.
Well most of the issues he complained about weren't actually related to Systemd.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change?
For one thing contributing to a project like that is a massive commitment, but more to the point the poster is fundament
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to. As long as that's the position someone is going to take, they shouldn't really expect things to change. Again, sel
>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.
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.
systemd has no site dependent configuration outside of/etc.
The files installed in/usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what/etc/systemd is for, putting things that override the distro defaults.
And/etc/default is good enough for every other package but not for systemd.
Eh? There are plenty of packages that pull default configs out of some location in/usr, with/etc/ being an override./etc has long (apart from systemd even) been considered the user-editable configuration, and/usr/share the non-user-editable configuration area (among other things).
No. I didn't change anything. No configs, editable or otherwise, should exist outside/etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under/usr as being) belong under/etc/default. They no more belong under/usr than the similar files installed by a thousand other packages do.
Mostly these are packages that predate the establishment of the/etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process. Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian s
Mostly these are packages that predate the establishment of the/etc/default standard,
Given all the packages I've had to mess around with over the years and seeing how they like to do things, I think/etc/default was a very short-lived standard that most just didn't pick up. I'm looking backwards at some of the distros I've used over the years, and I just don't see that it got a lot of traction.
Even if you are right it doesn't follow that text config files belong in/usr/lib does it? That's where libraries go. At the very least if it had to be under/usr it ought to have been in/usr/share/SystemD
Clearly you have spent time thinking about systemd, and so some questions:
1) Any chance systemd will improve? I think about how gnome3 seems to be slowly gaining more acceptance, perhaps this will be similar?
2) One of the challenges, even for a general-purpose computer distro, is to run on a wide variety of hardware with different needs. Example: Portable computer needs to be able to sleep, use graphics switching (start quicker??) while on a server these might be less important. It seems that systemd is
I think about how gnome3 seems to be slowly gaining more acceptance
Gnome 3 has always had a superior workflow, aside from its alt-tab behavior (which can take you to a different desktop, then back to a different window from the same application, then tab you between those two--no rapid swapping between the last 2 windows you touched). With the Activities view, it became possible to just press Meta and swap up/down through desktops, or press Meta and type an application name or keyword ("DVD burner" etc.), and press enter to take the first result. You can tap the corner
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thi
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
I find that logs still get pumped out to/var/log on Ubuntu, yet journalctl captures information that never went to those logs, so it has been an absolute boon in troubleshooting things I'd never understood before. There was a time when I'd occasionally try to run the application myself, or modify the init script; frequently I found this nigh-on-impossible with the ultra-complex, 700-line bash scripts Redhat and Debian like to shove into init.d.
I've never found journalctl to contain anything that wasn't in/var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have be
Lots of daemons don't capture stdout. On some systems, you can see logs spew to the console, making tty1 unusable.
Upstart was another SystemV-like, but better. I generally think of Upstart and whatever Gentoo uses as "SystemV" because they attempt to be that with new capabilities.
Just imagine if they all integrated Supervisord instead.
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else
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).
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.
they've claimed that they're supporting sysvinit... but in reality, as one of the posts further up points out, they had to REMOVE absolutely critical packages such as udisks2, policykit, and a fxxx load of other absolutely critical packages which should in absolutely NO WAY have anything to do with BOOTING.
even xorg now critically depends on libsystemd, i mean what the fxxx, man??
the only way to get rid of the dependencies cleanly and with full confidence that they're truly gone... and yet at the same time
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to.
True, but only an idiot would contribute to them. It's like handing the guy with a gun to your head the bullet he's going to use to shoot you. Much better to disarm him while the gun's not loaded.
That's not to say I believe that systemd contributors are idiots because I disagree with it's philosophy, just so they're no confusion; if they agree with it. But to contribute to something with which you don't agree is just plain idiotic.
There is a long history of Poettering and Sivers marking even clear security problems as "will not fix". Look for them yourself, they are not hard to find.
However your stance implies that you are just trying to sabotage the discussion. Your blue-eyed innocence is an obvious lie. Despicable.
I asked which patches have been rejected, not what those (so far not revealed) patches were supposed to be for. The claim was that the systemd team have rejected patches, but so far nobody has given any link or reference to any such patch.
That's the first one I could find; it's not like rejected patches are published -- after all, they were rejected. You're asking for evidence that only the person who submitted the patch and the person who rejected it would have, and you're asking in a place where you know you won't find either of those people. That I was able to find one example of something that it not typically published tells me there are likely more; if you were thinking objectively, you'd see this truth.
I can guarantee they've rejected more than one single patch. Where do they publish the list of rejected patches, then? I never claimed development was done in secret, only that no list of rejected patches is kept; and if such a list does exist, surely it lists the rejected patch I've provided, right? So where is it?
As I said, such a list does not exist; but that is not evidence that no patches are rejected; if it were, I would not have been able to provide a single rejected patch.
The main reason for systemd was and is hotplugging of hardware.
In the UNIX server world, hardware usually doesn't change during runtime (init 3 or init 5). Thus a boot process that starts new processes in a pre-determined, finely tuned sequence until all services are running, makes sense. All dependencies are already solved before the system boots up (and if not, you change your boot sequence until they are). And in this case, shell scripts as glue between the processes make thoroughly sense, as they prov
This doesn't require an entirely new RC system. For example, on FreeBSD this problem is solved by devd, which receives hotplug events from the kernel and runs scripts in response to events matching filters.
The real problem is the combination of both hotplug hardware and dynamic responses. For example, when I plug in a USB network or sound interface, I probably want to configure it once and have the same event trigger the same action every time. In contrast, when I plug in a USB mass storage device or
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?
And as a Linux user, I'm very happy about that too.
systemd is completely unapologetically Linux targeted, and made to expose all the cool stuff Linux has but that was getting little use. If it was written in a cross-platform compatible way, there would be no way to guarantee all the functionality would be there always.
Can I ask, why don't you and other admins/devs like you start to contribute to systemd?
Adding more code to something already hugely overweight isn't going to make things better. I can only think of one kind of contribution that'd be worthwhile: rip out a lot of code. I'm not convinced this sort of contribution would be accepted.
And generally I've much better plans to do with my time instead of joining a project I hate. For instance, my ceiling has this funny dot pattern and I still haven't gotten around to counting all the dots.
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work.
Huh? "service apache2 restart" works just fine with systemd. Hell, on Debian you can even do "invoke-rc.d apache2 restart" and it'll notice you're using systemd and do a "systemctl restart apache2" for you.
I've had numerous instance of "service xyz restart" not restarting the service yet not producing an error message AND giving exit code 0. It might be due to debian's unit files being a mess, but that doesn't really change anything.
Disclaimer before someone calls me out on the BSD message above: I have to fiddle with Linux at work.
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it?
The whole joke about Devuan is that you don't have to switch to Devuan to get rid of systemd -- Debian, unlike Devuan, lets you choose the init system you want. Don't like systemd? Just apt-get install sysvinit.
That does work. For now. And it comes with some problems, but nothing large at this time. The problem is that this is not fully supported anymore, otherwise I would not care about systemd at all and simply ignore it.
Why would we contribute to an obviously broken concept? Most of those complaining feel systemd falls into the "shred it and start over" category, not the "needs a few patches" one.
Most of these I agree with, but I fail to see why you'd want to fix this, but not fix sysvinit, which has always been a horrible kludge and has been "obsolete" (unable to deal with a world where networking, hot pluggable hardware, CPUs requiring complex thermal management, etc, are ubiquitous.)
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine, and there were several drop-in replaceme
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine,
What is a lie? That RedHat and Ubuntu had already moved away from sysvinit? That Arch Linux moved to systemd in 2012? That Debian was weighing up the possible alternatives with their usual glacial pace?
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
How many times have you actually had a problem due to sysvinit itself failing?
What do you mean by "sysvinit itself"? If you mean init(1) and the core scripts (/etc/rc1 and so on), never. init scripts from packages, quite a few times, sometimes leading to unbootable systems, sometimes to booted but useless systems (no network, missing services).
The most recent sysvinit problem was poor dependency handling, leading to failure to mount NFS volumes on boot. That was a pain to fix.
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
It's also worth noting that a large collection of integrated tools is totally unlike UNIX. The UNIX philosophy is about providing a large set of loosely-coupled tools. The UNIX tools are not designed to be tightly coupled (which shows at times, for example try doing ls -h and then use other tools to sort the result by size), they are designed to be composeable in ways that the authors didn't anticipate and to be replaceable by others. This is very different from systemd, which has a bunch of tightly coup
- 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.
Yep, that's annoying, but I don't know enough to say more.
- 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.
That's a downside of decentralized development. The issue here is that different platforms have different standards, and a lot of linux tools are multiplatform. So you have the choice of making the syntax different for each platform or being consistent between platforms. Furthermore, for licensing reasons, using a GNU parsing library may not be an option. Keep in mind that developers may not want to go out of their ways
Agreed on all except, I'll take another's comment on seLinux as something to consider. It may have it's uses.
Additionally, I'd add this;
- Reduce the number of security holes, bugs, quirks and whatnot, (but not at loss of reliability), over new features.
We don't need stinking new features! (I am looking squarely at you, Gnome 3! It should have been Gnome-NG, or something else, not 3.x.)
Everytime a new feature is added, it's possible that it added new security holes, bugs, quirks and reduced reliability
Yes, when you focus on what you intend to happen, issues seem so clear, don't they? But all this lack of responsiveness to your demands arises from attempts to contain potential unintended consequences.
I have a pet peeve, which is people who rank "crash" or "hang" bugs at the apex of the failure scale, above data corruption and faulty outputs. Think of an automated trading system that enters an abnormal state and starts generating random buy and sell orders for example. Or a system which is supposed to aut
I have several machines which run Ubuntu 14.04LTS. They work 100% perfectly under Ubuntu 14.04LTS, and shuts down IMMEDIATELY when I tell it to. Since I'm curious and have time on my hands, being retired and all, I decided I'd give a try to Ubuntu 16.04LTS. I slapped a fresh drive into my laptop and proceeded to install 16.04.. The install went fine, as Ubuntu installs always have for me since I started using it, around 8.04LTS. After the install completed, the reboot after removal of the USB install media
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.
Re:Problems with Linux that should have been solve (Score:4, Interesting)
- 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.
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
As long as people want new features there will either be new security vulnerabilities or software you can't afford and never gets completed. If SELinux adds enough security to be worth your bother then go for it, if not then disable it.
Re: Problems with Linux that should have been solv (Score:1)
A complex system will have some tools that are selinux ready and others that are not. How about having enforcing levels? Like this user is enforcing free and this one is not? In a simple
Turning off a bad program is not the solution in Linux has it often becomes so big that ppl will not develop alternatives.
If the kernel starts being buggy and crappy, is the alternativ
Re: (Score:2)
"A complex system"
Here is your problem, if you want a system to be secure then keep it simple...
And as for the kernel being big and buggy, the vast majority of kernel features are optional - you can compile a minimal kernel to suit your needs and get a more stable, more secure and better performing system.
Re: (Score:2, Funny)
Keep it simple: compile a custom kernel!
Re: (Score:2)
In modern use cases, it's better and simpler to partition with containers instead of SELinux, but even then, once you give them the ability to run code, they can escape from the jail.
Re: (Score:2)
SELinux doesn't give you any real extra security, that's the problem. Once people have the ability to run code on your OS, they can also find a privilege escalation exploit (this is true on all OSes, even OpenBSD).
Wait, what? The specific thing that capabilities-based security does for you is mitigate privilege escalation exploits! If you use capabilities correctly, then even if someone can execute code, that code can't do bad things because it doesn't have the rights to do so.
Re: (Score:2)
SELinux is focused on preventing privilege escalation between users. However, most modern systems are all run as single-user (to the point that most AWS instances have no root password). SELinux does nothing to prevent privilege escalation when the flaw is in the kernel (so, gaining kernel-level access). Unfortunately almost all privilege escalation exploits you see these days are kernel level exploits, so SELinux does not do anything to stop the (by far
Re: (Score:2)
not writing "bad code" isn't an option when even OpenSSL get major holes.
... and that's the reason why you shouldn't replace a bunch of editable and working scripts with some new, large and overly complex program written in C!
Re: (Score:2)
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
This reminds me of a New Yorker cartoon where the picture was of two winos laying in a garbage-strewn alley and one turns to the other and slurs "...and that's when I realized failure is an option."
In true New Yorker fashion, it's "funny" because it's true.
Re: (Score:2)
but not writing "bad code" isn't an option when even OpenSSL get major holes.
That's a bad example, the openssl people didn't even try.
Re: (Score:3)
Drop this selinux shit. It's too complicated and causes more problems than it solves.
I think the utility called audit2allow summarizes well the immense "value" of selinux.
generate SELinux policy allow/dontaudit rules from logs of denied operations
https://manpages.debian.org/un... [debian.org]
The first time I heard about it I thought it was a prank.
Re: (Score:2)
audit2allow is an automated rule writer to make usage easier. You're still supposed to use your brain and look at the policy it generates and make sure it's actually sane.
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.
Re: (Score:2)
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.
It seems like Lennart is an asshole with no clue about security, but despite that it does seem to offer enough for people who sell Linux, people who offer commercial support for it, seem to think it's better.
Red Hat said it hadn't affected sales when they did an interview here.
Re: (Score:2)
And then you could look at why people use Linux and not Windows. And you would not be surprised at the masses willing to run trash and the smaller group that finds it unacceptable.
Seriously, have you thought even one minute about what you just posted?
Re: (Score:2)
Sure, just like the tiny group of Slackware users who always argued that it was better because of its "more pure UNIX approach", talking about how package managers are essentially garbage (Slackware's package manager essentially unpacks a tarball and says good luck; removal wasn't a feature last time I saw this argument surface).
Re: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!)
Re: (Score:2)
Re: (Score:2)
"Redhat wanted more control of Linux so they pushed systemd" is "insightful?"
Re: (Score:2, Informative)
Re: (Score:2)
people who offer commercial support for it, seem to think it's better.
There's your reason.
Re: (Score:2)
Slashdot bitching is not really a good indication of the Linux community in general.
It's certainly not an indication of what people who know what they're doing (like distro maintainers) feel.
Re: (Score:2)
That is not true, unfortunately. In some environments you need two effective lines of defense and sometimes SELinux is the only thing that can provide the second one.
Also, any proper engineer knows that mistakes do happen and that the proper way to deal with that is redundancy, in software usually called "dense in depth".
Re: (Score:1)
So your solution is that rather than using libraries in a project, that each project should rewrite support for that feature from scratch? And you think this is going to increase security? Dozens of implementations of feature X that are only tested as much as the single project that uses that code. Reimplementation after reimplementation, no one in one project looking at the code in a different project because they don't share any - it's all uniquely written.
Great idea. Dist that out now!
Re: (Score:2)
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.
It would be really nice to be able to run software without worrying about the amount of damage it could do. Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions, and can do nothing whatsoever after they've been uninstalled. I assume we're a long way off from having the right permission granularity and the good UIs for managing them, but this is a model we should at least explore further.
Re: (Score:2)
... assume we're a long way off from having the right permission granularity and the good UIs
The problem is much deeper than that, unfortunately. Android apps are nothing at all like whatever passes for 'apps' in the general world of Linux. Running apt-get can play total havok with your system, due to Linux's obsession with complex dependencies and shared libraries. Android apps, iOS app and Mac OSX apps dispense with this nonsense completely, and imagine apps instead as completely self-contained repositories of code. Apt-get can modify your system's startup process in a way that you can't just "u
Re: (Score:2)
That stuff is all interface, not core to the execution of a Linux application. Dependencies aren't an issue because permissions are based on the process or user, not the file. (This is still an issue when a daemon is a dependency, or when a file has effective permissions of another user/group, but those are separate cases.) I don't have a complete solution, but modifying /etc (aside from /etc/$APP_NAME) could be considered a master-level permission, and the package manager would run with rights that don't a
Re: (Score:2)
Android apps are fairly limited in what they can do, and in the absence of a root exploit, they can't go beyond their stated permissions
You're talking about an entirely different security model. Android apps are isolated from each other, and they generally cannot manage the operating system.
In a desktop environment, you typically cannot isolate applications in the same way. Maybe if everyone rewrote their applications to place nice that way---but that's a lot of work and a long time away.
In a server environment, you have applications which monitor/manage other applications, and often applications which monitor/manage the operating system it
Re: (Score:2)
It's not completely unworkable, it's just in very early stages. And most desktop application don't need to be rewritten. Web browser: needs a rewrite so its permissions are integrated with file pickers (giving an implicitly granted permission) and prompted permissions. File explorer: needs a minor change to de-escalate permission of launched apps. Terminal: no change (running with permissive permissions, like before selinux). Chat applications: optional change (running with permission to write only to their
Re: (Score:2)
And servers are another case. Server applications would definitely need to be rewritten, but until then they can continue running with legacy (user-based) permissions. User-based permissions work better on a server than on a desktop. (On desktop, the user-based permission model is destined to fail, since every application is launched by one user.)
Re: (Score:2)
- Fix the logging.
Seriously. It's nearly impossible to troubleshoot issues if messages are just swallowed and not either output to the screen (which systemd has broken completely) or to the journal.
Re: (Score:2)
I'm happily running rsyslog on my systemd-containing distribution.
For debugging, though, the journal actually contains far more verbose logging than syslog ever did. And redirecting both standard error and standard out is a good thing, as before systemd a messages that you talk about being swallowed just scrolled off the console, eventually to disappear forever if you didn't happen to catch them at the time.
I'm amused that people would actually prefer the thousands and thousands of lines of buggy bash scri
Re: (Score:1)
Thank you! Finally someone actually outlines specific issues instead of just complaining.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Just my $0.02 as well. Not a 25-year Linux admin, I've run my own server for ~5 years, so I didn't have that much experience before the ch
Re: (Score:2)
Thank you! Finally someone actually outlines specific issues instead of just complaining.
Well most of the issues he complained about weren't actually related to Systemd.
But I have to say, I'm using Jessie and I have not experienced any of the problems you have cited... When I kill a process, it gets killed. When I reboot or shutdown, it reboots or shuts down. When I mount/unmount something, it gets mounted/unmounted. The other stuff I can't speak to.
Usually no, but it happens [noah.org]
Can I ask, why don't you and other admins/devs like you start to contribute to systemd? Obviously there are huge philosophical differences between the systemd devs and parts of the Linux community, but if people like you never get involved in systemd development because of those issues, can you really expect them to change?
For one thing contributing to a project like that is a massive commitment, but more to the point the poster is fundament
Re: (Score:2)
For one thing contributing to a project like that is a massive commitment
Sure, that's totally understandable. But there are people who have enough time to fork entire distros, like Devaun... So while you could make that argument on an individual basis, you can't honestly say that "only the people who like systemd's philosophy have time to contribute to systemd".
but more to the point the poster is fundamentally opposed to the underlying philosophy of Systemd.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to. As long as that's the position someone is going to take, they shouldn't really expect things to change. Again, sel
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.
Re: (Score:2)
So would you be okay with it if it still broke compatibility but that was necessary to add some really important/useful features?
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). /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.
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
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.
Re: Problems with Linux that should have been sol (Score:2)
I should not comment from my phone. Man autocorrect rapes my text...
Re: (Score:1)
Config outside /etc is a major deal
It's also a major misunderstanding of systemd.
systemd has no site dependent configuration outside of /etc.
The files installed in /usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what /etc/systemd is for, putting things that override the distro defaults.
Re: (Score:2)
Right... /etc/default is good enough for every other package but not for systemd.
And
You know, if you don't follow the standards and "misconceptions" arise - it's the fault of bad development.
Re: (Score:1)
Great groaning sound as the goalposts are shifted.
You're changing "Config outside /etc is a major deal" to "Config outside /etc/default is a major deal" now?
Are you unable to admit that one of your complaints about systemd, which you described as "a major deal" was simply wrong?
Re: (Score:2)
And /etc/default is good enough for every other package but not for systemd.
Eh? There are plenty of packages that pull default configs out of some location in /usr, with /etc/ being an override. /etc has long (apart from systemd even) been considered the user-editable configuration, and /usr/share the non-user-editable configuration area (among other things).
Re: Problems with Linux that should have been sol (Score:2)
No. I didn't change anything. No configs, editable or otherwise, should exist outside /etc. Configs installed by packages which should be overridden rather than edited (what you described the ones under /usr as being) belong under /etc/default. They no more belong under /usr than the similar files installed by a thousand other packages do.
Re: (Score:1)
No. I didn't change anything.
Oh yes you did. You said:
/use ought to not even need backups because everything there is supposed to be installed and never hand edited
I pointed out that that was exactly the case with systemd and now you've changed the claim to:
No configs, editable or otherwise, should exist outside /etc.
with exactly zero justification.
Re: (Score:2)
Re: (Score:2)
Mostly these are packages that predate the establishment of the /etc/default standard, or packages that are small third-party things that aren't shipped by distros, or are so badly coded that you can't actually change installation paths during the build process.
Because even if packages typically don't do it, distros would usually change that- even when it means applying patches to the code while building packages (official debian packages almost always have patches included to modify the package to debian s
Re: (Score:2)
Mostly these are packages that predate the establishment of the /etc/default standard,
Given all the packages I've had to mess around with over the years and seeing how they like to do things, I think /etc/default was a very short-lived standard that most just didn't pick up. I'm looking backwards at some of the distros I've used over the years, and I just don't see that it got a lot of traction.
Re: Problems with Linux that should have been sol (Score:2)
Even if you are right it doesn't follow that text config files belong in /usr/lib does it? That's where libraries go. At the very least if it had to be under /usr it ought to have been in /usr/share/SystemD
Re: (Score:2)
1) Any chance systemd will improve? I think about how gnome3 seems to be slowly gaining more acceptance, perhaps this will be similar?
2) One of the challenges, even for a general-purpose computer distro, is to run on a wide variety of hardware with different needs. Example: Portable computer needs to be able to sleep, use graphics switching (start quicker??) while on a server these might be less important. It seems that systemd is
Re: (Score:2)
I think about how gnome3 seems to be slowly gaining more acceptance
Gnome 3 has always had a superior workflow, aside from its alt-tab behavior (which can take you to a different desktop, then back to a different window from the same application, then tab you between those two--no rapid swapping between the last 2 windows you touched). With the Activities view, it became possible to just press Meta and swap up/down through desktops, or press Meta and type an application name or keyword ("DVD burner" etc.), and press enter to take the first result. You can tap the corner
Re: (Score:2)
1) It's possible - a big part of Gnome3's growth however was weakening the "we know what's good for you" arrogance of the developers (partly due to the huge user-losses they suffered on release) and actually listening to their users. Thus far, systemd seems quite uninterested in that.
2) This leads into the other problem with systemd - which may make the odds of improvement lower. It is more on the fundamental design level. There is a reason the unix philosophy is what it is. "Small programs that do one thi
Re: (Score:2)
Generally, the improvement is in if it lowers labor required downstream. That's the absolute measure of "better".
Re: (Score:2)
But downstream isn't one place, there are multiple stops along the way. The assessment of "Better" was made on stop down (the distro packagers) but nobody every really considered the question of whether it would be "better" (by your own measure) for the those even further downstream - the users, the sysadmins, the devops engineers.
I think, objectively, that it wasn't - at least for a large subset of those further downstream (notably experts and sysadmins).
Re: (Score:2)
I find that logs still get pumped out to /var/log on Ubuntu, yet journalctl captures information that never went to those logs, so it has been an absolute boon in troubleshooting things I'd never understood before. There was a time when I'd occasionally try to run the application myself, or modify the init script; frequently I found this nigh-on-impossible with the ultra-complex, 700-line bash scripts Redhat and Debian like to shove into init.d.
Docker has also been a godsend.
The one time shit pissed me
Re: (Score:2)
I've never found journalctl to contain anything that wasn't in /var/log - but if you only checked one file in a folder full of logs you'd likely have missed things.
And if you recall, I said in my original post that System-V had issues - you mention one of the worst, I just don't think SystemD was the best answer available - it wasn't even in the top-5 best alternatives that were available at the time. Personally I think upstart was but there were several other very good ones, and none of them should have be
Re: (Score:2)
Lots of daemons don't capture stdout. On some systems, you can see logs spew to the console, making tty1 unusable.
Upstart was another SystemV-like, but better. I generally think of Upstart and whatever Gentoo uses as "SystemV" because they attempt to be that with new capabilities.
Just imagine if they all integrated Supervisord instead.
Re: Problems with Linux that should have been solv (Score:2)
Upstart was in no way system V like, it had a backwards compatibility feature that led system V scripts work but that was only for non-updated third party software. Upstart's own system used config files, not scripts. Its wrapper utility commands were compatible with older ones created for system V but were drop in replacement code. Upstart was parallel capable, sensibly structured (dependency model) and fast. It was the right way to improve init. And it was just init. Upstart didn't mess with anything else
Re: (Score:2)
Today I learned that "conversations of slashdot" are consider "coding" by some people...
Re: (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 remain
Re: (Score:2)
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.
they've claimed that they're supporting sysvinit... but in reality, as one of the posts further up points out, they had to REMOVE absolutely critical packages such as udisks2, policykit, and a fxxx load of other absolutely critical packages which should in absolutely NO WAY have anything to do with BOOTING.
even xorg now critically depends on libsystemd, i mean what the fxxx, man??
the only way to get rid of the dependencies cleanly and with full confidence that they're truly gone... and yet at the same time
Re: (Score:2)
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to.
True, but only an idiot would contribute to them. It's like handing the guy with a gun to your head the bullet he's going to use to shoot you. Much better to disarm him while the gun's not loaded.
That's not to say I believe that systemd contributors are idiots because I disagree with it's philosophy, just so they're no confusion; if they agree with it. But to contribute to something with which you don't agree is just plain idiotic.
Re: (Score:1)
Just because you can submit a patch to something doesn't mean it will be accepted.
True.
What patches to systemd have been rejected? For what reasons?
Re: (Score:3)
There is a long history of Poettering and Sivers marking even clear security problems as "will not fix". Look for them yourself, they are not hard to find.
However your stance implies that you are just trying to sabotage the discussion. Your blue-eyed innocence is an obvious lie. Despicable.
Re: (Score:2)
Re: (Score:1)
I asked which patches have been rejected, not what those (so far not revealed) patches were supposed to be for. The claim was that the systemd team have rejected patches, but so far nobody has given any link or reference to any such patch.
Twat.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
As I said, such a list does not exist; but that is not evidence that no patches are rejected; if it were, I would not have been able to provide a single rejected patch.
Dude, get a clue.
Re: (Score:1)
If someone decided to build a house out of cardboard
...
https://www.sciencealert.com/t... [sciencealert.com]
Re: (Score:3)
In the UNIX server world, hardware usually doesn't change during runtime (init 3 or init 5). Thus a boot process that starts new processes in a pre-determined, finely tuned sequence until all services are running, makes sense. All dependencies are already solved before the system boots up (and if not, you change your boot sequence until they are). And in this case, shell scripts as glue between the processes make thoroughly sense, as they prov
Re: (Score:2)
The real problem is the combination of both hotplug hardware and dynamic responses. For example, when I plug in a USB network or sound interface, I probably want to configure it once and have the same event trigger the same action every time. In contrast, when I plug in a USB mass storage device or
Re: (Score:2)
That is to say, systemd fixes udevd not init.
Re: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.
Re: (Score:2)
for example he refuses to merge any patch that improves cross-platform compatibility.
As a BSD user, I'm incredibly happy about this decision.
Re: (Score:2)
And as a Linux user, I'm very happy about that too.
systemd is completely unapologetically Linux targeted, and made to expose all the cool stuff Linux has but that was getting little use. If it was written in a cross-platform compatible way, there would be no way to guarantee all the functionality would be there always.
Re: (Score:2)
Now if this isn't a textbook win-win situation I'm not sure what is. :)
Re: (Score:2)
Can I ask, why don't you and other admins/devs like you start to contribute to systemd?
Adding more code to something already hugely overweight isn't going to make things better.
I can only think of one kind of contribution that'd be worthwhile: rip out a lot of code. I'm not convinced this sort of contribution would be accepted.
And generally I've much better plans to do with my time instead of joining a project I hate. For instance, my ceiling has this funny dot pattern and I still haven't gotten around to counting all the dots.
Re: (Score:1)
I didn't even know systemd existed until I updated from Squeeze to Jessie and found that "service apache2 restart" didn't work.
Huh? "service apache2 restart" works just fine with systemd. Hell, on Debian you can even do "invoke-rc.d apache2 restart" and it'll notice you're using systemd and do a "systemctl restart apache2" for you.
Re: (Score:2)
I've had numerous instance of "service xyz restart" not restarting the service yet not producing an error message AND giving exit code 0. It might be due to debian's unit files being a mess, but that doesn't really change anything.
Disclaimer before someone calls me out on the BSD message above: I have to fiddle with Linux at work.
Re: (Score:1)
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either -- they're literally the same thing.
(/usr/sbin/service is, on Debian, a big shell script that ends up calling systemctl if pid 1 is systemd).
Re: (Score:2)
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either
Yes. So?
Re: (Score:1)
I'm not having any problems with systemd, so why would I switch to a smaller, less supported distro to avoid it?
The whole joke about Devuan is that you don't have to switch to Devuan to get rid of systemd -- Debian, unlike Devuan, lets you choose the init system you want. Don't like systemd? Just apt-get install sysvinit.
Re: (Score:2)
That does work. For now. And it comes with some problems, but nothing large at this time. The problem is that this is not fully supported anymore, otherwise I would not care about systemd at all and simply ignore it.
Re: (Score:2)
Why would we contribute to an obviously broken concept? Most of those complaining feel systemd falls into the "shred it and start over" category, not the "needs a few patches" one.
Re: (Score:2)
Most of these I agree with, but I fail to see why you'd want to fix this, but not fix sysvinit, which has always been a horrible kludge and has been "obsolete" (unable to deal with a world where networking, hot pluggable hardware, CPUs requiring complex thermal management, etc, are ubiquitous.)
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap
Re: (Score:2)
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine, and there were several drop-in replaceme
Re: (Score:1)
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine,
What is a lie? That RedHat and Ubuntu had already moved away from sysvinit? That Arch Linux moved to systemd in 2012? That Debian was weighing up the possible alternatives with their usual glacial pace?
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
Re: (Score:2)
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
How many times have you actually had a problem due to sysvinit itself failing?
Re: (Score:1)
How many times have you actually had a problem due to sysvinit itself failing?
What do you mean by "sysvinit itself"? If you mean init(1) and the core scripts (/etc/rc1 and so on), never. init scripts from packages, quite a few times, sometimes leading to unbootable systems, sometimes to booted but useless systems (no network, missing services).
The most recent sysvinit problem was poor dependency handling, leading to failure to mount NFS volumes on boot. That was a pain to fix.
Re: (Score:2)
Despite the complaints that systemd is somehow the "wrong" way to do this because it's a large collection of integrated tools which is totally unlike Unix (LOLWUT?), the only other place you could put all this crap would be in the kernel itself.
That is not the argument, and if that's all you've taken away from it, then you are a disingenuous douchebag who refuses to listen to other people's arguments at best. The argument is that it's a large collection of tools which are designed to replace existing tools without actually being compatible with them, and built in such a way that you have to take many of them on. Its modularity is mythical at best.
It's also worth noting that a large collection of integrated tools is totally unlike UNIX. The UNIX philosophy is about providing a large set of loosely-coupled tools. The UNIX tools are not designed to be tightly coupled (which shows at times, for example try doing ls -h and then use other tools to sort the result by size), they are designed to be composeable in ways that the authors didn't anticipate and to be replaceable by others. This is very different from systemd, which has a bunch of tightly coup
Re: (Score:2)
Um, you know, this sounds an awful lot like OpenBSD...
Coming from someone who uses several flavors of Linux, OpenBSD, and FreeBSD on a regular basis.
Re: (Score:2)
- 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.
What about the Magic SysRq key [wikipedia.org]?
- 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.
Yep, that's annoying, but I don't know enough to say more.
- 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.
That's a downside of decentralized development. The issue here is that different platforms have different standards, and a lot of linux tools are multiplatform. So you have the choice of making the syntax different for each platform or being consistent between platforms. Furthermore, for licensing reasons, using a GNU parsing library may not be an option. Keep in mind that developers may not want to go out of their ways
Re: (Score:1)
Additionally, I'd add this;
- Reduce the number of security holes, bugs, quirks and whatnot, (but not at loss of reliability), over new features.
We don't need stinking new features! (I am looking squarely at you, Gnome 3! It should have been Gnome-NG, or something else, not 3.x.)
Everytime a new feature is added, it's possible that it added new security holes, bugs, quirks and reduced reliability
Re: (Score:3)
Yes, when you focus on what you intend to happen, issues seem so clear, don't they? But all this lack of responsiveness to your demands arises from attempts to contain potential unintended consequences.
I have a pet peeve, which is people who rank "crash" or "hang" bugs at the apex of the failure scale, above data corruption and faulty outputs. Think of an automated trading system that enters an abnormal state and starts generating random buy and sell orders for example. Or a system which is supposed to aut
Re: (Score:2)
I have several machines which run Ubuntu 14.04LTS. They work 100% perfectly under Ubuntu 14.04LTS, and shuts down IMMEDIATELY when I tell it to. Since I'm curious and have time on my hands, being retired and all, I decided I'd give a try to Ubuntu 16.04LTS. I slapped a fresh drive into my laptop and proceeded to install 16.04.. The install went fine, as Ubuntu installs always have for me since I started using it, around 8.04LTS. After the install completed, the reboot after removal of the USB install media
Re: (Score:2)
SELinux is not hard to deal with, especially in targetted mode. Otherwise I agree.
Re:Problems with Linux that should have been solve (Score:4, Funny)
code contribution: /code/systemd
rm -rf
Re: (Score:3, Funny)
I tried your patch and it's amazing. Please submit a pull request upstream as soon a possible.