Is Modern Linux Becoming Too Complex?

An anonymous reader writes: Debian developer John Goerzen asks whether Linux has become so complex that it has lost some of its defining characteristics. "I used to be able to say Linux was clean, logical, well put-together, and organized. I can’t really say this anymore. Users and groups are not really determinitive for permissions, now that we have things like polkit running around. (Yes, by the way, I am a member of plugdev.) Error messages are unhelpful (WHY was I not authorized?) and logs are nowhere to be found. Traditionally, one could twiddle who could mount devices via /etc/fstab lines and perhaps some sudo rules. Granted, you had to know where to look, but when you did, it was simple; only two pieces to fit together. I've even spent time figuring out where to look and STILL have no idea what to do."

Comments

So roll your own.

[GloomE]

Just like Linus did.

Re:So roll your own.

[Nate B.]

Actually, there are some that are intent on doing just that despite being labeled "haters" even though their motivations have nothing to do with "hate". Disagreement does not mean hatred. So long as the Linux kernel does not require specific user space software or versions, those of us who prefer a more traditional approach will be fine.

Re:So roll your own.

[morgauxo]

Rolling your own 'Just like Linus did' may be a little extreme. I don't think you need a whole new kernel!

Just install Linux from scratch and don't put all that *kit, etc.. crap in it. I would imagine you could even get rid of udev and all that stuff if you are willing to run mknode yourself. Roll it like it's 1995.

You will lose out on some convenience if you are using a portable device such as a laptop but on a desktop with fairly static hardware everything should work just fine.

If having your own custom simple Linux isn't good enough for you then take it to the next step and start your own distro that leaves all that stuff out.

Re:So roll your own.

[NotDrWho]

Yeah, that's EXACTLY what Linux needs to make it less complex--another 1,000 forked distros.

Re:So roll your own.

[Lodragandraoidh]

I think you're missing the point. Linux is the kernel - and it is very stable, and while it has modern extensions, it still keeps the POSIX interfaces consistent to allow inter-operation as desired. The issue here is not that forks and new versions of Linux distros are an aberration, but how the major distributions have changed and the article is a symptom of those changes towards homogeneity.

The Linux kernel is by definition identically complex on any distro using a given version of the kernel (the variances created by compilation switches notwithstanding). The real variance is in the distros - and I don't think variety is a bad thing, particularly in this day and age when we are having to focus more and more on security, and small applications on different types of devices - from small ARM processor systems, to virtual cluster systems in data centers.

Variety creates a strong ecosystem that is more resilient to security exploitation as a whole; variety is needed now more than ever given the security threats we are seeing. If you look at the history of Linux distributions over time - you'll see that from the very beginning it was a vibrant field with many distros - some that bombed out - some that were forked and then died, and forks and forks of forks that continued on - keeping the parts that seemed to work for those users. Today - I think people perceive what is happening with the major distros as a reduction in choice (if Redhat is essentially identical to Debian, Ubuntu, et al - why bother having different distros?) - a bottleneck in variability; from a security perspective, I think people are worried that a monoculture is emerging that will present a very large and crystallized attack surface after the honeymoon period is over.

If people don't like what is available, if they are concerned about the security implications, then they or their friends need to do something about it. Fork an existing distro, roll your own distro, or if you are really clever - build your own operating system from scratch to provide an answer, and hopefully something better/different in the long run. Progress isn't a bad thing; sitting around doing nothing and complaining about it is.

Re:So roll your own.

[NotDrWho]

One man's variety is another man's hopelessly confusing goddamn mess.

Re:So roll your own.

[BarbaraHudson]

So maybe someone can "roll their own" by starting with a completely blank state, ignoring POSIX compatibility, and maybe come up with something unique, instead of yet another clone of an OS.

Re:So roll your own.

[HBI]

The problem with this approach is that the Unix paradigm of handling multiple processes is so good that anything new would tend towards the derivative rather than an actual improvement. For a long time after I was first exposed in the early 1990s, I wished for a simpler system that was more DOS-like. Finally realizing the power of the tools and structure changed my view - I no longer wished for a protected mode DOS with preemptive multitasking.

Re:So roll your own.

[Grishnakh]

Because then you'll just be reinventing the wheel, badly.

Every modern OS kernel basically does the exact same thing. MacOS X's kernel is POSIX compatible, even though it's rather different internally than Linux, and does multi-processing the same way. Window's kernel is really based on VMS, is not POSIX compatible (there are some extensions somewhere for the OS to emulate it, but that's different), but it still basically does the exact same thing: multi-processing with virtual memory.

The big debate these days in kernels is just over whether we should have microkernels or monolithic kernels. Mac's and Windows' kernels are both hybrids.

If you really think you have a better idea for how an OS should work, let's hear it. Lots of other really smart OS experts out there have come up with various ideas, but at their core they're really mostly the same, except for the debate over microkernel vs. monolithic.

Re:So roll your own.

[Jane Q. Public]

Actually, there are some that are intent on doing just that despite being labeled "haters" even though their motivations have nothing to do with "hate". Disagreement does not mean hatred. So long as the Linux kernel does not require specific user space software or versions, those of us who prefer a more traditional approach will be fine.

A lot of them just want to get the hell away from systemd. Talk about violation of "do one thing and do it well"!

I think it is quite possible to have comprehensive system security without one monstrous "Big Brother" to rule them all... especially since that's not what it was originally designed for.

Re:So roll your own.

[BarbaraHudson]

Does a mini OS that is designed to do a few things, but do them extremely efficiently, have to be POSIX compatible? Obviously not. By definition, it would lack the "Portable" in POSIX. But so what? The kernel would be very small - or non-existent, so there would be a much smaller surface to check for bugs and security holes, and much better performance - do one thing and do it well applied at the OS level instead of the utilities level.

Re:So roll your own.

[Grishnakh]

Oh please. The Windows kernel isn't POSIX-compliant either, and it's huge. There's a lot more to a kernel than POSIX compatibility; that's just a standard for the interfaces, mainly the system calls.

You're completely forgetting about everything else that goes into a kernel: the virtual memory subsystem, the scheduler, networking, IPC, etc.

You sound like someone who doesn't know much about kernels. Read this.

The kernel would be very small - or non-existent, so there would be a much smaller surface to check for bugs and security holes, and much better performance

And this sounds like a claim made by the microkernel supporters. The only problem here is that microkernels have crappier performance because of the message-passing needed. As a result, no one actually uses them, except for some hybrid versions which fall short of the pure microkernel approach. And even here, there's nothing stopping microkernels from being POSIX-compliant; it's an orthogonal issue. Every kernel has to have some kind of interface with userspace, whether it's POSIX system calls or something else.

Re:So roll your own.

[BarbaraHudson]

Not every kernel needs a continuously-running userspace, particularly if it's only doing a specific job. Also, no virtual memory, and no virtual memory manager, is required - just flat memory space and jump tables to the specific routines that need to be invoked. No message-passing either. Just jump directly from one routine to the other. No multi-tasking (except for interrupts), so no multi-tasking overhead.

And if you want to enable multiple instance of the tasks, there are ways to do it without time-slicing.

Re:So roll your own.

[Grishnakh]

Not every kernel needs a continuously-running userspace, particularly if it's only doing a specific job. Also, no virtual memory, and no virtual memory manager, is required - just flat memory space and jump tables to the specific routines that need to be invoked. No message-passing either. Just jump directly from one routine to the other. No multi-tasking (except for interrupts), so no multi-tasking overhead.

What you're talking about is not an OS that can be used for anything general-purpose, such as a desktop PC. It's not even an OS really, if it doesn't support multitasking. I've actually worked on an "OS" similar to this (if you can even call it that; it's really nothing more than a cooperative task scheduler), except this one had fixed-rate multitasking. This is something you'd use on a small embedded system such as with avionics, where you're controlling something in response to sensor inputs and need to keep the system extremely simple because it's safety-critical and everything must be deterministic. For things a little more complex, a commercial RTOS is normally used. These are usually much smaller and simpler than something like Linux (though RTOSes have a huge range: some are much larger and more complex, others are extremely minimalist and small).

What you're talking about, something with even less capability than MS-DOS, has no commercial use. No one uses anything like that any more; there's no reason for it since even the simplest RTOSes can very reliably handle multitasking. Can you even name any applications, or why anyone would want such a thing? If you don't need multitasking, you really don't need an OS at all, you can just run your application directly on the hardware.

Re:So roll your own.

[BarbaraHudson]

As I originally wrote, I was definitely NOT talking about a general-purpose OS. Everyone wants to include everything including the kitchen sink.

Re:So roll your own.

[Grishnakh]

Then I don't see what you're complaining about or what your point is. Linux isn't used in places where a tiny RTOS is warranted, and vice-versa. If you don't need a general-purpose OS, and in fact it would be bad to use one, then don't use one. There is no shortage of RTOSes out there.

Re:So roll your own.

[Anonymous Coward]

there are some that are intent on doing just that despite being labeled "haters"

Intent on doing that is fine, but can you stop wasting your day spreading bullshit about how you dislike systemd and do actual work?

Those people who genuinely dislike systemd [because it's work of satan] WILL flock to the distros that don't include it.
Others who only hate it because it's cool will gradually drop off once the benefits of systemd are smeared on their face [not that they're invisible at this time].

The rest of the world, which *drumroll* is the majority, doesn't give a shit about your struggles against systemd or any other kind of toolkit that you hate for whatever reason you came up with.

Re:So roll your own.

[Anonymous Coward]

Is that you, Mr. Tanenbaum?

Re:So roll your own.

[ookaze]

Rolling your own 'Just like Linus did' may be a little extreme. I don't think you need a whole new kernel!

Just install Linux from scratch and don't put all that *kit, etc.. crap in it. I would imagine you could even get rid of udev and all that stuff if you are willing to run mknode yourself. Roll it like it's 1995.

You will lose out on some convenience if you are using a portable device such as a laptop but on a desktop with fairly static hardware everything should work just fine.

If having your own custom simple Linux isn't good enough for you then take it to the next step and start your own distro that leaves all that stuff out.

I've run my own Linux From Scratch like system since 2001, and I can say your advice is a very bad one.
The problem is that the kernel provides dynamic interfaces since a long time. If you do what you say here, you will have a very limited setup that must not be a moving target, or take the risk of seeing your OS not boot very often, or even lose data (I had several of these problems before systemd). Your setup also has to be a very basic one.
Even your network interfaces or your disks can appear too late for your script on a very basic setup.
systemd is an answer to all this actually: it finally puts the dynamic parts in userspace needed to correctly handle the dynamic kernel.

The problems the OP is seeing, I've crashed into several years ago, and it's basically a documentation problem.
Some of the plumbing tools used for DE (like polkit or accountsservice) are badly documented, sometimes badly designed, sometimes with incomplete options (fixed in the latest versions of accountsservice) and the worst is that there is no howto that I could find explaining the big picture of how it all works together: everything is buried in various development ML. I had to basically reverse engineer nearly everything to understand how it works, mostly because as I compile everything from upstream, the DE like Gnome and KDE would just not start without everything in the right place and well configured.
Gnome 3 and KDE 4 were the worst upgrades for me, I delayed them a lot.
So what the OP discovered is actually nothing new, and I agree but only for security related plumbing needed for DE and user sessions.

Re:So roll your own.

[NateTech]

Yeah... that'd all be great if it were true... but the recent OpenSSL fiasco(s) show that there's significant non-variety in core things (because code-reuse is a good idea on things like crypto, maybe...) but those core things are continually and sometimes dramatically and fatally broken.

The crud layers on top of the core things don't add value when the core is broken.

Re:So roll your own.

[Anonymous Coward]

There are plenty of devices that have no OS on it. Just the services it needs to run on specific hardware.

Re:So roll your own.

[Damouze]

Systemd is a monstrosity that should never have seen the light of day. There is no excuse for closed-mindedness, arrogance. They lead to bad design. However brilliant its creator might be, systemd is flawed by design.

Some highlights (or maybe 'lowlights'?):

* System logs are primarily kept in a binary format, which is a very, -very- bad idea. You wish to store them in a database (which is basically what happens)? Fine, but only as a secondary way to store them, not the other way around!
* Init was built to do one thing and it was built to do that thing very well: run some variant of a shell script called rc. Everything else is superfluous. It is the cardinal rule, the core philosophy UNIX (and Linux nowadays) was created upon.
* Systemd is not very transparent. That in and of itself makes it a security concern to say the least.
* Nearly everything with systemd is done through (binary) modules with XML configuration files. A bad idea. A very, -very- bad idea. The pros of using shell scripts, and maybe, maybe use some (human-readabe) external configuration scripts are many, not the least of which is the fact that they are by far, much more customizable. With a classic init setup you not only control the setup and configuration of your system, you actually control its behaviour at boot time as well. If there is something you don't like about your system's behaviour, all you have to do is modify one or more of those shell scripts.

Your notion that systemd finally puts the dynamic parts in user space does not track at all. The dynamic parts have always (also) been in user space. That is why tools such as ifconfig, route (combined in the iptools ip* commands nowadays), etc. are user space / user land tools; they do not run in kernel space. The kernel provides an API for user space tools to work with. It has done that since the very early Linux days. The rc scripts and the scripts in init.d (in a SYSV like Linux setup) or in rc.d (in a BSD-like Linux setup, not many of those around anymore) in turn then use these userland tools to setup and configure your system.

If your network interface comes up too late during boot, before something that depends on it comes up, the problem is with the boot sequence, not with init itself. It's something you can fix yourself. You don't need some black box to do that for you. Moreover, if it succeeds at all at doing it, it will do it very badly. There is no excuse for a bad system setup. That goes both for the maintainers of a software distribution (in this case Linux) and you yourself as the individual who operates that software.

One thing I do agree with you about is the serious case of bad documentation. Moroever, I think that bad, incomplete or even missing documentation is the source of many a Linux user or admin's woes. But it is something that everyone can contribute to. Linux is after all, Open Source.

Re:So roll your own.

[Anonymous Coward]

They say younger engineers are better to hire than older engineers as they adapt to change more quickly. The older guys are too set in their ways. Your post is a perfect example of that.

Re:So roll your own.

[morgauxo]

"...I can say your advice is a very bad one."

I think you might be missing the fact that my "advice" was meant to be read in comparison to writing one's own operating system kernel from scratch. Certainly you don't think that would be better advice do you?

What I wrote was not intended to be serious advice as to a course of action. There are many shades of grey in between such a from-scratch system and just installing the latest RedHat or Debian Jesse and taking what you get.

" If you do what you say here, you will have a very limited setup that must not be a moving target,"

Yah.. I believe that I mentioned that. If you want a really simple system AND you want things like hotplugging hardware, sleep, dynamic cpu speeds and other power saving measures... well that's kind of a contradiction isn't it.

But.. on the other hand some of us do still have static desktops and servers that go for years without chaning hardware. It's not all laptops and USB. Some people seem to be forgetting that and force a lot of laptop/portable cruft on people who don't need it. I think it may be a generational thing.

"Even your network interfaces or your disks can appear too late for your script on a very basic setup."

I never said it would be easy. But there are simpler solutions to such things. I remember running ancient old versions of Linux like RedHat 2.x or Mandrake something or other. They had a lot less complication than what we have now and yes.. sometimes I did have to run mknode myself to get various hardware to work. But... once it was configured it worked. I never had networking or disk access or any of that stuff fail just because of a time to startup issue.

Re:So roll your own.

[Anonymous Coward]

Your empty head must explode when you go car or cereal shopping.

Yes

[drinkypoo]

Yes, yes it is. We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

There should be one facility for each function on the system. I don't need my network interfaces being diddled by bizarre and obscure programs. Example, libvirt doesn't use /etc/network/interfaces, this is stupid and complicates firewalling scripts and so on. And it insists on running its own copies of dnsmasq, rather than just dropping some files in /etc/dnsmasq.d. What a PITA. Use the goddamned operating system, that's what it's there for.

Re:Yes

[GrumpySteen]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Re:Yes

[Opportunist]

I think it's less the redundancy but rather the attempt to abstract away everything while at the same time including every kind of hardware and the stove into as few interfaces and scripts as you can get away with. There has to be ONE networking script, no matter whether the one actually used is wired, wireless or pigeon carrier based. And we have to include every single friggin' USB device ever built no matter whether 99% of them have at best a handful users and at worst a single user.

Linux is getting more and more similar to Windows, a huge abstraction layer crammed in between user and system in the vain attempt to make it "easy", and in this actually making everything overly complex.

Linux always had one defining strength over Windows: It is way more modular and its parts are way more easily separated and rejoined. And now various distributions try to nix this advantage by pouring their "version" into a monolithic block that "should be good for everyone". If they feel like diversifying, you'll maybe get a "server" and a "client" distri, with the main difference being that the server distri has no GUI.

Linux is getting overly convoluted, but only because we let it. Distributions are of course trying to take the easy way out, offering a system that will appeal to as many people as possible. Of course this lugs about a LOT of dead weight because what you need in your OS is useless to me and vv.

Re:Yes

[drinkypoo]

There has to be ONE networking script, no matter whether the one actually used is wired, wireless or pigeon carrier based.

Well, that's not really true. I mean, look at what I'm asking for WRT libvirt. There's a facility already present in the system for doing what they're doing, and they simply ignore it, with consequences for users. And what's more, the facility works really well for what they're doing with it, which they're doing very poorly.

And anyway, it's not true because interfaces can have their own scripts. I've used this functionality for firewalling on debian.

Linux is getting more and more similar to Windows, a huge abstraction layer crammed in between user and system in the vain attempt to make it "easy", and in this actually making everything overly complex.

Well, some things need centralized management, simply so that pieces of the system don't step on one another. Networking is basically the ideal example. Mounts are another. Nobody complains that everyone is expected to use fstab to define those, or that all mounts are tracked in the mtab.

Re:Yes

[umghhh]

in networking redundant is a base for constant amusement - all these people trying to figure out why loop protection software is not working or why certain things were switched off by loop protection software. It cannot really get better than this.....

Re:Yes

[Opportunist]

Centralized, yes. And I'm also in favor of choosing a tool for a job and sticking to it compared to everyone taking another one and distris having to support each of them in their scripts.

But that's exactly the point, do the scripts really need to lug about support for stuff that maybe one, maybe two people actually use? There's still support for some esoteric hardware that I never even heard about (and believe me, I've seen a lot) that has some odd quirks and has some "special needs" when it comes to scripting and starting, to the point where whole scripts that used to be easy and straightforward become insanely convoluted because that piece of junk needs you to do its name in interpretive dance to come up correctly.

My question is whether it is really warranted to overburden and complicate scripts and even the functionality of some tools to pander to the quirks of hardware hardly anyone uses. My approach would be to leave it out and offer patches for the 3 people who actually want to use them.

Re:Yes

[rastos1]

Sadly, systemd is the only effort to unify them

I don't know about "unify them". As far as I can see, it is trying hard to hide the complexity under one umbrella. And if the complexity is hidden completely, then there is little you can do to fix a problem that happens to be complex. Without this unifying effort I can easily plug in myself somewhere in the middle, track down what's going on and fix it. Or at least work around it. Ah, yes, I'm a Slackware user. Is that relevant?

Re:Yes

[Anonymous Coward]

Sorry, but mtab really is not it anymore. /proc/mounts gets you closer.

Re: Yes

[Anonymous Coward]

Systemd has been the most divisive force in the Linux community lately, and perhaps ever. It has been foisted upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just so they can get systems that boot properly.

Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.

Re:Yes

[Anonymous Coward]

Linux always had one defining strength over Windows: It is way more modular and its parts are way more easily separated and rejoined.

I suppose it depends on who you ask though. When administering servers, I agree the main advantage is the modularity. But in other cases, the big advantage of Linux is its support of older hardware, that I can take modern (maybe lightweight though) distros, and drop them on older hardware, and it just works.

Re:Yes

[drinkypoo]

My question is whether it is really warranted to overburden and complicate scripts and even the functionality of some tools to pander to the quirks of hardware hardly anyone uses. My approach would be to leave it out and offer patches for the 3 people who actually want to use them.

Seems to me like most of these issues are outright solved by the use of .d directories for configs... if you can drop scripts in them to extend scripts

Re:Yes

[Zeromous]

I have a new verb to describe this type of useless abstraction: I call it, "Poettering-around".

Re:Yes

[Ol Olsoc]

My question is whether it is really warranted to overburden and complicate scripts and even the functionality of some tools to pander to the quirks of hardware hardly anyone uses. My approach would be to leave it out and offer patches for the 3 people who actually want to use them.

Yet what really sold me on Linux is what you don't like. The nasty years of Windows Vista when perfectly good contemporary hardware had to be replaced. The present day situation where support for a product just goes away.

Linux now has the best support for devices of any OS.

My favorite example is when I was setting up a Dual boot system that used a USB to RS-232 adapter on both sides of the boot. I set it up first on the Linux end. No problem, Just enable the serial port (Linux looks at serial ports as a security issue) in bash, and it just worked. Now I start to set up on the Windows side. No worky. It sees the adapter, but no driver install. Nor help.

After a websearch I found out that the Adapter I had used was an old Staples adapter used for an ancient Palm Pilot my wife used maybe a decade ago. No Windows support, and none is forthcoming.

Its happily working on a Linux only system now, saved someone 50 bucks. It's also marked "do not use on Windows". Problem is, there really are a lot more than 3 of us who are using hardware other than the really common stuff. And your negative is our positive.

Re:Yes

[DarkOx]

libvirt doesn't use /etc/network/interfaces

My distro does not use /etc/network/insterfaces either so this is probably a good thing. Keep your debianisms to yourself.

Re: Yes

[arth1]

Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should give the guy a medal.

People are loath to publish new projects because keeping them running with systemd and all its dependencies in all possible permutations is a full time job. The whole "do one thing only and do it well" concept has been flushed down the drain.

I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7, but install new systems with RHEL 6 (or CentOS or ScientificLinux 6) and use 3rd party repos to get new stuff.

And that Red Hat sales go down is not just due to the turn in economy. It's people looking elsewhere, for something that lets people do their jobs. Systems that let you write simple scripts where you don't have to look up layers upon layers of abstractions to find out things. Where things are in plain text in known locations and names. Where you can copy configuration files from one machine to another without having to rewrite them or assemble a package of ten files from five different places.
Where the assumption isn't that when you install something, you want to run it (setting up HA on systems with systemd is a big pain, and failing over is an even bigger pain).
Binary logs without even forced flushing? Config changes that require reboots? No sane concept of runlevels? And I can go on and on.
Systemd is made for the convenience of single programmers on single laptops. It's anathema to system administration where you need to keep control.

Re:Yes

[morgauxo]

How about an example?

One of the things I love about Linux is all the old and esoteric hardware it supports. I don't want to throw away something that suites me just fine only because it isn't popular anymore.

I do agree that costs and benefits shoudl be weighed. But where is all this old hardware support complicating scripts that you speak of? The place I am used to seeing hardware support is in the kernel. It's a dropdown... build it in, make it a module or don't support it. I'm guessing that 90% or so of users don't even see that anyway! They are probably running kernels that came with their distros.

I don't even mind if distros chose not to build in modules for ancient hardware. So long as I am free to compile my own kernel who cares? But.. where are these scripts that will be oh so better if only we flipped the bird to the few people still using some hardware and told them they can't have their toy anymore?

Also.. even if removing support for one piece of hardware only alienates a few people... If you really clean house then that's a few people per each device you condemn to obsolesence. Don't you think they might add up?

Re:Yes

[morgauxo]

Either one will do. mtab usually still exists.. as a link to /proc/mounts.

Re: Yes

[Anonymous Coward]

SystemD has put in jeopardy the entire presence of Linux in the server room:

1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.

2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.

3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.

4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.

5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.

6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.

So, all and all, SystemD is the worst thing that has happened with Linux, its reputation, and potentially, its future in 10 years, since the ACTA treaty was put to rest. SystemD is not production ready, and potentially can put every single box in jeopardy of a remote root hole.

Re:Yes

[morgauxo]

"Linux is getting more and more similar to Windows"

Windows throws away support for old hardware all the time. I have a shelf full of network adapters, soundcards and more that are perfectly adequate for most purposes however only under Linux as Windows has no drivers.

Re:Yes

[leftover]

By any metric Yes! "Choice" was the old mantra, with the unspoken assumption that any of the alternatives actually worked. Now we have too many alternatives to track adequately, each one requiring too much fiddling and compromise to function at all.
IMHO the underlying cause is there was too much karma for having your own fork of a project and not nearly enough karma for making the base project more elegant = simpler, cleaner, more robust, better documented. Just look at several key aspects of nearly any distribution: boot, audio, display, toolkits. They are all ridiculous.
And the distributions themselves - have you looked at the chart on http://en.wikipedia.org/wiki/L... ? Again, ridiculous. That is not "choice", it is a quagmire.

Re:Yes

[morgauxo]

Yes but now we have people who grew up on iPods and their one-button simplicity. The mere existence of support for something they do not care about offends their sense of decor.

Re:Yes

[Anonymous Coward]

They only thing linux had going for it ever was that it was free. Now that I have money, I moved to a real OS that both works and offers a good CLI experience in addition to a decent GUI experience. Sadly, Apple seems hell bent on fucking that up as it's been all downhill since 10.6.

Re: Yes

[morgauxo]

So long as Slackware, Gentoo and LFS exist I don't see how anyone has been FORCED off of Linux or onto the BSDs. I think that is a combination of pre-existing curiosity and a knee-jerk reaction.

If anything people might be forced off of Gnome, KDE and anything else where the developers decide to REQUIRE Systemd. But.. how is switching to BSD going to help? How are those things going to run on the BSDs? Just use the forks... there will be many.

Sorry baby, this bathwater is looking pretty murky it's out to the dumpster with you!

Re:Yes

[gweihir]

You have the problem right but not the solution. The only way to deal with "too many frameworks" is to kick them out and go back to KISS and "do one thing and do it well". The problem is not the redundancy of the frameworks, but their use in the first place. Most of their functionality is not needed in most cases. Traditionally, the answer to that to was to only install when needed. These days, everything and the kitchen sink gets used by some obscure, minuscule part of the system and you cannot easily do without it. Minimalism is not done in engineering because it is elegant, it is done as it is critically needed for survival.

Example: I have been running Debian forever with my own kernels. These are non-modular, no initrd. That alone cuts down on the complexity of the boot-process severely. One of the reasons I do emphatically do not want systemd is the rumors that it needs specific kernel-version and hence the possibility to boot Debian with (almost) whatever kernel you want will be going away. The complexity increase of that alone already negates any possible advantage it could have.

Re: Yes

[Anonymous Coward]

Systemd is made for the convenience of single programmers on single laptops.

I'm a single programmer on a single laptop and I don't want systemd either.

Re:Yes

[gweihir]

Well, systemd follows the Windows philosophy of "the user is an idiot". The design of hiding everything in complex code is a dead giveaway, as is the communications of its development team and proponents. I did leave Windows behind (other than for gaming) to get away from exactly that BS. Now it starts to creep into Linux as well in a massive way and that is just not acceptable. I have to admit that I am by now fed up enough to seriously thinking about even throwing out things like udev. It is complex, intransparent, unreliable, hard to debug and I do not really need it. I have been running my own non-modular kernels for years to reduce complexity, and that has been working well.

Re: Yes

[gweihir]

Very, very true.

Re:Yes

[Anonymous Coward]

I don't know of any networking scripts that support the scanning and OCR functionality necessary to getting IP over avian carrier automated into the system.

Re: Yes

[Anonymous Coward]

Application and supported operating system requirements.

For example, if I decide to run a NetBackup media server on Slackware, if something glitches, Symantec will laugh in my face.

Then there is compliance and certification. No FIPS compliance, no authorization to run that OS in a lot of environments. SuSE and RedHat both have Common Criteria and FIPS compliance, BSD, Slackware, LFS, and Gentoo do not.

There is a big difference between what the enterprise needs and what runs on one's little playground at home.

Re:Yes

[unrtst]

But that's exactly the point, do the scripts really need to lug about support for stuff that maybe one, maybe two people actually use?...

:-) This topic is perfect for /. because of the complete lack of scope.

When you refer to "scripts", what level/layer are you referring to? I don't even think there is a well defined naming convention for that (ex. something like an OSI model with respect to configuration of hardware).

Given the networking example...

On the GUI level, there are loads of interfaces, many specialized, to aid in configuring the network. Some of them are protocol-specific, such as various VPN utilities, kppp and other ppp utilities, dial up interfaces, and a bunch of wifi ones too. Many of those are somewhat modular, with a backend/libs, command line interface, gnome/gtk interface, qt/kde interface, and possibly others (curses, xfce, tk, etc). That said, there is a primary target within this cadre: Network Manager and all its cousins.

On the other end of things, within the kernel, there's loads of drivers and standardized ways for those to interface with the various kernel subsystems. Those drivers necessarily have a wide variety of options... that's kinda the point. The vast majority of those can be compiled into the kernel, built as modules, or not built at all. This layer is fairly well defined as there is a clear separation of user space and kernel space; this ends at the first layer that provides a user space API (and this could be considered to constitute two layers... kernel space and user space of that... think OSI layer 1 and 2).

On that kernel level (similar to OSI media layers), I don't think we have a problem. This is, at least partially, due to the monolithic nature of the kernel and it's management by a benevolent dictator. A few comments here have mentioned support for old hardware, but I don't think they are referring to the drivers themselves nor the kernel... they're likely referring to something further up in user space. IMO, if the question is posed here, the answer is "No, Linux is not becoming too complex".

On the top end of the GUI side, I'd also argue that, "No, Linux is not becoming too complex". Yes, it can be a quagmire of various utilities at times, and some work better than others, but that *should* be fine. Hell, that's the only way to quiet those that complain about supporting all that old hardware - just snip it out of the GUI utility or hide it in advanced areas. I would never want to enforce a rule that these must all go through some specific middle ware, though that's really the part we should all be talking about.

So... the middle. This thread referenced "/etc/network/interfaces". That does NOT exist on all distributes (ex. redhat based systems don't have this). Personally, I like /etc/network/interfaces, but it's a good example of fragmentation of "standard" ways/interfaces to configure the kernel networking subsystem. Is it bad that debian and redhat both do it different? IMO, the "becoming too complex" question would imply that this is NOT bad, since this has been this way FOR A LONG LONG LONG TIME, and I'd agree that this amount of differentiation is ok and even good, but this could easily be argued is and firmly into the grey area.

The part that I have very large concerns with is what is currently happening with the low-level just above kernel... specifically, systemd and its related parts. Networking is an example here, as one of its goals is to provide one unified/common way to configure the network.... but doesn't that already exist!?!? It's called the kernel! On the other hand, maybe it will prove to be a useful shim? The fact that a single framework is going in above the kernel, which some direct ties to the kernel, and is casting a very wide net in terms of things it is, or can, control (logging, network, dhcp, login, init, sessions, mounts, consoles/vte, timedated/ntp, devices/udevd)... we'd better hope and pray it's designed well cause everything and the kitchen sink will soon have direct dependencies on the interfaces it's implementing.

Re:Yes

[CastrTroy]

As long as you have hardware that Linux works well with, then you could probably have a very good experience. However, every machine that I've ever tried to run Linux on personally has had some nagging hardware issues that just don't get resolved. Had I bought a machine specifically with the intention of running Linux on it, then I might have a better experience, as I could verify that all the hardware is compatible before loading on the operating system. But using the machines I just happened to own, it's pretty hit or miss as far as what hardware will have good drivers. Usually the video card isn't very well supported. If it's not that, then it's some other piece of hardware I want to plug in, like a camera, or a scanner, or a printer.

Re: Yes

[gmack]

Who modded this up?

SystemD has put in jeopardy the entire presence of Linux in the server room:

1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.

Formal code testing is pretty much what Redhat brings to the table.

2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.

At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.

3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.

Do you really understand the architecture of either SystemD or sendmail? Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD, Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly, since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on the systemd web site so I really don't get how you didn't know this.

4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.

Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done will not even notice the transition.

5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.

Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean up the horrific mess that was the previous init.

6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.

Solaris has already transitioned to it's own equivalent daemon that does roughly what SystemD does.
As for SystemD: It all

Re:Yes

[Bengie]

It's a balance between "change for the sake of change" and "being hamstrung by technical debt". Yes, old hardware support is technical debt if it holds you back.

Re: Yes

[Anonymous Coward]

Actually, 3 is not exactly true. While its separation still leaves much to be desired, it's not a one large blob, but a set of daemons and tools maintained together as one codebase. Other than that, it's all true.

Re:Yes

[Anonymous Coward]

'sth is poettering' means it acts invasive, possessive, destructive, and generally in an egocentric exacerbating negative way. ``this cancer is extremely poettering''

Re:Yes

[AmiMoJo]

It's nice to have support for lots of old hardware, but the real solution is not to include support for every random device in your OS, it's to standardise devices.

USB to serial converters use the USB CDC protocol. They shouldn't need a special driver, and in fact most use the generic CDC driver supplied with the OS on most systems, including Windows. The problem is that there isn't a simple way to identify what devices will work with such a driver, so Windows requires a .inf file to tell it and Linux has a big giant list of VID/PID pairs.

Even worse, some manufacturers deliberately want to make the user install their driver rather than using the generic one. If they bothered to support Linux they would probably force you to run a script as root to make their hardware work. They want to control the driver being used to make support easier. Known driver version, known OS version, anything else won't install.

On the other hand USB mass storage and HID devices (keyboards, mice, etc.) use the generic OS drivers automatically and "just work". If CDC had been implemented better it could have benefited from the same thing. Having said that, HID keyboards are a bit of a disaster as well... You still need to tell the OS what locale they are for.

Re: Yes

[Anonymous Coward]

systemd is not divisive, there are a few loud haters based on personalities working on it, that's all. The kernel developers are using it, and the major distros dumped sys-v for it. So the tiny minority of users making noises are statistically insignificant. They are more than welcome to role out their own non-systemd distro, put their time where their mouth is, as it were.

Re:Yes

[Dragonslicer]

There's a facility already present in the system for doing what they're doing, and they simply ignore it, with consequences for users. And what's more, the facility works really well for what they're doing with it, which they're doing very poorly.

If a software package used an existing, high-quality facility for doing a particular task, someone somewhere would complain about the dependency.

Re: Yes

[Dragonslicer]

3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.

Because of course it's been years since anyone found any security holes in well-tested software like Bash or OpenSSL.

Re: Yes

[Anonymous Coward]

Slackware, Gentoo and LFS are not options.

Slackware is 1990s-era relic. We're looking to use a modern Linux distro, like Debian from just before the switch to systemd. We aren't looking for something that hasn't really changed much since 1997.

Gentoo and LFS defeat the whole purpose of using a Linux distro. I don't want to wait a week for Gentoo on my laptop to finish compiling Xfce. I want to download and install binary packages, and be able to use Xfce within a couple of minutes, like how Debian does it. And I don't want to have to spend a week teeaking obscure config files.

We want Debian without systemd. We don't want Gentoo or LFS, and we surely don't want Slackware.

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Re:Yes

[BronsCon]

Finally! Someone else that feels the same way! I wish you hadn't posted anonymously...

Re:Yes

[Zeromous]

Synonymous with Oprah-ing! "You've got cancer, You've got cancer, and you've got cancer, everyone in the audience has received cancer! " *throws cue cards in the air and wraps the show*

Re: Yes

[Billly Gates]

Not until last summer was SystemD ever a big deal.

One story had hate comments then it became cool to hate and then became a religion afterwards as slashdotters made up their minds.

Look? Sun, Apple, and Ubuntu have all left init behind years ago. No flames, no anger, and some comments here praising the effort as init (yes slashdotters init has issues) can't handle events. Example is a laptop falling asleep and waking up or let's say you want your apache server to do a set of actions if it is hacked or a redundant connection is down.

With startupd, launchd, SMF, and SystemD you set the triggers for each event. No long scripts loaded with nested if/else statements galore or expensive proprietary software to mask this lack of functionality in init.

The FUD is LOOK IT IS ROUTING packets??! BLOAT OMG! Really it is just passing arguments to network daemons. Or LOOK IT HAS binary LOGS PROPRIETARY?! This is a feature against root kits as guess what I would if I hacked your server? Gee alter the logs.

It is only 300k lines of code.

Not saying SystemD is great. Just saying this being the cause of the death of Linux and is equal to SCO is lunacy

Re: Yes

[Anonymous Coward]

My systemd experience this morning was a total lockout and lockup while booting forcing a full re-install of my Red Hat Linux. This is the second time for me, where changing a parameter in systemd's bullshit start up process locked the machine so bad, that I could even rescue the system by booting to console on a rescueCD! I HATE SYSTEMD!!!! IT SUCKS!!!! ITS THE WORST PIECE OF CRAP EVER! ITS LIKE WORKING WITH A BINARY EDITOR!

Let me explain, I down loaded the source code to systemd because I needed to create my own startup code to get my head and wand tracking demon working. Normally you just create a shell script for these things, but because I used IPC protocol I thought looking a DBUS would be the way to go. So long story short, I install my things and something in the god damn chain of want's, services, sockets got broke. (I don't know here it is, because it locks up so hard). Unless Red Hate wants to write this the for me, screw it.

Systemd is the nightmare scenario come true in linux. A GIANT LEAP BACKWARDS into FULL BLOWN CRAP HOOD!

Re: Yes

[fahrbot-bot]

Unlikely, it is a minority of malcontents who are upset about SystemD ...

So anyone who disagrees with you and/or SystemD are "malcontents" - nice.

Re:Yes

[UnderCoverPenguin]

Had I bought a machine specifically with the intention of running Linux on it, then I might have a better experience, as I could verify that all the hardware is compatible before loading on the operating system. But using the machines I just happened to own, it's pretty hit or miss as far as what hardware will have good drivers.

Hardly surprising. FWIW, most people buying MS Windows PCs buy them with Windows pre-installed. The only time I ever installed "retail box" MS Windows was (over 10 years ago) when helping a friend who was "building" his own PC. We had to do a lot of searching and visit several component vendors' websites to find all the drivers needed. I can't speak to the current situation.

From comments made by the IT people at most of the companies I've worked for, there is a similar situation for "business" PCs running MS Windows. These comments came from me making the observation that PCs from a certain PC vendor were the most common (at the companies I've worked for). Their responses were to the effect that that vendor made it very easy for them to create custom system images. (So easy that they could create different images for different (groups of) departments - Administration, Finance and HR PCs got a system image "optimized" for office tasks. Engineering PCs got an image optimized for engineering needs, likewise, Logistics and Manufacturing PCs got an image for L&M needs.) They also said that PCs from other vendors required significantly more effort to create custom system images.

Re: Yes

[postbigbang]

It's my humble opinion that if systemd stops you cold, you ought to be in another profession. Just surrender your capacity to adapt and move on, hang up your holster and belt, and go into automotive tech or something else where the rules change less frequently.

Using systemd isn't rocket science. It a simple change that cleans up a lot of old code and retirement plan permutations.

Maybe I get marked as troll. Guys that can't think out of an ipconfig box need to embrace their brittleness and just bug out into early BSD or similar. The world's gonna pass you by.

Re:Yes

[greenwow]

> The design of hiding everything

And that is the problem. The concept of hiding log messages is a troubleshooting and security nightmare. For example, when MongoDB fails to start, systemd decides to eat the error messages. For example, on our server the output from "journalctl -u mongod" contained:

Feb 08 03:48:37 systemdtest systemd[1]: Starting SYSV: Mongo is a scalable, document-oriented database....
Feb 08 03:48:38 systemdtest runuser[28281]: pam_unix(runuser:session): session opened for user mongod by (uid=0)
Feb 08 03:48:38 systemdtest mongod[28275]: Starting mongod: [FAILED]
Feb 08 03:48:38 systemdtest systemd[1]: mongod.service: control process exited, code=exited status=1
Feb 08 03:48:38 systemdtest systemd[1]: Failed to start SYSV: Mongo is a scalable, document-oriented database..
Feb 08 03:48:38 systemdtest systemd[1]: Unit mongod.service entered failed state.

It logs that it failed to start, but systemd threw away the reason. Using strace I was able to find-out that it was a SELinux setup issue. The problem was that /var/lib/mongo somehow lost the mongod_var_lib_t security context. Doing a restorecon fixed the problem. That problem takes a few seconds to fix with standard syslog. With systemd's policy against logging, it took me over half of a day. This is why systemd is evil.

Even worse is if you have a security problem then systemd makes it much harder to find-out what happened because it throws away so much logging.

Re:Yes

[UnderCoverPenguin]

My pigeons have NFC implants. Packets are automatically down/up-loaded from the implants as the pigeons arrive/depart.

Re:Yes

[rahvin112]

Version 1 Neatreciepts scanner. It's a rebranded common brand with a changed USB ID. Linux recognizes it fine but on windows it's a nightmare to get it working. I have lots of examples like this where I can use it on linux but not on a new version of windows.

Re: Yes

[Eravnrekaree]

I agree that runlevels should be a part of the systemd model. Other basic concepts that systemd was trying to do are not bad. Its hard to argue that a system administrator should not be allowed to configure a certain program to run when the NIC goes up or down or when there is some other system event. It sounds as though systemd's execution of these things may be lacking. systemd should provide support for traditional sysv init facilities as well, if thats what you want to use.

As for binary logs, configuration, I think the system admin should have the choice between binary and text based. Binary has some advantages, in that they can be easily programatically accessed and still be accessed by text based utilities, since there is a hash or b-tree index, a large log or config database can be easily searched without having to do a scan of the entire file. Its also possible that binary logs could be used to generate a text version of the log, if you want to use the vi, and as well to the text file only, without anything being kept in the binary log. So the choice betwene binary and text should be your choice, it shouldnt be an either or thing.

Re: Yes

[gmack]

When they spread misinformation? Yes. When they bring up every possible opportunity to tell the whole world how much they hate SystemD? Yes.

What pisses me off is that based on the posts I was seeing here, I started to really worry about my future as a Linux admin but then I looked for myself and discovered just how much misinformation was being passed around here.

Re:Yes

[Eravnrekaree]

Linux should have a committment to old hardware. One big issue is the Wayland thing. Wayland supports a grand total of 3 adapter families or so. It only runs on the latest and greatest. There is a lot of old hardware that is supported well by the X server, so the X server needs to continue to be provided for that fallback.

I actually think that Wayland is potentially worse than systemd by far, if we do not allow people to run all their GUI programs as X applications. X needs work on security hardening for sure. But, Wayland puts hardware drivers and address space *inside your web browser*. Excuse me for being a little skeptical. Wayland introduces a very rigid desktop model where its hard to change your window manager without a complete restart of GUI, where the need for network transparency has not been addressed well enough,

Re:Yes

[dpidcoe]

The only time I ever installed "retail box" MS Windows was (over 10 years ago) when helping a friend who was "building" his own PC. We had to do a lot of searching and visit several component vendors' websites to find all the drivers needed. I can't speak to the current situation.

I've been building my own computers for the last 14 years and never once had to do any kind of excessive searching. Go to vendors site->find driver->download->run installer->done.

Contrasting to my typical linux driver experience which was usually look at vendor site->find driver->download->installation script doesn't work->google->find forum thread with same problem ending in "oh nevermind guys I solved it"->ask for help on IRC, get told to follow the directions on the vendor site. Get called an idiot after saying they don't work->try in desperation to recreate steps outlined in thread before OP left it hanging->break a few other bits of my linux install->post on forum asking for help->get called a moron for attempting to fix it and breaking it->someone finally links a working version of it from some obscure linux repo that I never would have found otherwise->driver works now->need to reinstall to fix damage inflicted during driver hunt.

Re:Yes

[Anonymous Coward]

Added to vocabulary.

Re:Yes

[Anonymous Coward]

"Distributions are of course trying to take the easy way out, offering a system that will appeal to as many people as possible."

Um. This is clearly NOT the "easy" way out.

Re: Yes

[Anonymous Coward]

Insightful? How about flailing-armed whining?

Re: Yes

[Anonymous Coward]

Systemd wasn't a problem for most Linux users when they could completely avoid it. But the number of users in such a position has been decreasing as more and more distros switch to it, often with disastrous results.

Debian's switch screwed over a lot of users, especially ones who don't put up with idiocy like systemd. The biggest uproar has come from these people. By taking away the ability to completely ignore systemd, Debian has basically condemned itself to irrelevancy.

No serious users are putting up with the danger and instability that systemd brought to Debian. These users have already moved to one or more of the BSDs, or are doing so now, since it's clear that there is no hope for Debian to recover from this disaster.

Re:Yes

[Anonymous Coward]

It really boils down to deciding what "Linux" is.

The kernel is too narrowly scoped to standardize all the complexity of network management, because the kernel boundaries tend to be defined by trying to throw as much "policy" as possible into user space via a simple, stateful, and imperative system call interface. The kernel has state about the current configuration of a device and a state machine that allows certain operations to be performed. It does not have the declarative policy for all the different network states the user might want/allow and the heuristics to move from state to state in response to environmental events or user inputs.

Charitably speaking, yes, systemd and friends is trying to factor out this policy and heuristic agent to site beneath the GUI. But, it still shows many design decisions that reveal a desktop/single-user focus. It is not clear that a one-size-fits-all solution can be found. In a laptop/mobile setting, you have a very different policy and set of heuristics than you have an a workstation or server that is wired into a permanent location. This differs further when the system is multi-user versus single user (whether concurrent or sequentially multi-user). In large-scale devops and virtualization, you want to externalize most of the policy and heuristics to remote management infrastructure, which is quite different from traditional stand-alone servers.

What is very frustrating is when someone has to move between these spaces or change the operating mode of an existing machine and there is a clash of worlds. A server (physical or VM) that supports remote users and clients should always bring up its network independent of any GUI state that it might have for local console users or virtual (RDP, VNC) console users. A workstation that has centralized admin should not treat the GUI user as a privileged actor who can change network state at the click of a button.

There are also differences in error handling and user trust policy that cross-cut all of this. In my world, a DHCP server may be unresponsive for a while after ethernet links stabilize, and the machine should keep retrying indefinitely, not fall into an error state assuming that the link status should bounce to indicate it has moved to a new network environment where a new address is required. In my world, the policy of which wireless network to use is a privileged decision of the admin, not the currently active GUI user. In my world, services and applications absolutely should not be allowed to poke holes in the Linux software firewall on demand. The whole point of the firewall is to add a second line of defense around these complex codebases that are not fully trusted.

Re:Yes

[Lightning McQueen]

I understand your desire to continue to use a technology. But hardware and software are constantly evolving. It's time consuming to develop new applications for new hardware / software frameworks and then also support old hardware / old software. The second part is usually cost prohibitive. I believe this is the direction of all other systems out there. Linux is entirely different.

Re:Yes

[gweihir]

Yikes, it throws away logging? That is really, really bad! Another excellent example why this thing is either not made by anybody with a clue, or constitutes active and intentional sabotage...

And I do understand exactly and completely agree that this is a security nightmare, for example when you are analyzing an attack. I expect people will start to actively exploit that by crafting attacks that do not show up in the logs in any meaningful way due to this log-truncation or the equally bad broken log-flushing.

Re: Yes

[fahrbot-bot]

I imagine there's some misinformation on both sides of the SystemD issue - perhaps not equal, but Lennart and Kay's hands are probably not clean - based on their histories.

SystemD seems overly engineered, complex and consuming for what actually *needs* to be done. Concerns of the "malcontents" shouldn't be casually dismissed - as the SystemD supporters seem to be doing.

Re:Yes

[ron_ivi]

systemd

Lol - I see this article is tagged 'sodomy'.

Is that the cool way to pronounce 'systemd' these days?

Re: Yes

[armanox]

Those "few loud haters" translate to a whole bunch of system administrators and IT Managers/Directors who played a very large role in getting Linux to it's place in the datacenter today. We have plenty of options, outside of the systemd infested GNU/Linux world to choose from, so why would we want to bother with a system where the developers don't want us?

Re: Yes

[Anonymous Coward]

Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should give the guy a medal.

Maybe Microsoft (and others) are giving him and his crew far more than just a medal...

Re:Yes

[Anonymous Coward]

Uh, systemd logs stdout and stuff otherwise sent to syslog. It doesn't throw stuff out.

If your distro or upstream is configuring mongod to not log stuff it should, that is a bug with your distro or mongo. The same is true if you have it configured to not log stuff to whatever other syslog implementation you prefer.

Re:Yes

[Anonymous Coward]

Yikes, it throws away logging? That is really, really bad!

Nope. Somebody just configured a program to not log something. If this were an issue there would be a bug logged somewhere, for starters.

There is no "systemd policy against logging" - it logs whatever it receives, and the package maintainers for your distro generally configure what gets sent to the logs. That has been the case for years - long before systemd came along.

Re: Yes

[rastos1]

So long as Slackware, Gentoo and LFS exist I don't see how anyone has been FORCED off of Linux or onto the BSDs.

Maintaining a distro that does not use systemd when almost every project (package) expects systemd is not trivial. The danger is that the distro maintainers just throw the hands up and say "fuck that, I don't have energy to wrestle with this anymore". And then the users will be FORCED off.

Re: Yes

[Anonymous Coward]

That's the point. If well-tested, established, widely-used programs and libraries like bash and OpenSSL can still have flaws that go undetected for years or decades, then systemd is probably rife with them, too. But systemd is far more critical to a system than even bash is, plus it's a lot less mature and undergoing frequent and significant change, so the risk is much greater.

Re: Yes

[rastos1]

Slackware is 1990s-era relic.

Are you qualified to say that? I use Slackware on server and desktop and it fills all my admin/office/development/multimedia needs. What makes it 1990s-era relic? Because it does not have dependency checking? Bah.

Re: Yes

[rastos1]

With startupd, launchd, SMF, and SystemD you set the triggers for each event. No long scripts loaded with nested if/else statements galore or expensive proprietary software to mask this lack of functionality in init.

Okay, I'm always willing to learn, so please, give me a lesson. I set up a trigger for the event and the trigger does not fire. What do I do? In case of the "long script with nested if/else statements galore" I'm pretty sure what do I do there - put in some echo statements to verify the execution path. What do I do with systemd?

Re:Yes

[Aighearach]

Reminds me of the 2001 interview where they asked Linus where he saw linux in 10 years, and he said hopefully people will have moved on to something better, because Linux was just something useful now, it wasn't the best thing imaginable, and something else should come along and be better.

Re:Yes

[Ol Olsoc]

I've been building my own computers for the last 14 years and never once had to do any kind of excessive searching. Go to vendors site->find driver->download->run installer->done. Contrasting to my typical linux driver experience which was usually look at vendor site->find driver-

Sounds like the last time you installed Linux was 14 years ago.

I use this method:

Install Linux from iso with peripherals attached. Have ethernet connectivity

Linux installs any drivers needed during installation.

I don't even think about it, and for probably the last 7 years or so have not visited a website for any Linux driver. I've visted Windows drivers sites, sometimes to be told to slag off because they don't have, nor do they intend to have a driver any more for the hardware I'm trying to install.

And on new peripheral installs, It automagically does it also. I brought a wireless printer online, tell my linux machines to access it, and they go get the driver for me. Easy Peasy, much much easier than a Windows install.

Note that yes, I have to approve the new installs including any additional files needed. One click trick.

Re:Yes

[Anonymous Coward]

The things will start to get really funny when kdbus hits the mainline kernel. With systemd's track record of backwards compatibility, likely the kdbus will be the only supported way of dbus really soon. After that point, one can only dream of bisecting kernel bugs, as the system simply will not start with older kernels.

Re: Yes

[Anonymous Coward]

I feel like the folks in the anti-SystemD crowd are just pissed because they can't justify their employment if they don't always need someone hacking away at init scripts to boot and maintain a system.

Re: Yes

[Anonymous Coward]

It's my humble opinion that if systemd stops you cold, you ought to be in another profession.

Is it also your opinion that we should happily accept any fundamental change in OS regardless of how shitty the implementation?

Re:Yes

[Grishnakh]

Linux always had one defining strength over Windows: It is way more modular and its parts are way more easily separated and rejoined. And now various distributions try to nix this advantage by pouring their "version" into a monolithic block that "should be good for everyone". If they feel like diversifying, you'll maybe get a "server" and a "client" distri, with the main difference being that the server distri has no GUI.

We've had this monolithic block that "should be good for everyone" for a very, very long time now: it's called "the Linux kernel". Every Linux distro, ever, has used the Linux kernel (unless you count Debian's version that uses the FreeBSD kernel). Very few people seem to have a problem with everyone using the same kernel, from big-iron servers to tiny embedded systems. And it works, very, very well.

Distributions are of course trying to take the easy way out, offering a system that will appeal to as many people as possible. Of course this lugs about a LOT of dead weight because what you need in your OS is useless to me and vv.

We've done the same thing with the kernel, since day 1. Drivers for everything are included in it. And why shouldn't they be? If you don't need drivers for something, it's not a problem as the drivers are only loaded on-demand on desktop distros. If you're worried about a few megabytes of hard drive space in the age of 1TB+ drives, you have some seriously skewed priorities. And on custom embedded systems where the drivers are compiled in (or included on the initrd), the extra drivers take no space at all since they aren't shipped with the system if they aren't used.

All this "dead weight" is actually useful to people; as long as it isn't taking up system memory and CPU cycles, who cares?

Re:Yes

[Grishnakh]

Do you have any real examples for this quirky hardware which you claim actually affects peoples' systems?

Re: Yes

[postbigbang]

Wrong question. The problems that led to systemd weren't built in a day/week/month/year, and neither will be the maturity that it needs to work.

Regardless of how shitty? If you're unaware of bad implementations, I can suggest many places to turn towards to find pretty ugly stuff, no matter the OS. The pain of systemd passes easily. Not rocket science. Pretty consistent.

Re: Yes

[Bill_the_Engineer]

It's my humble opinion that if systemd stops you cold, you ought to be in another profession.

Why look for another profession? It is easier to look for another OS.

It's obvious you like systemd. On the other hand, I have no pressing need for systemd and am quite happy with RHEL6.

There is a good chance that your attitude is one of the reasons why systemd has met some resistance.

Re:Yes

[Grishnakh]

I don't even mind if distros chose not to build in modules for ancient hardware. So long as I am free to compile my own kernel who cares?

It would be idiotic for distros not to build those modules. It takes no work at all to enable everything, and the modules just get built automatically when the kernel is built. The only downside is a bit of CPU time when building the kernel (which is part of the distro's completely automated build system anyway, so they won't notice it), and a tiny bit of hard drive space. It's so insignificant that distros don't even bother putting them in a separate package to save space on the install media.

Re: Yes

[gmack]

For me, there is only a single mandatory piece that I have a problem with and that is the binary logging but that is easy to bypass even if I can't turn it off. For the rest of the crap such as his DHCP server or his NTP server, I have no plans to install them.

This will not be the end of Linux, it is slightly different and hasn't caused me any headaches server side and a single problem with pulseaudio (permissions problem) on my desktop running Debian testing (my laptop works fine however). It has however saved me once on the server when I accidentally typed "/etc/init.d/networking restart" instead of "nohup /etc/init.d/networking restart" Previously that would have caused the machine to terminate the script as soon as my remote console dropped without completing, leaving me without a network connection but now the command runs in the background and it just works.

Re: Yes

[postbigbang]

Along the way, your RHEL6 will be fine, and it will grow cold, like they all do, as will your skills. I don't particularly care for systemd, but I learned it in a couple of hours, and yeah, it works.

I've been doing Unices for longer than most slashdotters have been alive, a very long time. This isn't much to get outraged over. Many changes meet resistance. I saw this changeover first in Solaris; I knew it was coming. First few times, PITA. Now, I shrug.

Stuff is going to change. This one's for the better, IMHO. I would change other stuff, too, but that's another thread. This one was ripe. If it's too hot in the kitchen, go back to the dining room. Find another dining room. Linux has more darwinism in it than any other OS I've seen. I used think that fact was forboding, but it's not. It's pressured evolution.

Re: Yes

[theArtificial]

I'm a single programmer on a single laptop and I don't want systemd

I'm just a poor boy from a poor family~ SystemD Rhapsody

Re:Yes

[Anonymous Coward]

> crafting attacks that do not show up in the logs in any meaningful way

That's trivial to do with fail2ban on Red Hat/CentOS 7 with systemd, because systemd throws away all of the messages that fail2ban logs. My firewall is under constant attacks, but systemd deletes all of the logged messages from fail2ban:

# journalctl -u fail2ban

Feb 11 18:20:08 vpn systemd[1]: Starting Fail2Ban Service...
Feb 11 18:20:08 vpn fail2ban-client[10177]: 2015-02-11 18:20:08,398 fail2ban.server [10178]: INFO Starting Fail2ban v0.9.1
Feb 11 18:20:08 vpn fail2ban-client[10177]: 2015-02-11 18:20:08,398 fail2ban.server [10178]: INFO Starting in daemon mode

There's nothing about any of the attacks! Before I upgraded to systemd, you'd see messages logged to syslog like:

fail2ban.filter [10180]: INFO [sshd] Found 58.218.213.234
fail2ban.filter [10180]: INFO [ssh-iptables] Found 58.218.213.234
fail2ban.filter [10180]: INFO [sshd] Found 58.218.213.234
fail2ban.actions [10180]: NOTICE [ssh-iptables] 58.218.213.234 already banned
fail2ban.actions [10180]: NOTICE [sshd] 58.218.213.234 already banned

Now, I can't tell who is attacking me. systemd is a security disaster.

Re:Yes

[drinkypoo]

My distro does not use /etc/network/insterfaces either so this is probably a good thing. Keep your debianisms to yourself.

On your distribution it should use whatever the thing is that is used. redhate distributions have their own equivalents, etc etc. If there is no such thing, then do the management totally freeform. Is that more work? Sure. This is the kind of thing I always hoped would get unified, just not under systemd

Re: Yes

[Billly Gates]

Outside of slashdot started last July I have yet to meet a SystemD hater.

It seems just here. But now that is fashionable we all ahte it because everyone else hates it.

Init is going away. Not just linux but all the unix platforms are switching to more event driven models. No one complained on here when Solaris switched to SMF. No one complained that Ubuntu abandoned init for Upstart. People thought Apple leaving init for Startup was cool and begged for linux to leave init too! ... no really??'

No one complained about Fedora not using init. Then all of the sudden one comment set off a chain and it is INIT BEST EVER!!! Psychology did the rest and it is weird to say the least.

Re: Yes

[Billly Gates]

With startupd, launchd, SMF, and SystemD you set the triggers for each event. No long scripts loaded with nested if/else statements galore or expensive proprietary software to mask this lack of functionality in init.

Okay, I'm always willing to learn, so please, give me a lesson. I set up a trigger for the event and the trigger does not fire. What do I do? In case of the "long script with nested if/else statements galore" I'm pretty sure what do I do there - put in some echo statements to verify the execution path. What do I do with systemd?

An event will log it. No need for echo paths.

A very basic schematic on how it works is here.

Re:Yes

[Anonymous Coward]

track down what's going on and fix it.

Which is impossible to do with systemd since it swallows stdout, stderr, and most other start-up log messages. It makes it impossible to troubleshoot. Standard System V init scripts will show you the error output. systemd destroys that information and gives you no way to see it. Yes, destroying information makes the system appear simpler, but when you need that output, it is asinine to just destroy it like systemd does. Tracking down problems with systemd is very often impossible.

Re:Yes

[dpidcoe]

Sounds like the last time you installed Linux was 14 years ago.

Last time I installed linux was 6 months ago. I ran debian off the ISOs, connecting it to the internet during the instal would have been nice except that the network drivers were one of the things I was having problems with.

Re: Yes

[Kabukiwookie]

I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7

Right here with you!

Re: Yes

[Kabukiwookie]

I saw this changeover first in Solaris

Indeed, and see how Solaris is doing now. Those changes were the main reason a lot of shops replaced their Solaris kit with Linux in the first place

Re: Yes

[Kabukiwookie]

Those bits of software were completely modular and could be fixed separately from anything else running on the host. The point was that with Systemd you don't have that luxury, you have to replace the whole kitchen sink.

Re: Yes

[postbigbang]

Oh, sure. Are you sure it wasn't the fact that all of the Sun engineers exited for greener pastures, and Oracle left the openness in a ditch? Took all of Schwartz's pile of open goodies and stepped on them like they were cockroaches?

C'mon. Say something real.

Re:Yes

[DamnOregonian]

Well, that's not really true. I mean, look at what I'm asking for WRT libvirt. There's a facility already present in the system for doing what they're doing, and they simply ignore it, with consequences for users. And what's more, the facility works really well for what they're doing with it, which they're doing very poorly.

What you mean, is that there are already many facilities present in many systems for doing what they're doing. We don't all use debian (/etc/interfaces? holy crap.) w/o NetworkManager anymore. You blame libvirt for trying to handle the actual problem in a fashion that causes the least amount of headache for the majority of users across disparate systems. That's silly.

Re:Yes

[Anonymous Coward]

Linux installs any drivers needed during installation.

That's an overly broad sweeping generalization. "Linux" is just a kernel, there are literally hundreds of Linux distributions and many have their own installers and processes. Maybe whatever one of those hundreds of distributions you chose installed the required drivers for your hardware but that doesn't mean every one does it for every kind of hardware, for example I have had issues with Wacom digitizers, touchscreens, wifi cards (even built in ones like on my 2009 imac having all sorts of problems getting wpa_supplicant working), sound cards and very often it only installs the barely functional generic driver (like Windows does), like the VESA driver for graphics cards or the various sound drivers for all the different sound subsystems leaving you needing to go to the site to find an appropriate driver.

Re:Yes

[Ol Olsoc]

Linux installs any drivers needed during installation.

That's an overly broad sweeping generalization.\

That's because I didn't want to write a book. Yes, it's true that there are some really minimal distros that might harken back to 1999, and that you have to roll everything on your own, just like earlier days. And as for problems, have you researched which distort is applicable to your needs? When I wanted a replacement OS for my wife's Asus touch screen laptop, I did diligence, and Cinnamon Mint came up as the winner. I have had exactly one problem in that Dockey doesn't like to wake form sleep mode. But that's not an OS but a Docky problem. I could just be really lucky, but I haven't had an install problem in a long, long time.

If I hadn't done that due diligence, I suspect I would have had a lot to do to get it to work.

And since we are here, one of the biggest pluses of Linux is one of it's complications

At http://distrowatch.com/ They have at present 286 different distros they are keeping track of. And there are more out there. I'm burning a dvd .iso of Shackbox premium as I write this. But selecting the right version of Linux has become as complex as selecting a program.

Re: Yes

[Anonymous Coward]

7. It swallows stderr and log messages. This makes it impossible to troubleshoot problems with starting daemons.

I love how simple the start-up config files are. Example:

# /etc/systemd/system/zeus.service
[Unit]
Description=Zeus Server
After=network.target

[Service]
User=zeus
Group=zeus
ExecStart=/home/zeus/start.sh

[Install]
WantedBy=multi-user.target

But the fact that an error message to stderr is swallowed and impossible to find by systemd means that it is impossible to troubleshoot. Also, the server logs to standard syslog, but only messages at logging level Warning or less are logged in the journal, but more important messages are not saved. That is ass backwards. No logging system should ever throw away Emergency, Alert, Critical, or Error level log messages. That shows a very basic lack of understanding by the systemd developers. They're doing a "level ."

Re: Yes

[Anonymous Coward]

ohh c'mon. What momentum are you talking about? Linux isn't anywhere near ready because of crap like this. Systemd fits perfectly with getting Linux pre-installed on your granny's new computer. I say throw out junk from the kernel and let systemd handle that. It makes the kernel cleaner, leaner, and meaner; system management tasks can then be perfected in a seperate project. Basically I see systemd (the idea, anyway) as a perfect companion to Linux proper.

Unix tools need to go. We need to rethink all of this. You do want momentum, don't you? Systemd is a step in the right direction. Another good direction would be to get rid of FSH.

Re: Yes

[Anonymous Coward]

I'm not sure what point you think you are making. If we're finding holes in software like Bash and OpenSSL then SystemD is clearly going to have issues as well while having network access and root. It's much larger making it more likely to have those issues and it was forced down in RHEL 7 without testing. Like he said it will be decades before SystemD becomes a solid program yet we're expected to use it in enterprise?

Re: Yes

[Anonymous Coward]

hear hear

Re: Yes

[armanox]

I was complaining in the Fedora community when it first debuted (which was somewhere around Fedora 14 or 15). I also complained about GRUB 2, posted HOWTOs on keeping GRUB 1, and got laughed at for the thought that I wouldn't want systemd or GRUB2 (or GNOME 3, or a desktop that didn't always 'need' 3D accel, etc).

Last time I checked, SMF and upstart just replace init (Launchd is a bit larger in scope, and I don't think I have heard people complaining about it (now I need to see it changes how to use cron jobs on OS X...)) Nor are they written by someone who is fairly disliked within their own communities. Also, Apple and Sun have a lot more at stake for releasing something that works then Fedora does. Fedora has had plenty of releases that were pure crap over the years - they just shrug it off and move to the next one. Personally, I have fallen in love with the some of the old UNIX systems (my home servers are running IRIX at this point) and how simple things used to be to manage.

Re:Yes

[Lodragandraoidh]

Excellent points. I think all of the angst that is coming out of the systemd debacle is really the result of a long time defacto state where most distros - because of their common POSIX-ish modular implementations could work with just about any software out there - so even if your distro didn't support something (like a very small X11 compliant text based window manager - which I managed to shoehorn onto an old AST 486 laptop with 20 MB harddrive and 1 Mb ram running a stripped down version of Slackware 10) it could be made to work on the distro you were most happy with. People had their cake and because of interoperability could generally eat it too relatively easily - with some exceptions (e.g. device drivers).

Systemd, Dbus, et al created a situation where the choices that were once 'AND' choices, now became 'OR' choices - at first for the developers of key system components - but with enough momentum this trickled down to the end user. Developers who were once maintainers of alternative versions of various key applications are finding that the code they once depended on for porting no longer supports the old interfaces, and so they are faced with a hard choice - either spend their time working on the most widely distributed version of their software (for systemd based distros - abandoning general support across BSD and non-systemd Linuxes), or focus their energy on back-porting the code in external interfaces to work across non-systemd distros. A Hobson's choice for both developers and users who value interoperability/portability of their systems.

Frankly, I am surprised that Linux, BSD, and the shared GNU POSIX tool set was able to maintain this benign portability for as long as it has across such an eclectic assortment of distributions. I would argue that this gave Linux time to incubate, and grow up in a stable environment. With the systemd gauntlet thrown down it is now time for other alternatives to be put out there - the more the merrier! Maybe one new distro would be enough to address the complaints. Maybe 10 or a hundred. Who knows? The more of these there are, the more likely someone complaining about lack of options today will find something they like tomorrow without having to try to move a boulder up hill with a straw.

Re: Yes

[arth1]

Along the way, your RHEL6 will be fine, and it will grow cold, like they all do, as will your skills. I don't particularly care for systemd, but I learned it in a couple of hours, and yeah, it works.

The problems with systemd is when it doesn't work. You risk a system that's inoperable - you can't boot to single user mode and you can't even check logs from a different system, because they're not humanly readable and not committed. And you can't single-step through the tasks one by one and see what happens.

Never mind that it's also MSDOS .ini file based, which is about the most automation-unfriendly system there is. What a key is for depends on which section it is in, and there's no inheritance whatsoever. It's a file format that should have expired in the 90s, and thankfully never caught on in the Unix world. Because of that truly WTF choice, modifying settings through scripts becomes an error-prone headache.
And at the first error - boom, you have a system that can't be brought up or troubleshot. Better keep a bare metal backup handy.

What this sysadmin cares about isn't how fast a system boots[*], but that it's stable, consistent, has as few dependencies as possible, is debuggable when the shit hits the fan, and that no one failing part can bring down the whole house.

[*]: When an IBM system spends ten minutes in pre-boot running self-checks and enumerating all the SCSI disks, I couldn't care less whether it cuts the boot that follows down from a minute to half a minute.

Re: Yes

[postbigbang]

Slow down. We disagree on all your points.

First, use grub2 to set alternate boots. Not tough.
Second, use rsyslog or install syslog-ng to push out the logs to a log server so you can see why it goes down.
Third, BIOS is still the longest part of my boots; not sure what you're using.
Fourth, the file format you loathe is easy pushed back to half-ASCII if you simply must; you can ask chron to push it for you regularly, if you're really anal.

As far as stability is concerned, mine are just fine, thanks, doing their jobs nicely. This .ini problem you speak of is no different from the madness of other conf files that permeate the landscape, and prior versions are worse. I can squirt plentiful relevant system calls to one freaking spot, not eleven, and not nineteen different goofball apps twisting relevant settings through backdoors going back to Minix. I call that progress. It enforces a little discipline.

Re:Yes

[hitmark]

That redundancy was perhaps Linux's greatest strength, as once size fits none.

Re:Yes

[hitmark]

If by hide you mean replace everything and the kitchen sink with their own implementation, complete with doing the same mistakes that the older alternatives had hammered out of them a decade ago, then yes.

Their DNS "client" can be cache poisoned, their DHCP "client" ignore security checks for the sake of speed, and this is a project that is being pushed heavily towards cloud services.

Re: Yes

[hitmark]

I dunno, most, if not all, balk at functioning without pid1-systemd being there.

I think when people are looking for separation they are looking at GNU coreutils as a reference.

Re: Yes

[hitmark]

Bingo, if bash is a issue there is quite a few replacements floating around. This because the interfaces etc have been solid for decades.

Similarly, the Linux kernel will keep userspace facing interfaces in place even if new ones have been introduced to replace them. This to allow people to update at their own pace.

Systemd claims to be a collection of tools, but the interfaces between those tools have no stability guarantee. Thus they are more like the interfaces internal to the Linux kernel and may as well be considered a solid blob.

Re: Yes

[hitmark]

One can already see an example of that with how Arch went systemd.

Re: Yes

[hitmark]

For me systemd was a non-issue until i ran into the chain of replacement for consolekit (a beast all its own, but at least unix modular) and found that i would have to rip out the current init and replace it with systemd, because logind insisted on it, and logind was replacing consolekit across the board.

Re: Yes

[arfonrg]

"We aren't looking for something that hasn't really changed much since 1997." AND THAT proves you have no idea what you're talking about.

Re: Yes

[rastos1]

An event will log it. No need for echo paths

Can you elaborate, please? Let's say the network interface comes up and I (as a human) expect that my home-made network daemon starts up. But it does not. And by "it does not start up" I do not mean that "the daemon process is exec()-ed but exits immediately for some reason". I mean "the exec() call does not happen at all". Perhaps some stupid reason I failed to properly explain to systemd that it should be started. How does systemd know that a human expected the daemon to start?

Re: Yes

[thule]

I've been working a new new project where we are using Chef 12 and RHEL7. So far no issues. I *like* the systemd service files. We whipped up custom files in no time. SUPER simple. The /var/log/messages file is still there. No difference. My only beef is that Chef 12 server only runs on RHEL6 right now. Chef says that RHEL7 support is coming and it works in the 12.0.3 release. I haven't tried it yet.

Am I the only person that does not have trouble with systemd? I've been using RH since 3.0.3 days. Before that I was running Slackware. Maybe I am a rare sysadmin that doesn't mind some change.

Re:Yes

[gweihir]

That statement is inconsistent with the log-data being there on manual or systemd free start. Or put briefly: What you say is not consistent with the observable facts.

Re:Yes

[gweihir]

A security disaster indeed. And I am more and more convinced that is by intent. Apparently Linux was to hard a target, so they are now softening it form the inside.

Re:Yes

[bemymonkey]

Are you me? Your experience with Linux sounds like mine back in the day.

For the last few years, I've only run Linux in VMs (on Windows hosts), and it runs pretty much perfectly and does everything I ask it to. Standard "hardware", I guess...

Re: Yes

[Eunuchswear]

But the fact that an error message to stderr is swallowed and impossible to find by systemd means that it is impossible to troubleshoot.

Sorry? stdout and stderr are logged to the journal. Use journalctl to find them.

Also, the server logs to standard syslog, but only messages at logging level Warning or less are logged in the journal, but more important messages are not saved.

Huh? What on earth makes you think this?

root@celtic:~# logger -p local6.emerg "This is a test"
 
Broadcast message from systemd-journald@celtic (Thu 2015-02-12 11:56:33 CET):
 
john[20291]: This is a test
 
Message from syslogd@celtic at Feb 12 11:56:33 ...
  john: This is a test
root@celtic:~# journalctl PRIORITY=0
-- Logs begin at Tue 2015-02-10 18:03:58 CET, end at Thu 2015-02-12 11:56:33 CET
Feb 12 11:56:33 celtic john[20291]: This is a test

Re: Yes

[Eunuchswear]

We want Debian without systemd.

Then use Debian without systemd.

How many times do you have to be told that systemd is optional?

Re:Yes

[Eunuchswear]

That's trivial to do with fail2ban on Red Hat/CentOS 7 with systemd, because systemd throws away all of the messages that fail2ban logs. My firewall is under constant attacks, but systemd deletes all of the logged messages from fail2ban:

What's the bug report number? This is not how systemd is supposed to be working.

I see bugs where fail2ban doesn't work with systemd on RedHat because they don't run syslogd and fail2ban reads the syslogd logs (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1047436)

But I can't find any bugs about systemd "throwing away" messages.

Re:Yes

[Anonymous Coward]

Debian doesn't include firmware for some network cards. This is particularly ridiculous for HP Servers. I still don't understand why someone sells "server" hardware that isn't supported out-of-the-box on Debian. That isn't server-level quality. HP certainly must have the clout to make Broadcom release (at least a basic version of) firmware with terms that allow inclusion in main Debian.

Re:Yes

[ookaze]

So... the middle. This thread referenced "/etc/network/interfaces". That does NOT exist on all distributes (ex. redhat based systems don't have this). Personally, I like /etc/network/interfaces, but it's a good example of fragmentation of "standard" ways/interfaces to configure the kernel networking subsystem. Is it bad that debian and redhat both do it different? IMO, the "becoming too complex" question would imply that this is NOT bad, since this has been this way FOR A LONG LONG LONG TIME, and I'd agree that this amount of differentiation is ok and even good, but this could easily be argued is and firmly into the grey area.

This /etc/network/interfaces which is distro specific that you talk about, is exactly one of the configuration for which a replacement is proposed by the systemd you talk about below:

The part that I have very large concerns with is what is currently happening with the low-level just above kernel... specifically, systemd and its related parts. Networking is an example here, as one of its goals is to provide one unified/common way to configure the network.... but doesn't that already exist!?!?

Yes, in systemd it exists, nowhere else for now.

It's called the kernel!

No it's not, you don't understand what you're talking about. The kernel doesn't configure your network interface for you, it just manages the device.

On the other hand, maybe it will prove to be a useful shim? The fact that a single framework is going in above the kernel, which some direct ties to the kernel, and is casting a very wide net in terms of things it is, or can, control (logging, network, dhcp, login, init, sessions, mounts, consoles/vte, timedated/ntp, devices/udevd)... we'd better hope and pray it's designed well cause everything and the kitchen sink will soon have direct dependencies on the interfaces it's implementing.

It sure enough removes complexity from the OS if you use every control systemd allows.

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Re: Yes

[ookaze]

Systemd has been the most divisive force in the Linux community lately, and perhaps ever.

As it has been adopted by most distro, you're obviously wrong with your rhetoric. It has been one of the most cohesive force actually.

It has been foisted upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just so they can get systems that boot properly.

systemd doesn't have the power to force anyone to do anything, people that went to BSD did this on their own will.
Debian community has not been torn by systemd but by trolls actually, systemd was the point used by the trolls.
And usually, victims are unwilling to be victims, or so I heard.

Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.

I won't take your word for it on this, only time will tell but I'm pretty sure what you say is just plain hyperbole.
Competent sysadmins actually have no problem with systemd, on the contrary.

Re: Yes

[Anonymous Coward]

People who institute changes just for the sake of change probably shouldn't be in the profession.

Re:Yes

[anyGould]

I use this method:

Install Linux from iso with peripherals attached. Have ethernet connectivity

Linux installs any drivers needed during installation.

Unless it does what it did to me last weekend, where the step in-between is: Linux blacklists *all* the network-drivers, so on reboot you have a machine that says you don't have a network card. Proceed to spend several hours walking between computers while figuring out that it was blacklisted, and how to fix the blacklist and manually reset the drivers.

I'm all for making things simpler, but I do miss the 90s-era installs where you were asked what components you wanted. (And I'm fine if there's a "shut-up and give me the usual" button - I just want the *ability* to pick and choose, y'know?)

Re: Yes

[Anonymous Coward]

what complexities do you speak of? admins have been adminning servers withour sysd for a long time. its not needed or most times even wanted. its forced on its users. systemd solves nothing while trying to solve everything.

Re: Yes

[Anonymous Coward]

Pottering? is that you?

Re: Yes

[Anonymous Coward]

so basically your answer to fixing all this broken systemd shit is to add more broken shit? bravo. you must be a firecracker where you work. i bet your in high demand.

Re: Yes

[Anonymous Coward]

if your running RHEL 6 then systemd isnt installed by default. how are you running RHEL 7 with Chef 12
if it doesnt work on 7? your whole post sounds like a lie.

Re: Yes

[postbigbang]

Not broken. It's an improvement. Devices needed organization. It's not a perfect solution. Nothing is.

Re: Yes

[thule]

To clarify... All the boxes in the project are RHEL7 with the exception of the Chef 12 server. The Chef 12 Server currently runs RHEL6. Chef Server 12.0.3 supports RHEL7, but I have yet to test it. All RHEL7 boxes run chef-client 12 without issues.

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Agreed!

Re:Yes

[buchanmilne]

Example, libvirt doesn't use /etc/network/interfaces, this is stupid and complicates firewalling scripts and so on.

/etc/network/interfaces is Debian-specific. Libvirt (optionally) supports the netcf library, which is a cross-platform network configuration library that claims to support Debian. Is libvirt in Debian compiled against netcf?

And it insists on running its own copies of dnsmasq, rather than just dropping some files in /etc/dnsmasq.d. What a PITA. Use the goddamned operating system, that's what it's there for.

Have you filed a bug?

Re: Yes

[buchanmilne]

Systemd has been the most divisive force in the Linux community lately, and perhaps ever.

s/Linux/Debian/

Many other distros switched to systemd with no antics, commotion, and very few problems.

Maybe the problem here is Debian, not systemd?

Re: Yes

[buchanmilne]

I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7

Did you even try it?

What bugs did you encounter that were specifically due to systemd? Did you file any?

We are preparing to start rolling out RHEL7 (still have some internal packages to rebuild), and systemd didn't really feature as a problem at all.

Re: Yes

[buchanmilne]

My systemd experience this morning was a total lockout and lockup while booting forcing a full re-install of my Red Hat Linux.

If it *really* was that bad, surely you could have booted into a rescue environment?

Re: Yes

[Anonymous Coward]

That's actually hilarious: "Numerous death threats" that Poettering mentioned in his blog post turned out to be just a joke on IRC channel about hiring a hitman for him on Silk Road, written as a response to someone frustration with some systemd bug by a guy particularly known for his trollish sense of humor on that channel. No wonder Poettering can't feel safe at night!

Re:Yes

[Anonymous Coward]

> systemd is the only effort to unify them that seems to have traction.

Which is sad because it makes it impossible to troubleshoot most start-up issues. I have a very complicated Apache setup, and the stderr output from Apache was ignored by systemd and not logged in the journal. Also, the nonzero exit status was ignored. "systemctl start" returned a zero! I was able to troubleshoot by running Apache directly at the command line, but for someone new to Linux, it would have been impossible for them to fix the problem.

Re: Yes

[arth1]

Did you even try it?

Outside production, yes.
In production, no way. The amount of work required just to try was determined to be immense, and there were incompatibilities from the start that seem prohibitive - like systemd taking over cgroups, while we already use cgroups for our own purposes, and hal not working because of incompatibilities with the "improved" dbus, and we rely on user-triggered external hardware detection, not system-triggered.

I currently run a test system with EL7 that does not need cgroups and hal, and when it works, it is not much of a problem - but that can be said of any software, regardless of quality. It's when it doesn't work, and a boot crashes that systemd leaves you stranded. If you haven't provoked boot problems to see what happens, and how to recover, you have not truly tried EL7.

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Agreed!

Agreed!

Re:Yes

[Anonymous Coward]

Agreed!

Re:Yes

[Anonymous Coward]

> If your distro or upstream...

No. MongoDB outputs the lock file error mentioned above to stderr and exits with a nonzero exit status. Output to stderr should be in the journal no matter what, and a nonzero exit status should be recognized by systemd no matter what. systemctl is returning a 0 and not outputting an error. That is broken by design. The stderr output is not in the journal. Again, that is broken in design. Trying to distract from fundamental systemd design problems is dishonest of you. This is not, and it cannot be, a distro or package problem. It is a systemd problem.

Re: Yes

[Anonymous Coward]

What on earth makes you think this?

Not the GP, but anyone that looks at the systemd journal would think this:

# journalctl PRIORITY=0 | wc
0
# journalctl PRIORITY=1 | wc
0
# journalctl PRIORITY=2 | wc
0
# journalctl PRIORITY=3 | wc
0
# journalctl PRIORITY=4 |wc
    83796 1965179 19388617

That's for a heavily used server that's been up since Dec 15. It is our DHCP server, and dhcpd logs duplicate client errors and OpenVPN logs disconnects to level 3(error). We have thousands of those per day. It is also the edge SSH server, and SSH logs socket disconnects to level 2(critical), but there are none in the journal. Before upgrading to systemd, we'd have thousands of those per day. PAM logs login failures to level 1(alert). We used to have over ten thousand of those messages logged per day, but systemd logs none of them now. The lack of logging of login attempts is a pretty serious security problem. It also breaks fail2ban.

Re: Yes

[Anonymous Coward]

It's been my experience that restoring from a backup image is usually faster than researching the problem and digging through all the innards.

Re: Yes

[Anonymous Coward]

> root@celtic:~# logger -p local6.emerg "This is a test"

That's a very nice command. Thanks for that. Since it's part of util-linux, it is available pretty much everywhere so that makes it very useful.

As far as why people think systemd doesn't log, it's because it doesn't at least on any of the servers where I've looked. I don't know why people question that. On my home server that I setup about a month ago:

journalctl -p 0..3 | wc
            1 15 85

journalctl -p 4..7 | wc
  233701 3995872 41403908

The one line for levels 0 through 3 inclusive was the logging start message:

-- Logs begin at Mon 2015-02-02 18:42:40 UTC, end at Thu 2015-02-12 23:39:07 UTC. --

systemd really needs to get over their syslog is obsolete mantra. We need syslog.

Re:Yes

[Anonymous Coward]

Debian is ancient dogshit.

Use a real distro like opensuse for a seamless, easy experience.

Re:Yes

[Anonymous Coward]

A proper Linux distro will support more hardware than Window 8,7,vista and XP combined.

Re: Yes

[Anonymous Coward]

Solaris was dying long before the Prince of Darkness got a hold of it.

Re: Yes

[Anonymous Coward]

A dozen executables that all depend on each other is no different than a single executable.

Damn, you Poettering ass lickers are as stupid as MS shills.

Re:Yes

[Ol Olsoc]

I use this method:

Install Linux from iso with peripherals attached. Have ethernet connectivity

Linux installs any drivers needed during installation.

Unless it does what it did to me last weekend, where the step in-between is: Linux blacklists *all* the network-drivers, so on reboot you have a machine that says you don't have a network card. Proceed to spend several hours

What distro, what machine, and did you do a live CD/DVD boot first?

Bet really, being repository based, a working network card is needed for the very install. itself.

Re: Yes

[Anonymous Coward]

Are you advocating more moving parts to get around the crap that is systemd?

You must be Poettering himself because only he is that stupid.

Re: Yes

[Anonymous Coward]

I am one of those users. Been using Fedora since Fedora 5 just about, maybe earlier.

Anyways, now I'm looking into new hardware to stage builds of OpenBSD and FreeBSD. Once I work out the kinks, I'll be moving my main workstation off of Fedora Forever.. Kiss my ass systemD and Poettering.

Re:Yes

[anyGould]

What distro, what machine, and did you do a live CD/DVD boot first?

Bet really, being repository based, a working network card is needed for the very install. itself.

Was the current version of Ubuntu, an old Dell, and I booted using a USB key, network worked there, installed from that, no network.

Google seems to say it's a known issue of some sort. Didn't need to install anything, just edit some obscure file and type the usual arcane words into a terminal.

But the take-away is that requiring a network connection doesn't help if your system disables all the network connections. (And worse, the GUI was no help in correcting the problem.)

Re: Yes

[Anonymous Coward]

Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do

Microsoft and SCO tried to get a judge to declare Linux illegal, so that may be a bit of an exaggeration.

Re: Yes

[thegarbz]

Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should give the guy a medal.

Upsetting a few nerds and admins and making them chose a different OS, or more likely just a different distribution is hardly "killing momentum". Ultimately what he is doing and what he has always done is to try and combine everything a system should need under one umbrella to make it simple for the end users. Admins, nerds and tinkerers hate it, but this is the driving force that is slowly bringing GNU/Linux to more desktop users and people who were previously not considered normal users of it.

Just like pulse audio. Everyone hated it and it was full of bugs. But Linux audio was basically unusable for any kind of generic desktop operation beforehand (seriously it took Linux years to be able to recognize a headset was plugged in and automatically switch audio to it for a subset of applications).

My prediction is less dire:
1. Near term people will complain more and more. Distributions will not care.
2. A few forks will happen. People will realise that Linux is still the same as it always was and if they don't want to use systemd they just pick the appropriate distro (this has already started happening).
3. Systemd will iron out bugs and people will slowly submit the RHEL and return to them.
4. Interfaces will be written that make systemd do what it currently doesn't, init do what systemd already does, and we will all be right back where we started.
5. Pottering will attempt to reprogram the entire internet removing pesky things like http from browser bars, and TLDs .... wait a minute!

Re:Yes

[Ol Olsoc]

Was the current version of Ubuntu, an old Dell, and I booted using a USB key, network worked there, installed from that, no network.

Google seems to say it's a known issue of some sort. Didn't need to install anything, just edit some obscure file and type the usual arcane words into a terminal.

But the take-away is that requiring a network connection doesn't help if your system disables all the network connections. (And worse, the GUI was no help in correcting the problem.)

I must be the luckiest person on earth. I installed Lubuntu on an eepc netbook, no problems at all, I installed Ubuntu on a Chromebook, and Ubuntu on an old Toshiba Laptop and On a mac (Shackbox) In the last couple months. I guess we can write it off to shitty software that doesn't work for anyone else but me! Lots of Mint installs, and plenty Ubuntu before that. Sorry it isn't the right software for you. Windows 10 is out soon, it should work pretty good.

Re: Yes

[strikethree]

Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies.

Speaking of outright lies... where is your proof that only a minority of people are unhappy about SystemD?

Let's examine our current environment: Slashdot.

Here there are more people who are deeply against SystemD than there are for SystemD. If you look at the arguments against, there are numerous well-reasoned arguments that nobody from the SystemD has even begun to address. If you look at the arguments for, they do not seem terribly convincing, such as "this is a better way" or "startup is faster in the best case".

I mean really, even if the damned thing did what it claims to do, the specific implementation is clearly lacking. So I have to ask, why exactly are you so gung-ho for SystemD? Surely you should be gung-ho for a solution, not a specific method. No?

Debian switched because they were losing market share on larger systems that the current init system only handles under extreme protest.

What are you talking about? losing market share? larger systems? Which systems? How was market share measured? Show me where the Debian project claims this. You sound like an MBA.

Re: Yes

[gmack]

Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies.

Speaking of outright lies... where is your proof that only a minority of people are unhappy about SystemD?

You do realize RedHat (the distro running systemd for the longest) has reported their subscriptions going up for the last several quarters? Meanwhile we have people who are making a lot of noise about leaving but never actually do. (Distrowatch is showing interest in *BSD as dropping) We have a Debian fork claiming to be a bunch of "veteran admins" without naming any of them and a mailing list of people who like to argue more than they like actually doing anything. So where are all of these upset people going?

Let's examine our current environment: Slashdot.

Here there are more people who are deeply against SystemD than there are for SystemD. If you look at the arguments against, there are numerous well-reasoned arguments that nobody from the SystemD has even begun to address.

Well reasoned like the post I was replying to? It managed a "Score 5: Informative" despite not having any arguments that were actually true.

The Slashdot echo chamber is what annoys me the most about all of this. I see posts like "SystemD is Monolithic" (it isn't) "SystemD includes an NTP and DHCP server in PID 1(They are optional and don't run as PID 1). Or my all time favorite: "SystemD" is designed for desktops and makes server administration harder" When the reality is that SystemD was designed with some of the more complicated server setups in mind and the speed improvement on the desktop was mostly an accidental byproduct. The only actual valid complaint I have seen so far is about the binary logs but they are easy to bypass and even with journald doing mostly nothing, the whole thing uses less RAM and disk space than the init system it is replacing.

If you look at the arguments for, they do not seem terribly convincing, such as "this is a better way" or "startup is faster in the best case".

Naturally, this is plumbing and boring by nature. "Works best for this case" is actually a good reason for doing it In the meantime, the old system was a bug ridden mess. I mean really, I had until recently some servers that need a partial filesystem mount followed the network followed by GlusterFS followed by Apache. Care to guess how well that works in a default Debian stable install?

I mean really, even if the damned thing did what it claims to do, the specific implementation is clearly lacking. So I have to ask, why exactly are you so gung-ho for SystemD? Surely you should be gung-ho for a solution, not a specific method. No?

I am not so much pro SystemD as much as I am anti FUD. I am annoyed that I let the slashdot crowd actually made me worry about my future as a Linux admin until I researched for myself what the facts were .In the end, I wouldn't be shocked if SystemD ended up being a good proof of concept and replaced with something else. In the meantime, it solves more problems than it creates and manages to be better than the alternatives.

Debian switched because they were losing market share on larger systems that the current init system only handles under extreme protest.

What are you talking about? losing market share? larger systems? Which systems? How was market share measured? Show me where the Debian project claims this. You sound like an MBA.

It's right in their "Why SystemD" document. " But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling."

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Re: Yes

[Eunuchswear]

As far as why people think systemd doesn't log, it's because it doesn't at least on any of the servers where I've looked. I don't know why people question that.

Well, I question it because it's not true on any machine I'm running systemd on. For example on the laptop I'm typing this message on:

# journalctl -p 0..3 | wc -l
149

What distros are you running that don't log error messages? Did you report it as a bug?

Re: Yes

[Eunuchswear]

The lack of logging of login attempts is a pretty serious security problem.

It sure is.

Where's the bug report?

Re:Yes

[morgauxo]

" old hardware support is technical debt if it holds you back"

That would be where I was asking for an example. GP claimed that scripts are overly complicated with old hardware support. I am calling him/her out. What scripts? I'm not used to seeing specific hardware support in scripts.

Of course.. if he/she did provide examples... So what? Why should LINUX get rid of hardware support because some distro coded their scripts poorly? There are plenty of ways to modularize things so that one doesn't have to sift through all that stuff to configure the hardware that they do have. If some distro isn't good at that then if it's open you can fix it. If not.. well... either way you can chose a better distro.

What is an example of how old hardware support is burdening you in any way?

Re: Yes

[morgauxo]

Are these maintainers then going to maintain a BSD port? How does that work? Is someone going to port Systemd to BSD? And if so then what did you gain by switching?

Re: Yes

[morgauxo]

Well.. your example hardly forces you onto BSD then does it.. seeing as you listed BSD as something that is NOT supported.

As for Symantec.. if as many of Symantec's customers were bitching to Symantec about them only supporting distros that use Systemd and if they were threatining to put their money where their mouths are and walk away... Symantec would be supporting something else.

Seeing how many desktop machines I have seen totally trashed by Symantec software I find it interesting that the 'big Enterprise' user should care.

I don't know much about various certifications including FIPS but first off.. if users were demanding a non-Systemd FIPS compliant distro and ready to spend their money on it wouldn't it exist? Even if the Slackware and Gentoo people were totally uninterested wouldn't someone else see an opportunity to make some money and go for it?

Second.. from the outside it's amusing how much credence 'Enterprise' types put into those fancy acronyms. I realize that you need some paper to CYA but you do realize that it's all the same GNU running on a Linux kernel right? Wether or not your environment is secure has a lot more to do with wether or not you spend the time to properly secure it than what name is on the boot logo.

It seems like Enterprise types tend to make the shittiest decisions when it comes to which distros to invest in anyway. Has RedHat done anything positive since they adopted Yum? And that only after years of being in the dark ages as compared to Debian's Apt?

Why are Enterpirse users so stuck on distros with periodic releases? There is nothing that warms my heart more than logging into my bank account only to find my bank's computers are down for maintenance. In 2015, really? How many decades have distros with rolling releases been available?

Also.. listen to Lennart Poettering talk some time about the various controvercial changes he has made. He defends everything by explaining how it was done to meet X, y and Z that RedHat ENTERPRISE Linux customers were demanding.

If (and I'm not even sold on that) Systemd is half as bad as people say then if anything it's Enterprise users that we can thank for it. Maybe our "little playgrounds" as you so condescendingly refer to them would be better off without you anyway.

Re: Yes

[Anonymous Coward]

stderr is an out of date concept. systems is correct to ignore those messages. You systemd.bashers are fucking morons. I hope you get cancer.

Re: Yes

[morgauxo]

"Slackware is 1990s-era relic."

I wouldn't know, I don't use it. I find it hard to believe that it has continued this long if that is true though.

"We're looking to use a modern Linux distro, like Debian from just before the switch to systemd."

Well.. there's Devuan which was specifically a response to systemd. Of course it is totally unproven that they will stick it out though. But.. one thing about Debian.. it has always had countless sub-distros built off of it. This is nothing new. I'm sure some of them will not adopt Systemd. You will have your pick!

"I don't want to wait a week for Gentoo on my laptop to finish compiling Xfce."

Hmmm.. where to start...

First off.. save your straw men for Burning Man. The only way it's going to take a week to compile Xfce is if you bought that laptop back in the 90s. (probably at the same time you were last trying Slackware) Furthermore.. there is no reason you should be waiting for anything to compile. That's what screen or tmux are for. You can even throw nice levels into the mix to lower the priority on the compile task if you really need all that processor available to you as you work in the previous version of Xfce.

"We want Debian without systemd"

So?

First off, back to my whole baby and bathwater point BSD isn't Debian either. How does switching to BSDs get you back to old Debian?

Second, no-one owes you old Debian. Did you pay the developers for it? No. But... you are free to make it yourself. Or.. just sit back and relax because with soooo many people bitching... I'm pretty sure someone WILL make 'old Debian' for you. It might have a different name is all.

Re: Yes

[Anonymous Coward]

Outside of slashdot started last July I have yet to meet a SystemD hater.

It seems just here. But now that is fashionable we all ahte it because everyone else hates it.

Init is going away. Not just linux but all the unix platforms are switching to more event driven models. No one complained on here when Solaris switched to SMF. No one complained that Ubuntu abandoned init for Upstart. People thought Apple leaving init for Startup was cool and begged for linux to leave init too! ... no really??'

No one complained about Fedora not using init. Then all of the sudden one comment set off a chain and it is INIT BEST EVER!!! Psychology did the rest and it is weird to say the least.

Here's the deal. Sysadmins have jobs. We do work. We trust(ed) that Fedora (the upstream for RHEL) and similar distributions were doing sane things. Replacing upstart with systemd? Eh, sure, why not. Init was replaced with upstart and it was basically transparent. Then we went back to our jobs.

Suddenly, one day you wake up and realize that every sysadmin on the fedora-devel mailing list had been replaced with a developer three years ago and nobody noticed until now.

SystemD should have been knifed in the back as soon as it tried to be 15 tools in one. It should have been further nuked as soon as its creators took action to force adoption by tying other projects to it. This was called "Embrace and Extend" when Microsoft did it and it's no more moral now simply because it's happening in *nix land.

Re:Yes

[anyGould]

Not saying it was the wrong software (and the second laptop I tried worked fine out of the box).

My point was intended towards the tendency in the new distros (at least in my experience) to insulate the user from details, even when they're looking for them. For instance, the Network Manager (which cheerfully pre-install found both wired and wireless networks), after install refused to accept that a network card might exist, and didn't expose any method to see that a blacklist existed, much less change it. And installing packages wouldn't help because the package is already there - the install disabled it and didn't tell me.

My daughter is actually enjoying her new Linux box (now that it has a network and runs Minecraft) a great deal - my issue was that the installation has moved a bit too far from the old "OK, I hope the user knows what he's doing because the OS ain't gonna help" to the new "OK, I hope the OS knows what it's doing because we're not going to tell the user anything" model.

Re: Yes

[thule]

Update.... Chef 12.0.3 up and running on RHEL7!

Re: Yes

[strikethree]

It's right in their "Why SystemD" document.

I am flabbergasted. The reason Debian does not get corporate contracts is because they do not have a corporate program to provide assurances to customers like Redhat does. It has nothing to do with SystemD.

Redhat is about to lose a largish DoD contract because of SystemD. Debian has removed themselves as an option with this crap. Will my decision hurt Redhat? Individually, no. I will not be surprised if lots of other people responsible for choosing technologies refuse this crap as well. Will it hurt Debian? I was already not using them but now they have excluded themselves. They have limited their own potential growth.

I have quite a few Linux servers under my control. SystemD buys me nothing. SystemD has not caused me any problems in my professional life (yet) but it has caused me numerous problems in my personal life.

In my professional life, I have two services that I would like SystemD to restart when those services die. It does not restart them. Is this a problem? No. It is no different than previous behaviour.

Other than service monitoring, I am unsure what else SystemD is supposed to offer to me. My servers never change hardware, never change networks, never do anything at all other than the two services they provide. Binary logs makes troubleshooting transient boot problems impossible. It never gets far enough to start writing text logs through the other interfaces. I do not even bother to troubleshoot anymore. I have an ISO image that tkes less than 10 minutes to install and make fully functional. Is this the goal of SystemD? To just reinstall like we do with Windows?

Meh. There is no point in discussing this. Some people want SystemD. As a rejection of init, I can understand that position, but it is like worshiping Satan because Beelzebub was too evil. All I can say is, What the fuck is wrong with you people?

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Re: Yes

[HiThere]

I understand why you choose to be anonymous.

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Re:Yes

[Anonymous Coward]

We have too many redundant frameworks. Sadly, systemd is the only effort to unify them that seems to have traction.

Because lots of different redundant efforts to unify lots of redundant frameworks is clearly be the best way to solve the problem of lots of different redundant frameworks!

Redundancy is awesome!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Agreed!

Slackware

[Vyse of Arcadia]

No problems here. Slackware seems to keep things simple. Granted, I haven't tried to mount a camera with DigiKam in a couple of years.

Re:Slackware

[Anonymous Coward]

No problems here. Slackware seems to keep things simple. Granted, I haven't tried to mount a camera with DigiKam in a couple of years.

You need a man with a vision to deploy a distro like Slackware.
Most linux distros are of the "me-too" type variety. Lots of smoke, no substance.

Although I don't like the BSD license, the BSDs are much more well engineered than linux. And it's fukcing ironic because linux has a ton of commercial entities behind it that pour copious amounts of $/€ for development.

Right now if I had to choose between linux and BSD, it would be 60% BSD, 40 % Slackware.

Re:Slackware

[Anonymous Coward]

Right now if I had to choose between linux and BSD, it would be 60% BSD, 40 % Slackware

While that's an interesting idea... I'd be surprised if that system boots.

Re:Slackware

[Anonymous Coward]

No one uses slack in business, and very few do at home. slack is a funny little distro true to its roots because it has no user base.

Re:Slackware

[Anonymous Coward]

Funny little distro and no user base. This was a joke, correct?

Re:Slackware

[BronsCon]

I'm taking that as 60% of BSD and 40% of Slackware. Those have to be rough figures, as 3 characters (BSD) can be split into 0%, 33.3%, 66.7%, or 100% while 9 (Slackware) can split into 0%, 11.1%, 22.2%, 33.3% 44.4% 55.6%, 66.7%, 77.8%, 88.9%, or 100%.

The result would be the first 66.7% of BSD and the last 44.4$ of Slackware... so... BSware.

Re:Slackware

[AntEater]

Actually, that's not true. I managed dozens of slackware systems at my job for many years. I haven't found anything yet that was less hassle to manage and I've been using Linux since '95. The only weak point is if you need support for a commercial application that expects RHEL or Ubuntu specifically. 90% of the time I could work around such issues, but the vendors don't like to support it in a "non-standard" configuration.

Why does John shut down all systemd talk?

[Anonymous Coward]

I was reading through the article's comments and saw this thread of discussion. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away. The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems with Linux today. I don't use Debian, but I do use another distro that switched to systemd, and it is in fact the problem here. My workstation doesn't work anywhere as well as it did a couple of years ago, before systemd got installed. So when somebody blames systemd for these kinds of problems, that person is totally correct. I don't get why John would censor the discussion like that. I also don't get why he'd label somebody who points out the real problem as being a 'troll'. John needs to admit that the real problem here is not the people who are against systemd. These people are actually the ones who are right, and who have the solution to John's problems! The comment I linked to says 'Systemd needs to be removed from Debian immediately.', and that's totally right. But I think we need to expand it to 'Systemd needs to be removed from all Linux distros immediately.' If we want Linux to be usable again, systemd does need to go. It's just as simple as that. Censoring any and all discussion of the real problem here, systemd, sure isn't going to get these problems resolved any quicker!

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Switch to Slackware, it has all you are looking for.

It even has a sane filesystem layout instead of spraying config files all over the place EVERYTHING goes in /etc or as user configs in the proper place. none of this retarded /opt garbage that some brain dead morons though needed to exist.

If you install software and it does not store the system wide/global configs in /etc then that software was written by no talent idiots that need to be beaten with a sack of doorknobs.

Re:Why does John shut down all systemd talk?

[fph il quozientatore]

How exactly is systemd causing this problem? Neither you nor the author on the other thread give any sort of argument (which is the reason why he/she was accused of being a troll in the first place).

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Because, as experience shows time and again, systemd discussions tend to get out of control. Note that I don't like systemd (I don't like most of things FreeDesktop either), but I'm with John on this one.

> I also don't get why he'd label somebody who points out the real problem as being a 'troll'.

Read again:

> The systemd and GNOME 3 communities (theyâ(TM)re pretty much one and the same) are the problem here. Theyâ(TM)re killing the Debian project.

This *is* trollish. It's finger-pointing. There are people out there that *like* systemd and GNOME3 (gasp!) and they deserve all the respect each of us deserves. Live and let live. Find ways to cooperate.

Me, I won't install systemd on my machines or those I'll be responsible for -- but I won't insult systemd developers (or assume bad intentions on their part). They're working on free software after all, dammit.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

There are people out there that *like* systemd and GNOME3 (gasp!) and they deserve all the respect each of us deserves.

Why? I don't see anyone else save Microsoft, who surprise, surprise is just about as well liked for some mysterious reason, so hell bent on shoving various kinds of broken software down the throat of people who realize it's pure poo.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

It's not 'trolling' to point out when somebody has done something bad and harmful. It doesn't matter if they're working on free software or not. Maybe they haven't fucked over every single person, but the systemd developers and their software have caused a lot of problems for a lot of people, me included. I didn't have a choice to opt out of systemd when I updated to a newer version of my distro. Now my Linux system doesn't work well at all. So my choices are to 1) go back to the old version of my distro, which has security holes, or 2) stop using Linux. Since systemd has been put into pretty much every distro today, I don't have the choice of ignoring it. No, I'm not going to use Slackware, because it's prehistoric. I don't know what I'm going to do at this point. I can't keep using my Linux workstation in its current state, where it doesn't boot properly due to systemd failing, and where the logs are difficult to get at because systemd uses a binary format for logging. So I'm going to have to go with one of the BSDs, or Mac OS X, or maybe even Windows 10 once that's released. It's pretty bad that systemd renders Linux systems so unusable that long time Linux users consider moving to Windows just to get a usable system again!

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

There are a few good web pages that summarize complaints, but here is one:

Systemd has brought a ton of bloat and cruft that is enabled by default, and has undesired automatic behavior.

For example, I plugged in my android to load music yesterday. While reviewing logs, I see systemd started fprint, a "fingerprint authentication" service. All this automagic stuff of questionable quality is a security nightmare. (And I still wasn't able to view my android files, btw, so they've handled all kinds of bizarre use cases while missing the most common use cases)

Re:Why does John shut down all systemd talk?

[Barsteward]

"My workstation doesn't work anywhere as well as it did a couple of years ago, before systemd got installed. So when somebody blames systemd for these kinds of problems, that person is totally correct." - its these sorts of comments that gets labelled as trolling because they are vague anecdotes with no facts backing it up. If someone points out a specific problem and backs its up with facts, it gets discussed properly.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

systemd prevented my laptop from shutting down properly. systemd didn't know how to unmount / for some reason, so it eventually caused physical drive damage (ton of new bad sectors) when I had to hard-power-down the laptop. Reinstalled an older version of the OS without systemd, and everything just works now. systemd is worse than slashdot beta.

Re:Why does John shut down all systemd talk?

[Junta]

Of course some of the vagueness is precisely because things happen mysteriously, and systemd has a habit of doing unexpected mysterious things. Of course it's not alone, you have quite a few subsystems all deciding to be a bit 'automagic', with systemd and associates just being the most prominent. As a consequence, if you manually do something like reconfigure a network device using the underlying tools, something can mysteriously redo them later when it thinks something has happened like a lease expiry, even though dhclient no longer runs. Or a time change event at boot causes dhclient and some mysterious third party to disagree about when lease goes away. dhclient isn't renewing lease, but some third party decided that a lease wasn't renewed and deconfigures the adapter. It makes no sense, but someone in some random component thought something wasn't proper and decided to 'help' take care of something that wasn't their business.

Re:Why does John shut down all systemd talk?

[cheesybagel]

It probably has pulseaudio as well. Better to just dump Linux for FreeBSD if that happens.

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

Devuan

Re:Why does John shut down all systemd talk?

[Kagetsuki]

Every time I've played with it I had things like weird locking issues - but this was maybe a year ago when I last tried it.

What bothers/worries me about it are the devs behind it. Poettering was bitching about how hostile the community was before but he completely deserved every bit of criticism. All the major devs on that project are known to have abandoned other projects. Several times they made mainline commits which completely broke things. They constantly pushed barely tested and poor quality code (which is why Linus got angry at one of them and banned them from making pull requests till they got their sh*t together). On top of that the design of systemd is not very *nix like so it does seem an odd fit. All this makes me uneasy, and I don't think I'm the only one, because from this I am expecting a big lump of poorly tested experimental play code that the lead devs will just abandon once they get interested in another project.

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

How is that vague? The problem is very clear: that user is worse off after systemd was installed than before systemd was installed.

The exact flaws with systemd don't really matter. Maybe it was problems booting. Maybe it broke sleeping/hibernation on a laptop. Maybe it stopped mounting drives properly. Maybe it was the binary logs making debugging difficult or impossible. Maybe it was one of the thousands of other bugs plaguing systemd and distributions using systemd.

When a computer is less useful today than it was last year thanks to systemd getting installed, the problem is solely with systemd.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Yes, there are lots of web pages and comments that have complaints, but many of them are either really vague or turn out to be flat out wrong (e.g. saying systemd can't do something or that something else can't be turned off when it has an explicit option for that). Your comment continues being vague (although less so than many others, like the original) by giving a concrete example, although that doesn't fit into the "doesn't work anywhere as well as it did a couple years ago."

I have no horse in this race, but was curious what the big deal some people make about systemd. But trying to find anything concrete and correct from discussions of systemd is like trying to find something concrete and true out of political talking heads on 24 hour news stations.

Re:Why does John shut down all systemd talk?

[Ol Olsoc]

How exactly is systemd causing this problem? Neither you nor the author on the other thread give any sort of argument (which is the reason why he/she was accused of being a troll in the first place).

You noticed that too?

If all the claims I've heard about systemd were true, it would destroy our computers on first boot.

If all the proof of systemd perfidy I heard were put in a 2 ounce shot glass, I'd still have a 2 ounce shot of tequila with my dinner.

If I may delve into the past, this comes close to the GUI-Command line wars in that the command liners knew they hated a Desktop display and mouse, but couldn't quite articulate why.

Re:Why does John shut down all systemd talk?

[Ol Olsoc]

Of course some of the vagueness is precisely because things happen mysteriously, and systemd has a habit of doing unexpected mysterious things.

So if my car breaks down, or coffemaker quits running I can blame it on systemd, and that's okay? No it's not okay. Don't our computers have event logs? I've used them a lot over the years, and they do a lot to take the mystery out of failures.

Anyhow, Perhaps now that these "mysterious things" that systemd does are known, why don't you tell us about them?

I'd do that myself, but so far, aside from an early pulseaudio issue, I don't have a problem with it

There must be a whole catalog of the things that systemd messes up by now. Can we see pleeze?

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

This is the same kind of logic Windows users use to blame IT for their computer getting slower....It's an assumption that something they heard about caused the problem because "magic". Without proof this puts you squarely in the end luser category.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

If all the claims I've heard about systemd were true, it would destroy our computers on first boot.

It destroyed my computer on halt -p.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

1) go back to the old version of my distro, which has security holes, or 2) stop using Linux.

I think you missed 3) switch to Gentoo or Sla---

No, I'm not going to use Slackware, because it's prehistoric.

Ok, Gentoo it is.

I'm very happy with it. I even have in my /etc/paludis/package_mask.conf a section labeled Lennart Poettering that prevents systemd or pulseaudio from ever being pulled in by anything. grub2/OpenRC boots like a charm

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

The people who use systemd should go somewhere else (systemd forum?) to complain about their problems. Anyone with half a brain knows to avoid it any cost.

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

Just because B follows A, it does not mean A caused B. This is a commonly made logic fallacy.

Re:Why does John shut down all systemd talk?

[morgauxo]

"Live and let live. Find ways to cooperate."

Ummm... wouldn't that mean supporting both sysvinit and systemd? Wasn't there a vote about that a while back and the Debian maintainers decided not to?

Re:Why does John shut down all systemd talk?

[duke_cheetah2003]

I've been kinda sitting on the sidelines about systemd all this time.. I still run init based startups on my debian boxes (wheezy and squeeze currently in use, on 2 machines.)

I hear so much... hatred for this program... now as someone who's mostly not researched this... what is good about systemd over init scripts, besides supposedly ridding ourselves of the need for init scripts? I won't go into why I think that's probably not a good idea in general, but anyway. I hear so much hatred and so much 'it breaks this and breaks that.' I've never heard one good thing about systemd?

Based on the tone of the anti-systemd camp, I'm certainly afraid of this .. thing. Where's the big shiny beacon of 'this is cool you should use it, this is why' camp?

Re:Why does John shut down all systemd talk?

[Eunuchswear]

I was reading through the article's comments and saw this thread of discussion. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away.

Of course he shut it down, it was pure trolling.

Goerzen writes about a problem he's having with Gnome, Xfce and KDE on a non-systemd system, which is fixed by moving to systemd, and some moron jumps up to claim the problem is Gnome and systemd.

Re:Why does John shut down all systemd talk?

[fisted]

If you install software and it does not store the system wide/global configs in $PREFIX/etc then that software was written by no talent idiots that need to be beaten with a sack of doorknobs.

FTFY. People who assume or hardcode the install prefix to be /, should line up right with the "no talent idiots" to collect their beating.

Re:Why does John shut down all systemd talk?

[fisted]

If I may delve into the past, this comes close to the GUI-Command line wars in that the command liners knew they hated a Desktop display and mouse, but couldn't quite articulate why.

Well you seem to simply haven't paid attention, then. The obvious and still valid argument in favor of a command line is the ability to automate stuff, which you don't get in a GUI, unless baked into the programs thenselves (and even then it's nowhere near as flexible).

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

I have no horse in this race, but was curious what the big deal some people make about systemd. But trying to find anything concrete and correct from discussions of systemd is like trying to find something concrete and true out of political talking heads on 24 hour news stations.

Believe me, we are on the same page. The systemd debate tends to be very emotional and personality-based. I'll try to dig up those links and post them later today.

For me, it boils down to two things:

• I dont see the need for such a paradigm shift. Leonard has a web page where he lists all the advantages of systemd, and I dont see anything on the list I want.
• The code base for the sysd suite has grown very large very quickly, and due to the "bazaar" style of development, does not seem to follow QA processes of a proper dev shop (if I'm wrong, someone please correct me). This approach brings more risk than I'm comfortable with, on my personal desktops or production servers.

That said, I appreciate Leonard's contributions to the community.

Re:Why does John shut down all systemd talk?

[gweihir]

I have to agree that this is highly suspicious. Stinks of foul play.

I do agree that systemd is not the only instance of the problem, but it is clearly the worst example of it.

Re:Why does John shut down all systemd talk?

[gweihir]

You either have not looked or you are trolling. Try google("systemd sucks"). There really are very few unsubstantiated rants about systemd, most comments are fact-based and explain what is wrong with it. The systemd proponents are waging a war against a large part of a whole community.

Re:Why does John shut down all systemd talk?

[gweihir]

Something that was problematic a year ago cannot be production-stable now. Server operation and in fact, professional desktop operations, has higher standards. It is like a partially broken and ever-changing thing is pushed into Linux in order to boost support revenue.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Here's my few observations from when I had to deal with it for some quick testing:

  * Ignored entries in /etc/fstab -- They were just skipped. Could manually mount them fine, but ignored on boot. This was NFS mounts, and some local drive mounts that were not configured during install, etc..
  * Ignored SysV scripts -- Ignored the init scripts that were added in. Again, could run them manually just fine. But not having InfiniBand on boot was an issue.
  * Order of init was... wrong for some thing --- This I just ignored completely, but it was trying to start up a service that was impossible to start because there wasn't networking yet. *shrug*  Distro misconfiguration most likely (i.e. happened first boot after install).

But yeah, I never looked into it much; just needed to test some small things out then haven't touched it again.

IMHO, it doesn't belong in the server space. I want to have full control on my clusters over every step I can. Desktop I can see where it could be useful (same as sadly network manager *God I typed that didn't I*), but please keep it far far away from my servers.

Re:Why does John shut down all systemd talk?

[gweihir]

When vague anecdotes start to pile up (and they do for systemd unreliability), they become facts in themselves. Add to that that systemd problems are exceptionally hard to debug (you have to look into complex C source code for many) and the development team is unhelpful, and you get a pattern: The reason many, many people are reporting vague anecdotes about their system being unstable from systemd is not that they are lying, or fantasizing or on drugs, the reason is that systemd does indeed break reliability and on top is very hard to debug and fix.

Some very old engineering failure analysis wisdom applies here: To really break things, you have to screw up in two major aspects. Systemd manages to do this easily by being unreliable and so hard to debug that most people fail at it. People are scared of it and angry at it, because they cannot master this complexity. And they are right to fight it: A decent OS has no business at all being complex in any place where it is avoidable and in particular, it has no business at all replacing simple things that work with complex ones, regardless of whether they work or not. If Linux is not kept free of high complexity in core components, it will implode.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

ok, i'm giving you an example. OpenSuse 13.1 - 13.2. Reboot (!) doesn't work. Very often it stics somewhere in wilds of systemd. DO you want to help me to troubleshoot it?

Re: Why does John shut down all systemd talk?

[gweihir]

This is clear from the available evidence to any rational person. The systemd proponents would have to admit some very unfortunate things about it though, so they rater put their heads in the sand and insult anybody that points these issues out.

Re:Why does John shut down all systemd talk?

[Eunuchswear]

here are a few good web pages that summarize complaints, but here is one:

Systemd has brought a ton of bloat and cruft that is enabled by default, and has undesired automatic behavior.

But that doesn't answer the question you were asked:

How exactly is systemd causing this problem?

If you'd bothered to read the fucking ariticle you'd have seen that John Goerzen was complaining about a problem he was having on a machine that didn't have systemd installed

So, once again: "How exactly is systemd causing this problem?"

That's why "Geoffrey" was accused of being a troll -- because he is one.

Re:Why does John shut down all systemd talk?

[Eunuchswear]

Tried it.

https://www.google.fr/search?q..."systemd+sucks"

About 524 results (0.15 seconds)

1st: Guy says he hates it, gives no reason, then explains how to use it
2nd: Christopher Barry's rant reported on pipedot
3rd: linux.com article about systemd, with one comment that claims systemd takes 10 minutes to reboot, gives no details, bug report, whatever
4th: Posted on %A %B %e%q, %Y by Markus -- unsubstantiated rant about systemd on arch.
5th: freebsd forum post about Ubuntu going with systemd, one commenter says: "So, yeah, systemd sucks as an init solution, but most people (admins included) will never notice the difference. " ...

I'm too bored to carry on. Remarkable absense of fact based explanation.

Re:Why does John shut down all systemd talk?

[gweihir]

Well, if that is the level of Google-Fu you have, then I can understand you see nothing wrong with systemd. You have a far more serious problem instead.

Re: Why does John shut down all systemd talk?

[Billly Gates]

It is only 300, 000 lines of code.

Sun, Apple, and Ubuntu left init for good reasons. No problems as it wasn't hip to hate yet.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

so, your saying that letting the orthagonal concern of preserving an individualist philosophical tenet that validaes people who have bad opinions is more important than maintaining a status quo that works and has worked, and that deviating from is causing serious disruption to the community? I disagree. Remove the instigator and the problem is solved. Some opinions just arent valid, no matter how unpleasant it may be to come that conclusion. And it *is* up to you and within your rights to make that call. The software is not tending towards 'freedom' when it is disrupting the rest of the communities effort to preserve itself.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

I've read through the article's comments a few times today, and I'm no longer seeing perfectly good comments that were there earlier. I think he may still be deleting any that express ideas that he doesn't like. This is pretty typical behavior for the systemd crowd. They're a bunch of petty tyrants. They instantly toss around "troll" false accusations, and resort to censorship and deletion whenever possible. They cower away from any real discussion, instead choosing to abusively sculpt any discussion whenever they can. On one hand I think this is rather sad and petty, but on the other hand I'm glad that they're doing it. This kind of behavior, coupled with their shitty software, will kill Linux faster and faster. While I don't want to see the Linux community disperse, I do think that it's the best thing to have happen at this point. When stricken with a contagious terminal illness, sometimes it's best if the host (the Linux community) passes on, in order to prevent further spread of an infection (systemd). They're setting the stage for a Linux renaissance, and it won't include systemd.

Re:Why does John shut down all systemd talk?

[fahrbot-bot]

Of course some of the vagueness is precisely because things happen mysteriously, and systemd has a habit of doing unexpected mysterious things.

So if my car breaks down, or coffemaker quits running I can blame it on systemd, and that's okay?

Not yet and shut up. Don't give Lennart and Kay any more ideas. We're all suffering enough as it is.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Yeah, mentally challenged spamers = foul play.

Re:Why does John shut down all systemd talk?

[BronsCon]

Well, systemd uses its own binary logging format; if systemd isn't working, good luck reading it. Yes, I know I can use syslog in addition to systemd's own logging; well, I could, if systemd would start it. And even if/when it does, if systemd's bad behavior occurs before syslog starts, it's on systemd's log but not syslog's, which, again, means it's only useful when systemd is behaving, which, if it were, would render the whole point null.

Follow?

Re:Why does John shut down all systemd talk?

[BronsCon]

You won't get an answer. Supporters of systemd are all either too ashamed of themselves to admit they were wrong, or too snowed to know it but not quite sure why they like it. It's like crack, most of us know not to use it, some of us still will, and of those who do, some will be able to walk away, but most will end up stuck on it whether they like it or not. Sadly, I'm in the latter group.

Re:Why does John shut down all systemd talk?

[Eravnrekaree]

I can definitely agree that with such a core part of the system there has to be a high degree of focus on quality, it needs to be well documented and should not have major bug problems in the stable releases.

The "not very *nix like" is suspect. As long as it supports the traditional unix initization System V facilities, such as the rcX symlink directories and maintains backwards compability with these traditional forms of initilization, its keeping a unix like quality. The addition of new functionality does not mean it is taking away older ways of doing things, and does not mean you are forced into using these new capabilities. If you dont like that the web server is starting from systemd's own method, you just move its initialization over to the old System V facilities.

Its sort of hard to argue that you should NOT be able to set up the HTTP server to be stopped and started with the NIC or run other processes triggered by other events if you want to, and it seems thats what systemd's opponents are saying, "you cant do it that way, you shouldnt be allowed to have that functionality".

The basic concepts of what systemd does is good, this does not mean the execution has been particularly great.

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

Let me make sure I understand this. So because systemd's logging is irreparably broken, I should use it alongside a logging system that's known to work. So why not just get rid of systemd's broken logging system, and just use only the other logging system that actually works?

Re:Why does John shut down all systemd talk?

[RavenLrD20k]

As far as hardcoding the install prefix, I can agree with you; there needs to be a way for users to change the install target. I disagree that global configuration files need to have the $Prefix as well, and I'm against that idea. A global configuration really needs to be placed in /etc as a matter of convention. If a daemon/application has multiple configuration files that require a global position where multiple users must be able to access them(ssh, apache, etc.) then a directory should be created for that daemon/app underneath the /etc directory (/etc/apache, /etc/ssh...). It's precisely the known convention because that's what system administrators are used to; having to re-learn the location of where these files are placed from system to system or even version to version is a training nightmare in a professional environment and wastes time most often in situations where time does not need to be wasted. Maybe you were thinking more of /etc$PREFIX or /etc/$PREFIX

Re:Why does John shut down all systemd talk?

[John Goerzen]

I didn't shut down all systemd talk. Just the stuff that was flamebait. What you didn't see is the comments that I deleted, which degenerated exceptionally quickly into namecalling and four-letter words. I am happy to tolerate many viewpoints on my personal blog as long as they are expressed with respect. I have seen sooooo many threads, whether here or elsewhere, start with statements like the one there. That post was on a technical matter, and things that are verifiably false and rehash the way a systemd decision was made were both off-topic and non-respectful.

There are a lot more systemd comments on the post, by the way. Some pro, some against.

"Systemd is a problem because..." was fine. "forced upon us" is a completely different discussion that is still highly-charged, produces nearly instant flamewars, and I didn't want to go there (yesterday).

My blog is my own little corner of the Internet where I try to raise the level of discourse just a bit. It's fighting a tidal wave, but I do try.

Re:Why does John shut down all systemd talk?

[gweihir]

Interesting thought. Well, the kernel is mostly fine and userspace could really use a renaissance where people remember what made Linux great and go back to that.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

poorly tested experimental play code that the lead devs will just abandon once they get interested in another project.

Hmm. Perhaps another way of looking at it is: once the mission they have been given is complete - to subjugate free and open source software like Linux to corporate behemoths - Poettering and his accomplices will be retired on a fabulous payout from their not-so-secret paymasters?

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

As a long-time reader of your blog, I'm very disappointed to see how you handled this situation. You stifled perfectly valid and insightful discussion, you resorted to pathetic name-calling, you actively engaged in censorship, and now you try to justify this poor behavior with a whole lot of bullshit reasoning. All of those are very distasteful things, and I expected much better from you. Your attempt to "raise the level of discourse" did the complete opposite, plus it made me and others lose all respect we might have had for you. I'm sorry, I don't think I'll ever be able to take anything you write or do seriously after having witnessed your behavior during this silly incident. I'm disappointed.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Don't let people get you down. People get really passionate about systemd for whatever reason and you get a really vocal minority that will flood you with comments/etc.

When I did a presentation at an LUG introducing systemd there really wasn't any arguing at all. Granted, my presentation was mostly designed to educate/inform/etc, but most people seemed to be impressed with it, with an audience ranging from hobbiests to professional sysadmins. The biggest comment seemed to be "so why is this such a big deal?"

But, that is in a room full of people who regularly get together and discuss topics of interest and we then go out and have drinks/etc and generally don't treat each other like position papers. Go online and when you post about anything you're sure to attract the 5 most passionate people on the planet on the topic and it is a total shitstorm.

You don't have to foster that stuff on your blog. Let people discuss issues and actually elevate the discussion. We don't need one guy posting a problem he's having and 47 replies saying "yeah, the guy who wrote this software should burn." Better to have somebody posting a problem and then somebody commenting on why it happened and how to fix it.

I think the biggest issue with systemd is that it is simply new in most distros. Anytime my distro rolls out some new tool that involves lots of per-package configuration there are always little bugs. Systemd is just more of the same on steroids. Roll out SELinux and you'll see the same thing. Ditto for something like policykit, or udev. Most of the power is in the configuration and distros have to adapt that stuff.

Re:Why does John shut down all systemd talk?

[Aighearach]

What bothers/worries me about it are the devs behind it. Poettering

Hateful logical fallacies are your own fault, you can't blame them on others. And no, they don't have technical causes.

It is strange that a SysV (the greatest evil ever known to UNIX, as everybody has known for over 30 years) init replacement would spawn it, but it is somewhat of a Litmus test for separating technical people from raging anti-technical aholes.

If the people involved becomes important to you, rather than the technical concerns, you're a complete failure both as a nerd, and as a human being.

Re:Why does John shut down all systemd talk?

[Aighearach]

If I may delve into the past, this comes close to the GUI-Command line wars in that the command liners knew they hated a Desktop display and mouse, but couldn't quite articulate why.

Usually it was because they couldn't understand how to calculate modelines. And they weren't smart enough to realize that having the X Window System means having multiple CLIs on the screen at the same time.

I was a late adopter of GUIs because I had wimpy computers and "didn't need it," but I never thought that switching between virtual terminals was going to be as efficient for the human as switching between xterms.

I don't know what makes these people think that SysV Init is something to worship. It was always something gross and non-optimal, but that allowed flexibility. All the things about SysV init that made it "popular" originally are even better in systemd. Somebody told them to hate systemd, but they're too young to understand that they were already supposed to be hating SysV, and for technical reasons not just because "I don't like the name of one of the developers."

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

The binary logs suck really bad when the systemd decides that system shutdown must freeze with blank screen after it has updated itself. Good luck solving the problem, as the binary logs are corrupted after forced shutdown. I would not mind if the logs are in binary format, as long as they provided the atomicity and error recoverability one usually expects from binary files used eg. in rdbms. But putting the critical maintenance data (=logs) to unstable storage which is fragile by design is a major obstacle.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

"If I may delve into the past, this comes close to the GUI-Command line wars in that the command liners knew they hated a Desktop display and mouse, but couldn't quite articulate why."

I always use a terminal when I need to get something done. It is easier to set the font size so I can see it, and the cursor stays where it belongs.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

The use cases systemd assumes is not what every user wants. Linux works best when it does what you want, not what was decided by the developers of a sub-project that affects nearly the entirety of user space.

So, slackware it is. Works great, does what it is suppose to, doesn't do arbitrary activities because a committee (or just some pushy dev) believes that everything that connects must connect through their solution. And the system logs work, as in they are readable with tail -f. Hey, look! That works and it's usable.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Maybe if you provided your super-effective search instead of an ad hominem attack, then we could take you seriously.

Re: Why does John shut down all systemd talk?

[david_thornley]

How is it vague? For one thing, it says nothing about how his system is worse. Increased boot time? Doesn't mount stuff? Takes too much bandwidth uploading /user to ftp.nsa.gov?* For another thing, it says that his workstation doesn't work as well with a new version of the distro, which doubtless includes lots of things changing besides just systemd. Since it was a couple of years, maybe he's installed new hardware has problems, or is using updated versions of certain applications that have bloated, or is using the system in a somewhat different way.

If people are going to blame every problem on systemd, then there are going to be a lot of problems blamed on systemd, regardless of whether systemd is causing them or not.

*"Broke sleeping/hibernation on a laptop"? Do you realize how touchy that can be on distros without systemd? My laptop doesn't do that reliably with the Windows 7 it shipped with.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Are you sure that DHCP lease renewal problem (manually change the IP address of an interface, but it gets changed back on a lease renewal) was systemd? I ran into it on Ubuntu 9.10, and 10.04, well before systemd.

I just wonder if systemd isn't getting blamed for some other system's problems just because everybody is talking about systemd's problems. I have yet to run into a problem that I could pin on systemd. Lots of apparmor problems and a fairly serious upstart problem (mounting of /usr wasn't a prerequisite to bring up the network, yet bonding required it), but nothing with systemd. With apparmor and upstart, the problems I've ran into are misconfigured apparmor profiles and misconfigured upstart rules, neither of which are really problems with apparmor or upstart. Couldn't the same be true of systemd?

Re:Why does John shut down all systemd talk?

[Kagetsuki]

I don't think you are familiar with the controversy surrounding him, but a quick google search dug up a rather good summary of the situation:
http://www.infoworld.com/artic...

The people involved are always important because the people involved will:
1. Shape how the project evolves.
2. The life of the project is usually dependent on those primarily interested in it staying interested in it.
3. A project needs to take criticism into account and look for opporunities to improve. Completely ignoring all critcisim could be ignoring fixes you could make now that could make things a lot smoother and avoid problems in the future.

Also I'm not defending SysV :P

Re:Why does John shut down all systemd talk?

[Kagetsuki]

I actually completely agree with you on most parts here. The "not very *nix like" thing is more referring to how the core of systemd is trying to do a lot more than it should and then is wrapping that in several layers. Then to make matters worse many of those processes are hard coded and not configurable without actually recompiling the module for that. As cluttered and dated as SysV is at least you don't have to take pieces of it apart to change what flags are being used to call some secondary command at boot time.

Of course I say this but you are correct in that the design states it should not be this way but it is. Or, to put it another way, let me just quote the last line of your comment:
> The basic concepts of what systemd does is good, this does not mean the execution has been particularly great.

Re:Why does John shut down all systemd talk?

[Kagetsuki]

> in order to boost support revenue
I don't want to believe that's the reason systemd was pushed through, but if that statement has even a fragment of truth to it then someone at RedHat needs to have their skull busted.

Re:Why does John shut down all systemd talk?

[drinkypoo]

I think systemd is bullshit but the two good things about it are early boot logging and cgroups support. Neither required a new daemon, let alone a replacement for init. So there you go.

Re:Why does John shut down all systemd talk?

[Ol Olsoc]

In a blazing fit of irony, the anti systemd crowd has shown themselves to be identical to the Microsoft shills.

Someone posts something you disagree with, and you mark it as troll.

Thank you for proving part of my point.

Re: Why does John shut down all systemd talk?

[Anonymous Coward]

It is only 300, 000 lines of code.

I was talking about the whole suite, which is more than 300k lines. Phoronix said it was 550k as of last May http://www.phoronix.com/scan.php?page=news_item&px=MTY5NjM

From what I've read, 1 defect per 1000 lines of code is a respectable ratio for industry software. We don't know what that rate is for the sysd suite, but we do know that Linus has criticized sysd devs for failing to fix their bugs.

Sun, Apple, and Ubuntu left init for good reasons. No problems as it wasn't hip to hate yet.

Ok. What's your point?

Re:Why does John shut down all systemd talk?

[Aighearach]

When you're confusing a technical discussion with name-calling and HS clique behavior, it might seem to make sense to shout, "but he's a bleepity-bleep!"

The thing to understand is that most adults do not even listen to or measure the substance of your name-calling. He's a famous, successful programmer. People who believe he is some sort of pariah are just idiots, none of whom are qualified for his job, which is a high profile job that he has been very, very successful in. The fact is that is his peers, others with similar qualifications, who work for other distros respect his work deeply and indeed, adopt the very software that armchair morons would somehow "call him out" over.

All your hate just proves you don't even know what he does, much less if he is any good at it or not. You just wave your hands and shout, "but... pejorative! Pejorative!" It tells us something about you, but nothing about why we're ignoring you and choosing systemd.

Re:Why does John shut down all systemd talk?

[Eunuchswear]

Uh, it was you who provided the search. You claimed it would show "most comments are fact-based and explain what is wrong with [systemd]".

I suspected before doing the search that was not what it would show (seriously, "systemd sucks"?). I was right.

If I'm expected to google the contents of your brain to find the real search then I'll admit to not being up to it.

Re:Why does John shut down all systemd talk?

[gweihir]

Hahahaha, despite massive, dishonest and very likely paid-for negative moderation, I am at +2 Flamebait. Really, the systemd propaganda campaign is as pathetic as it is dishonorable.

Re:Why does John shut down all systemd talk?

[gweihir]

You are really pathetic. Of course, a literal application of advice will almost always go awry. You either know that and are lying about it, or you have not active intelligence.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

Thank you for this fascinating insight into a zealot mind.
You do really believe what you wrote, that your guru is a great programmer that can do no wrong, and not the author of pulseaudio, a loudmouth, rude twat who closes bugs with wontfix because he doesn't understand any reasoning but his own, and is only admired by the same gnome-bred "developers" who managed to take over main distributions by virtue of being paid to do so (by Novell, RedHat, etc.)?
Rational adults look at past performance and at human qualities while evaluating if they should support a project, rational adults don't call all non-believers haters, rational adults when confronted with a wave of rejection and criticisms don't gloss it over with the "hate the new" brush, but instead try to find if there is any substance. Good developers don't answer complains of breaking other people's work flow with "then fork it" to then throw a temper tantrum and start name calling when some volunteers indeed fork it.
Power users don't find a overly complex, all absorbing middleware, with "dumbifying" defaults like disabling sysreq as a technical advance. Power users don't appreciate the gnome inherited attitude of "[paid] developers know best".
Personality of the lead developer, as well as past performance, tells you a lot of what to expect of the current project.
But I guess that is difficult to understand for someone who still thinks poettering is some kind of genius, and not just an arrogant, mediocre programmer that got to where he is just because it fits with his employees (direct and indirect) strategy.

Re:Why does John shut down all systemd talk?

[Kagetsuki]

First off I don't hate him - I just don't trust him and I find the way he deals with people to be a bit childish.

As for the rest of your post:
> He's a famous, successful programmer.
He's kind of famous for not being liked by some other high profile programmers more than he's famous for delivering a stellar project. We can only hope systemd will turn out to be as fantastic as is promsied and everyone can just drop the issue and give praise [when and] where it is due. Mind you, that day has not yet come.

> none of whom are qualified for his job
He's not some sort of genius. There are many many incredible coders out there who would certainly be as qualified for his job - just few of them are so motivated or have been offered the incentive or opportunity to do it.

> All your hate ...
Criticism and/or lack of trust are quite different than hate. Again, I don't hate him. And I really, really want systemd to be good. I want to just transition into using it regularly and think "This is great! I'm so happy it turned out so good." And that possibility certainly exists as I regularly have deployment issues that hinge on sysv being a little too old and crusty to deal with newer things elegantly. Some of the things promised by systemd look like they will gracefully solve these problems but I have yet to see an actual build of it that did.

Seriously though, what kind of relationship do you have with him? It's obvious you have some sort of emotional or empathetic attachment to him and I'm curious as to what warrants that.

Re:Why does John shut down all systemd talk?

[Zontar The Mindless]

It's not just Gnome3 and systemd--it's the Gnome3/systemd "we know what you want better than you do" mindset that is troubling.

Re:Why does John shut down all systemd talk?

[Kagetsuki]

SysV is significantly simpler in design and functionality than systemd and that is exactly why so many people want to stick to it rather than jump on the systemd bandwagon. systemd tries to do way too much and in turn gets itself tangled into parts of the system that SysV would never be involved in. That means that in cases where SysV has done its simple job and gotten out of the way systemd could have some failure in some unrelated part of the system that could have a residual effect on something else. What's damning is that there are quite a few recorded instances of this happening.

The fact of the matter is as much as SysV can be inflexible and occasionally difficult to deal with, it works and it rarely breaks. You need to consider the install base we're talking about and how much of a massive loss of time and money even a 1% increase in down time could cause. This is an issue we need to be certain on, we need more testing on, and as much as it would be great to just love new and shiny things we need to act like grumpy old men a little bit so we don't break parts of the world.

Re:Why does John shut down all systemd talk?

[Zontar The Mindless]

I happen to run both of those, and I've never had any boot/reboot issues with either one.

Still don't like systemd very much, though.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

SystemD changed a lot of things and got those changes widely adopted really fast.

So of course it's a very divisive subjects, but do consider that it didn't get magically installed on every recent distribution, some very reasonnable and responsible people debated about it, and took the decision of including it.

You may want to try it simply because it is arguably technically superior in quite a lot of ways.
It currently works well for my desktop usage so I have few complaints. That said, as others have pointed out, I wouldn't for the life of me want to make my way through the resulting mess if SystemD stops working for me.

And I can only hope that cute little lennart won't leave it unmaintainable and without support in 5 years.

Re:Why does John shut down all systemd talk?

[ookaze]

I was reading through the article's comments and saw this thread of discussion. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away. The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems with Linux today.

perhaps he shuts them down because he specifically said that installing systemd solved his problem but he doesn't know why.
Yet people with logic problems claim systemd is the problem, despite the fact that it wasn't installed on the systems experiencing the problem.

Re: Why does John shut down all systemd talk?

[ookaze]

>When a computer is less useful today than it was last year thanks to systemd getting installed, the problem is solely with systemd.

In the OP, it's the opposite: the computer is more useful today than it was before thanks to systemd getting installed, so the problem is solely with something else.
Which makes sense since a distro upgrade is not just systemd being upgraded, contrary to belief of non proficient people.

Re:Why does John shut down all systemd talk?

[ookaze]

When vague anecdotes start to pile up (and they do for systemd unreliability), they become facts in themselves.

No, anecdotes never lead to facts even if you have millions of them. You can't even say facts of what. Only analysis of anecdotes can lead to facts.
This is becoming ridiculous, pushing dogmatic thoughts like that is dangerous.

Add to that that systemd problems are exceptionally hard to debug (you have to look into complex C source code for many) and the development team is unhelpful

This is pure lie that can be debunked by just looking at the devel ML.
Why systemd haters always have to rely on lies?

The reason many, many people are reporting vague anecdotes about their system being unstable from systemd is not that they are lying, or fantasizing or on drugs, the reason is that systemd does indeed break reliability and on top is very hard to debug and fix.

No, the reason is that the unstable distro these people are using is really unstable, but they are too young to have experienced previous big breaks in GNU/Linux distro, like udev predecessor, kernel 2.2 to 2.4, 2.4 to 2.6, 2.6 to 3.0, 3.3 to 3.4, Gnome to Gnome 2, Gnome 2 to Gnome 3, ...
systemd is far from being the biggest change and challenge in Linux since I've worked with it starting in 1999, it's actually a breeze that no decent admin that know several Unix + Linux should trip on.

Some very old engineering failure analysis wisdom applies here: To really break things, you have to screw up in two major aspects. Systemd manages to do this easily by being unreliable and so hard to debug that most people fail at it. People are scared of it and angry at it, because they cannot master this complexity. And they are right to fight it: A decent OS has no business at all being complex in any place where it is avoidable and in particular, it has no business at all replacing simple things that work with complex ones, regardless of whether they work or not. If Linux is not kept free of high complexity in core components, it will implode.

When I read this I could be made to believe I'm a genius. This is wrong on so many levels, the first one being that things didn't work before, things were duct taped constantly by distro providers or by admins. Which is why the first thing systemd haters talk about is being able to tweak their initscripts, because the secret to unknowing people is that the basic distros just don't work with their setup, which has to be tweaked with ugly hacks for every specific environment.
It becomes a hell to maintain and every distro upgrade is at risk of failing very badly or erasing their change.
Usually what happens is that you forget about it, then when it blows up, blame the distro, and then quickly flee in shame when you realise it was all your fault to begin with. Now these admins blame systemd for their faults, the good ones come regularly to the ML to see their problem fixed.
Fortunately systemd is part of the fix for this mess.

Re:Why does John shut down all systemd talk?

[Anonymous Coward]

You should not use it. Developers should use it. If you're an end-user use what comes with your distribution.

You're looking for a reason to be afraid and/or outraged. You must be, because almost all of the Linux distros have seen sufficient technical advantages to systemd to switch to it. If you haven't heard about these technical reasons, you're self-selecting against this information. It's okay, everyone does it, but in this case the majority of technical experts are for systemd, and that's prima facie evidence that the opposing information is lower-quality. Be aware of what your influences are.

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

https://wiki.debian.org/Debate/initsystem/systemd

Init is a misnomer; we're talking about the thing that starts and manages services and runlevels. Init is part of that. As a service manager, sysvinit fails badly. Starting a service on linux involves double-forking and writing your process number to a file, and hoping that file is still accurate when you want to kill the process. See here for an example. All of those steps must be implemented by every service, and the logic for doing so is duplicated across every service — hopefully correctly. There are quite a few things that can cause the pidfile not to be accurate, at which point init can't do anything with it. Also, because sysvinit is just a collection of scripts, [a] they're all run in sequence, and [b] when problems happen, the script exits with a non-zero return value. If you need anything more than a non-zero return value you'd better roll it yourself.

Cgroups were invented to fix this, because you need kernel cooperation to track processes accurately. Systemd was invented to manage services using cgroups, and is heavily influenced by OSX's service manager. For a more thorough investigation about the rationale behind systemd's features, collectively and severally, please see Poettering's blog (https://0pointer.de/).

Sysvinit is really good for people that need to script every aspect of their OS. Some of these people are sysadmins who think that scripting is actually their job. Some of these people think that scripting is what Unix is all about. These people are generally bad programmers who forget that Unix is also about cleaning up scripts and rewriting them in C. Init scripts are easier to debug, but most other OSes seem to get by without anyone needing to debug init scripts.

Also, if you've ever worked with chroots, check out systemd's containers; they are a major feature and quite nice to use.

Re:Why does John shut down all systemd talk?

[fisted]

I see how what you say seems desirable from a Linux POV, where the install prefix even for 3rd party packages is just "/".
Other OS approach the matter more carefully, providing a split between the base system (pfx /), a prefix where installed packages go (e.g. /usr/pkg) and a prefix for the user to use for their own purposes (trypically /usr/local). A good thing, IMO.

Re:Why does John shut down all systemd talk?

[fisted]

[...] packages is just "/usr".

FTFM

Re:Why does John shut down all systemd talk?

[thegarbz]

But I think we need to expand it to 'Systemd needs to be removed from all Linux distros immediately.

So your answer to a buggy program that was forced on you when you upgraded your distribution of choice is to forcefully remove that program from all distributions thereby limiting both choice and the ability for the code to evolve and bugs to be reduced?

That is the single most idiotic view I have every heard uttered from a proponent of open source. If you actually believe this then *YOU* are far more dangerous to GNU/Linux than systemd ever will be.

Re:Why does John shut down all systemd talk?

[gweihir]

Keep the propaganda coming. We see right through you.

Re:Why does John shut down all systemd talk?

[gweihir]

Not that I can be sure, but at this time I see:
- No technical merits of systemd that are important or critical, just some convenience issues
- Systemd is in hurried development, a stable feature set is nowhere in sight
- The development leads are known incompetents with inflated egos and no communication skills
- There are a number of design decisions that are very, very bad for security and stability

At the same time I see:
- Systemd is pushed strongly with emotional (not factual) arguments
      This is a coordinated and targeted propaganda campaign. A campaign focused on technical
      merits is not even attempted seriously.
- Systemd opponents are ridiculed, insulted and their arguments are not taken seriously
- Systemd is getting very hard to avoid

I can only deduce that there _must_ be one of or a combination of the following going on:
- Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
- Linux did not generate enough support revenue Red Hat and this is intended to fix that
- Red Hat wants total control over Linux and systemd is their attempt to establish that

So if it walks like a duck, quacks like a duck, the most probable explanation is that it is a duck and hence I conclude that something nefarious is going on and the last three items are the most likely candidates IMO. I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves. They must have significant, coordinated help, with significant propaganda and manipulation experience. Whether it is military PsyOps or just commercial PR, the effects are the same. And they are massively negative and destructive for Linux and its community if not repelled decisively.

Re:Why does John shut down all systemd talk?

[strikethree]

It's fighting a tidal wave...

Maybe you should understand the tidal wave and how it came to be rather than just fighting it reflexively.

Kind regards,
Dave

Re:Why does John shut down all systemd talk?

[Aighearach]

I don't have to have a "relationship" with a tech to know that hating a person, and using that hate in place of technical considerations, and even bringing it up when talking about software, is pathetic and childish and an extreme anti-pattern.

A "relationship?!" Seriously? That is the only reason you can think of why a nerd would be bothered by your clique-forming and conflation of clique-shaming with technical analysis? You might want to turn in your nerd card.

Re:Why does John shut down all systemd talk?

[Kagetsuki]

Again, I don't hate him. I'm just curious as to why you defend him so much. And by "relationship" I mean do you know him? Have you worked with him? Have you been involved in the technical discussions his negative image arose from? I wasn't implying anything else... So why are you so bent on defending him?

> and using that hate in place of technical considerations
I think the problem here is a lot of the "hate" he's getting is from *him* ignoring technical criticism. At least that's what a lot of people have pointed out. He kind of projects this attitude of "I'm right because I know I'm right and my way is better" which is an extermely frightening considering how much of an integral and low level component of the system systemd is.

As developers we need to take criticism seriously. When someone says "I think this is wrong" or "I'm worried about this in this situation" or "Do you think this is really a good idea?" it is quite possible they may have noticed something we've overlooked or failed to consider.

Re:Why does John shut down all systemd talk?

[Kagetsuki]

This is the most insightful comment in this entire discussion. It's nested pretty deep though - maybe you should copy this and paste it as a new post. People need to see this.

Re:Why does John shut down all systemd talk?

[gweihir]

Thank, you. Good idea, I will. I also have it on disk, this is something that has evolved over a while. There is something very, very fishy about the whole systemd thong and I am still trying to narrow it down.

Re:Why does John shut down all systemd talk?

[RavenLrD20k]

Ok...I think you're confused here. We're talking about where the global configuration files are going. We're not talking about where the packages or the user's own files are going. What you're talking about, Linux itself has no problem doing. If you want the "more careful" approach, all you have to do is build each package from source, ensuring that you point the $PREFIX environment variable to where you want that package to install. If you want to break FHS, there's nothing in Linux that stops you. When I built my LFS system, $PREFIX was heavily used to direct packages to /usr, /usr/tools, /usr/games, /usr/bin, or wherever else I wanted the package to install to using the ./configure script for the source code before running make.

Global configuration files (what the AC above was actually talking about) , however, you don't generally want to have placed anywhere but /etc. This makes system administration considerably easier because the location of the configuration files are now known across systems.

• Where do I go to disable root from logging in to my box through ssh? /etc/ssh/sshd_config
• Where do I go to change a vhost in apache? /etc/apache2/apache2.conf
• Where do I go to fix an acl problem for my dns server? /etc/bind/named.conf.options

See the pattern? If I need to configure something, I don't need to think through "ok, where did this package install its config? /usr/config? /opt/conf? /svr/<appName>/conf?" All I have to do is know the name of the daemon that needs to be configured and then I can do ls /etc...and there will either be an <appName>.conf file or a directory for <appName>. If it's not <appName> then at the very least it would be <daemonName>. Easier on the Admin which is always a good thing, especially in larger administrative environments.

Re:Why does John shut down all systemd talk?

[fisted]

No, I'm not confused, and as said, I understand how what you want is desirable if all you've ever used is Linux, which seems to be the case, and hence it's probably futile to try and explain why what you're proposing is /not/ generally desirable.

If I need to configure something, I don't need to think through "ok, where did this package install its config? /usr/config? /opt/conf? /svr//conf?"

Please use better straw-men.

Re:Why does John shut down all systemd talk?

[hitmark]

>As cluttered and dated as SysV is at least you don't have to take pieces of it apart to change what flags are being used to call some secondary command at boot time.

And that may be touching on a big issue. sysv en its like was created in an era where you could not easily spin up another server as needed, and doing a full reinstall for a "minor" issue was seen as insanity.

Thus systems that could be fixed in place, with minimal tools, where the order of the day.

Now however we have a generation that has grown up accustomed to doing reinstalls at the drop of a hat, thanks to desktop computers. And their server environment makes heavy use of virtual machines and containerization. Neither of these are conductive towards a mentality of fixing issues in place, never mind making sure they stay fixed.

In essence they are doing service uptime via machinegun, not belt and suspenders engineering. Who cares if a instance crashes, there are 1000s ready to take over, and it will be rebooted in seconds anyways.

Consumerism has reached the server rack...

Re:Why does John shut down all systemd talk?

[Kagetsuki]

Until you framed the context here I actually hadn't realized what the motivation for designing systemd like that could have been. As you've pointed out; while that mentality of hard-coding all these modules into pretty-little uniformly shaped candy shells will be super convient to deploy a few thousand disposable server instances it's going to make any hand-tuning a big pain in the ass.

The fact that one of the "sale points" of systemd is to have these localized initialization modules included in packages just re-inforces your point - and it makes me worry systemd is going to replace any customized modules each time a package is updated. Ugh.

Re:Why does John shut down all systemd talk?

[petrus4]

Unfortunately though, many do not. Said propaganda has been working too well; and the other problem is that most people do not have the psychological strength to avoid caving into it, even if they can see that it is factually false.

Re:Why does John shut down all systemd talk?

[hitmark]

Indeed, the boot aspect of systemd has long since "matured". the feature creep happening now is very much about "cloud" and containerization.

An area that happens to be a stated target market for RH moving forward.

And may be why other distros are adopting systemd, as it is likely to become THE basis for Linux (cloud) servers going forward. Especially when backed by the 800 pound gorilla of the Linux ecosystem.

Yep...

[Lumpy]

Linux is starting to get the "feature creep" crud that is making it a mess. the nice part is we still have some choices to avoid the things we dont like and it will create a split like Linux and BSD but inside linux it's self.

Re:Yep...

[Anonymous Coward]

There was no "Split" between Linux and BSD. BSD (Berkley System Design) was around first. It was UNIX without much of the Bell Labs stuff. So Free UNIX. Linux is NOT UNIX but UNIX like.

Re:Yep...

[fisted]

There was no "Split" between Linux and BSD. BSD (Berkeley Software Distribution) was around first. It was UNIX without much of the Bell Labs stuff. So Free UNIX. Linux is NOT UNIX but UNIX like.

FTFY...

What do you mean, modern?

[Kokuyo]

Look, you can joke all about how I'm just too stupid to use it but the fact is I am an IT professional and I'm not incompetent at what I do. Which means that technical concepts do not leave me in the dust by default.

And yet, every few years when I try to get into the swing of all things Linux, it ends in utter frustration.

Make of that what you will. And when you tell me I am at fault because I am unwilling or incapable of hurdling that learning curve, I will throw back in your face that a good product is also defined by usability considerations.

Linux is a pain in the ass. It is good at a broad variety of tasks, but so are other OSs that make my life less of a living hell.

Re:What do you mean, modern?

[johnlcallaway]

Make of that what you will. And when you tell me I am at fault because I am unwilling or incapable of hurdling that learning curve, I will throw back in your face that a good product is also defined by usability considerations.

HAHAHAHAHAHHAHA!!!!!

When Linux was less 'usable', it was simpler.

Increased usability means more scripts and automation, meaning more things are abstracted.

You can't have it both ways.

I know what the real problem is. I stepped away from Linux/UNIX for about 5 years because of a new job (Went from a Sun/Unix/Oracle shop to a Windows/SQLServer shop). When I got back to Linux, I didn't understand a lot of things, it had changed so much. It took a while to dig into it.

But .. know what??? It was all there. All I had to do was understand how it started up to find all the scripts and then read them. It wasn't that hard.

It just took a little effort. And enough intelligence to actually read scripts and Google things I didn't understand.

If you don't get it .. it is you.

Re:What do you mean, modern?

[cyber-vandal]

Burn the witch!

Re:What do you mean, modern?

[Anonymous Coward]

Simple for the desktop != simple for the admin != simple for the programmer.

Desktop users want to click on a mac'ish interface on obvious icons and do stuff. Make a slide show, print a document, send an email, connect the wireless.

Admins want to quickly understand the state of the system, analyze problems and fix them.

Programmers want hookers, blo and the newest widgets and functions, abstracted to hookers and blo.

These are orthogonal, but they don't have to be contrary. Userland can have a nice interface that does wireless shit while interfacing with simple core functionality. Programmers can have the libraries. They don't have to break each other. However, that's a significant management challenge, which our bazaar model is failing at.

Re:What do you mean, modern?

[jedidiah]

The "abstractions" aren't any easier. They might have the virtue of being better automated WHEN THEY ACTUALLY WORK. Beyond that, they are more complicated and thus LESS usable when something doesn't go precisely to plan.

The "abstractions" do less well when you wander off the reservation and Linux has always been about wandering off the reservation.

Linux is mature enough that people are now trying to fix things that really aren't broken and they are breaking them in the process.

Re:What do you mean, modern?

[Anonymous Coward]

RTFM or Google it most likely someone already has gone thru your issue.
It's not like you have to setup a Beowulf for the CERN.
Linux isn't hard now it isn't 1996 you know....

Re:What do you mean, modern?

[Anonymous Coward]

Linux is difficult to learn, use, and administrate because it lacks consistency.

Re:What do you mean, modern?

[bouldin]

This.

I would personally like to see three flavors of Linux:

Server - lean, NO systemd or plug-and-play crap, focus on security

Desktop - includes whatever bells and whistles people need for a modern, useable desktop; focus on productivity

Mobile - similar to desktop, but with a focus on low power consumption and small screens

I don't need a tablet GUI on my desktop, and I don't need hotplug support for webcams and printers on my server.

Re:What do you mean, modern?

[Kagetsuki]

I'm of the complete opposite opinion but that's just because I'm more used to Linux than Windows or OS X. And I'll call you on the "usability considerations" thing - my father got a Windows 8 box and was completely frustrated with it - I threw Ubuntu on it and he loves it. OS X is the opposite in that it hides so much of the functionality behind a shiny and simple interface it's like being forced to wear mittions for a power user.

Do yourself a favour and put Linux on a machine you use regularly - then actually use it for a few weeks. Don't "try and learn it", just use it. As an IT guy I think you'll start to appreciate some of the amazing stuff you can do with a terminal and how awesome it is to have a package manager with a huge variety of packages just an apt-get away.

Re:What do you mean, modern?

[AmiMoJo]

I'm somewhat the same. I'm okay with Linux now, and BSD, but the learning curve for Linux in particular is a bugger. The filesystem seems to be a mess - people joke about Windows being bad but they mostly fixed that back in Vista, where as Linux still has random config and executable files all over the place.

Part of the problem seems to be Linux's diversity, which is what TFA is complaining about. Say you have no sound. Okay, there are at least three layers where the problem can be. Driver, ALSA and Pluse Audio. Oh, and probably the desktop environment you are using has another layer of controls on top of all that. On other operating systems there is pretty much the driver and the single volume control that the OS provides.

I've recently starting thinking about using Linux on an embedded product at work. It's all very different to desktop Linux though... Everything seems to run on Busybox rather than having the usual shell (well, there are several shells to choose from actually) and there isn't much good documentation out there.

Being modular and flexible is all great, but it does make it hard to learn. I bought a book on BSD and learned it pretty quickly, and its fairly tidy and compact for the most part.

Re:What do you mean, modern?

[Drethon]

For no graphics program development I found linux to be about as easy to use as the PC. I did have to learn a lot of command line stuff but I prefer that to digging through dozens of menus to find what I'm looking for. YMMV.

Re:What do you mean, modern?

[DuckDodgers]

I can - and do - make Linux dance to my tune and I've used it as my only desktop operating system at home for years. But yes, the learning curve was a pain in the neck. 90% of the time, everything installs and works perfectly. 7% of the time, you hit a problem that you can fix with a quick web search and twenty minutes of work. 3% of the time, you hit a headache that requires days of research and trying different things until you solve it or give up and try a different distribution or give up and go back to a proprietary operating system. I probably made a dozen switches to Linux that failed before they finished or only lasted a few months before I acquired enough skill to make the switch permanent.

About once every four or five hours of play, Minecraft crashes for my kids on my Linux machine. The display becomes completely unresponsive. So I have to switch to a virtual terminal or use a remote ssh (or better, mosh) connection into the machine, run "ps aux | grep -i minecraft" to find the processes related to minecraft, and "kill -9 PID" the processes for Minecraft. A full screen crash that hung the entire graphical interface has not happened to me on Windows more than a handful of times since Windows 98. I would never expect a casual user or even a moderately technical one that does not have a lot of Linux experience to be able to deal with this. I think I read somewhere that Wayland (the replacement for the X11 window system that underpins most graphical applications on Linux) has some fundamental design differences with X11 specifically so that a crash or hang of a full screen application can be detected and dealt with inside the graphical interface instead of requiring a switch to a terminal or remote shell.

All of these things can be improved and should be improved. I want to do my part, but work plus kids keep me too busy.

But to the article's original complaint, I think that sounds like the whining of someone who refuses to learn something new. For example, older /etc/fstab files listed disks and partitions like /dev/sda1 (first disk, first partition) and /dev/sdb2 (secon disk, second partition). The newer /etc/fstab files can support that format, but the preferred way to work is to use the UUID (universally unique identifier) of each disk partition. Yes, UUIDs make the file harder to read. Yes, UUIDs take a little more time to set up. But the advantage is that if you add a hard drive, solid state disk, etc... or remove one, it can change the order drives are enumerated to the operating system. If your /etc/fstab has the UUIDs of the partitions then that change is not a problem. If your /etc/fstab has /dev/sda1, /dev/sda2, etc... that change can break your boot process or at least mount some partitions in the wrong place. Likewise, the systemd "journalctl -r" is a new command to learn instead of "tail /var/log/messages". But the systemd journal uses digital hashes to make sure the system log has not been tampered with by a hacker. /var/log/messages has no such security, so the old way is convenient but less safe. Some changes are stupid, and unnecessary. But some are necessary, and useful.

Re:What do you mean, modern?

[Anonymous Coward]

Just the fact that you refer to your self as "an IT professional" marks you as a joke and a charlatan. And frankly speaking, if you think Linux is frustrating and a "living hell", you have never ever had any of these fantastic "good products" with "usability considerations" designed in from the ground up go haywire on you.

Re:What do you mean, modern?

[Anonymous Coward]

You can take off your mittens with the OS X Terminal.

Re:What do you mean, modern?

[dl_sledding]

Well said, and, other than the "Mobile" version (which I have no interest in, so haven't researched), they are already out there in use.

For instance, this is my current life (and this is by NO MEANS comprehensive or complete, or even possibly fit for others!!!):

Server - CentOS: no GUI by default, many choices during install for different server functions, dev and build libs easily available, no real bloat, lean and fast.
Desktop - Mint, Elementary, etc... Each are user-friendly FOR THE USER, including those migrating from Winblows or Mac.

I'm a sysadmin, have been for 20 years, and have always used some form of Linux and as few M$ servers as possible. And we're successful and have a growing body of customers using our servers and services.

HOWEVER, I agree with you in that a distro should firmly recognize and position itself into one of these three flavors (using your syntax), and not try to be all three. It would make selection and use more clear and easy. It would also help those distros become better at what they are trying to accomplish, rather than a "one ring for all" mentality where nothing works as well as it could and should.

That's why I chose CentOS for my servers (as their mentality is SERVER, not desktop or GUI or some other function) and Mint or Ele for desktop (again, they are focusing on an end-user experience, user application stability, and usability, rather than server functionality). I am NOT saying this is right for everyone, just what I have found works perfectly for ME and MY OPERATION. CentOS may not work for some server applications (though, I haven't found that to be true), or there may be something about it that another sysadmin may hate... That's fine, there are other choices. That's the great thing about the Linux universe.

And Mobile fits right in there too: a moble OS GUI should be VERY different from a desktop OS GUI, as Micro$oft has so eloquently proven. No suggestions from me. Though, I carry an Android phone, if anyone cares. :)

The right tool for the job. The Linux distros should embrace this concept, and if it would, the world would be a better place.

Re:What do you mean, modern?

[Anonymous Coward]

"Actually use it" means you can run needed applications on it. Without 'try[ing to] learn' it one might assume (possibly rightly) that the applications they seek are either unavailable, or needlessly complicated to deploy.

When it WORKS, of course, it's fine. Just like Windows, OS/X, and anything else.

Re:What do you mean, modern?

[Ol Olsoc]

Look, you can joke all about how I'm just too stupid to use it but the fact is I am an IT professional and I'm not incompetent at what I do. Which means that technical concepts do not leave me in the dust by default.

And yet, every few years when I try to get into the swing of all things Linux, it ends in utter frustration.

If I were to make a guess, you might be trying to impose Windows on Unix. I don't know for certain, but you do also realize that you are sort of bragging that you have problems with Linux that others don't. Its like when I ask someone a question, and they respond "I don't have a clue what you are talking about" as if their ignorance makes them superior.

Since you are above even helpful criticism, It's hard to know what else to say. Enjoy what you are working with now.

Re:What do you mean, modern?

[Ol Olsoc]

Burn the witch!

She turned me into a newt!

Re:What do you mean, modern?

[Anonymous Coward]

Sounds like you're too stubborn to get help when you get stuck, or maybe you don't have availability to other people who are willing to help you. I work with some very smart technical people, who are great on Windows, but utter rubbish at linux because they're unfamiliar with the OS and it takes a while to learn new things, which as a very smart technical user can be really bruising on the ego, so it's very easy to blame the OS, when it's really just an unfamiliar OS, and unreasonable expectations on yourself. It took me a few years and a couple of tries at linux before it really clicked. For a technical user, I'd really recommend something like Arch or Slackware so that you can really understand how things work together. Things like Ubuntu are great for a novice user, but terrible for an advanced user. It's a real shame as I'm sure you'd really love it if you had the time to learn it. I'd recommend the folks over at Jupiter Broadcasting if you're looking for help. They are an amazing community, with knowledgeable, intelligent, supportive people willing to help out.

Re:What do you mean, modern?

[chihowa]

If you think that OS X constrains you in ways that Unity (ick) on Ubuntu doesn't then it's just because you haven't yet realized that OS X has a terminal, too. OS X is just a fairly standard BSD with a pretty UI. If you were afraid of using the terminal on Linux, like you are on OS X, you'd feel like you were wearing mittens there, too.

I agree with you about Windows, though. The only way to get anything done there is to repeatedly bang your head against it. The Metro tiles are an improvement in that regard!

Re:What do you mean, modern?

[Anonymous Coward]

ALSA and pulse audio on the same system still? Weird. As far as Windows, that's no different than a driver and a codec. Windows definitely has numerous layers you aren't aware of as well, you're just familiar with them and know how to route around them. Speaking as someone who works on multiple OSes every day, it's all about familiarity.

As to BSD, it's an engineered OS versus most other OSes that are organically grown. That engineering is one of the wonderful parts of BSD.

Re:What do you mean, modern?

[bouldin]

I like CentOS too, but CentOS 7 will have systemd for reasons I don't understand.

Here is a page with systemd advantages for CentOS (https://linuxacademy.com/blog/linux/centos-7-take-the-plunge-into-systemd/), and I don't need any of this:

Read Ahead

Socket Based Activation of Service

Device Based Activation of Service (i.e. USB)

System Snapshotting (Virtualization, ZFS, or otherwise

SELinux Full Integration (Kernel level, not service level)

Device Dependency Configuration (udev rules)

Service Respawn without Connectivity Drop

Service SSL Cert/LUKS Password Handling (including Console, wall and Gnome Agents)

Interactive Bootup (Dependency Based with Confirmation of Service Start)

Reliable Termination of User Sessions During Shutown

Earlier BOOT Logging

Re:What do you mean, modern?

[Anonymous Coward]

I think I read somewhere that Wayland (the replacement for the X11 window system that underpins most graphical applications on Linux) has some fundamental design differences with X11 specifically so that a crash or hang of a full screen application can be detected and dealt with inside the graphical interface instead of requiring a switch to a terminal or remote shell.

There's no need for Wayland just for that. You could reenable the "grab_break" option in the xkb configuration (they've disabled it for "security" reasons, because it lets you bypass screen locking screensavers -- who the fuck is using that??), then use xkill(1) or whatever else. And btw, any wm not written by morons will let get out of modal dialog boxes and full screen windows. There's nothing in the "design" of X11 that forces you to suffer through that.

But the systemd journal uses digital hashes to make sure the system log has not been tampered with by a hacker

LOL, I hope it rot13's then the hashes too.

Re:What do you mean, modern?

[Eunuchswear]

For instance, this is my current life (and this is by NO MEANS comprehensive or complete, or even possibly fit for others!!!):

Server - CentOS: no GUI by default, many choices during install for different server functions, dev and build libs easily available, no real bloat, lean and fast.
Desktop - Mint, Elementary, etc... Each are user-friendly FOR THE USER, including those migrating from Winblows or Mac.

Well, for me its:

Server: Debian
Desktop: Debian
Mobile: Debian

(well, I lie, Mobile is Sailfish, but it was Debian (Fremantle) and will be again, I hope).

I see no reason at all to use different distros.

(And, by the way, both Desktop and Mobile use systemd, and Server will, when I get round to upgrading).

Re:What do you mean, modern?

[Anonymous Coward]

3% of the time, you hit a headache that requires days of research and trying different things until you solve it or give up and try a different distribution or give up and go back to a proprietary operating system.

And therein lies the problem: I have a fucking life. I run Redhat Enterprise and Solaris at work (both on fully supported hardware), and MacOS on the home front.

I get that some of our brethren have the time, motivation, and think that it's fun to deal with that three percent, but outside of work (which consumes 40-60 hours a week) I get tired of fucking with this stuff. If I moved from my Mac it would be to FreeBSD or Windows.. sure as hell not to Linux.

Re:What do you mean, modern?

[Anonymous Coward]

Boot up OSX, click LaunchPad, type 'Terminal'. Now click LaunchPad again and type 'Automator'.

If that's too hard for you then you are not a power user.

Re:What do you mean, modern?

[gweihir]

I very much second this. Of course I will put the "Server" variant on my laptop, but that is my decision and _nobody_ has a right to try to take that away from me.

Re:What do you mean, modern?

[dryeo]

On the other hand, when you update to a new hard drive the system breaks as the UUIDs have changed even though / is still on /dev/sda3 or wherever.
Personally, while Linux was fun to learn, I've gotten tired of relearning it regularly.

Re:What do you mean, modern?

[Dragonslicer]

On the other hand, when you update to a new hard drive the system breaks as the UUIDs have changed even though / is still on /dev/sda3 or wherever. Personally, while Linux was fun to learn, I've gotten tired of relearning it regularly.

There's a very good reason for that. You don't want the decision of which partition to mount at / to be based on which disk device responded to probes from the kernel the fastest. As for relearning, the place to change the UUID for the partition that you want mounted at / is /etc/fstab, where it's been for as long as I can remember.

Re:What do you mean, modern?

[Vyse of Arcadia]

One of the things I love about Linux is that there are a gazillion flavors of it. We call them distros, and they span a whole continuum of configurations. My personal preference is for some, but not too many, bells and whistles, and there's a distro for me! The people who want more bells and whistles than me, but who don't want the whole shebang, there's a distro for them too!

Re:What do you mean, modern?

[BronsCon]

I like CentOS too, but CentOS 7 will have systemd for reasons I don't understand.

It's based on RedHat, which now has systemd. CentOS doesn't make decisions, they take RedHat's old packages and release them as the new CentOS, then continue maintaining them with RedHat's current patches. On one hand, some might complain that the packages are old, they're from the previous release of RedHat, while on the other hand, it means that CentOS users haven't had to deal with systemd yet while RedHat users have. The knife cuts both ways.

Re:What do you mean, modern?

[BronsCon]

Linux is mature enough that people are now trying to fix things that really aren't broken and they are breaking them in the process.

On one hand, that means it's well-tested. On the other hand, it means it was well-tested until someone decided the well-tested bits should be replaced for... well... what reason, exactly? Systemd makes BSD look very attractive on the server.

Re:What do you mean, modern?

[BronsCon]

Came here to say this, see that you already did.

Re:What do you mean, modern?

[BronsCon]

The Metro tiles are an improvement in that regard!

Larger targets?

Re:What do you mean, modern?

[BronsCon]

The thing is, while Windows is getting better about this, no doubt in part due to people shouting "Linux does the better than we do and we're losing market share", Linux seems to be getting worse about it, no doubt in part due to people shouting "Windows doesn't care about this and it's not hurting their market share". It's a matter of perspective, and the views of people firmly entrenched in one camp will necessarily be the opposite of the views of those entrenched in the opposing camp. That's not to say that either camp is right or wrong, either; Linux did handle configuration better than Windows and Windows didn't care about keeping the filesystem clean, and both camps made their realizations around the same time and the Windows team set out to fix the problem, while the Linux team set out to create it. So, here we are, with Windows machines now easier to configure than Linux was 5 years ago and Linux machines now more of a pain in the ass than Windows was 5 years ago.

I'm happy for the Windows camp, I really am; they may bitch about their GUI, but things aren't really any better for Linux users, aside fro ma GUI being largely irrelevant to a Linux sysadmin; meanwhile, the Windows admins now seem to have the easier job.

Personally, I jumped to OSX for the desktop about 4 years ago and haven't looked back except when I've needed to test something on Windows or Linux, and I'm more and more tempted to move to BSD for my servers.

Re:What do you mean, modern?

[DuckDodgers]

I'm not an expert in X, so I'll have to lookup "grab_break" and xkb and screen locking screensavers.

With respect to the systemd binary journal, a design document is here: https://docs.google.com/docume... Each entry is digitally signed with the hash of the previous entry. So any attacker that gets root can rewrite an entry, but in order to make the digital signatures pass verification he's got to rewrite the digital signature on the modified log entry and on every log entry from that point forward in time - feasible, but a lot more work than just modifying a text file and then changing the timestamp in a traditional log. and you can use rsyslog alongside journald.

Re:What do you mean, modern?

[userw014]

Burn the witch!

She turned me into a newt!

Another convert to FreeBSD?

Re:What do you mean, modern?

[DuckDodgers]

Of course I understand where you're coming from. I'm practical, too - I run mostly free (as in freedom) software, but I work on proprietary software to pay the mortgage.

But the thing is, by living that way you let Microsoft or Apple control aspects of your digital life that they have no right to touch. Consider that.

You admin Red Hat and Solaris. I'm sure the price premium of proprietary software also isn't a headache for you unless maybe you wanted a private copy of Oracle 11. But for most of the population, $100 for Windows whatever or $400+ for a new machine or $150 for a professional reinstall after they get hit with malware is all a very big deal. I was having budget problems and was making less than half my current income when I got interested in Linux. I could afford to pay the Microsoft or Apple tax now - but thanks to the skills I developed then, I don't need to. I donate some of the difference to Debian and keep the rest.

Every dollar we throw at Microsoft and Apple - and Google, Oracle, etc... - strengthens proprietary software, strengthens the hold of Digital Rights Management, makes it easier for the government to snoop on all of us as a matter of routine, and makes it harder for poor people to get a good computing experience. Every dollar we put into open source strengthens open source software, weakens DRM, weakens privacy invasions, and makes it easier for regular people to have a good technology experience without spending more than they should budget to get it.

Re:What do you mean, modern?

[DuckDodgers]

Nope, because usually when you add a new drive you reinstall Linux. It's free. Anyone who understands enough to transfer the whole filesystem image from one disk to another disk is going to update /etc/fstab manually.

Re:What do you mean, modern?

[Anonymous Coward]

The second part to relearn is that the boot process doesn't really look at /etc/fstab or even obey the boot kernel command-line arguments sometimes but instead gets compiled into an initial ramdisk that at one point had to be regenerated by mkinitrd and later by dracut, and there seem to be a million ways this can go wrong when you want to do something like migrate the storage of an existing system. It is doubly so when involving changes like software RAID, LVM, or partitioning formats.

Re:What do you mean, modern?

[Anonymous Coward]

Original AC here, and I just wanted to say that I agree with you.. so much so in fact that I've just spooled up a CentOS 7 instance in VMware over lunch (I know, not sexy, but as I stated before I do RHEL on the job so it's familiar) to see how much I need to screw with it to operate in my home environment.

You've made me reconsider. With the addition of a couple of repositories it seems to be pretty solid for my use case.

Now, I'm not going to throw my MacBook away just yet (though it's coming), but I am looking into an ASUS Zenbook loaded up with Linux for my next system.

Re:What do you mean, modern?

[Anonymous Coward]

Server - lean, NO systemd or plug-and-play crap, focus on security

Amusing. The first place I installed systemd was on a server, precisely because it did its job well and actually promoted security.

Re:What do you mean, modern?

[Anonymous Coward]

Wut?

~ RHEL

~ Fedora

~ Android

My head hurts.

Re:What do you mean, modern?

[Anonymous Coward]

Shaddap Gingrich. No one cares about you anymore!

Re:What do you mean, modern?

[Ol Olsoc]

Burn the witch!

She turned me into a newt!

Another convert to FreeBSD?

No - I got better.

Re:What do you mean, modern?

[dryeo]

Nope, because usually when you add a new drive you reinstall Linux. It's free.

Only the software is free, getting the ISO often has a cost, especially if for what ever reason you're bandwidth challenged and stuck on dial-up.

Anyone who understands enough to transfer the whole filesystem image from one disk to another disk is going to update /etc/fstab manually.

If they're also maintaining a DOSish dual boot setup then they're careful to maintain the disk/partition order. Also for quite a while, perhaps still, /etc/fstab accepted using /dev/hd?? and then /dev/sd?? fine even though the kernel was looking for a uuid.

Re:What do you mean, modern?

[Aighearach]

It is always a weird progression when an OS-X drone asks me for help with their computer. First they get worried, because I'm mousing over things and not finding anything useful, and swearing, and generally making it obvious I have no clue how to use their type of computer. Then I give up on the solution being easily discoverable, open a terminal, and resort to *nix trouble-shooting. At that point it is smooth sailing, and before long the proper configs had been edited and everything is happy again. And at the end they can't understand how such an idiot can also be a magician.

"Luckily they included a UNIX interface, it's a lot more expert-friendly."

Re:What do you mean, modern?

[Anonymous Coward]

but the fact is I am an IT professional and I'm not incompetent at what I do.

The rest of your post shows that to be a lie. If you can't handle Linux while thousands of other sysadmins can, then you are the problem.

Re:What do you mean, modern?

[bouldin]

Yeah, but RHEL has the systemd suite now (I don't need it on my servers), and both Fedora and Ubuntu have moved towards mobile-oriented GUIs.

Re:What do you mean, modern?

[Anonymous Coward]

The problem is that servers do need plug and play, because the big proper servers have hot swappable hardware.

Re:What do you mean, modern?

[chihowa]

Exactly!

Re:What do you mean, modern?

[david_thornley]

Personally, I like my GUI. It' makes it easy to have plenty of xterms around that I can use with the CLI. This is just my preference, of course.

Re:What do you mean, modern?

[Anonymous Coward]

Not VMs

Re:What do you mean, modern?

[phorm]

Actually, I can agree with this. Where they talk about "fast boot time" benefits of systemd etc, I don't reboot servers often, and the time it takes to boot the OS is a fraction compared to the bloody raid-controller etc doing their checks.

On a desktop, having fast boot and tying things in might be nicer (although I generally would say boot time with an SSD isn't an issue). There's generally less tinkering with the deep internals of the OS than on a server as well.

Re:What do you mean, modern?

[david_thornley]

Every time I've seen an offer of Linux on CD-ROM or DVD-ROM, it's been pretty inexpensive. Moreover, GP said "reinstall". If you keep the install media around, like any sane experienced user, there's no cost to reinstalling.

Re:What do you mean, modern?

[Anonymous Coward]

> Likewise, the systemd "journalctl -r" is a new command

Which is nice since it automatically uses less if you don't pipe the output to another command, but the command is utterly useless since systemd's policy is to throw away start-up errors and most other log messages. Why build a tool to view data when you have a policy against saving the very data you're viewing? That is ridiculously illogical of systemd. People that run Linux servers need syslog and need to see logged messages. We need that. Throwing all of that away makes systemd useless for a real server.

Re:What do you mean, modern?

[DuckDodgers]

I'm running Ubuntu 15.04 alpha and Fedora 21, and /dev/hd?? and /dev/sd?? are still supported. UUIDs are just preferred.

Re:What do you mean, modern?

[Kagetsuki]

The terminal in OS X is OK if you install iterm2 - and in fact when I use OS X it's usually just a full screen terminal. The probelm lies in using the GUI. Aside from the fact that I'm not used to it and honestly don't really like it (and can't switch window managers like I can in Linux) there is a lot of functionality which has been strangely obscured. Case in point is showing hidden files in the finder. Maybe this has been improved since I last did it, but I actually had to modify some setting and restart finder. It seems to me a lot of the mentality in the design is "Grandma could accidentally do something if we let her see/access this. We should hide it.".

Re:What do you mean, modern?

[drinkypoo]

About once every four or five hours of play, Minecraft crashes for my kids on my Linux machine. The display becomes completely unresponsive.

I only have problems on Windows, where the game explodes. It runs faster and more reliably on Linux for me. Are you using ATI graphics by any chance?

Yes, UUIDs make the file harder to read. Yes, UUIDs take a little more time to set up. But the advantage is that if you add a hard drive, solid state disk, etc... or remove one, it can change the order drives are enumerated to the operating system.

There are other mechanisms for doing that, though. You can use labels instead, which are nice and readable. Or you can use udev persistent devices.

I mostly use UUIDs, because they are more unique than labels in many cases...

Re:What do you mean, modern?

[CronoCloud]

both Fedora and Ubuntu have moved towards mobile-oriented GUIs.

Which you don't have to use.

https://spins.fedoraproject.or...

Or of you installed the standard version with gnome 3 you can:

yum group install "Xfce Desktop" or whatever desktop group you want.

Re:What do you mean, modern?

[Anonymous Coward]

Linux is a pain in the ass. It is good at a broad variety of tasks, but so are other OSs that make my life less of a living hell.

Yep. Linux can be the basis of a nice desktop if you're careful with your hardware choices, but for more than that it is a royal PITA.

And yes, it seems to be getting worse, not better, with each iteration.

Re:What do you mean, modern?

[bouldin]

Understood. My point was that these distros do not have a clear focus, purpose, or identity.

From http://www.itworld.com/article/2856604/with-unity-8-ubuntu-will-bring-pure-linux-experience-to-mobile-devices.html

It is evolving from a server/desktop OS to one that will run the same codebase across devices such as TVs, desktops, tablets and smartphones.

I think part of the problem we are seeing is that distros are trying to handle the server, desktop, and mobile markets with one codebase, and, as a result, they are not great at any one them.

Re:What do you mean, modern?

[Anonymous Coward]

> , the systemd "journalctl -r" is a new command to learn instead of "tail /var/log/messages"

Which is fine, but when systemd throws away the most important messages, that makes it useless. The original RFC 3164 (http://tools.ietf.org/html/rfc3164) for syslog defines eight severity levels:

                      0 Emergency: system is unusable
                      1 Alert: action must be taken immediately
                      2 Critical: critical conditions
                      3 Error: error conditions
                      4 Warning: warning conditions
                      5 Notice: normal but significant condition
                      6 Informational: informational messages
                      7 Debug: debug-level messages

As we found after converting a few dozen servers to Red Hat 7, messages with a severity 3 or less are not logged in the journal. That shows a basic misunderstanding of syslog levels. The lower numbers are *more* important. If the creator of systemd doesn't understand something as basic as that, what else are they missing?

Re:What do you mean, modern?

[DuckDodgers]

Are you trolling? I've never heard that the systemd journal discards startup information. I'm seeing everything on my Fedoral install. dmesg looks normal too.

Besides, you can run rsyslog alongside the systemd journal.

Re:What do you mean, modern?

[DuckDodgers]

AMD graphics, yes. With the open source drivers. I understand the drivers have gotten better over time, but I guess they're not up to Windows or Linux nVidia proprietary driver standards.

Re:What do you mean, modern?

[DuckDodgers]

That's bizarre. I'm not a sysadmin, I'm only running Linux on my work laptop and my personal desktop. For Fedora 21, if I do "journalctl -r -o verbose" I'm getting plenty of priority 6 and priority 7 messages in the output.

Anybody else have access to Red Hat 7 to check?

Re:What do you mean, modern?

[chihowa]

I agree about the UI, and I think your guess about their intentions probably falls close to the truth. Once you get used to the quirks, it's not really much better/worse overall than any other UI I've used.

UIs in general seem to suck and seem to be trending worse. Configurability in general is pretty bad across the board. I console myself with the fact that Mac's options are twiddlable through the plists and that they are all in easy to find places.

I can't think of a UI that I've really loved over the years. Those that are nicely configurable seem to be more buggy and unstable, so I grudgingly understand the desire for simplicity.

Re:What do you mean, modern?

[dryeo]

Usually after some time I've done enough apt-get upgrades that the install media is severely out of date along with cleaning the cache due to shortage of disk space.

Re:What do you mean, modern?

[whoever57]

Each entry is digitally signed with the hash of the previous entry. So any attacker that gets root can rewrite an entry, but in order to make the digital signatures pass verification he's got to rewrite the digital signature ....

Or, I could just send the logs to a remote, hardened log server so that an attacker has no way to modify the logs immediately prior to the compromise.

Re:What do you mean, modern?

[Culture20]

CentOS doesn't make decisions, they take RedHat's old packages and release them as the new CentOS

Not exactly. They take RedHat's current sources and edit to remove references to RedHat, then compile and repackage and release as the current CentOS. It just takes them a while to do that. Of course anyone using RHEL probably has been sticking with RHEL6. I tried using RHEL7 but the system I installed it on wouldn't boot with RHEL7. "systemd! systemd!" /Kirk

Re:What do you mean, modern?

[BronsCon]

You're defending it as though I was complaining. I wasn't.

Re:What do you mean, modern?

[CronoCloud]

About once every four or five hours of play, Minecraft crashes for my kids on my Linux machine. The display becomes completely unresponsive.

Are you running any mods and are you using openjdk or Oracle Java?

Re:What do you mean, modern?

[Eunuchswear]

Your VM's don't have swappable hardware? You don't add disks, memory, cpu's to your VM's?

Re:What do you mean, modern?

[Eunuchswear]

It's bizzare -- I've never seen anyone claiming that systemd throws away log messages before, but this slashdot article is full of it, often claiming that it's "policy".

Where is this "policy" described?

Or, if it's not "policy" where are these problems reported as bugs?

Re:What do you mean, modern?

[Eunuchswear]

He's claiming that you don't get any 3, 2, 1, or 0 (error, critical, alert or emergency) messages.

At least on Debian that's just not true.

Re:What do you mean, modern?

[drinkypoo]

AMD graphics, yes. With the open source drivers. I understand the drivers have gotten better over time, but I guess they're not up to Windows or Linux nVidia proprietary driver standards.

Yeah, we recently discussed an article here about how AMD's binary drivers for Linux are also not up to Windows or Linux nVidia proprietary driver standards, either. In fact, they are pretty much garbage. ATI may have nice hardware sometimes, but on Linux, you always get garbage drivers, OSS or not.

It's difficult to imagine this situation ever improving, for two reasons. One, ATI has always had bad drivers, ATI's drivers have been murdering Windows for me since Win 3.1 and the ATI Mach32. Two, AMD has never been serious about their commitment to open source drivers. It's an on again, off again kind of thing for them. They gradually trickle out the information needed to support their cards. They need to get serious either about that, or about their own binary drivers, or both. They never have done. Linux is an afterthought to them. And then there's *BSD support... for nVidia, it's fairly serious. Support is important to them. For ATI (or intel, for that matter) it's a "when-we-get-to-it" kind of thing. They're just not serious or competent.

Re:What do you mean, modern?

[Zontar The Mindless]

Burn the witch!

She turned me into a newt!

But I got better.

Re:What do you mean, modern?

[DuckDodgers]

Thanks for catching my failure at reading comprehension. In any event, that still doesn't match what I'm seeing on Fedora 21. "journalctl -r -o verbose | grep -i 'priority=3' " gives hits, as does grep for priority 2. I'm not getting any hits for 1 or 0, but presumably that's because nothing has gone catastrophically wrong.

Re:What do you mean, modern?

[DuckDodgers]

I have encountered all of that information too. However, the situation has been improving. I can't say how much of that improvement is due to AMD and how much is due to open source developers that are good at reverse engineering. http://www.phoronix.com/scan.p... Also, I had those Minecraft crashes on Ubuntu 14.04, 14.10, and 15.04 alpha - that article I linked has kernel 3.18 (same as Ubuntu 15.04 alpha), Mesa 10.5-devel (15.04 alpha has 10.4.something), and open source radeon driver 7.4.99 (15.04 has 7.4.0). Maybe if I compiled my own driver and mesa I would get better stability, but I can't be sure.

I'm an AMD fan from way back because of the monopoly tricks Intel pulled in the late 1990s early 2000s ( https://en.wikipedia.org/wiki/.... ) - I figure Intel has the money and resources to put towards open source today because of the advantage they unfairly gained due to tricks then.

Re:What do you mean, modern?

[DuckDodgers]

You can also do that with the systemd journal. Where's the problem?

Re:What do you mean, modern?

[DuckDodgers]

Good luck. If you're familiar with Red Hat and CentOS, then Fedora may work too. I have Ubuntu on one machine and Fedora on another. I like a lot of Linux distributions, but I try to use the most mainstream ones so that if a casual Linux user among my friends or family has a question, I have up to date experience with something close to their setup.

Re:What do you mean, modern?

[Eunuchswear]

Yup, it works correctly on Debian too -- everything that goes to syslog gets into the journal.

I've been making an effort to find some kind of confirmation or source for these "systemd doesn't log by policy" claims, which, AFAIK are the opposite of the truth (systemd/journald catch output to stdout/stderr that used to get lost).

So far the only one I've been able to get a handle on is the "mysql didn't start and there was no info in the journal" one, which appears to be because the default mysql config writes error messages to a file in /var/log instead of to syslog.

How is systemd/journald supposed to know that it should put the contents of random disk files in the journal?

Re:What do you mean, modern?

[whoever57]

You can also do that with the systemd journal. Where's the problem?

That systemd's journaling log is not required for security, thus removing one more justification for the use of systemd.

Re:What do you mean, modern?

[drinkypoo]

I'm an AMD fan from way back because of the monopoly tricks Intel pulled in the late 1990s early 2000s

I've been using AMD processors almost exclusively since the K6/2 came out. I think since then I've bought two intel processors new, a P55c and a P2-400. Since then, any intel chips I've got have come in something cheap and used, and even most of those have been AMD chips.

I've been pissed off at ATI for the poor state of their drivers for decades, and I will not mess with their video cards until they make a truly serious effort to replace all the user-facing portions of the driver completely with lean, mean, native code with functional GUIs — to say nothing of ceasing treating non-Windows operating systems like afterthoughts. I don't care if it's called part of AMD now, AFAICT it's the same old ATI.

I won't pretend that I've never had a problem with an nVidia card, I've been using them since the TNT and have owned a card from every third generation or so ever since, plus a few. But the problems have been nothing in comparison to the ATI graphics, and they tend to actually get fixed — and in good time, too.

My current system has an AMD 1045T, an AMD chipset, an nVidia 450GTS and is about to get a 750Ti. And it works well for both Windows 7 and Linux. I'm relatively little money into it and it has all the goodies save for Blu-ray...

Re:What do you mean, modern?

[ookaze]

I would personally like to see three flavors of Linux:

Server - lean, NO systemd or plug-and-play crap, focus on security

So you will need systemd on your servers, especially if you want focus on security. The Linux kernel provides dynamic interfaces since a long time, and no one in userspace provided the tools to cope with it until systemd. Devices was done with udev and its predecessor devfs, but init was unable to cope with it before systemd, despite higher level tools trying to cope with the linux kernel dynamic nature.

Re:What do you mean, modern?

[Anonymous Coward]

What dynamic interfaces do you mean?

I run servers without sysd today and have no problems.

Re:What do you mean, modern?

[Anonymous Coward]

You can't hotplug CPU cores. I don't think you can hotplug RAM, either.

When we add hardware to a VM, we reboot it in a maintenance window. It's really not a big deal.

The only use case I've seen for hotswapping hardware on a server is replacing a failed disk in a physical machine. Most of the servers I use these days are in an ESX cluster, so there is literally no need for hotswapping or plug&playing anything.

Re:What do you mean, modern?

[dl_sledding]

And like I said, isn't the Linux universe great?

I haven't tried Debian, though I should as it's been around *forever* and is very well known for it's stability. But you know what it's like: you start using something that's familiar and get in a rut. And time is precious. So looking into something different becomes difficult.

Maybe a Debian New Year's Resolution...

Re:What do you mean, modern?

[Anonymous Coward]

I use /dev/disk/by-label/... in my fstab. Same advantage as UUID without the disadvantage.

My USB flash drives are labeled by colour or something, unless they have some prominent logo or something else. So there's nothing stopping me from just typing "mount silver", which is near enough as fast as automounting itself.

Re:What do you mean, modern?

[Anonymous Coward]

> the default mysql config writes error messages to a file

Are all of the systemd shills childish liars? That is not the default configuration for MySQL community edition from Oracle. The word error doesn't even appear in /etc/my.cnf. Just admit that the creator of systemd is too young to comprehend the concepts of stderr and logging levels. I know for damn sure that output to stderr does not make it into the journal.

Just found a very nice script that proves the problem:

http://linux.slashdot.org/comments.pl?sid=6953777&cid=49039657

I ran it on a "CentOS Linux release 7.0.1406 (Core)" system, and systemd threw away both the stdout and stderr messages. It also failed to detect the nonzero exit status. That shows a fundamental lack of understanding of what we need to start and control services. The service *did not start* but systemctl returned a zero.

Re:What do you mean, modern?

[Eunuchswear]

> the default mysql config writes error messages to a file

Are all of the systemd shills childish liars? That is not the default configuration for MySQL community edition from Oracle. The word error doesn't even appear in /etc/my.cnf.

# apt-get install mysql-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libdbd-mysql-perl libdbi-perl libhtml-template-perl libterm-readkey-perl
  mysql-client-5.5 mysql-server-5.5 mysql-server-core-5.5
[...]
Setting up libhtml-template-perl (2.95-1) ...
Setting up mysql-server (5.5.40-1) ...
# grep error /etc/mysql/my.cnf
log_error = /var/log/mysql/error.log

Why are anti systemd people so quick to accuse others of things like being "childish liars"?

Just found a very nice script that proves the problem:

http://linux.slashdot.org/comments.pl?sid=6953777&cid=49039657

Well, I just tried that example on Debian sid and it worked for me.

http://linux.slashdot.org/comments.pl?sid=6953777&cid=49041613

So there is no evidence that "systemd shills are liars", just that Centos is a buggy piece of shit.

Re:What do you mean, modern?

[Anonymous Coward]

You have just described Windows 10...

Re:What do you mean, modern?

[DuckDodgers]

No mods, openjdk. Someone else pointed out elsewhere that the problem may be the open source AMD drivers.

Re:What do you mean, modern?

[DuckDodgers]

I have a 1055T (not trying to one-up you) and a Radeon 5770. It worked fine for Windows 7 when I had it, but I had bought Win7 retail so when my wife's Windows XP install croaked I bought an SSD for her machine and put the Win7 install on that, and since then I've run Linux full time.

Re:What do you mean, modern?

[Anonymous Coward]

> I've never seen anyone claiming that systemd throws away log messages before,

You're either a liar or haven't been paying attention. Throwing away all messages for level 3(error) and below has been a problem for a while. Instead of talking about solutions, the systemd guys have been attacking and banning people from the mailing list. They're acting like spoiled children. They simply don't understand that professionals that manage servers need syslog. On my newest web server:

journalctl -p 0..3 | wc
                        1 15 85

There is *nothing* logged at levels 0 through 3, inclusive. systemd throws them away. For the less important messages:

journalctl -p 4..6 | wc
  234429 4006245 41530495

systemd doesn't throw those away, but in general, they're the messages we don't care about. This is a huge security problem that systemd has created.

Re:What do you mean, modern?

[thegarbz]

You're not abstracting enough.

Are you saying you don't need to hotplug a webcam on a server, or are you saying you don't need to hotplug at all? That was one of Linux's most incredible features from back 20 years ago, you could hot plug everything, in some cases even the CPU. That was a killer server feature it supports. The difference between hotplugging a network interface and hotplugging a USB stick are incredibly minor.

You are literally throwing out one of the biggest features of Linux in the server market simply because you now think that Plug-and-play and hot-plugging equates to using a webcam.

A desktop is nothing more than a server with a GUI. All the same features apply. Desktops still have advanced RAID management, servers still need support for plug and play. In many cases most actually benefit with a supporting GUI, and productivity is not something reserved for the receptionist, but also system admins too.

Mobile ... I agree there. That is a very different beast.

Re:What do you mean, modern?

[CronoCloud]

openjdk

Mojang recommends Oracle Java. Personally I think it runs somewhat better with Oracle Java than openjdk.

the problem may be the open source AMD drivers

Ouch, yeah use the proprietary driver.

Re:What do you mean, modern?

[Anonymous Coward]

> Centos is a buggy piece of shit.

Lennart Poettering is paid to work on it full time. He is the creator of this mess, and he is the one that is not fixing it. CentOS is the most reliable distribution wrt systemd, because Poettering works on it. It is his number one priority. If it is "a buggy piece of shit," as you admit, then the other distributions are even worse because they don't have Poettering's full time help. He is the asshole that refuses to fix what he is responsible for. He is the reason this garbage has spiraled out of control and is hurting Linux in the data center. The simple fact that he doesn't grok the concepts of stderr, exit statuses, or syslog is proven by the fact that he has not fixed CentOS despite receiving a nice pay check for doing so. He apparently hates Linux and wants to destroy it. He has done more to harm Linux in the past five years than even Microsoft has. That is probably his exit strategy. Do what Miguel de Icaza did which is to screw us all over then accept a big check from Microsoft. This Lennart guy appears just as dishonest.

Are you sure you were running Linux?

[xxxJonBoyxxx]

>> it was simple; only two pieces to fit together

To me, the Linux experience has been based around the use of simple, command-line oriented tools that could be easily scripted together. That's the opposite of "only two pieces fit together" - just like Legos you have thousands of pieces that could fit together to make billions of different things.

Re:Are you sure you were running Linux?

[Anonymous Coward]

To me, the Linux experience has been based around the use of simple, command-line oriented tools that could be easily scripted together.

Scripts have a huge execution overhead (each of those command line tools have to be forked separately), they are slow to parse, and they break easily. The risk of security vulnerabilities is also high, as data and commands are mixed. For example when the shell expands a wildcard and someone creates a file called "-rf", you know what can happen. Or when the Shellshock vulnerability made the DHCP client script vulnerable. Then there are the problems of spaces in filenames breaking things, and so on.

Re:Are you sure you were running Linux?

[ckatko]

So scripts are bad because people write bad scripts? Interesting. C must be bad because there is code that has buffer overruns.

And as for execution overhead? Who cares. 99% of people are bandwidth or disk limited. Why does it matter if updating my Linux distribution takes 60 seconds instead of 30, if it means the developers can get the job done. If using something better requires a developer to work harder, they'll just not do the work at all. And in 4 years, when my computer is more than twice as fast as it was before, it'll take 15 seconds anyway.

You're acting like optimization is more important than serviceability.

Re:Are you sure you were running Linux?

[Anonymous Coward]

So scripts are bad because people write bad scripts? Interesting. C must be bad because there is code that has buffer overruns.

Yep, exactly. They both are a tool which allow you to shoot yourself in the foot easily.

Why does it matter if updating my Linux distribution takes 60 seconds instead of 30

Because then the updating happens twice as fast, which is a fantastic improvement.

Sounds like someone is getting old...

[Anonymous Coward]

You can always tell when lines like "it used to be", "there was a time", and "I remember when" are used. Things change, and when software changes it typically gets more complex. Just take REO Speedwagon's advice and roll with the changes!

Re:Sounds like someone is getting old...

[johnlcallaway]

It's not the getting old part. It's the last part. Time passes, things change. Those unwilling to learn will be left behind.

I'm 55 and don't have a problem digging in and learning new shit. I gave up COBOL a couple of decades ago. Could still write it if I had to, but I didn't hang onto it like the last piece of chocolate cake.

In 2025, everyone whining about how hard Linux is will be regarded the same as COBOL programmers are today.

And stuck working on old shit that nobody else wants to touch.

Re:Sounds like someone is getting old...

[Anonymous Coward]

I remember when there was a time that it used to be that one thing Linux used to be noted for was its ability to run well on obsolete hardware with limited resources of processing and memory. I don't hear that anymore. Has that changed?

Ironically, the last time I heard that was before the emergence of single-board hobby computers like the Raspberry Pi and Arduino. Even so, those have vast resources compared to the machines that Linux ran on years ago, back in the day, in the good ol' days.

Re:Sounds like someone is getting old...

[Drinking Bleach]

It still does, so long as you're selective of the software you run on it. You could run a totally modern kernel and X.org (or Wayland) on an original Pentium with 32MB of RAM, but in no way should you expect to run GNOME or LibreOffice or Chrome or Firefox on it, at least not without glacial loading times.

But more frequently, PCs from 10-15 years ago still in service just aren't that starved on resources anymore. They'll chug along slowly, but they can still get the job done, and nobody is really surprised when they're capable of it. Hell, if you have half a gig of RAM, you can probably still run full GNOME and LibreOffice and all without major issues.

Re:Sounds like someone is getting old...

[Eunuchswear]

I'm 55

Newb.

Re:Sounds like someone is getting old...

[aaaaaaargh!]

Things change, and when software changes it typically gets more complex.

That's the principal flaw of modern software development. Instead of fixing bugs features are piled up.

Yep

[ArchieBunker]

The answer is BSD. Try it, you'll love it. Great documentation, testing before features go live, UNIX philosophy still alive, the list goes on...

Re:Yep

[Anonymous Coward]

No commercial packages, no commercial support. No drivers, and those they get they pilfer from Linux. Utterly broken sleep/resume despite ACPI being a billion years old. IRC channels dead or full of supercilious twats, aggressive mailing list. The list goes on...

Re: Yep

[Anonymous Coward]

I totally agree. switched to BSD across the board and never looked back. it is a breath of fresh air. I really like openbsd but I've found that hardware support is best on machines that are like 1-2 years old. their documentation is just amazing too. FreeBSD is really nice too and seems faster although I haven't done very serious benchmarking yet. I just find that compared to Linux I can really understand the entire system which makes me more confident that I'm securing the system properly. with Linux I always seem to have a nagging doubt that I've forgotten to lock something down.

Re:Yep

[jfbilodeau]

I second that!

Re:Yep

[ctrl-alt-canc]

Totally agree. BSD is to Linux just like internet is to ham radio.

Re:Yep

[jones_supa]

At this point moving to BSD would indeed be a breath of fresh air for the open source software community. A lot of the classic UNIX goodness is still there but also plenty of modern features. There's now also PC-BSD for those who want to get a desktop running quickly.

Re:Yep

[Anonymous Coward]

Tried it with the recent PC-BSD 10.1 release, fails to install on a Zotac AD-04 with an obscure log message. While not State of the Art the ad-04 is not ancient crap either.

Complex and SLOW

[Anonymous Coward]

After 15 years of Linux only, I went Windows 8.1 PRO with Cygwin for bash, ssh, some python, and Vagrant for my development needs. Maybe overkill but I can assure that this combination is FASTER than Ubuntu 14.04 on the same box (14.10 is a complete disaster, at least from the virtualization point of view).

Re:Complex and SLOW

[jfbilodeau]

The keyword in here might be 'Ubuntu'. I've never found Ubuntu to be particularly fast.

But honestly, if you going through the effort of installing/using bash, ssh, python, on Windows, how much are you relying on the GUI?

Re:Complex and SLOW

[Anonymous Coward]

I'll up your Windows/Cygwin setup with Slackware.. now watch my tail lights.

Re:Complex and SLOW

[Anonymous Coward]

The desktops are slow indeed. I can run Windows 10 Technical Preview smoothly with all candy turned on with the same hardware that I use for Xfce.

Re:Complex and SLOW

[guruevi]

I'm happy you're not working for me and not developing real software then.

I've used Cygwin (or at least tried to) and Python on Windows. You're missing a hell of a lot of things there that are crucial for development and relying on VisualC to not screw you over.

Re:Complex and SLOW

[gweihir]

You may have missed that this person is obviously not developing Windows software.

Perspective

[MikeRT]

Traditionally, one could twiddle who could mount devices via /etc/fstab lines and perhaps some sudo rules. Granted, you had to know where to look, but when you did, it was simple; only two pieces to fit together. I've even spent time figuring out where to look and STILL have no idea what to do.

On the other hands, mounting USB storage "just works" now on Linux.

Re:Perspective

[Anonymous Coward]

Only on the command line. If you read the article, he says that on the desktop he could not use a digital camera anymore because he just got an ambiguous "not authorized to perform operation" message because something had broken.

Re:Perspective

[jedidiah]

USB storage has "just worked" on Linux for a very long time now. Whatever has been added recently to "fix it" clearly isn't making it better. Meanwhile, it's also more complex apparently.

Again, Linux has gotten mature enough that things that really aren't broken are being fixed by bored children that need some sort of distraction.

Re:Perspective

[Anonymous Coward]

why has it not worked before? I have never had a problem ever mounting a usb device? mount /dev/blah /mnt ?

Re:Perspective

[Twinbee]

Slow hand clap?

Re:Perspective

[YoopDaDum]

Tempest in a tea pot really: I had the very same issue with Jessie and a little googling around quickly found the issue and a solution (for example here: https://lists.debian.org/debia...).

In short, if one installs (installed?) Debian Jessie from a USB key the installer would add an entry in /etc/fstab for the key. Now the automounting of USB keys for the currently logged user is normally taken care of by udev, who does things properly. But for backward compatibility if there's a /etc/fstab entry udev bows out and let the legacy system handle the key, and that's where one end-up with a USB key mounted as root instead of as the user. Fix: remove the useless /etc/fstab entry. As this has been discussed already on the Debian user mailing list it's likely been fixed in the install process by now (not check, will try with a new laptop next week).

All in all: a small installation process glitch in the testing distribution, so still beta. But let's not waste such an opportunity to rant on how much the old times were betters, and young ones are hopeless. I guess the real issue is that early Linux users (me included) are getting older, and more adverse to changes.

Re:Perspective

[Anonymous Coward]

Not sure if you're being sarcastic here... "just works" in this context certainly implies automounting without the need to type any commands. Plug it in, and a file-browser pops up.

Re:Perspective

[Dragonslicer]

For some people, "just works" is something that only belongs in operating systems from Microsoft and Apple.

Re:Perspective

[pavon]

Well it was a little more than that. For some months automounting of USB drives was broken for any combination of X11 display manager and window manager except GDM and gnome 3 because the systemd udev apparently handles that stuff differently than the old udev.

And this is why people get upset about systemd. I actually like the idea of systemd as a boot manager. Elimination of pointless boiler-plate demon scripts, better exposure of all sorts of cool kernel process management features, and using filehandles activity to manage the order in which daemons are launched (rather than explicit declaration of daemon dependencies), dovetails very nicely with the unix philosophy that everything is a file.

But it has becoming a sprawling feature creep monster, and I don't like that. I don't like that the developers put on false airs about how they aren't forcing you to use the other 68 daemons under the systemd umbrella, while making design decisions that make it next to impossible for distros to deploy anything but an all-or-nothing solution. I don't like how they are unilaterally making compatibility breaking system level decisions that affect everyone without giving adequate consideration to the rest of the ecosystem. That sort of attitude and approach is only going to cause more problems in the future, not less, which makes me very wary of getting on the systemd train, even though I like the technical core.

Like you said, this is a beta distrubution so as a user I'm not upset that it was broken for a while. I'm upset at the undue upheaval that one project is having on the entire Linux ecosystem.

Re:Perspective

[Anonymous Coward]

Spot on.

I've recently decided to stop complaining about systemd and just ripped it out of my archlinux install, replaced udev with eudev, written a simple init in ruby (reaps children, respawns a few gettys, and initiates either /etc/rc or /etc/rc.shutdown, handles the signals/syscalls for reboot/halt/poweroff, no runlevels). The deamon start/stop scripts are added from crux, slackware, wherever i find something that works. Removable media is now again automounted by some simple udev rules (which worked for years before systemd somehow silently made them stop working). Added back dcron and syslogd, went back to building linux from /usr/src/linux, wihtout an initramfs and even without modules, went back to trusty old lilo. This is all pretty simple and bareboned, but it's all i actually need on this machine.

My system has become so incredibly simple again, it's outright boring. Maybe it's just too boring nowadays to keep things simple.

Re:Perspective

[Zontar The Mindless]

Eh? My Linux machines have been auto-mounting USB storage devices without issue for about ten years now.

Oblig. XKCD

[Anonymous Coward]

Oblig. XKCD: http://xkcd.com/927/

Re:Oblig. XKCD

[DuckDodgers]

I know that post, but while I think he has a point, I also think it's too defeatist. If everyone took that attitude, nothing would ever get done.

Re:Oblig. XKCD

[Anonymous Coward]

It is only defeatist in the sense that if you don't think about what you are doing then don't expect to be successful at changing things. The issue is not progress or creating new frameworks & standards, but people who make them without thinking about the various possible reasons why there are so many different ones already in place.

Re:Oblig. XKCD

[Anonymous Coward]

There is also the infinitely restless human desire to screw with things and change them even when they work just fine. I know that's how improvement comes about, but reflection and patience would be good virtues to practice. Yes, the bleeding edge.

Re:Oblig. XKCD

[DuckDodgers]

Well, if you take the first panel of that comic there are two possibilities, right? The first possibility is that one or more of the existing standards has a design adequate to address the technical problem it tries to solve, and the people in the panel should throw their weight behind one of those. In that case, creating a new standard is counter-productive. The second possibility is that all thirteen competing standards are inadequate and a new attempt is required. In that case, creating a new standard is the right thing to do.

Re: Oblig. XKCD

[Anonymous Coward]

Exactly. The real problem is so many half-baked "standards." I run into that problem with incredible frequency. I think that's part of the reason that so many job postings these days list 20 different frameworks as requirements. Coupled with even lousier developers who can't do anything without a framework, it's a perfect storm of failure.

Re:Oblig. XKCD

[Anonymous Coward]

You're creating a false dichotomy though. It is possible that none of the competing standards are adequate, but people create a new standard for the wrong reasons. Some people are motivated to create new standards or solutions simply motivated by, "There are too many standards, we need to unify them," without actually addressing the inadequacies. That seems to be the attitude the comic is addressing (whether intentional or not), not that we shouldn't ever make new standards.

Re: Oblig. XKCD

[thebrieze]

It's more complicated than that. There is lot of inertia for existing users and applications to move to a new standard. Sometimes there are very good practical reasons why this is the case. If there is a critical mass of users/applications that are on the old standard, it will remain a standard and continue to develop, even if the new one is better/more complete. This very often explains how you got to 14 competing standards to begin with..

Re:Oblig. XKCD

[DuckDodgers]

Thanks for the correction. You're right, and I didn't allow for that possibility.

Re:Oblig. XKCD

[Anonymous Coward]

And the standard that wins will be the one in a program that will load all other standards, but will only save in their own.

Re:Oblig. XKCD

[Anonymous Coward]

> The second possibility is that all thirteen competing standards are inadequate and a new attempt is required. In that case, creating a new standard is the right thing to do.

No, the solution to 13 inadequate standards isn't to create a 14th that is even worse! That is completely idiotic, and the panel is about that many people that can't get it into their head that creating yet another piece of shit doesn't solve the problem of having too much shit!
Creating a new standard is still absolutely wrong in that situation unless you are reasonably sure that you manage to do _significantly_ better (and not just because you think you are so great but because you have the expertise and support from enough others with sufficient expertise).
Otherwise you're just contributing with throwing things at the wall and see what sticks.

Re:Oblig. XKCD

[DuckDodgers]

The Anonymous Coward a few posts back pointed that out to me already. I forgot the third possibility - that my fourteenth standard is at best no better than the best of the thirteen others and I have just made the situation worse. You and he or she are correct about that, and I'm sorry I didn't include it in my list of options.

Re:Oblig. XKCD

[allquixotic]

In addition to what AC said, there's another possibility. Even if the design of an existing solution is adequate to solve the problem, and even if someone isn't looking to create another standard simply to try to unify the existing standards, there are still an enormous number of *non-technical* reasons why something might not be desirable.

For one thing, there will always be license purists who insist that absolutely everything in their favorite distribution comply with their specific license of choice. The two biggest offenders are the all-GPL camp and the all-BSD camp, but there are probably others too. Even if they evaluated an existing solution purely on its technical merits and determined it to be superior, they'd still have a motivation to start their own project because Licensing Matters. Licensing matters at least a little to most people, but it's the #1 priority for some people. If those some people also have programming skill, they'll start their own project.

There are also other non-licensing issues that could come up. Maybe the primary maintainer of foo project requires Contributor License Agreements, and soandso thinks that CLAs are the work of the devil. They don't want to fork it (even if the license allows it) because they think it would result in too much infighting between the communities. So they go and start their own project.

One thing that seems to help is to abstract away *specifications* from *implementations*. This works marvelously in the case of the networking stack (from IP to TCP to HTTP), USB device classes, etc. Implementations are free to license under the GPL, BSD, whatever they want. As long as the interfaces between your widget and the other components of the software ecosystem are standard and consistent, people are happy to write their own implementation if they want a specific license. But you don't suffer from the proliferation problem when you have multiple conforming implementations, because the compatibility issues can be ironed out to be very minor with the right level of cooperation and standardization.

It's a wonder we have standards that are established as they are (like HTTP), given the number of reasons people use to justify proliferation.

Your agreement or disagreement with their justifications, such as the examples I gave above, depends on where you stand on the axis of pragmatism or purism with regards to the issue at hand. But regardless of your opinion, that doesn't change the fact that people nonetheless will use these reasons to fork, and hence, proliferation continues apace.

Re:Oblig. XKCD

[Anonymous Coward]

If it is obligitory you don't have to point it out you fucking numbnuts retard

Re:Oblig. XKCD

[DuckDodgers]

Good point. I did mean to include that under the inferior and inadequate solutions options, but of course it does complicate things because finding a technical solution that works that also has your preferred combination of license and contributor license agreement is much harder than just creating a technical solution that works.

Re:Oblig. XKCD

[Anonymous Coward]

If everyone took that attitude, nothing would ever get done.

I'm fine watching the grass grow. I'm fine with you cutting the grass if you need to get things done.
Stay off my lawn.

Re: Oblig. XKCD

[Anonymous Coward]

Derp.

Software entropy

[seven of five]

The more complex the system, the more potentially undesirable states you have.
Undesirable states take work to remove.
Human efforts being imperfect, undesirable states appear spontaneously and accumulate over time, requiring further work.

Modern?

[Anonymous Coward]

Haha! He used 'Modern' and 'Linux' in the same sentence without a 'not'...

Just one step closer to becoming Windows

[QuietLagoon]

As an occasional user of both Windows and Linux, I used to see a significant difference between the two. The clarity of Linux, the fog of Windows.

.
But now Linux seems to be getting closer to fog than clarity.

One example:

Last week I installed opensuse. When I tried to send an email using the mail command, Postfix was giving me odd permission errors for maildrop. So I went to look at the Postfix log, and there was none that I could find.

One step closer to the fog of Windows, where the system is hidden behind magical portals that only a few know how to access....

Re:Just one step closer to becoming Windows

[jones_supa]

Control Panel -> System and Security -> View event logs

That thing is actually nice to use and gives very descriptive and precise log messages of what happens under hood.

Re:Just one step closer to becoming Windows

[Barsteward]

Whats your issue here? Did you not find the log file ( /var/log/mail ) or was postfix configured not to log?

Re:Just one step closer to becoming Windows

[DuckDodgers]

It's open source, though. So the information is available somewhere and it's never a violation of a EULA to make use of it.

I think the problem you hit is poor documentation - and that's almost always a major weakness of open source software that we the users need to work on.

Re:Just one step closer to becoming Windows

[neurovish]

Control Panel -> System and Security -> View event logs

That thing is actually nice to use and gives very descriptive and precise log messages of what happens under hood.

...exactly his point.

Re:Just one step closer to becoming Windows

[QuietLagoon]

Control Panel -> System and Security -> View event logs

I see no such menu structure in either opensuse or Windows 7.

Re:Just one step closer to becoming Windows

[jfbilodeau]

I LOVE the Windows' event log. Messages are short and precise. Messages such as: The operation failed: HRESULT 0xFF0SUX2BU

Re:Just one step closer to becoming Windows

[QuietLagoon]

The problem is that Linux used to be better than Windows in this area, the opposite of what you assert.

Re:Just one step closer to becoming Windows

[QuietLagoon]

Whats your issue here? Did you not find the log file ( /var/log/mail ) or was postfix configured not to log?

I did not see /var/log/mail nor did I even see /var/log/messages.

When I went into opensuse's Control Center, and drilled down to view the system log, I got an error message that /var/log/messages could not be found.

Fog.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

Woosh

Re:Just one step closer to becoming Windows

[Anonymous Coward]

It's likely that certain piece of sh.. I mean software decided that it's the only one who is allowed to have access to /dev/log if you want to boot your system. After all, who wouldn't want binary log files?

Re:Just one step closer to becoming Windows

[duke_cheetah2003]

Last week I installed opensuse. When I tried to send an email using the mail command, Postfix was giving me odd permission errors for maildrop. So I went to look at the Postfix log, and there was none that I could find.

cd /var/log
ls
USE YOUR EYEBALLS.

Re:Just one step closer to becoming Windows

[QuietLagoon]

Last week I installed opensuse. When I tried to send an email using the mail command, Postfix was giving me odd permission errors for maildrop. So I went to look at the Postfix log, and there was none that I could find.

cd /var/log

ls

USE YOUR EYEBALLS.

I did. The log files were not present in /var/log.

Even opensuse's System log viewer could not find /var/log/messages

Re:Just one step closer to becoming Windows

[nine-times]

And then you look up that error message, and oh, "0xFF0SUX2BU" is the error code indicating that "the operation failed for some reason."

Re:Just one step closer to becoming Windows

[geantvert]

No! that is an error code that indicates a bug in the decimal to hexadecimal conversion code.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

No! that is an error code that indicates a bug in the decimal to hexadecimal conversion code.

And 20 results from web forums, half of which show up because someone just dumped the entire logfile even though you're having a hard drive issue and someone else's game doesn't work...

...and the other half of which are morons saying "u may have a virus!" (whereupon the thread devolves into OP saying "No, I know the system is clean, I can replicate the result on a fresh install" and fellow morons saying "how u know unless u run virus scan? when my system no work is always becauz virus!"

Re:Just one step closer to becoming Windows

[Dragonslicer]

Sounds like a problem specifically with OpenSuSE then. The only times I can remember not having log files in /var/log were when there wasn't any disk space available.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

If you believe the event log viewer is even vaguely comparable to what Linux/UNIX applications typically log, then you've never really admin'd a Linux box.

I can walk through every line in an init script, running them manually. Once I find the piece that's broken, even if it doesn't output a helpful error message, which is rare, I can strace it and find out exactly what it's trying to do when it breaks. Worst case, I can recompile it with debugging symbols and step through it with a debugger because, tada, I always have the source.

It's no surprise that Windows admins' answers to all problems is "reboot", followed by "reinstall". Because their tools don't let them actually do any troubleshooting.

Re:Just one step closer to becoming Windows

[ahodgson]

Recent versions of systemd have hijacked syslog. I don't know about opensuse, but on Gentoo I had to go and tell systemd to send me my logs back to a real syslog daemon.

Re:Just one step closer to becoming Windows

[DuckDodgers]

It was? When? I've been using since 2001.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

It seems that your understanding on Windows administration isn't on that solid ground either.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

Yeah, you just have to be okay with monkey clicking around a GUI.

Re:Just one step closer to becoming Windows

[jones_supa]

Ya think?

How about typing this in PowerShell: get-eventlog -logname system -newest 10

Re:Just one step closer to becoming Windows

[Anonymous Coward]

And systemd trashes that concept by not logging all messages! syslog was great. System V init scripts were great. If something failed, you saw it in your terminal. Also, most daemons logged to syslog so you could look at /var/log/messages to find the problem. systemd hides all of that. For example:

# systemctl start mysqld

Outputs nothing in my terminal, but MySQL fails to load. "journalctl -u mysqld" returns:

-- Logs begin at Sun 2015-02-01 10:49:18 UTC, end at Wed 2015-02-11 21:01:45 UTC. --
Feb 08 04:12:57 redhattest systemd[1]: Starting SYSV: MySQL database server....
Feb 08 04:12:59 redhattest mysqld[31582]: MySQL Daemon failed to start.
Feb 08 04:12:59 redhattest mysqld[31582]: Starting mysqld: [FAILED]
Feb 08 04:12:59 redhattest systemd[1]: mysqld.service: control process exited, code=exited status=1
Feb 08 04:12:59 redhattest systemd[1]: Failed to start SYSV: MySQL database server..
Feb 08 04:12:59 redhattest systemd[1]: Unit mysqld.service entered failed state.

It didn't start, and systemctl returned an incorrrect 0 exit status! It also didn't warn that MySQL didn't start. Notice the journal doesn't contain the reason MySQL didn't start. systemd throws away log messages we need. The error was that /var/lib/mysql/ibdata1 was owned by user root instead of mysql. Running mysqld_safe by hand output the error message, and that allowed me to fix the problem. Using just systemd, I could not fix the problem.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

we the users need to work on.

Screw you. I don't want to work on documentation. Just because there is no monetary cost associated with the software doesn't mean you can charge me in other ways. You fucking do it.

Re:Just one step closer to becoming Windows

[DuckDodgers]

s/we the users/we the people who want open source software to be more popular and are willing to work to that effect/

I didn't mean to imply users are expected or forced to contribute. I meant that fans - and I consider myself a fan - that want this to be more popular should contribute because it will help that goal. Happy now?

Re:Just one step closer to becoming Windows

[Kabukiwookie]

Yes, looking up error codes in in a manual. That brings be back to the 90s.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

> But now Linux seems to be getting closer to fog than clarity.

And systemd creates fog by swallowing and hiding stdout, stderr, and syslog messages from daemons. It makes it impossible to troubleshoot start-up issues.

Re:Just one step closer to becoming Windows

[shutdown -p now]

Well, have you tried turning it off and on again?

Re:Just one step closer to becoming Windows

[bemymonkey]

Hahaha, every time someone posts with, "I had problem X in distro Y", someone else posts, "that's a problem with distro Y, try distro Z!"

And you wonder why people just fuck off back to Windows after the first few snags... :D

Re:Just one step closer to becoming Windows

[Zontar The Mindless]

This is an OpenSUSE 13.2 system I'm using, and it definitely has a /var/log/messages, a /var/log/mail, and all the other stuff you'd normally expect to see in /var/log..

Re:Just one step closer to becoming Windows

[Eunuchswear]

Well I just tried that on Debian, and the problem wasn't that systemd threw away any log messages, the problem was that the default mysql configuration writes its error messages to /var/log/mysql/error.log rather than the journal.

Removing "log_error = /var/log/mysql/error.log" from the mysql configuration gets exactlt what you want:

# systemctl start mysql
Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.
# systemctl -l status mysql.service
* mysql.service - LSB: Start and stop the mysql database server daemon
  Loaded: loaded (/etc/init.d/mysql)
  Active: failed (Result: exit-code) since Thu 2015-02-12 15:38:55 CET; 42s ago
  Process: 2633 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
  Process: 5482 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
 
Feb 12 15:38:25 celtic mysqld[5839]: 150212 15:38:25 InnoDB: Operating system error number 13 in a file operation.
Feb 12 15:38:25 celtic mysqld[5839]: InnoDB: The error means mysqld does not have the access rights to
Feb 12 15:38:25 celtic mysqld[5839]: InnoDB: the directory.
Feb 12 15:38:25 celtic mysqld[5839]: InnoDB: File name ./ibdata1
Feb 12 15:38:25 celtic mysqld[5839]: InnoDB: File operation call: 'open'.
Feb 12 15:38:25 celtic mysqld[5839]: InnoDB: Cannot continue operation.
Feb 12 15:38:55 celtic mysql[5482]: Starting MySQL database server: mysqld. failed!
Feb 12 15:38:55 celtic systemd[1]: mysql.service: control process exited, code=exited status=1
Feb 12 15:38:55 celtic systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
Feb 12 15:38:55 celtic systemd[1]: Unit mysql.service entered failed state.

I can't see how a crappy mysql configuration is systemd's fault.

Re:Just one step closer to becoming Windows

[Anonymous Coward]

default mysql configuration writes its error messages to /var/log/mysql/error.log rather than the journal.

Nice troubleshooting on your part. Also, it's nice to get a level-headed response from a systemd guy rather than the typical childish personal attacks and/or stream of obscenities. One of the guys on the mailing list even found my wife on Facebook and sent her threats. /etc/redhat-release contains "CentOS Linux release 7.0.1406 (Core)". The MySQL version is mysql-community-server-5.6.23-2.el6.x86_64. The string "error" doesn't appear anywhere in /etc/my.cnf. There is no /var/log/mysql/error.log file. The problem is not with the configuration. It is, as I have found with more than a dozen other services, with systemd. It throws away the log messages and ignores nonzero exit statuses. The kids that created it simply do not have the experience to understand why these concepts are so important to UNIX.

Re:Just one step closer to becoming Windows

[buchanmilne]

systemctl status postfix # will show the last 10 log entries for the service, along with all the other useful information
journalctl -f # tail all logs
journalctl -b /usr/lib64/postfix/pickup # show just the logs for this boot of the postfix pickup binary

These are a few examples from a different distro, so you'll have to use totally different commands and log file names ... oh wait, with systemd you don't need to do that, you can always easily find the logs unlike before where each distro configured it's chosen default logging daemon differently by default.

It looks like you haven't even bothered to read anything about systemd, and it's not like you have an excuse:
$ rpm -qd systemd|grep man|wc -l
291

A good place to start is probably 'man systemd'

Re:Just one step closer to becoming Windows

[buchanmilne]

Really? I find it easier to troubleshoot, as you can easily find the logs for any service (e.g. foo):
systemctl status foo

Re:Just one step closer to becoming Windows

[Anonymous Coward]

You're missing the point that systemd doesn't log everything into the journal. These old UNIX guys think that the concepts of exit codes and stderr are still important. As the wildfire success of systemd has proven, they're no longer important. systemd throwing away of messages is not a problem. No one really cares.

Here's great instructions for reproducing what the GP described:

http://www.reddit.com/r/linux/comments/2vnaea/reactions_to_has_modern_linux_lost_its_way_and/cojfrmh

I think that poster there stole that from the systemd mailing list, because I remember seeing it. That person was insulted by the list and the problem ignored, as it should be.

Linux???

[Big Hairy Ian]

It's just Fluffeh Unix

That's all user space.

[tlambert]

That's all user space.

Honestly, I thought this was going to be a kernel rant, and I came loaded for bear: there's a lot that needs fixed about the Linux kernel and the processes and relationships between stakeholders.

But let's address the subject of the blog post instead, because there's a lot of fodder there too.

Everything complained about in the blog post is not a Linux problem, it's a Linux distribution problem, since the distributions are what add the user space components that are doing things like automatically mounting his phone so that something else in user space can't talk to the second control channel on the USB interface (because the phone uses the primary command channel to switch to the second command channel, and it's in use by the mount).

This is basically the problem you are going to face on a distribution without an overall architectural design for the user/kernel interaction, and interaction between user space components that allow for layered access.

For the "It's a camera! It's a phone! It's a mass storage device!" problem, I don't have a specific answer; I'll note that uugetty solved the contention for typed use of a resource problem for modems ("It's an inbound modem! It's an outbound modem!") in the 1980's in HoneyDanBer UUCP. And they did it by having an integrated model that all the consumers used. IT's called a layered approach to software development.

I think the big driver for user space problems is that a lot of Open Source people believe that *their* program is the most important thing your computer can possibly be running, and if it interferes with someone else's use of something, so what? The computer is still performing it's *most* important function, which is to run *their* work product.

Even Apple is not immune from these problems; there are third party phone tools that can do nifty things with pretty much any cell phone and come with all sorts of USB cable ends that plug into this USB cable adapter, but the OS grabs the phones out from under the software, and you have to hack the device ID list in a plist to get it to work like it's supposed to (then iPhoto, etc., can no longer see the phone). But at least on Apple systems, there's one place to go to to fix it, the fix is well known, and when Apple is informed of the problem, they generally fix their software to "get out of the way" (or tell the third party how to do it temporarily so their software will work).

What's really missing for Linux distributions, honestly is...

(1) An architect with a holistic vision
(2) A project manager for the components
(3) Productization - people in Open Source only want to work on fun stuff, not on boring stuff that makes stuff actually usable
(4) Usability engineering
(5) Interface contracts which don't change over time
(6) A way to shunt third party installed software (i.e. "apt get", etc. stuff) off into an isolated hierarchy so it doesn't screw with normal operation
(7) Documentation that doesn't have to change over time ...in other words, if you want it to look like a commercial OS distribution, you have to approach it as one. And that's not happening.

Re:That's all user space.

[Anonymous Coward]

(1) An architect with a holistic vision
(2) A project manager for the components
(3) Productization - people in Open Source only want to work on fun stuff, not on boring stuff that makes stuff actually usable
(4) Usability engineering
(5) Interface contracts which don't change over time
(6) A way to shunt third party installed software (i.e. "apt get", etc. stuff) off into an isolated hierarchy so it doesn't screw with normal operation
(7) Documentation that doesn't have to change over time ...in other words, if you want it to look like a commercial OS distribution, you have to approach it as one. And that's not happening.

Sounds like Lennart Poettering's political program.

Re:That's all user space.

[Anonymous Coward]

Skip all those steps.
(8) Write code!
I think that one might happen.

Re:That's all user space.

[Anonymous Coward]

(1) An architect with a holistic vision
(2) A project manager for the components
(3) Productization - people in Open Source only want to work on fun stuff, not on boring stuff that makes stuff actually usable
(4) Usability engineering
(5) Interface contracts which don't change over time
(6) A way to shunt third party installed software (i.e. "apt get", etc. stuff) off into an isolated hierarchy so it doesn't screw with normal operation
(7) Documentation that doesn't have to change over time

Yes, this is my general thought as well: the complexity and disorder is a natural result of welcoming lots of hobbyist contributors. The orderly form it had in the past was a legacy of BSD's cathedral development at CSRG.

I guess, if you want that, you can still use BSD. I'm not sure orderliness is incompatible with hobbyist developers, but you need a project like Linux to serve as a moth-light for the flightier developers so you can develop BSD over in the corner away from their spaz. However, the spazzy developers do actual useful work, and the corporate developers paid to work on the biggest ecosystem aestetics be damned do work as well, meaning that BSD has too many performance shortfalls and concrete feature deficiencies compared to Linux, and it's too frustrating that fun weird languages don't run on BSD, or run but in degraded mode (Erlang, Rust https://mail.mozilla.org/pipermail/rust-dev/2012-February/001399.html ).

Maybe there's a way to get the best of both worlds through a strict form of container spec that runs on both BSD and Linux. Already we can get pretty far by emulating syscalls, and if we designed a container with fewer, better-chosen syscalls exported to it "emulation" for a large class of programs could be good enough that there'd be no such thing as "native," just many working implementations of the container with similarly-sized sets of bugs. See the Dune paper from Stanford for how such a container might look.

  http://www.scs.stanford.edu/~dm/home/papers/belay:dune.pdf

Such a future wouldn't feel like traditional Unix, but it could let you take individual server-side programs from Linux and run them on BSD without "degraded mode" penalty, and without the BSD packaging side spending all their time working around linuxspaz rototilling things for no reason as they now do, which would be a way to win back simplicity if you're willing to give up Linux kernel features. It could also be a way to toss out most of the Linux userland on servers, so the spaz would be contained to the "linux on the desktop" and "phone OS" crowds which many of us can safely ignore, yet the corporate-sponsored performance work targeted at the largest ecosystem would still go to the kernel the complexity-haters get to use.

Re:That's all user space.

[Anonymous Coward]

Sounds like Lennart Poettering's political program.

Maybe he's the wrong guy for the job. The job is much needed though and I would mod the granparent up if it wasn't already 5.

Re:That's all user space.

[Anonymous Coward]

What's really missing for Linux distributions, honestly is...

(1) An architect with a holistic vision

Are you related to Poeettering? Or perhaps a PR guy of his?

Re:That's all user space.

[Anonymous Coward]

[golf claps] Spot on! I nominate you for the position mentioned in either #1 or #2 in your list. :)

Re:That's all user space.

[Zontar The Mindless]

(7) Documentation that doesn't have to change over time ...in other words, if you want it to look like a commercial OS distribution, you have to approach it as one. And that's not happening.

As one of the maintainers of the docs for a commercially-supported Open Source product, I'd like to inform you that this is one of the funniest things I've read all week.

Some clarification for the recently arrived.

[nimbius]

In case you're recently joining us in Linux after a long hiatus, or are coming from the sanity that is BSD, its worth clarifying a few points and I as a formal neckbeard am here to help

The kids: this has been a problem since Subversion but it rears its ugly head now and again with the sun mircosystems crowd that insists the network is the system. These kids dont want to be bothered by man pages or perldoc, so instead they ship a stub with a reference to their CSS/HTML5/Web 5.0 project discovery special snowflake site. The page includes a full colour mascot, links to all the social sites for the project, and videos of the latest con/talk/pep speech the kid with the most pogs/pokemon badges for the project gave with ample references to cats, cheeseburgers, and memes. Loading it up in links gets you a neat scrabble game. Let me be clear: linking your webpage in the absence of man is a waste of time. it is literally the Unix ethos equivalent of "check out my mixtape"

2. The god damn pottering man:
Hes controversially steamrolled most major distros into giving up everything from competent init scripts to non binary logs and even the bootloader in favour of 1 single process capable of doing everything, forever. The backlash was delayed but as of recent, its been pretty consistent. The root of the problem is new developers with a raging hardon for Apple design philosophy. At its peak, this madness turned gnome into a screaming hell-mouth of fades, pans, jiggles, wiggles, and performance tests for even the beefiest video cards. Everything comes with a widget now, and even the console eats 30 megs of ram. configuring gnome or kde with simple text files is now totally impossible, because modern developers have created a MacOS UI managed by a Windows XP system of registry values and control touples. What we gained from this is a frustrating ecosystem of security-questionable user switching and a network stack thats controlled by the user with the mouse. Perfect if you're about to load up team fortress, but crazier than a shithouse rat if you need to, say, run a production firewall.

that having been said ive had enough and you should too. Come join Gentoo, or Arch, or any BSD with more sanity than Unity (Ubuntu.) Gain back that big goose egg we all remember as freedom 0: to run the application the way you want. And on behalf of the POSIX community, the Unix geezers and the hackers, get these goddamned kids off my lawn.

Re:Some clarification for the recently arrived.

[Noryungi]

Just as I was warming up to your rant...

Gentoo? Oh, please, bitch. Gentoo is for ricers. Period. I have better things to do with my time than to compile every single shitty utility on my system. That's what a distro is for. Oh, and Gentoo can be systemd'ed as well. Read it and weep.

Arch? Uses systemd. Don't believe me? Click here or click here. Arch is the Gentoo of the 2000s.

You have no idea what you are talking about. I would be tempted to add a STFU or two, but I am just too lazy.

Re:Some clarification for the recently arrived.

[Meneth]

Arch has had systemd since 2012, and was one of the distros that received negative comments in TFA.

Re:Some clarification for the recently arrived.

[Barsteward]

"2. The god damn pottering man: Hes controversially steamrolled most major distros into giving up everything from competent init scripts to non binary logs and even the bootloader in favour of 1 single process capable of doing everything, forever. " - Poettrering steamrollered the major distros????? i've got a tin foil hat for sale, you sounds like you need a double layer version.

Re:Some clarification for the recently arrived.

[JBMcB]

Gentoo? Oh, please, bitch. Gentoo is for ricers. Period.

And NASDAQ.

I have better things to do with my time than to compile every single shitty utility on my system.

emerge pciutils

Whoo boy what a pain.

Gentoo can be systemd'ed as well

But it doesn't have to be. Your choice. Or do you run Linux so the distro can tell you how your system is to be run?

Arch is the Gentoo of the 2000s.

You mean 2010s?

Re:Some clarification for the recently arrived.

[Anonymous Coward]

he knows everything he is talking about. you don't know what you are talking about.

Re:Some clarification for the recently arrived.

[DuckDodgers]

I agree on your first point, and would add that if your application runs on the command line then you will increase your chance of popular use and recommendations by a factor of ten by giving useful error messages and ending with "for more information, run 'man foo'" so that a complete newbie gets help.

On your second point, I emphatically disagree. Read Poettering's blog, starting with "Rethinking Pid 1", then "Biggest Systemd Myths". The backlash against systemd is 90% people who don't even understand systemd and have been too lazy to RTFM and 10% people who understand the technical tradeoffs and think differently, all spurred on by Slashdot, Phoronix, and a dozen other sites making a mint off the advertising revenue from people visiting the flame war. And the documentation for systemd, both at the official website and from the man pages, is outstanding.

Re:Some clarification for the recently arrived.

[neurovish]

Just as I was warming up to your rant...

Gentoo? Oh, please, bitch. Gentoo is for ricers. Period. I have better things to do with my time than to compile every single shitty utility on my system. That's what a distro is for. Oh, and Gentoo can be systemd'ed as well. Read it and weep.

I think you just made nimbius's point for him. Sure, you can systemd gentoo, but you don't have to. From the gentoo wiki page that you linked, at the very top: "It is supported in Gentoo as an alternate init system."

This is how Linux was. If you didn't like the way something worked, you used something else instead. Unlike the large distros that are moving more towards "here is all your crap", love it or leave it.

Re:Some clarification for the recently arrived.

[snarfies]

Arch and its derivatives use SystemD too.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

I wondered how long it would take for one of Pottering boys to show up denying the debian CTTE coup...

Re:Some clarification for the recently arrived.

[hansbogert]

You do know that Arch has welcomed SystemD with open arms right? And KDE and Gnome are not linux. That said, I use Awesome window manager, but sometimes I do wonder if it's really worth the hassle reading man pages and googling for answers if I only want to change some trivial setting. I'm at a point I no longer have the feeling of accomplishment when I've spent 10 minutes what a GUI could've done in 10s. Should this GUI have a text backend? Yes please! But atm, that's the case in KDE as far as I know. Furthermore init is also always running, forever, what's the difference? Don't come up with "Yeah but Systemd has a friggin' network manager", true, but it's in its own process. The remark about the bootloader and SystemD.. I didn't get that, but sounds interesting, link?

Re:Some clarification for the recently arrived.

[Eunuchswear]

The backlash against systemd is 90% people who don't even understand systemd and have been too lazy to RTFM and 10% people who understand the technical tradeoffs and think differently, all spurred on by Slashdot, Phoronix, and a dozen other sites making a mint off the advertising revenue from people visiting the flame war

And the guy that thinks feminists are stopping him banging 14 year old girls like god intended.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

On your second point, I emphatically disagree. Read Poettering's blog, starting with "Rethinking Pid 1", then "Biggest Systemd Myths". The backlash against systemd is 90% people who don't even understand systemd and have been too lazy to RTFM and 10% people who understand the technical tradeoffs and think differently...

SysVinit has worked exceptionally well at least since 1999, if not earlier, with GNU/Linux. Why must we be forced to SystemD? I prefer the simplicity of shell scripts and text log files rather than the binary blob that is the Microsoft Windows Event Viewer come to GNU/Linux. Debian used to stand for purity and simplicity. Today the distribution's development team are drunken rioters wielding barbed clubs against anyone opposing their Dear Leader Poettering.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

> non binary logs

That doesn't bother me. You can always pipe the output from journalctl to grep. The bigger problem is their policy against logging all messages. It makes troubleshooting very difficult especially with a distro like Red Hat that uses SELinux. In just the past week I've gone through hell trying to get MySQL, MongoDB, and fail2ban to work with systemd, because it does not log the reasons each of those failed to start. For example, MongoDB has a lock file under /var/log/mongo/*.lock that you have to delete to get it to start after a crash. systemd swallows that log message so you don't have any clue why it didn't start. I had to use strace and go through tens of thousands of lines of output. With fail2ban, the version on EPEL is very broken wrt to SELinux, and it requires a lot of configuration to get it to work. With systemd blocking the audit logs, there's no way to create the rules to get it to run without making guesses. Again, I had to disable SELinux and go through thousands of lines of strace logs to try to guess the rules needed.

Why is systemd's policy to hide the log messages we need? Why lie?

Re:Some clarification for the recently arrived.

[Eunuchswear]

I think you just made nimbius's point for him. Sure, you can systemd gentoo, but you don't have to. From the gentoo wiki page that you linked, at the very top: "It is supported in Gentoo as an alternate init system."

This is how Linux was. If you didn't like the way something worked, you used something else instead. Unlike the large distros that are moving more towards "here is all your crap", love it or leave it.

You mean like Debian, where systemd is the default init system, not the only init system?

Re:Some clarification for the recently arrived.

[gweihir]

And that is perfectly fine. If somebody wants to run systemd, I have no issue with that. I have a ton of issues with me being forced to run systemd or else switch distros or be stuck with an old release. On a recent test-install of Gentoo, I also noticed that I know all that stuff they describe step-by step in the set-up manual anyways, so when Debian wheezy-lts (if there is an LTS) gets too unusable, I will move.

The only thing new to me was the config system, but putting "sys-apps/systemd" into "/etc/portage/package.mask/vade_retro_satana" is really not that hard.

Re:Some clarification for the recently arrived.

[Eunuchswear]

Tha's bizzare. Exactlty what log messages were missing? Got any source for a "policy" about not logging some messages?

Re:Some clarification for the recently arrived.

[gweihir]

Thank you and fuck you too. And besides, if even 10% of the criticism on systemd is by people that actually have a clue, then it is a massive catastrophe in the making.

Re:Some clarification for the recently arrived.

[Eravnrekaree]

Having a text only log and configuration is not necessarily better in all cases, in some cases indexed/binary is better, but, it shouldnt be an either or type thing. People who use the logging and configuration should be able to choose which to use. In some cases, an indexed log and configuration system can make configuration settings more accessible programmatically, allowing for system administrators to write scripts if needed for these things, lets say if they are configuring a large number of systems. Text based utilites can easily access the database anyway for human access. Binary configuration db can in some cases provide for better performance because it is indexed, instead of having to scan the whole file for one value, it uses a b-tree or hash.

Re:Some clarification for the recently arrived.

[Eunuchswear]

have a ton of issues with me being forced to run systemd or else switch distros or be stuck with an old release

So run Jessie without systemd.

Where's the problem?

Re:Some clarification for the recently arrived.

[Eravnrekaree]

I want to point out that systemd does not take away your capability to use traditional Unix init scripts, these can be easily configured to be spawned by systemd. If you want init scripts, just disable your stuff from starting in systemd's own facilities and move it to your own init scripts. Problem solved. It is odd that people who think that systemd providing additional functionality is taking away something from other people. The fact is, it does not. As for the "single process" issue, that I believes refers to the cron like functionality in systemd. If you really want cron in a seperate process, you can do that by simply starting a seperate cron program and having your cron jobs run by that rather than systemd. Systemd does not preclude you from using other programs for certain functionality. Its not like "now that systemd provides X functionality I MUST use systemd for that!".

Re:Some clarification for the recently arrived.

[jafac]

IMO: it is the "major distros" (ie. We'll just call it "RedHat" and "Ubuntu" for now. . . ); who have been poor stewards of what are actually very influential segments of the Linux market. Spreadsheet jockeys who were clearly not "technical" - at these companies, made these decisions. To the detriment of the entire community. These guys are invested in their quarterly bonus check. Not the overall success or failure of Linux. They have their corporate accounts, with money rolling in. Like Microsoft, and sorta like Apple. They give no fucks about the people who actually use the system.

I don't see Pottering as the problem. Unless he has a mind-control ray that works on the fat fucks at RedHat and Canonical. Or; unless he's an NSA plant, and RedHat is paid-off by the US Government, and Canonical paid off by GHCQ. And while that's wildly speculative and crazy sounding, I think that at it's root, the problem with Systemd, is that admins and developers do not TRUST that Systemd is their tool. It's a Tool that's foisted on them by the vendor - and bundled with all the other "free" stuff they were used to getting. In that regard, this is really the quintissential RMS argument. But then again, I think RMS's advice was that everyone should be running BSD anyway. Fuk da man.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

policy against logging all messages.

That is an understatement! systemd doesn't just not log all. It almost always doesn't log the important message you need for troubleshooting.

I've been working on scripting server setups with Vagrant, and more often than not systemd doesn't log the reason something fails. It also hides the stderr output! With Red Hat 6, I created about two dozen Vagrantfile setups in a week. With Red Hat 7 and troubleshooting blind because of systemd, it has taken me nearly six week to upgrade those configs. Think about that. Working around systemd's hiding of logging and console message has caused it to take six times longer to upgrade a set of scripts than it took to write them in the first place. Hiding the reason something doesn't start and refusing to log it is just evil.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

The backlash against systemd is 90% people who don't even understand systemd and have been too lazy to RTFM and 10% people who understand the technical tradeoffs and think differently...

I prefer the simplicity of shell scripts and text log files rather than the binary blob that is the Microsoft Windows Event Viewer come to GNU/Linux.

It is simple to run init scripts from systemd and simple to forward logging to syslog. Those two hangups are easily worked around with 5 minutes of Googling. You sound like part of GP's 90%. Note that I personally have some misgivings regarding systemd's design, and I think it would have been best to keep it optional until it was more mature, but in practice I haven't had any problems with it.

Re:Some clarification for the recently arrived.

[DuckDodgers]

I didn't say 10% were people with legitimate complaints, I said 10% were people who understood the tradeoffs. A tradeoff implies advantages as well as disadvantages. So it's not the end of the world.

Re:Some clarification for the recently arrived.

[DuckDodgers]

You're one of the people who didn't actually read any of the systemd documentation. Why should I waste my time responding to you? But because I'm stupid, here it goes:

1. FreeBSD, OS X, and Solaris have all moved on from SysV init. Do you think they did that because it was fun? Because they felt like it? Or maybe because there were design flaws and maintenance headaches in SysV init that needed to be addressed?

2. You can run the systemd journal alongside rsyslog. And the journalctl command for getting text output from the systemd journal takes all of twenty minutes to learn.

3. Systemd services are written in C by convention with text configuration files. But you can run any executable you want as a systemd service: shell scripts, C++, Perl, Java, Lisp, Ruby, COBOL.

Come back and raise an objection after you RTFM.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

I salute you sir

Re:Some clarification for the recently arrived.

[Anonymous Coward]

You're right. Poettering didn't steamroller the major distros. Red Hat did. And poettering is the bitch that they've used to do it

Re:Some clarification for the recently arrived.

[Anonymous Coward]

Why do you call it bizzare when the entire point of systemd is to hide needed information from users? Lennart Poettering has said many times that he thinks syslog is an out of date concept and that is why he has worked so hard to destroy it.

It's an absolute and utter pain in the ass to try to maintain servers running systemd. We've converted about 5% of our nearly four thousand servers to Red Hat 7 and systemd. The amount of man hours it takes to wrestle the config on a systemd server is many times what it takes on a system with a real logger like Greg Wettstein's sysklogd or the newer rsyslogd. Hiding the information we need to maintain our servers, from our point of view, looks malicious. It appears that the systemd guys are trying to hurt Linux.

Re:Some clarification for the recently arrived.

[silas_moeckel]

OK I'll bite I understand the "tradeoffs" and nothing is rather useful for a server. All the activation based bits sound great for a laptop or even a desktop but are useless on a production server. A prod server should not be running piles of things ssh, a config engine (chef,puppet whatever) and the app. If your app is some ugly pile of services on one box fix it. Take a standard web server stack firewall/IDS, LB, Webserver and DB throw in fast and "slow" object storage, nosql and back end services nothing should be running more than a handful of things.

Lets not even get started into activation based vm start-up. VM players have been trying to sell the whole spool up more web servers during high demand and then reuse that capacity for other things bit for a long time now. It looks great in a PR bit from a sales guy

Sure RH went with it for rhel7 they are are pushing a deskop pretty hard. It's not that it's bad for servers it's just not really bringing anything to the table.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

Tha's bizzare. Exactlty what log messages were missing?

Huh? That's systemd's policy. I've setup hundreds of CentOS 7 servers for customers since last Sept, and I can't remember ever seeing a start-up error in the systemd journal. It simply throws away the messages administrators need to do our job. Between installing packages from EPEL, trying to keep SELinux enabled, and trying to copy configurations from old systems, I have to do a lot of troubleshooting of service starts. I have to run them by hand from the command line to see the errors. systemd hides stdout and stderr. It does not log either. It also swallows syslog start-up messages so you can't find them. You have to start daemons by hand and use strace to see what is being logged since systemd throws that information away. systemd is obviously made for end-users that don't care about daemons or logging.

Re:Some clarification for the recently arrived.

[DuckDodgers]

Sure it is useful on the server. In no particular order:

1. The journal digitally signs each entry with the entry contents and the hash of the previous entry, so that for an attacker to insert a spoofed entry or remove a valid one they have to alter the signature on every entry after that point or else the signature mismatch will be detected. And you can still also send logs to rsyslog if you want.

2. Faster boot time does matter for a server - when you need to move physical boxes, add hardware that requires a power cycle, and so forth less time to restart is helpful.

3. You don't need to run "piles of things" with systemd. It's modular, so you only need to compile in the services you want. http://freedesktop.org/wiki/So...

4. Systemd lets you set limits on resource usage by each service: memory limits, CPU limits, Block IO limits, etc... which is useful on the server.

5. On-demand socket-driven service start is useful, so ssh is available 100% of the time but sshd isn't actually consuming resources until it receives a connection attempt.

6. Per-service private /tmp directories, configurable read-only access to some directories, so a hacked service can't access information it should not or make invalid writes.

7. Because of the use of cgroups in the Linux kernel, when you halt a service you can be confident there are no uncleaned resources - threads, forked processes, file handles, etc... left in use.

8. systemd is compatible with services written in any programming language you want, including shell scripts, so you don't have to rewrite your custom SysV init service in systemd. Just spent a few hours in the documentation to make the text file you need, and you're set.

Re:Some clarification for the recently arrived.

[drinkypoo]

1. FreeBSD, OS X, and Solaris have all moved on from SysV init.

heh. FreeBSD has moved on from System V init? heh heh heh.

SMF and launchd are hated, reviled, cursed, et cetera.

You can run the systemd journal alongside rsyslog.

No, rsyslog is a second-class citizen to journald.

And the journalctl command for getting text output from the systemd journal takes all of twenty minutes to learn.

And if something goes wrong with that command, I'm up shit creek.

Re:Some clarification for the recently arrived.

[silas_moeckel]

1 Logs on the server why? Already have real time logging to a different host.

2 If boot times are an issue you failed to build it correctly.

3 same with init

4 Systemd just keys into existing kernel bits, i'ts not providing anything new.

5 SSH and SNMP idle memory/cpu use is trivial balanced against with starting them up every time. I'll take a long running process vs startup time.

6 Again already in existence, it makes it easier to setup but no added function.

7 Yet again nothing new.

8 Init shell scripts are hard? Been writing them for 25+ years. Systemd probably no harder or easier so it's a moot point.

Re:Some clarification for the recently arrived.

[Anonymous Coward]

I wondered how long it would take for one of the liars to show up putting the debian CTTE mythos...

Re:Some clarification for the recently arrived.

[Anonymous Coward]

No, rsyslog is a first-class citizen to journald. It works according to purpose for those who need it.

Re:Some clarification for the recently arrived.

[DuckDodgers]

1. systemctl-journal-gatewayd sends the digitally signed logs over https to another machine, same thing with all of the digital signing and security benefits.

2. Faster never hurts. There's no extra money made by waiting longer.

3. You wrote "A prod server should not be running piles of things". My point is with systemd you don't have to. I never said init did not also fit that criteria.

4. Sure. But it makes it easier. Just a few text file entries.

5. No, as far as I understand systemd socket activation the startup cost is incurred once on the first request, then after that the process keeps running. So best possible combination.

6. Again, less work to set all of this up. Just a text file.

7. Again, less work to get this feature. With systemd, you get this with "systemctl restart foo.service". No extra commands in every single init script for every single service to make sure all resources are closed down.

8. And you can keep writing them. systemd is compatible with init scripts. So what's the drawback?

Re:Some clarification for the recently arrived.

[silas_moeckel]

1 If you don't understand why https is a very poor replacement for syslog over a network that may well be unreliable. I will assume your not really familiar with low level hardware and the failure modes. You do not seem to get the overhead and delay of TCP connections in general and thus why it's a poor choice for logging.

2 Well when your billing T&M there is :), point is reboots should occur so infrequently it does not matter.

3 again no advantage.

4 In your opinion it makes things easier. One text file vs a text file in /etc/sysconfig read in from an init script whats the advantage? Frankly it's just a different templates for the same set of variables in configuration management system, no new functionality is being exposed.

5 So I start SSH and SNMP a few seconds later since the monitoring system is checking them on a regular basis? I'm not seeing any advantage for a server, if your running a service your monitoring a service.

6 Work to setup? Maybe if your just getting started. All this stuff is already been baked into config management systems. systemd just means reworking all that into systemd speak with no great advantage.

7 Outside of service upgrades if I have to restart a service it's broken and needs to be fixed, be that by the vendors or rolling our own if necessary. This is not windows if you have to restart it's broken (mind you I have the same opinion of windows services). So pretty much if you need this your fixing the wrong issue.

8 Systemd fails to give an advantage that is the drawback, something that is new that adds nothing useful in an of itself.

Were just going round and round, systemd fails to do anything new and useful for servers. The pressure to migrate comes from the OS vendors with lots of work and debugging required to get in parity with the current state. So it's effort and time without any improvement for a shop that is already competent and utilizing modern tools. I get that it's got a lot of advantages for laptop/desktops it's just not compelling to server admins. It really should have been an option for rhel7 rather than the default, it's a boon to integration consultants for sure.

Re:Some clarification for the recently arrived.

[Barsteward]

you'd better buy a tin foil hat as well

Re:Some clarification for the recently arrived.

[Barsteward]

if thats all you wonder about, its a sad life you lead

Re:Some clarification for the recently arrived.

[DuckDodgers]

Systemd is more work for you, someone with a broad depth of expertise in SysV init and shell scripts. For someone new to both, systemd is less work and provides all of the same features and advantages. Lennart Poettering is not a Red Hat executive or a Fedora guidance committee chairman - he and his team got systemd adapted by Fedora, then OpenSUSE, then Arch, then Debian, then Ubuntu, then CentOS based only on its technical merits.

Re:Some clarification for the recently arrived.

[Eunuchswear]

If you don't understand why https is a very poor replacement for syslog over a network that may well be unreliable. I will assume your not really familiar with low level hardware and the failure modes. You do not seem to get the overhead and delay of TCP connections in general and thus why it's a poor choice for logging.

UDP over an unreliable network is better?

Re:Some clarification for the recently arrived.

[Eunuchswear]

Tha's bizzare. Exactlty what log messages were missing?

Huh? That's systemd's policy. I've setup hundreds of CentOS 7 servers for customers since last Sept, and I can't remember ever seeing a start-up error in the systemd journal.

Not my experience.

AFAIK systemd logs everything it gets given.

Systemd logs everything that gets sent to syslog, everything that gets sent to the kernel log and the stdout/stderr of almost all things it starts (you can put "StandardError=null" in a service file if you want, for example ModemManager.service).

I suppose some lunatic could put DefaultStandardOutput=null, DefaultStandardError=null in system.conf, but that's user (or distro) error, not systemd.

Where did you get the idea that this is "policy"?

Re:Some clarification for the recently arrived.

[silas_moeckel]

Far better the lack of connection overhead etc means some packets will get through with useful data even with extreme packet loss. Hell it works with total loss of connectivity on the return path (and with properly configured static arp continues to do so). Point being is that some logs is far better than no logs.

Hell we used to build unidirectional ethernet cables for log servers, it's rather hard to leak data to a hacker over an air gap after all.

Re:Some clarification for the recently arrived.

[silas_moeckel]

I'm not so sure about the technical merits in the server space, systemd is and will rack up a lot of consulting hours that is good for redhat and others.

Centos picked it up because rhel moved to it, nothing to do with merit only compatibility.

If your starting up a new shop systemd is the path forward because rhel made it that way in the commercial linux space. If your a current shop your moving to it for the same reason. My issue is that is that it is not significantly better. It will generate rhel and others a lot of money and position it better for the desktop/laptop space. Those seems to be the reason commercial linux is moving to it. Ubuntu and the likes it's something new and shiny that is why those distro's exist, support the new stuff compared to the stodgy rhel and the likes.

This argument is similar to the GUI wars on servers, I simply could care less a GUI has no place on a server, if anything it's going to be tunneled down ssh to whatever window manager etc I like to use.

Re:Some clarification for the recently arrived.

[Eunuchswear]

Hell we used to build unidirectional ethernet cables for log servers, it's rather hard to leak data to a hacker over an air gap after all.

Twisted pair, not coax I presume :-)

Re:Some clarification for the recently arrived.

[silas_moeckel]

Fiber works as well :)

Re:Some clarification for the recently arrived.

[DuckDodgers]

Try mosh, if you haven't already. :)

Freedom of Choice

[ckatko]

With developer choice, comes complexity. End of story.

You want everything to be the same, write in Python, where they enforce a coding style.

If you want to do things the best way for you, you'll have to support a variety of duplicating libraries and APIs. The thing is, one once library becomes a clear winner over all the others, development often stops on the others, which means everyone stops using those libraries.

So while yes, things may be complex now, but only because of the rapid amount of development and progress. As things calm down, the lesser ones will be depreciated. Give it time. You can't control an entire community spanning the globe as if it had a single leader, as if we could predict the right answer 30 years from now. Moreover, we shouldn't. To say things should be less complex means people should be restricted from doing what they think is best. And that mentality is the opposite of what attracts people to Linux.

Yes and Yes!

[thogard]

The problem is modern operating systems have taken on too much of the operating environment role leading to excessive complexity. Our modern opening systems are hypervisors like like xen or vmware. The OS has become a mess of other things that aren't related to security and suability of a system. The Operating Environment is where the rapid changes and R&D should be so features can progress and mistakes can be quickly removed.

Re:Yes and Yes!

[neilo_1701D]

I do agree with you.

In the occasional fit of nostalgia for when life was simpler, cleaner and only occasionally interrupted with a Guru Meditation, I'll boot up an Amiga emulation. It's simpler, cleaner, faster... and utterly frustrating if I want to do anything remotely "modern" with it. Like, you know, browse the web or something. Then I need to be running Workbench 3.something, with a TCP stack etc.

That's me, with an Amiga. Choose your own nostalgia and try.

Operating Systems have got more complex simply because we expect more of them.

Nope..

[the_rajah]

I disagree with your analogy in that when the Internet goes down, Ham radio keeps on working,.

or simpler

[ssam]

Replacing 100 shell scripts with a single binary is a simplification.

Re:or simpler

[jones_supa]

Please don't confuse the discussion with facts.

Re:or simpler

[Anonymous Coward]

right up untill something breaks, and you need to check wtf the system is doing when it breaks

Re:or simpler

[peppepz]

...unless you get a single binary which is 100 times more complex than a shell script.

Re:or simpler

[gweihir]

Only if you do not try to change anything. In that case it does not matter though....

Re:or simpler

[ahodgson]

Yeah except now it's a single binary with 100 configuration files. Half of which just run a shell script anyway, because you need one to get the job done.

And I don't even mind that it replaces init, init sucked, but that it's that it's hijacking ntp, login control, syslog, cron, and any number of other tools that just worked before systemd.

Re:or simpler

[Anonymous Coward]

Only if you want to use the binary in exactly the same way as its author intended. If you want to modify the behavior, it's easier with 100 shell scripts.

Mysteriously doesn't work?

[Anonymous Coward]

Probably SELinux's fault.

Yes

[Punto]

Reminds me of this e-mail from Bill Gates http://blog.seattlepi.com/micr...

(talking about the "add/remove programs" screen) "Someone decided to trash the one part of Windows that was usable? The file system is no longer usable. The registry is not usable. This program listing was one sane place but now it is all crapped up."

At least we still have a filesystem

Yes?

[Anonymous Coward]

It's been too complex for years.
It's not a friendly OS for the inexperienced. Considering there are so many things that requires you to even use the terminal, Linux will never be a mainstream OS. If you can't do everything with a few clicks on the mouse, the mass will never adopt Linux.

Thnings are not like I want them to be

[devent]

Is that another "things are not like I wanted them to be" posts? Linux is a community of vastly different groups with lots of different interests, with over 100,000 software packages, each scratching an itch. If you want a complete "experience" then MacOSX or even Windows is maybe better for you, i.e. a computer system where each component is designed from only one vendor. As a newbie Linux user myself, I'm pretty amazed that all those thousands of different software packages, all from different developers, can even work together and that even better than, for example, on Windows. On Windows I remember that every software app brings a whole SDK so it can run, and there is zero reusing of software packages (except for the Windows SDK).

Re:Thnings are not like I want them to be

[Anonymous Coward]

> On Windows I remember

I think your memory is broken.

Becoming more complex?

[whitelabrat]

Wut? More complex? I'd think that some of the distros make using Linux easier than ever. For anyone else, there are plenty of distros out there that would suit your needs.

this is why I've started migrating to *BSD

[eleitl]

I'd rather have a sane, conservatively developed high-quality system. Linux has always been drek code-wise, but at least it was fixing its bugs faster than becoming a ball of slime. Now, it's all just degraded user experience.

No, it's not becoming too complex

[Anonymous Coward]

"The defining component of Linux is the Linux kernel[...]" - https://en.wikipedia.org/wiki/Linux

I've always heard that Linux is the kernel and I guess it's true.

When we start to discuss Slackware (BTW it's my favorite), OpenSuse, Ubuntu, Fedora or whatever flavor we're adding another layer on top of Linux. That extra layer can be viewed as good one or as bad one and it all depends on what type of usage the user gives to the machine/OS.

I manage my own servers (Slackware of course =D) and I don't need the GUI. Console access is more than enough for managing a server. In fact Windows seems to agree with this since, well... it launched Windows Power Shell, maybe some tasks do not need GUI. On the other hand if I need to use some hardware/software most likely I'll end up on Windows but that's a different issue (mostly because of market structure. If Linux usage increases than support from companies will show up)

So, is modern Linux becoming too complex? No, I don't think so.
The extra layer I mention is what makes it complex and adding stuff increases the potential for entropy.

Anyway it's just my two cents.

regards

Simplicity needs to be the new goal.

[Qbertino]

Simplicity needs to be the new goal in a FOSS OS project like Linux. 20 years ago it was all about getting an alternative to systems that cost north of 100 000$ up and running to be able to do the stuff we all wanted to do but couldn't afford to.

Today leading FOSS solutions and extremely powerful hardware is available in abundance, as are network and cyperpunk-working-coding-and-collaboration resources. It is now that we need to push for simplicity and perhaps even an own hardware standard.

To be honest, putting emphasis on FOSS hardware might even provide the right incentive for exactly that simplicity. Apple won all the Unixers over a decade ago, because it offered exactly that. Zero-fuss out-of-the-box FOSS-*nix functionality. It started losing them ever since the golden cage starting to close and lock. This is a gap the FOSS community needs to fill.

It is, in my opinion, high time for FOSS hardware to move into the limelight. We need to start crowdfunding our own NixBook Airs, flashy pro desktops and servers. ... The librem 15 is a step in the right direction - we need more of that.

"Programmers want hookers...!!!"

[Anonymous Coward]

horizontal nor vertical I bet

Do something once. And do it very well.

[Anonymous Coward]

That's the name of the game. And FUCK systemd.

The "you have the source so you can fix it mantra"

[Anonymous Coward]

FTA, "I havenÃ(TM)t had the time to switch my workstation, and frankly I am concerned about it."

The whole "you have the source so you can fix anything you want is great", until your busy with things like, you know, actually making a living. Then it becomes a serious pain in the ass.

Just find out what to remove

[junkgoof]

As a sysadmin I find I just have to dig a bit to find what to remove. All the gui config tools. All the tools that are meant to help people who don't really know anything about Linux or UNIX. A lot of the stuff that tries to "help." I agree that recent tools tend to be neat but underdocumented, fragile, and destructive.

I understand the security rationale for making logs readable only by root but it makes working on servers adminstered by random offshore people ($5/hour, no IT abilities whatsoever) quite difficult (hey, this server is networked half-duplex and the admin doesn't know what that means. Hmm, the time is off but the admin doesn't know what ntpd is. Why is the sysadmin rebooting that Linux server repeatedly to try to solve a problem that does not require rebooting?) as you need to analyze the problem, not describe the symptoms, and it's harder without read access to the logs. The Linux assumption that someone with root should have a clue is long gone at large companies; the very first thing to go to the least knowledgeable is the root account, and it is widely shared but only to others who don't know the O/S. Note that the logs are readable on most other UNIX flavours (mostly dying flavours at this point). I'd suggest fixing the security problems with the logs or confining them to specific restricted files instead of just hiding all the logs from users. Not every Linux box is used by one guy in his basement.

RHEL no longer has a whole lot of competition in the data centre (real competition, that is, stuff that works and has a reasonable vendor). I don't really expect it to improve at this point. No pressure. Should be OK as long as it doesn't degrade too much more.

Re:Just find out what to remove

[Anonymous Coward]

A) Local logging is dumb, use a log server.
B) Your servers should be diskless and stateless, they should be netbooting ramdisks in this day and age.
C) If a server screws up to the point where it can't log to the management network, the axeman (watchdog appliance) will be along shortly to reboot it.
D) Decent sites have their own server initramfs images built from scratch with only the components they need for their workload. Everyone else is a moron, who cares what they do.

deeper problems than complexity

[sdinfoserv]

I've made several attempts to use Linux for the desktop... all have failed. Worse than being too complex, after 20 years of development, it fails the ‘just work’ test. I’m a techie by trade, a programmer longer than I want to think about. I do network support, server support and mange a team. I have kids, a wife, home interests.. I don’t have the time or patience to futz with computer problems when an install or an app refuses to function. When I was younger, I enjoyed the hack to make it work. That was 20 years ago. Now it annoys me. I just want it to work. After 20 years of Linux development there needs to be some level of maturity, stability, uniformity.. It needs to just work without having to hack it for the casual user to accept it. unfortunately, Linux doesn't pass that bar. I’m done with Linux at home. It’s nothing more than a toy for hackers who want to tweak. For people who just want their stuff to work, Linux is not the answer..

Re:deeper problems than complexity

[Alioth]

Don't know what distro you using, but "just works" test has passed for me both at home and work with Debian.

Not so much with Windows. I have a Windows partition because a couple of games I like don't have Linux equivalents - it took some fscking around to make them run because a default Windows install doesn't actually have all the required DirectX DLLs, and software installers for Windows do not have any dependency resolution built in, so it requires running around finding the DLL on microsoft.com. Not to mention the time it took to actually install Windows *and* have it actually do something useful due to the lack of drivers on the WIn 8.1 install DVD. Didn't even have a driver for my incredibly common onboard ethernet (so required fscking around with removable media to be able to even start the process of finding all the other drivers I needed).

Re:deeper problems than complexity

[Anonymous Coward]

I could not agree more strongly with this. I've been using Linux off and on since the days when you could get a Slackware floppy in a plastic envelope glued inside the back cover of a book. And it's been a real love/hate relationship for me. Linux is like the smart, funny, beautiful girlfriend who just happens to be howling at the moon crazy.

I would add, though, that the fundamental problem is that OSS coders love to work on what's fun and sexy and not what's really needed. Making an OS that just works can be a perversely difficult task, and it involves a lot work that's most definitely not fun; I'm reminded of SF futures and alien locations that look shiny and slick, but no one talks about what it takes in these worlds to keep the plumbing and other mundane things working.

Re:deeper problems than complexity

[Anonymous Coward]

If you cannot get a linux distro to install and just work on your ETHERNET-connected DESKTOP you are a monkey. Sorry, but there is just no other word for it. My 12 years old brother installed Ubuntu in 1 hour on our new desktop. He had never installed an OS in his life. He doesn't know what an partition is.

Nota : The WIFI-situation, on the other hand, ranges from perfect-out-of-the-box to horrendous-no-way-to-make-it-work which is a shame.

No!

[morgauxo]

No, it became too complex years ago. And it just keeps getting worse!

If it ain't broken ...

[michaelamerz]

.. don't fix it. But that is unfortunately not the mission principle of some of the Linux developers. Nowadays, people are driven to abstract and to objectifiy everything. If it doesn't have a lot of 'this' in it, it's not good. The early Linux system was built by people with a lot of C and Assembler experience. But Java changed all this as it became the language of choice in a lot of schools and colleges. And it ripples through all areas of software engineering. They tell me it's easier, more error resistant and more portable - but they need more than half the time to tinker with the IDE because they can't keep track without it. And guess what: It still dumps, it still has (security) flaws and it still breaks. Android development is a nightmare, Javascript is morphing into REACT and will be completely abstracted and Linux, well, sooner or later we will end up with $(this) at the prompt. After all, home is not really an object now, is it?

Re:If it ain't broken ...

[Alioth]

It is generally easier, more error resistant and more portable. Java makes my day job of writing boring back end business software much more rapid and productive.

I do C and asm too. One of my current projects is for embedded ARM (in C). I've also done a significant amount of 8 bit asm (very recently) and also asm for an OpenRISC SoC. Those I'd never dream of letting Java or even C++ get near.

Right tool for the job. Sometimes, that's C or even in some niches, asm. But the vast amount of software people are writing isn't system level - some business application with a GUI is much better done in java or C# etc.

Re:If it ain't broken ...

[Anonymous Coward]

Right tool for the job. Sometimes, that's C or even in some niches, asm. But the vast amount of software people are writing isn't system level - some business application with a GUI is much better done in java or C# etc.

Most business application software ain't worth doing.

But I guess you do what the client pays for. Hell, virtually all the work I do for a living is completely pointless idiotic crap and business ideas that are structurally unsound, but as long as I get paid, I crank out the bullshit.

I also run a business and ALL the business software I use is all written in sed, awk and a few utilities I wrote in C to compute aggregates over tabulated DSV records. Most business software is 1000x more complex and 100x less flexible than the batch-mode software I use.

It's just a simple fact that retards (customers) favor appearances over reality.

And I've even ran benchmarks comparing my batch mode business software against implementations in SQL databases and it turns out that simply streaming stuff through pipes in unix between sed, awk and aggregators is much (50x or more) faster than any commercial or FOSS SQL database.

complex or fragile?

[junkgoof]

I had a "get off my lawn" moment. I thought Linux was getting more fragile, then I thought back to some of the problems I had in the late '90s and changed my mind. There is more fluff, but once the fluff is removed it's more reliable.

Re:complex or fragile?

[ahodgson]

The kernel is more reliable. Userland is definitely getting worse.

minix?

[Anonymous Coward]

No one so far has mentioned minix, which I think might be a bit of a solution for these issues.

Re:minix?

[Chrisq]

No one so far has mentioned minix, which I think might be a bit of a solution for these issues.

No one has mentioned HURD either, perhaps they want something that's production ready?

Re:minix?

[Anonymous Coward]

HURD will be production ready any day now.

Look at WIFI support

[RogueWarrior65]

Wifi support in Linux is a mess.

Re:Look at WIFI support

[Eunuchswear]

Wifi support in Windows is a mess.

Wifi support in MacOS is a mess.

Wifi support in Android is a mess.

Wifi support is a mess. Does it work anywhere?

Re:Look at WIFI support

[Anonymous Coward]

wpa_supplicant supports my Intel card just fine, and my configuration file has one section per network I commonly use. It's a bit tricky to add a new network, but that happens infrequently (and I have written down instructions, just in case, inside my wpa_supplicant.conf).

Re:Look at WIFI support

[RogueWarrior65]

Well, at least on commercial platforms there is a front end to configure it. On Linux (sans a GUI), you have to edit files. Or at least you did until wicd was finally updated this past December. It's still a major pain though.

Re:Look at WIFI support

[Eunuchswear]

I don't understand.

On commercial platforms with a GUI there is a front end.

On Linux with a GUI there is a front end.

On Linux without a GUI you use command line tools, nmcli for example.

Re:Look at WIFI support

[RogueWarrior65]

Hmm...that's a new one on me. I've been working in a Yocto embedded environment. I'll have to see if nmcli is part of that distro. At least a curses-based version of wicd works now. You still have to build it though.

Re:Look at WIFI support

[Anonymous Coward]

Yes. Mostly because of the drivers though... So mostly because of the manufacturers.

Gawrsh.. just like DOS vs Windows in the Enterpris

[Anonymous Coward]

You mean that modern Linux, deployed at enterprise scale, requires a lot of specialized knowledge and is complex? Just like Windows? Funny thing, that.

It's easy to manage a system that is on a single machine, managed and operated by a single person. A few configuration files and scripts, and it's good to go, whether it's DOS, Windows 3.1, or Linux.

It started to go down hill with selinux

[mike2006]

The lack of symplicity I would say started with selinux which I find to this day to be a pain in the ass with bugs and poor logging. I see we are going down the same path with systemd and this continued BS change for the sake of change. Linux had the chance to rival Microsoft on the desktop and it was absolutely bizarre distros went down the same road as MS with making the desktop like the mobile UI. Maybe I am just a conspiracy theorist but from a distance it seems this is all intentional to prevent Linux as a desktop rival. So it really makes me wonder about the decisions made with selinux and systemd.

Re:It started to go down hill with selinux

[Eravnrekaree]

I agree with the need for better documentation. On features themselves, something like selinux is a bag of tools for use by experts to configure systems which may have widely different needs. The needs in different installations can be very different and therefore you need a wide set of tools and capabilities so that things can be easily configured how they need to be. It does not mean you have to use all of these tools or need them, but they are there to cover the different use cases. You dont even have to use selinux at all, if you dont want it. Its a tool for people who need its features and one user may need one subset of its features and another user needs another ssubset. For an OS to be useful it needs to cover the whole spectrum of use cases, but you only need to use the tools that are valuable in your particular case.

Mange: Mange /mend/ is a class of skin diseases

[TrollstonButterbeans]

Mange is a class of skin diseases caused by parasitic mites.

And proof of a dedicated programmer.

Re:Mange: Mange /mend/ is a class of skin diseases

[sdinfoserv]

I had an older laptop that was running XP just fine. It was an HP convertible with a touch screen. I loved the foot print but couldn't keep unsupported windows. I tried several flavors of 'Nix on it. I settled on Mint due to the older hardware and I wanted a smaller software foot print.

However – there’s 3 annoying issues
1 – There’s a message on the screen before the GUI starts about invalid user. From the research, this is a debian bug. As far as I can tell, it doesn’t affect anything. I ignored it.

2 – There’s no support for Netflix?!? This surprised me, as it would be similar problem with any version of Linux. According to posts on the internet, this is because Netflix requires Microsoft Silverlight, which is not available on Linux. I really, really have to say I don’t believe this at all. I have Netflix on both my android phone and my iPad. Both have a Linux connection. There’s no excuse not to run Netflix.

3- This is the killer -. After the initial install of Linux Mint, I performed an update. The update killed the OS. No boot, just a brick. I re-installed Mint and it worked, however I didn’t perform the update.

Issue number 2 makes the device unusable for the majority of my entertainment. Issue number 3 makes the device just plain untrustworthy.

Re:Mange: Mange /mend/ is a class of skin diseases

[sdinfoserv]

Other issues..... It didn't automatically install dual core processor support, I had to add that later. I didn't recognize and install the WiFI driver, I had to manually download and install the separately..(via a USB from another machine what PITA). Like I said... too much 'tweak'.

Not Modern Linux, some modern Linux distributions

[Danathar]

Not really trying to split hairs, but the issue is certain distributions of Linux, not Linux itself (the kernel). Distributions like Slackware are quite easy to understand, but others not so much.

Lessons from using the same distro (since 1999)

[hazeii]

Still running the same distro here, from 1999 (and am mercifully free of systemd, pulseaudio, etc). All upgrades have been done by downloading and compiling from source, with the exception of a small number of large programs/drivers (specifically Firefox, Palemoon, OpenOffice, Java, nvidia driver). This 'in-house' distro gets copied onto all new computers, so there's about 50 or 60 running it (including a few laptops). So what doesn't work?

In short, not a lot. Occasionally have to 'chmod a+rw' something in /dev (easier than running udevd), but that's about it. Written a couple of init scripts, fixed a few others (all very simple, maybe a day in total).

The best bit is, if anything breaks we can fix it - easily.

As to why modern distro's are so complex: "follow the money". If everything was so simple that no-one needed support, well, there goes the business model of all the major distros. So it's not unexpected they put developers in change who like 'elegant' (read complex, bloated, impenetrable and obscure) solutions - it means that end-users pretty much have to fork out for a support contract (or spend a *lot of time* on inhouse admin).

Answer: No, it is not

[Eravnrekaree]

From what I have seen, most of the improvements have increased control and flexibility. Its odd to argue against a system that allows you the flexibility to set a program to run when any other system event is triggered, such as the NIC coming online.

The fact is, the ones who don't like systemd or polkit tend to be a certain percentage of the system administrator types (not all of them). Ironically, these who do most of the complaining have the skills to be able to configure the system how they want. Don't like polkit or systemd? Just configure your system not to use it. No one is stopping you. You can replace systemd with your own init system if you want. Use an older WM like fvwm and you wont have any problem, which you probably prefer anyway. There are many other WMs that dont have any dependancy on systemd, as well. I do agree that a program with a systemd dependancy should not refuse to run at all if systemd is not there, instead, only the systemd dependant features of it would be unavailable. if Gnome does not work this way, that is a valid point., Of course it is okay for gnome to hook systemd features, but if systemd is not there, the basic functionality should still work, just the systemd dependant features would be unavailable.

If systemd and polkit are not well documented and not configurable enough, I think that those are valuable points, these things should make our control and monitoring of the system easier, they should add more options and more logging facilities for expert users to keep an eye on things.

I seriously question the mentality of those who find the general concept of polkit or systemd unacceptable. For instance, it sort of makes sense that there ought to be some sort of an framework for IPC authorization, rather than a million incompatable systems, its better to have a well audited standard facility for that. It can also be handy to have a facility so that I can set up a program to be run when the IP address is asigned or just after another process starts or any other system event. To argue against having this functionality is just bizarre in my opinion and seems to be that these so called "experts" who argue against them want us to have less control over the system.

The basic system of Unix permissions while being suitable in many cases, can be more difficult to manage in others. What if i want to write some rules to say that a particular user should not have access to certain directories, or to say they should only have access to certain directories. Some sort of rule based system where you can define a set of rules that apply to that user can be better in some cases than the per file permissions.What if I want to apply such a set of rules to a single process when he process is run? The same thing goes. The basic system of Unix permissions is good for many things and a good foundation but that doesnt mean its the end all and be all of access control.

Re:Answer: No, it is not

[Eunuchswear]

The basic system of Unix permissions while being suitable in many cases, can be more difficult to manage in others. What if i want to write some rules to say that a particular user should not have access to certain directories, or to say they should only have access to certain directories.

If you want to get into windows ACL hell it's easy:

$ man 5 acl

Linux != Linux distribution

[johanwanderer]

Distributions, etc. will continue to change to suit their needs. Linux itself is probably not quite that extensive yet, as evident by the multitude of complains about the non-working drivers.

The answer: SLACKWARE

[arfonrg]

Stop using crap distros with do-everything-in-one apps, sym-link-hells and all!!!

Every single complaint is covered by Slackware's simplicity.

Re:The answer: SLACKWARE

[Anonymous Coward]

Or by using OpenBSD or even FreeBSD. the BSD camps, while not perfect, seem to embrace the tenets of UNIX to a far better degree, esp. OpenBSD, which reject binary blobs, is text throughout, is user-friendly, has arguably the best man pages of any OS, and is simple, secure, and stable to the point of being boring. I've never, ever, short of a hardware failure, experienced a problem with OpenBSD. It's a well maintained system written by men who know what they are doing.

Re:The answer: SLACKWARE

[arfonrg]

Slackware uses BSD inits so, you can have the BSD inits AND Linux code base. WIN WIN!

GUI?

[Anonymous Coward]

I thought Linux uses a graphical user interface like Gnome and KDE? Can you not double-click icons to open hard drives or use the control panel? Is super user still available? Am I missing something? The article is too short for me to understand the issue the original poster is having. Sorry.

Tackle one piece at a time

[dcooper_db9]

I also come from a Windows background and looking at Linux from the perspective of someone with pure Windows experience is daunting. Lot's of tutorials make assumptions without noting prerequisites. For example, you might not know how to start and stop services, how to elevate privileges, or where to find important files in the folder structure. I'm hardly an expert but I have gotten to where I work on both platforms and I prefer Linux as my primary work station. My advice would be to pick one narrow challenge at a time. For example, you might set out to setup a server with MySQL. Then try setting up an FTP file server. After you tackle a few of these projects you'll start to get some grounding in the system. The best thing about Linux is that there are lots of people out there who are willing to help.

I have to acknowledge that there are some tasks I've just not succeeeded at. I've been (in my spare time) trying to figure out how to setup a Samba domain controller and haven't got that working. The problem isn't that I don't know enough about Linux, but rather that I don't have a background in networking.

Re:Increased usability

[Anonymous Coward]

"Increased usability means more scripts and automation,..."

No, this is not a simple fact. "Increased usability" is a moving target, it means vastly different things to different people. Each use-case will have a different definition of usability. It is highly suspect of you to try to make such an over simplification. You seem to have no interest in recognizing the computers and software are multi-functional tools with a myriad of purposes, and you seem to have disdain for those that do.

Bloated complexity.

[Anonymous Coward]

Dude, that boat sailed looong ago.

Whatever you're used to seems simple

[nine-times]

I used to be able to say Linux was clean, logical, well put-together, and organized.

You would only say that because you were used to the previous organization. It has always been a mess of "catering to old UNIX paradigms" while also "trying to squeeze in the latest new thing." Old UNIX guys have always complained whenever the GNU tools had a different behavior from what they were used to, including changes that you take for granted. Bash was once new, and some people still don't like it.

Do you remember the first time you saw a UNIX filesystem? Think back. You have directories like etc, usr, and var. "usr" doesn't really contain user information. "etc" doesn't include miscellaneous files. "var"? WTF is "var"?

None of that shit ever made sense. It's what you were used to. If we set out today to make a sensible, orderly, logical, clean system, it would not look like modern Linux, and it would not look like old Linux.

Re:Whatever you're used to seems simple

[Eravnrekaree]

Introducing non backwards compatable changes for the sake of "i dont like how it looks" is bad because you blow up applications and scripts that depended on it, just because someone "doesnt like how it looks". Your complaints of /etc and so on lack merit, its not hard for someone to learn what these directories are for and not hard to remember. Most non-techie users of distros designed for them never need to mess with these directories, and lack the capability or will to mess with what is in those directories anyway, the apps save and open screens take them directly to ~/Documents, and apt-get et all takes care of app installation.

Re:Whatever you're used to seems simple

[nine-times]

Your complaints of /etc and so on lack merit, its not hard for someone to learn...

Right, so what you're saying is, I'm already used to it, so it's fine. That was kind of my point. It's not a sensible layout, but you're used to it.

And don't give me this crap about "just because someone 'doesnt like how it looks'." It's not about how it looks. It's about sensible design. When you're designing something like this, you should basically make some attempt to put things where an knowledgeable person would expect them to be. In the case of directory structures, this translates into something like, "Show the list of directories to someone who doesn't know the directory tree, and have them guess where things go." What goes into "dev" vs. "etc" vs. "bin" vs. "sbin"?

And sure, you can say that it doesn't really matter what things are called and how things are organized, since people can always learn the weird, confusing, obscure directory structure. And that's a fine argument. But then don't give me this nonsense about the setup being, "clean, logical, well put-together, and organized." It's basically a bunch of kludge to maintain compatibility.

Re:Whatever you're used to seems simple

[Eravnrekaree]

It is a sensible design. /usr is so called because it is where user installed programs and their supporting stuff usually go, in contrast to /bin which is your main system programs. bin means "binaries", which is exactly what is in there. /dev means "devices", again, thats whats in there. We used abbreviations to reduce the amount of typing needed when using the command line. Hundreds of tutorials and books have been written about the directory structure and explain exactly what it means. /etc really is fine, it does not refer specifically to configuration, but its been in use forever, its just not important enough to change something that is a part of the tradition. If your enough skill to modify config files, good for you, and you can learn what /etc means. I came to Unix from Windows wanting to learn its way of doing things. I tend to place a lot of importance in following the Unix traditions.

I am not averse, to providing additional functionality on top of the Unix canon, but I am for full adherance to Unix conventions, additional functionality can be added on top of that. For instance, in gedit, the user is put by default in their ~Documents folder when they open and save files, so they dont even need to know what /etc is. /etc is for literate users and we can learn what this stuff means.

Re:Whatever you're used to seems simple

[nine-times]

/usr is so called because it is where user installed programs and their supporting stuff usually go, in contrast to /bin which is your main system programs. bin means "binaries", which is exactly what is in there.

Exactly. So there are never non-binary scripts in /bin, right? And if I install a vanilla Linux install without any additional installations, than /usr will be completely empty because it's only for user-installed programs. Well, and their "supporting stuff", which can be damned near anything.

And then some things go into "opt", because fuck you that's why.

Honestly, you're not even arguing with me. People don't need to know what /etc is, and if you know enough to mess around in /etc, then you'll probably know enough to know what's in there. But again, that says nothing about whether the name of it makes sense. Your argument boils down to "It's what we're used to, and we know what it is, so it's fine." And I say again, that's a fine argument. Just drop the nonsense in claiming that it's clean, logical, and well thought out.

And I'm just talking about one simple little factor of the design-- directory naming structure. There's lots of messiness and nonsense. We just usually ignore it and forget about it in favor of maintaining conventions and compatibility.

Re:Whatever you're used to seems simple

[John Goerzen]

Actually, I DO remember the first time I saw a Unix filesystem. It was on FreeBSD. And it DID make sense. When I switched to Debian not long later, there was this document that eventually became the Filesystem Hierarchy Standard (FHS). It clearly spelled out where things lived, and in Debian non-compliance with the FHS was a bug (and once the notion of a release-critical bug was invented in Debian, it was a release-critical bug.)

Part of the problem here is that we are in a twisty little maze and every passage looks alike, and our flashlight ran out of batteries in 2013. The manpages, to the extent they exist for things like cgmanager and polkit, describe the texture of the walls in our little cavern, but don't give us a map to the cave. Therefore we are each left to piece it together little bits at a time, but there are traps that keep moving around and it is slow going.

Add to the the fact that it's a damn big cave.

I could understand the FHS in about 10 minutes. This stuff? Would probably take weeks.

The order of magnitude of complexity is entirely different. It came out in the comments on my post that Fedora finally threw up their hands, and the reason that Wifi works out of the box there is because they just expose all wifi passwords to all users of the box. Whoops. Could you have known that by looking at the permissions with ls? Nope. You'd have to read some XML file in a location that network-manager never mentions.

Re:Whatever you're used to seems simple

[spitzak]

That's a nice excuse for /usr/bin but it is not true. /usr was intended to be user-owned directories, and all the commands a user was expected to type would reside in /bin (and .). Early AT&T Unix systems had multiple disks and made "/usr" be the "big" one, since they mistakenly thought that documents and things users worked on would be far larger than the system. Then what happened is the system disk filled up as more and more commands were added, and they needed space to put more commands, and since $PATH meant the "/bin" was not hard-coded in most places so it was easy to search other directories, and the lack of symbolic links or union mounts at the time meant the only way to put something on the /usr disk was to make it a directory under /usr, they added /usr/bin and started populating that. Eventually this also happened with libraries and /usr/lib was added.

Some people then started the excuse that /bin was for "system binaries" as opposed to "user binaries" but the distinction was pretty random. Not only that, /bin eventually filled up with "system binaries" and they had to add /usr/sbin!

Eventually so much stuff was put in /usr that people stopped putting home directories there. A different directory allowed them to be on a different disk than the system which was now about 90% under /usr/bin and /usr/lib. Almost everybody used $HOME rather than any hard-coded values so this was possible to change. First /users was the new directory but this was changed to /home more recently).

Re:Whatever you're used to seems simple

[passionplay]

It was all very simple. /home contained the home directories for users /sbin contained system special executables /lib contained system libraries /bin contained sytem executables /usr contained user space files /usr/sbin contained user space special executables /usr/bin contained user space executables /usr/lib contained user space libraries /usr/share contained shared user space files /usr/local contained add-on user space files (bin,sbin, lib) /var contained the most variable files (high data through put) or most often changed (which leads to /var/www /var/lib/ /var/adm /var/tmp /var/run) /proc contained process pseudo file system /dev contained device pseudo file systemIt was all very simple. /sys system pseudo file system - this one is new /tmp obvious /etc EVERYTHING ELSE that is not a library, user space file, or a binary in one of the other categories

Just because you were never told and never bothered to learn does not pre-suppose a lack of design.Ignorance is no excuse for claiming to be knowledgeable. It's like saying you never read the bible because it was all in Greek.

Just because you were never told and never bothered to learn does not pre-suppose a lack of design.Ignorance is no excuse for claiming to be knowledgeable. It's like saying you never read the bible because it was all in Greek. But you got the gist by looking at it long enough.

If you cut your teeth on Dec UNIX, Solaris, AIX and HP-UX, it's very easy to understand because you learn the history through comparison. This "I don't get it so there must be no rhyme or reason" is just crazy.

It's like the other old timer said - the new folks don't want to learn about how we got here - they just want to repeat our mistakes. I cut my teeth on Linux and then UNIX proper and then VAX since 1990 (TSR 80s and the like on 8086 processors and then 80386 systems before getting to real machines ). It's a proven fact that we are all social learners by nature. Maybe it's time to exercise our social learning instead of our social media which is leading to our social ignorance..

Re:Whatever you're used to seems simple

[nine-times]

I'm not saying that I don't understand the filesystem. I'm used to it, and I often forget how random and silly it is. My point is that if you try to look at it with fresh eyes, it is a bit silly.

And people tend to do what you've just done, which is to make up an order and arrangement that almost makes sense. But the truth is, the whole thing evolved over time, and almost none of those things were the original intention. As someone pointed out, /usr started out as the place for user home/profile directories, but people kept putting things in there that didn't belong, which lead to the creation of /home and the abandonment of /usr to "another place we put binaries, for some reason."

AFAIK, /var started out as a place for specifically variable-sized files. The idea was that if you had a set of files which might grow very quickly, you might want those on their own drive or partition so they wouldn't overrun the rest of the system. Now, when you get down to it, it's because sort of like the /home directory that doesn't belong to any particular user. Sort of like Windows "ProgramData" folder. And /etc was named that because it was a bit of a catch-all for anything else, but really now it's pretty much a dedicated "system configuration file" location.

But those are just the names, and my point wasn't just "Oh, I don't particularly care for the names". My point was, this is a structure that's grown organically over decades, and it is not really "clean". Do we really need /lib, /var/lib, and /usr/lib? Do we really need /bin, /sbin, /usr/bin, /usr/local/bin, and /usr/sbin? My impression is that some of this repetition was created as a bit of a kludgey way to solve some particular problem, and then left in place for compatibility/legacy reasons, and maybe just "we're not sure whether this will break anything, so let's leave it alone." And then, after sitting around that way for a decade, everyone was so used to it that it just seems like "the way it's supposed to be."

And fine, whatever. It works. People are used to it. Why change for the sake of change? But don't pretend like it was an elegant planned organization.

Finally

[Anonymous Coward]

Thanks to systemd, 2016 will finally be the Year of the Plan9 Desktop!

A Generation Lost in the Bazaar

[Galactic Dominator]

Your desire is reflected in this article:

http://queue.acm.org/detail.cf...

Evolution vs. Intelligent Design

[Anonymous Coward]

This may be a reflection of the Linux designer's philosphy; to see it as "Evolution", not "Intelligent Design". Basically the design is reactive to stimulus, with the hope that useless or harmful features are pruned out with a survival of the fittest. Perhaps we need more predators to weed out the sickly gazelles.

Unix was built on top of a few paradigms

[jzu]

- Use text whenever possible
- Performance is not paramount, so use C
- And do one thing at a time but do it well - connect small specialized tools to build complex applications
- Documentation, while terse, should cover all features
- The filesystem is a simple tree starting with /

Let's see what modern Linux does:

- Lots of binary stuff everywhere, where text would do
- You'll boot up faster with systemd, oooh yeah baby, totally rad!
- Oooh, and it's more integrated, one single process does everything!
- Look for processes with stranges names running on your machine, then try to find any documentation on them
- gphoto2://[usb:008,044]/store_00010001

The last one makes me angry. It's VMS all over again: is anyone here old enough to remember host::disk$1:[directory]file.ext;version? I can't find another way of accessing my phone data. I can't, for the life of me, mount it the way I would mount another volume.

Guys like Poettering couldn't care less. They have a vision, for sure, and they have good ideas sometimes. But there are really two issues here: a good idea is not sufficient when you engineer a system, and their vision is not Unix. To hell with simplicity, to hell with consistency.

Re:Unix was built on top of a few paradigms

[Eravnrekaree]

1. There is a good argument for having an option for a programmatically accessible configuration database, to allow programmatic access to configuration settings as well as human access to these settings. I dont think its an either or thing, both can be provided.

2. The comment about C is absurd. C is a horrible language for applications and almost every C application I have seen is bloated any way, full of memory leaks and buffer overruns. C should be used only in the underlying kernel and system libraries and in the hottest code paths, not in applications. Your better off with python or ruby for apps. The higher level languages can be designed to use "managed code", that is they don't have to run on an interpretor but do use a runtime library that provides for the automatic memory management.

3. If you dont like how systemd works, your probably someone who can modify the system to use something else, and I agree you should be able to do so. The single process is sort of was done for dependant triggering of events between different event types to be done. You can also run an alternative init facility which you can start from systemd, using sytemd for just some basic functions. Again, no one forces you to use systemd for everything on your system, it does not exclude alternatives being used alongside it.

4. I agree that every process should be well documented. The Gphoto thing is not what you would call a core part of the system but is for your camera. I dont know what you expect it to look like, i dont see a problem.

Re:Unix was built on top of a few paradigms

[rixon]

It's VMS all over again: is anyone here old enough to remember host::disk$1:[directory]file.ext;version?

Yep. You are not alone :-)

Re:Unix was built on top of a few paradigms

[jzu]

> The comment about C is absurd

You missed the point entirely. When Unix was conceived, it would not be written in assembly language as was usually the case back in the days. C was seen as terribly slow, its functions were costly. The vision behind that choice was that performance was not as important as clarity of design and maintainability.

> The single process is sort of was done for dependant triggering of events between different event types to be done.

I know that. Using a monolithic architecture makes it easier to manage dependencies. It is not the only solution to that problem though, and I would have preferred another one, more modular. Since I'm not in a position where I can design my own init subsystem, I use systemd, but I can't help noticing this "dependent triggering" doesn't work too well yet. No magic wand will solve such a complex problem, and being unable to easily isolate faulty parts makes it in fact harder to solve issues.

> The Gphoto thing is not what you would call a core part of the system but is for your camera. I dont know what you expect it to look like, i dont see a problem.

Hmmm... Ok, let's repeat. Instead of gphoto2://[usb:008,044]/store_00010001, I want something along the lines of /media/user/Camera/. This is straightforward. This is something I can use in scripts (instead of godawful hacks like parsing dmesg to grab these device numbers). Instead, we have this annoyance, a false abstraction, yet another telling symptom of what is wrong with "modern" Linux.

Re:Unix was built on top of a few paradigms

[ookaze]

Let's see what modern Linux does:

- Lots of binary stuff everywhere, where text would do
- You'll boot up faster with systemd, oooh yeah baby, totally rad!

It's funny you say that, as systemd is about putting back text (systemd units) instead of lots of binary stuff everywhere (init scripts).

- Oooh, and it's more integrated, one single process does everything!

Not on my Linux, and I use systemd. I mean it's integrated and I do not have one single process which does everything.

Re:Unix was built on top of a few paradigms

[thegarbz]

- You'll boot up faster with systemd, oooh yeah baby, totally rad!

Actually systemd is not the fastest, and that's not a design goal, just a side effect from event driven startups. But the fact that this was one of your first complaints says volumes.

- Oooh, and it's more integrated, one single process does everything!

I assume you're still talking about systemd. I think it is really time you read the manual. Actually don't bother reading the manual, it's on their FAQ page, better still it's actually refuted myth number 1, on the list of systemd myths. The fact that you still think the way you do says even more volumes.

Guys like Poettering couldn't care less. They have a vision, for sure, and they have good ideas sometimes. But there are really two issues here: a good idea is not sufficient when you engineer a system, and their vision is not Unix. To hell with simplicity, to hell with consistency.

I prefer a guy with vision than a guy who will not look something up, not understand how something works, get all his technical knowledge from the echochamber that is slashdot posts, and then go and talk about something not being Unix ignoring that large parts of Linux have not been or followed the Unix philosophy for many years.

Lack of management

[iONiUM]

The behaviour of "Linux" (all the distributions and kernels) as a whole is exactly the same behaviour you see in companies with poor management. Everyone is working on stuff, and maybe even working hard, but all those things don't add up to the whole. There's no 1 person over-seeing it all to ensure everyone is working smart, and in the same direction.

To me, this is what is happening with Linux. Everyone has ideas, and some of those ideas are great, but when everyone can fork and create and merge without an overall management process, you end up with a bit of a mess and mass confusion for those on the "outside."

This is both the advantage (choice) and disadvantage (lack of alignment) with Linux. Should I use Gnome or KDE or Unity? Do I even know what those are as a end-user? Should I?

What I get OSX, I know what I get. When I get Windows, it's the same. Everything (mostly) from the previous version will work with this version, the interface isn't some massive surprise, etc (which is partially why Windows 8 was such a fiasco; things WEREN'T compatible and the UI was totally different).

At the end of the day, what needs to happen is exactly what most Linux devs hate the most: a large corporation with 1 vision needs to come in and create a clean, uniform experience that allows consistency and compatibility for years/decades, and reduces "choice" to a degree in order to provide consistency.

To some degree, you can argue RedHat did this a bit, especially with packages, but everyone hates on them too now..

Re:Lack of management

[Anonymous Coward]

The use of the word 'corporation' here could be controversial. And that's acknowledging the contributions of Canonical and Red Hat.

It doesn't really need to be a corporation. Linus fulfills this role for the kernel. A foundation could do it. There are a lot of possibilities, though in general the benevolent dictator model is not the best (I refer only to dependence upon a single individual).

The issue is one of leadership. I believe you are talking about leadership and vision.

The counter-argument is the need for change and the issue of being able to safely experiment with new thought models. Linux has slanted strongly toward the "fork it, or make your own" philosophy. It does need to be said though, that the freedom bias has frequently led to integration problems and a certain level of disjoint system experience.

Re:Lack of management

[Anonymous Coward]

The behaviour of "Linux" (all the distributions and kernels) as a whole is exactly the same behaviour you see in companies with poor management. Everyone is working on stuff, and maybe even working hard, but all those things don't add up to the whole. There's no 1 person over-seeing it all to ensure everyone is working smart, and in the same direction.

There is only one kernel. The guy over-seeing it all is called Linus Torvalds. He doesn't set the direction, but he does set the requirements for interoperability and quality.

Re:Lack of management

[ookaze]

The behaviour of "Linux" (all the distributions and kernels) as a whole is exactly the same behaviour you see in companies with poor management. Everyone is working on stuff, and maybe even working hard, but all those things don't add up to the whole. There's no 1 person over-seeing it all to ensure everyone is working smart, and in the same direction.

And the outcome is pretty good as Linux runs on every computer available to this day, be it embedded or phones or HPC. So I don't understand what you mean by poor management, are they able to do that in poor management companies?

To me, this is what is happening with Linux. Everyone has ideas, and some of those ideas are great, but when everyone can fork and create and merge without an overall management process, you end up with a bit of a mess and mass confusion for those on the "outside."

You're just new to this: Free Software is like that since it started, what you say is laughable to people used to FOSS. You talk like you just discovered FOSS.

This is both the advantage (choice) and disadvantage (lack of alignment) with Linux. Should I use Gnome or KDE or Unity? Do I even know what those are as a end-user? Should I?

What I get OSX, I know what I get. When I get Windows, it's the same.

Should you use Windows or OSX? Windows Vista, Windows 7, Windows 8, Windows Server 2008?
When you get Ubuntu, you know what you get just as much as when you get OSX, you even can test it without installing anything.
You're juste spewing fallacies here.

Everything (mostly) from the previous version will work with this version, the interface isn't some massive surprise, etc (which is partially why Windows 8 was such a fiasco; things WEREN'T compatible and the UI was totally different).

You must be young as what you say is patently false, especially in Windows. Nearly everything I learned in Windows 98 was made useless when Windows XP came, including most of my work environment. I can say the same with Windows NT to Windows Server 2003. While nearly everything I learned in school on Unix 20 years ago is still usable today on Linux which is not even Unix.

At the end of the day, what needs to happen is exactly what most Linux devs hate the most: a large corporation with 1 vision needs to come in and create a clean, uniform experience that allows consistency and compatibility for years/decades, and reduces "choice" to a degree in order to provide consistency.

To some degree, you can argue RedHat did this a bit, especially with packages, but everyone hates on them too now..

This is what distro do, it's nothing new, it's just you discovering it now, but everything you're saying has already been done and evolved since then.

Not just Linux

[tverbeek]

It isn't just Linux; it's the nature of modern systems to become "too complex". Back in the days of my youth, it was possible for one person to grok an entire operating system, but it simply isn't possible anymore, unless it's a tightly-focused and built-to-purpose system.

Re:Not just Linux

[iggymanz]

Some general purpose modern OS aren't "too complex" and a human mind can "grok" them, such as OpenBSD.

Re:Not just Linux

[tverbeek]

Is there really any one person – even Theo de Raadt – who is personally familiar with the entirety of OpenBSD? And even if there are such people, isn't that more a reflection of the fact that it's fundamentally still Ye Olde BSD (which was tightly focused and built-to-purpose), and not a modern general-purpose OS?

Re:Not just Linux

[ookaze]

It isn't just Linux; it's the nature of modern systems to become "too complex". Back in the days of my youth, it was possible for one person to grok an entire operating system, but it simply isn't possible anymore, unless it's a tightly-focused and built-to-purpose system.

And yet that's exactly what I'm doing today on my systems, which I build from scratch. And I grok the entire operating system, systemd was a god send tool for me.
I run in a setup where multiple graphical sessions run on one computer, which only Linux allow me to do very easily.

There is one exception though : polkit. It is the only tool on my systems that I never tried to completely understand. Now I don't even need to anymore with udev + systemd. And I bet that's where the op is having problems, as it was fixed by installing systemd.

Re:Not just Linux

[iggymanz]

eh? the purpose of BSD was to be a general purpose OS, which it is. OpenBSD scales from embedded controllers for elevators to at least 64 cores systems including big Sun/Oracle iron and x86-64 It runs the usual web server stacks, many modern desktops, multimedia apps, chromium browser, java, all the common scripting languages, gcc collection...how is it not a general purpose OS?

We Have Lost Sight...

[Anonymous Coward]

of the tenets of UNIX. Yes, I realize we are in the modern era, and UNIX is over 40 years old, but the tenets that made UNIX great are still valid to this day.

The tenet I wanted to touch on is the tenet of UNIX that suggests we "keep it simple". Complexity is not only the enemy of this tenet, it's also the enemy of security and common sense.

I have, in the last year, begun a move of my critical machines to BSD variants, namely FreeBSD and OpenBSD. OpenBSD in particular, exemplifies the tenets of UNIX better than any other OS that is in use. Theo and team correctly understand the issues of complexity and security and their product reflects the care they take. I liken their work to that of a gardener and his bonsai trees.

FreeBSD is rapidly becoming the "go to" OS for those who are disillusioned with what Linux as become -- namely bloated, complicated, and difficult to deal with. Linux, while intentionally what it is in terms of choices, has become fractured internally what with respected long-standing developers leaving for this or that reasons. Some of this is because of systemd, some of it for other reasons.

Let's be honest for a minute. Linux is not a bad ecosystem. It's has become a difficult maze of kernel, weird and varied frameworks, too many user land utilities and DE/WMs, and the legacy stuff that Windows and Apple were accused of is there for all who have eyes to see. Nothing is perfect, obviously, but the creep is evident and obvious. I'm severely disappointed with the notion of binary blobs, something OpenBSD correctly rejects out of hand.

For me and my IT shop, we are headed towards the BSD camp because of the above and because I value stability and engineering above all else. BSD has always cared more about being "correct" than cool. BSD is engineered, while Linux seems haphazard. My .02.

Sounds like example of an Ad Hominem:

[lippydude]

@Anonymous Coward: 'You can always tell when lines like "it used to be", "there was a time", and "I remember when" are used. Things change, and when software changes it typically gets more complex. Just take REO Speedwagon's advice and roll with the changes!'

No, it sounds like a Linux Developer has some very valid points to make:

John Goerzen: I believe that Modern Linux Becoming Too Complex?
Anonymous: Of course you would say because you're getting too old.
John Goerzen: How about addressing the arguments I gave to support my position?
Anonymous: Doesn't count, you're too old so anything you can say on Linux complexity is therefore invalidated.

Re:Sounds like example of an Ad Hominem:

[Anonymous Coward]

It isn't about HIM being old. It is about Linux being old.

  Linux does 100 times the things it did 10 years ago. Guess what ? it is a little more complicated than 10 years ago... I know crazy : a system that does much more different things and accomodate a much wider hardware range has gotten more complex !

  To all the whinners : just go ahead and restart an open-source kernel with a functionnal language, I hear it's the new way of KISS'ing.

Maybe "too helpful" is the right phrase

[WoodstockJeff]

I used to be able to create a bootable drive, configure it the way I wanted, then clone it to allow redundant hardware; only the IP and host name varied between machines. Several machines were built with two boot drives, imaged after the configuration was complete, then the "spare" powered down.

That stopped working a few years ago. Distributions now made partitions that included the serial numbers of the disks in their GUIDs. If the MAC address on net card didn't match, a "new interface!" was discovered, so routing tables needed to change. Now, it takes less time to build the install from scratch than to patch the mirror image to replace a failed boot drive.

The systemd fanbois are pieces of shit

[Anonymous Coward]

The poster makes a good point against systemd's policy against logging and gives a specific example, but was quickly hammered down and marked a troll. I've had that same problem and the more common:

old lock file: /var/lib/mongo/mongod.lock. probably means unclean shutdown

systemd doesn't log either of those problems. That makes it impossible for a newcomer to troubleshoot why a service isn't starting. I know from experience that I need to check both issues, but systemd prevents me from seeing MongoDB's stderr output that specifies the exact problem. systemd is a real barrier for inexperienced or junior sysadmins that can't troubleshoot blind.

The systemd fanbois are disgusting. When people bring-up legitimate problems, they go on the attack. If they spent as much time fixing their problems as they did attacking their users, we probably wouldn't have anything to complain about. Stop attacking your users.

Re:The systemd fanbois are pieces of shit

[gweihir]

This is really incredible. The ones that have moderated greenwow down have done so in the face of a clear and precisely documented and rather serious issue. This has nothing to do with facts on the systemd proponent side. (Well, it never had, but it does not get any clearer than in this example.) In fact I strongly suspect that this is paid-for manipulation by people that have sold their honor and integrity.

Re:The systemd fanbois are pieces of shit

[Eunuchswear]

Okeydoke, let's try it.

# aptitude install mongodb
The following NEW packages will be installed:
  libboost-dev{a} libboost-filesystem1.55.0{a} libboost1.55-dev{a}
  libgoogle-perftools4{a} libpcrecpp0{a} libsnappy1{a}
  libtcmalloc-minimal4{a} libunwind8{a} libv8-3.14.5{a} mongodb
  mongodb-clients{a} mongodb-dev{a} mongodb-server{a}
[...]

Let's simulate your problem:

# echo 11289 > /var/lib/mongodb/mongod.lock
# systemctl start mongodb
# systemctl status mongodb
* mongodb.service - An object/document-oriented database
  Loaded: loaded (/lib/systemd/system/mongodb.service; enabled)
  Active: failed (Result: exit-code) since Thu 2015-02-12 23:31:44 CET; 5s ago
    Docs: man:mongod(1)
  Process: 11321 ExecStart=/usr/bin/mongod --config /etc/mongodb.conf (code=exited, status=100)
  Main PID: 11321 (code=exited, status=100)
 
Feb 12 23:31:44 russia mongod[11321]: all output going to: /var/log/mongodb/mongodb.log
Feb 12 23:31:44 russia systemd[1]: mongodb.service: main process exited, code=exited, status=100/n/a
Feb 12 23:31:44 russia systemd[1]: Unit mongodb.service entered failed state.

Huh? "all output going to: /var/log/mongodb/mongodb.log"? Maybe that's why we see nothing in the journal?

In the mongodb.conf file I find:

#where to log
logpath=/var/log/mongodb/mongodb.log

And the doc says:

--logpath <path>
 
    Specify a path for the log file that will hold all diagnostic logging information.
 
    Unless specified, mongod will output all log information to the standard output.

So, let's take out the logpath and try again, and now we get the error in the journal:

# journalctl -u mongodb
-- Logs begin at Sun 2015-02-08 13:27:50 CET, end at Thu 2015-02-12 23:38:53 CET. --
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] MongoDB starting : pid=11372 port=27017 dbp
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] db version v2.4.10
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] git version: nogitversion
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] build info: Linux julia 3.16-2-amd64 #1 SMP
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] allocator: tcmalloc
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] options: { bind_ip: "127.0.0.1", config: "/
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten]
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] ** WARNING: Readahead for /var/lib/mongodb
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] ** We suggest setting it to 256KB
Feb 12 23:38:53 russia mongod[11372]: Thu Feb 12 23:38:53.858 [initandlisten] ** http://dochub.mongodb.org/core/
Feb 12 23:38:53 russia mongod[11372]: **************
Feb 12 23:38:53 russia mongod[11372]: old lock file: /var/lib/mongodb/mongod.lock. probably means unclean shutdown,
Feb 12 23:38:53 russia mongod[11372]: but there are no journal files to recover.
Feb 12 23:38:53 russia mongod[11372]: this is likely human error or filesystem corruption.
Feb 12 23:38:53 russia mongod[11372]: please make sure that your journal directory is mounted.
Feb 12 23:38:53 russia mongod[11372]: found 1 dbs.
Feb 12 23:38:53 russia mongod[11372]: see: http://dochub.mongodb.org/core/repair for more information

So, configuration error. systemd "threw away" nothing.

Re:The systemd fanbois are pieces of shit

[Anonymous Coward]

> So, configuration error. systemd "threw away" nothing.

No. I managed about forty developers and around three dozen development-related servers all running MongoDB. They're all virtual machines hosted on Windows servers so they crash pretty often and leave the lock file around. MongoDB outputs the lock file error to stderr. The logpath setting is not used for this error. I'm using the official package from:

http://downloads-distro.mongodb.org/repo/redhat/os/i686/

That error is not saved in the journal, and other than from experience, my developers have no way of knowing why MongoDB didn't start since that message to stderr is thrown away by systemd.

Re:The systemd fanbois are pieces of shit

[Eunuchswear]

Interesting. Like I say it demonstrably works for me on Debian. Mongodb don't seem to have a version for Debian Sid/Jessie yet.

What version of RedHat are you using?

(Did you ever make a bugreport about this? What number?)

Re:The systemd fanbois are pieces of shit

[Eunuchswear]

So I install Centos7 and mongodb and, in fact you are right, the error message is not written to the systemd journal.

Why?

Let's look at /etc/init.d/mongod, here's how it starts /usr/bin/mongodb:

daemon --user "$MONGO_USER" --check $mongod "$NUMACTL $mongod $OPTIONS >/dev/null 2>&1"

So, how is systemd supposed to add mongod's stderr to the journal, the mongo startup script is sending it to /dev/null.

It gets worse, even if we fix /etc/init.d/mongod to not redirect stdout/stderr it's calling the function "daemon" from /etc/rc.d/init.d/functions (sic) to launch the program, and that does:

# A function to start a program.
daemon() {
        # Test syntax.
[...]
        # And start it up.
        if [ -z "$user" ]; then
          $cgroup $nice /bin/bash -c "$corelimit >/dev/null 2>&1 ; $*"
        else
          $cgroup $nice runuser -s /bin/bash $user -c "$corelimit >/dev/null 2>&1 ; $*"
        fi

So if /usr/bin/mongod writes to stderr then systemd never gets to see it because of the fucked up centos sysvinit scripts!

Yes, it's the sysvinit scripts that are preventing you seeing the message, not systemd!

Wow, the moderation here is now crap

[Anonymous Coward]

Why in the hell was this post marked a troll? I wasted three weeks on and off trying to get fail2ban to work on Red Hat 7 under systemd, and it does not log any of the reasons why it fails to start. After realizing I should try to start fail2ban by hand rather than by systemctl, it took me less than twenty minutes to get it running because I could see the error messages. It was because I forgot to install iptables (stupid me!) and because SELinux was preventing it from accessing /run/log/journal. systemd's policy of hiding the error messages you need to see is ridiculous. There is no justification possible for such a stupid decision. It seems almost like it was done maliciously.

PS: Why is it called systemd, but the systemd people insulted and attacked people that wanted the command line program to be named systemd? Instead, they name it something unrelated, systemctl. How in the hell is a new user supposed to make that leap of nonlogic? Why not use sensible names?

Re:Wow, the moderation here is now crap

[gweihir]

I really hate to say it, but intentional sabotage looks more and more likely. There are just too many instance of things that are either utterly stupid or intentionally malicious.

Re:Wow, the moderation here is now crap

[Anonymous Coward]

Why in the hell was this post marked a troll?

Because the bug has nothing to do with systemd? If a daemon doesn't log something, then it is hardly the loggers fault for not capturing the data it was never sent.

I see no evidence that anything else is going on here.

Re:Wow, the moderation here is now crap

[hitmark]

About your PS, they also keep boincing between "systemd can do so much" and "systemd is just a init!".

It is like they insist on not giving the init part a separate name in face of the scope creep, and instead using the confusion to frustrate opponents and brandish them clueless in the eyes of onlookers.

Re: Wow, the moderation here is now crap

[Anonymous Coward]

i hope you are being sarcastic.

systemd attitude: it aint our fault.

Re:Wow, the moderation here is now crap

[Eunuchswear]

Tomorrow I'm having my best developer look at the source to systemd from https://github.com/systemd/systemd.git and I'm going to see if he can track down the problem.

Please ask your best developer to look at /etc/init.d/mongod and /etc/rc.d/init.d/functions.

I think you'll find that it's the mongod init script and the CentOS/RedHat svsvinit functions that are redirecting stderr, systemd is never getting the message.

Re:Wow, the moderation here is now crap

[Anonymous Coward]

They don't give a damn about their users. Instead of addressing this legitimate bug/design flaw with systemd, they mark this guy as a troll to hide his post. They attack users and hide complaints rather than fixing problems. This is disgusting.

Posting as an AC so I won't lose karma when one of those jerks inevitably moderates this post down.

systemd runs on my rincky dink Pi just fine.

[anwyn]

I run a service on my Raspberry Pi that distributes hardware random numbers to my lan. For computers that don't have a hardware RNG. Just to see what the fuss was about I converted this Pi to systemd. It worked fine. The unit files were easier to read and write.

On my desktop I run debian testing. and I converted to systemd, with out knowing it, just by doing periodic updates.

Systemd is still free software. All the source is published, and it can be forked at any time. We need this functionality. It is a good thing that it has been redesigned to work smoothly together.

If the complainers really wanted to help, they could do a security audit instead of bellyaching!

If pottering becomes unbearable, the project can be forked. A lot of powerful forces need this project to work, so I suspect it will.

Its just a lot of whining and bellyaching from people who don't want to do anything.

SystemD and complexity

[Anonymous Coward]

Linux is certainly getting more complex but at the same time, it has managed the complexity of modern computers easily. In fact, each generation of Linux has been a pleasure to use and to explore. I've been a user of Linux since 0.94 (pre-slackware). Linux is a Hero for keeping the Linux source clean, simple and straight forward and in plain C. It's a work of art. An off the wall example is the Comedi interface is beautiful at taking something as complex as controls and measurements in a *Nix* environment and bringing them into a standardized API to program against.

It's what I see periphery to Kernel where simple is being complexified with hidden abstractions. On thread about really stated that issue well. Systemd is the antithesis to efforts at bring an aesthetic quality to the various distributions. Systemd is a program that seems to be sketched out in some computer science class without thought about how it would be utilized in the real world. It should have been a failed experiment except that some measure of politicking brought this abomination of complexity into a full blown standard that all distributions will be forced to adopt. Those that don't adopt and submit will be put into the oblivion of non-existence through software creep and raging dependencies.

Systemd looks to me to be the first piece of software for Linux that looks worst than it predecessors in all respects. In terms of pure chess-board complexity, Systemd takes the prize!

Agreed!!

[dentar]

I do not like upstart or any of the other new sysv init replacements. They add levels of complexity and don't seem to add any functionality that a good shell scripter can't solve with a homebrewed script, for the one percent of boxes that need something custom. NetworkManager took years to "just work" right, especially for wireless. I -still- wind up turning off selinux for some servers due to the hassle.

98% of the posts here

[Anonymous Coward]

98% of the posts here:

"It's so HAAAAAARD."

"I have to relearn things."

"That mean guy Lennart, he's so pushy and ugly too! He kicked over my lego tower and I don't like him."

"ingenius tipps for an optimal system"

[burni2]

this is not a typo it's the from german hard translated headliner of the Sep/2014 monthly of the german Chip Linux magazine.

it also stated
- adjust unity
- remove crap
- increase speed

So, yes, most distros are either a heavy crap loaded like a lenovo-compaq-hp-acer craptop, or are uncomfortable as hell-

I stopped being aggrovated, I just started to use FreeBSD some 15 yrs. ago. when Mandrake turned bad and gotten fuzzier each release.

Luckily Red Hat is not the only distro

[Anonymous Coward]

And that Red Hat sales go down is not just due to the turn in economy. It's people looking elsewhere, for something that lets people do their jobs. Systems that let you write simple scripts where you don't have to look up layers upon layers of abstractions to find out things. Where things are in plain text in known locations and names. Where you can copy configuration files from one machine to another without having to rewrite them or assemble a package of ten files from five different places.

You're right, but I think Red Hat sales are going down because

1) they don't listen to customers and never have, and

2) Erik Troan, who built what customers wanted without ever actually listening to them, has left.

Red Hat has evolved itself into something no specific customer really wants more than they want a competing product.

Dbus, HAL, systemd, all this half-implemented GUI stuff... it's too unpolished and counter-intuitive for the clueless, and too complex for the clueful, basically because they keep trying to reach for the former market at the expense of the latter.

The clueless are happier with a mac lappie, and now that MS-Windows has Powershell and headless installs it's actually more targeted at the clueful than any Red Hat product is.

"We are confronted with insurmountable opportunities." -- Walt Kelly, "Pogo"

Re:Luckily Red Hat is not the only distro

[arth1]

Dbus, HAL, systemd, all this half-implemented GUI stuff... it's too unpolished and counter-intuitive for the clueless, and too complex for the clueful, basically because they keep trying to reach for the former market at the expense of the latter.

I could live with hal. It provided useful functionality. Although whoever created the command line interface to hal must have been a masochist who loved typing and had an aversion to allowing more than one qualifier per command.

for udi in $(hal-find-by-capability --capability storage); do
    if [ "$(hal-get-property --udi=$udi --key storage.removable.media_available)" = "true" ]; then
        hal-get-property --udi=$udi --key block.device
    fi
done

Re:Luckily Red Hat is not the only distro

[hitmark]

Or used a modern shell.

Pulseaudio

[phorm]

The thing with Pulse is... while it probably *did* turn off a lot of people in the desktop arena, it could in some ways be worked around (usually by killing it), and it didn't much affect the server arena where Linux tends to be more popular.

Now... we have RHEL7 etc foisting it upon admins, and when it breaks it breaks badly and is very hard to diagnose.
And yes, I personally have experience with this - albeit not on a RHEL machine - after an upgrade made it unbootable for an older kernel which I still had some need for.

Filesystem structure

[phorm]

I've tended to see this as

usr - Generally binaries and libraries, stuff that doesn't change much
var - Transient/variable files, stuff that changes fairly frequently, cache, package lists, mail messages, logs (/var/log) etc
etc - Configuration files, initialization scripts

This is somewhat variable with the use of /opt or /usr/local/xxx but for most part this has been fairly consistent across most *nix systems I've used.

Re:Filesystem structure

[nine-times]

Yes, I agree that you're used to it.

3 things for your spring cleanup!

[Anonymous Coward]

1. Systemd
2. Polkit
3. Pulseaudio

Or just Poettering. That'll do.

You're right. The shills are incredible!

[Anonymous Coward]

Punishing this guy by hammering his post down to a -1 and marking him as a troll is ridiculous. He posted a problem and documented the problem well. As Linus Torvalds has pointed out several times, the systemd guys ignore bug reports and user requirements. They just don't give a damn. I've had the same problem with MongoDB package from the official 10gen repository so I know he is right about this systemd problem. Starting MongoDB outputs the error when you start it by hand and systemd hides it. It hides the information we need to manager our servers.

Derp

[Anonymous Coward]

Open Sores developers realize that to actually give people what they want, things get complex. News at 11.

I agree

[mo0n_sniper]

I agree with John, Linux is not as fun to use anymore. And I'm not that old into Linux.

Dotage much?

[bitterblackale]

I see that Linux is now mature. Why? Because there are people who complain that "It was simpler my day. We didn't have all those extra features. If you wanted to use Linux, you had to KNOW Linux... and it helped if you knew Linus, too!"

Proof the systemd shills are liars

[Anonymous Coward]

> Where did you get the idea that this is "policy"?

Because complaints to the mailing list are ignored and the posters insulted. Here's one example I saved that I just ran on an updated CentOS to confirm that it is still a problem. This shows the systemd guys prevent the troubleshooting sysadmins need to manage our systems. The test:

# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)

# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target

[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh

[Install]
WantedBy=multi-user.target
EOF

# cat /root/broken_systemd.sh
#!/bin/bash
echo "Example systemd service"
echo "Error that should not be thrown away" >&2
exit 1
EOF

# chmod +x /root/broken_systemd.sh

# systemctl start broken_systemd ; echo $?
0

# journalctl -u broken_systemd

Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.

It shows that the kids running systemd don't get the concepts of stderr or exit statuses.

Re:Proof the systemd shills are liars

[Eunuchswear]

Ok, just tried it on recent Debian sid:

# systemctl start broken_systemd
# echo $?
0

Interesting, but:

# systemctl status -l broken_systemd
* broken_systemd.service - Broken systemd example
  Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
  Active: failed (Result: exit-code) since Thu 2015-02-12 21:49:30 CET; 2min 0s ago
  Process: 8831 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
  Main PID: 8831 (code=exited, status=1/FAILURE)
 
Feb 12 21:49:30 russia broken_systemd.sh[8831]: Example systemd service
Feb 12 21:49:30 russia broken_systemd.sh[8831]: Error that should not be thrown away
Feb 12 21:49:30 russia systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 21:49:30 russia systemd[1]: Unit broken_systemd.service entered failed state.

Looks like your version of systemd is broken.

I have

# dpkg -l systemd
[...]
ii systemd 215-8 amd64 system and service manager

Re:Proof the systemd shills are liars

[Eunuchswear]

Ok, just tried it on recent Debian sid:

# systemctl start broken_systemd
# echo $?
0

Interesting

The problem with the exit code is that you're missing "Type=forking" in the service file. If I add that then I get:

# systemctl start broken_systemd
Job for broken_systemd.service failed. See 'systemctl status broken_systemd.service' and 'journalctl -xn' for details.
# echo $?
1

So it looks like you've got:

1. CentOS bug losing stdout/stderr
2. User error losing exit status

systemd shills may be liars, but systemd haters display symptoms of idiocy.

Re:Proof the systemd shills are liars

[Eunuchswear]

> Where did you get the idea that this is "policy"?

Because complaints to the mailing list are ignored and the posters insulted. Here's one example I saved that I just ran on an updated CentOS to confirm that it is still a problem. This shows the systemd guys prevent the troubleshooting sysadmins need to manage our systems.

So, while we're busy accusing people of being liars, care to give a link to the "complaint to the mailing list" or bug report you made for this problem.

Because so far I can't find it.

Re:Proof the systemd shills are liars

[Anonymous Coward]

You systemd bashers are all old out of touch pieces of bearded shit UNIX dweebs. You expect the entire world to conform to your out of date standard that exit statuses are respected. Guess what? That is stupid. No one does that any longer. That is why systemd takes the modern design of considering the status to be garbage. It throws it away by design. Get over yourself. Besides, if it was such a fundamental problem, then it wouldn't take your kind so much bash nonsense to reporduce it.

Re:Proof the systemd shills are liars

[Anonymous Coward]

Because complaints to the mailing list are ignored

As they should be. Attacks like this on any open source project must be ignored, or it becomes too painful to deal with the trolls. Your kind needs to be more forward thinking. Yes, there are some serious bugs that make it harder to manage Linux servers, but by attacking systemd so irrationally and so hatefully, you are hurting the future of Linux. You need to see the bright future systemd brings rather than bitching about minor bugs that prevent your servers from working. Your kind is the equivalent of the people that bitch about the amount they owe in taxes after winning the lottery. Keep your eye on the prize. Stop attacking us! Stop your whining! Stop your bitching! Get a damn life.

Re:Proof the systemd shills are liars

[Anonymous Coward]

> It shows that the kids running systemd don't get the concepts of stderr or exit statuses.

So what. I've interviewed a lot of junior sysadmins the past few years, and they simply just don't grok the concepts of exit status or stderr. systemd is correct to move on from those out of date and hard to understand concepts. I like the fact that errors are hidden from my admins. That means they ask me fewer stupid questions. If something breaks, then I get asked questions and have to take action. There are no false positives like with SysV init scripts. Microsoft figured-out a long time ago that the best way to make a computer easier to use was to hide what you need in order to work. systemd takes that concept even farther.

Re:Proof the systemd shills are liars

[Anonymous Coward]

> missing "Type=forking" in the service file.

That's not the right solution if the documentation for systemd is correct. The man page for systemd states:

"Type=...If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up."

That shell script obviously doesn't fork.

Re:Proof the systemd shills are liars

[Anonymous Coward]

don't get the concepts of stderr or exit statuses.

Who cares? Those concepts are over forty years ago and no longer relevant to a modern OS. systemd is doing the right thing by ignoring them. Do you really think the average new Linux user understands those concepts? No. They just want their USB harddrive to work when plugged in and for their wireless Ethernet to not be that hard to configure. By distracting from those sort of important problems with crap about stdout vs stderr, your kind is harming Linux.

Re:Proof the systemd shills are liars

[Eunuchswear]

You are, of course, totaly correct. My suggestion was rubbish.

Think about it, the original "problem" was that launching the "broken_systemd" service with systemctl gives no error, and returns no error status.

But how could it? Imagine that "broken_systemd" runs for three hours and fails. Do you want systemctl to hang around until it fails. Or for three minutes? Or three seconds? Where do you put the arbitrary limit?

systemctl start starts the service. It will tell you if the service can't be started (if the program can't be found, or if there is a startup script (Type=forking) which fails) but it can't tell you that the process started will fail at some time in the future.

Re:Proof the systemd shills are liars

[Eunuchswear]

Ok, I tried it on Debian and it works.

Now what happens on CentOS.

Script started on Fri 13 Feb 2015 01:50:00 PM CET
 
[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)
[root@localhost ~]# systemctl start broken_systemd
[root@localhost ~]# systemctl status broken_systemd
broken_systemd.service - Broken systemd example
  Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
  Active: failed (Result: exit-code) since Fri 2015-02-13 13:59:11 CET; 23s ago
  Process: 16880 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
  Main PID: 16880 (code=exited, status=1/FAILURE)
 
Feb 13 13:59:11 localhost.localdomain systemd[1]: Starting Broken systemd example...
Feb 13 13:59:11 localhost.localdomain systemd[1]: Started Broken systemd example.
Feb 13 13:59:11 localhost.localdomain broken_systemd.sh[16880]: Example systemd service
Feb 13 13:59:11 localhost.localdomain broken_systemd.sh[16880]: Error that should not be thrown away
Feb 13 13:59:11 localhost.localdomain systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE)
Feb 13 13:59:11 localhost.localdomain systemd[1]: Unit broken_systemd.service entered failed state.
[root@localhost ~]# exit
 
Script done on Fri 13 Feb 2015 01:59:56 PM CET

Works for me.

Re:Proof the systemd shills are liars

[Eunuchswear]

Moron. systemd throws nothing away.

Re:Proof the systemd shills are liars

[Eunuchswear]

Moron. Complaints should not be ignored. It is possible that the original complaint or bug report didn't include enough information.

You need to get a life, preferably in some sphere that has no impact on real human beings.

Re:Proof the systemd shills are liars

[Eunuchswear]

systemd is correct to move on from those out of date and hard to understand concepts. I like the fact that errors are hidden from my admins

Moron. systemd is hiding nothing. You are a brainless troll.

Re:Proof the systemd shills are liars

[Eunuchswear]

Fuck off you tedious troll. systemd is hiding nothing.

Re:Proof the systemd shills are liars

[buchanmilne]

It shows that the kids running systemd don't get the concepts of stderr or exit statuses.

No, this example shows that in previous 'init systems', the init system was adding no value after the default runlevel was reached. You were basically just running a script, and you had the option to check its return value. It just so happens that the init system would also run this script when changing to the relevant run level (but not in exactly the same way).

In systemd, systemctl tells systemd to start the service. systemctl doesn't exec the script in question itself.

The difference is that, under e.g. sysvinit, while a server remains at a specific runlevel, init scripts are no different than any other scripts. This also means that there are potential problems, where the last person to have started the service may have had different environment variables which made the service work (PATH, LANG, LC_ALL, JAVA_HOME etc. etc.), now when it fails (or the machine is rebooted), you (or init, in the one case it actually does something) try and start it, and it doesn't behave the same way. Go compare the /proc/$pid/environ for a service on a sysvinit box that was started at boot to the environ if you restart it later. In systemd, since systemctl isn't forking the init script (or similar), a clean environment can be gauranteed.

So, since systemctl isn't exec()ing the script, systemctl doesn't have to wait for the execution to finish before it returns.

Setting Type=forking will change the behaviour to what you expect. Why? In the case of a forking daemon, the init system *should* wait for the process to fork before it returns. Maybe there should be another option for Type that doesn't require a PID file but does return the exit status.

However, instead you can always call sytemctl is-active broken_systemd after-the-fact. But, if your 'service' may take some time to get through it's initial checking, maybe you are better off using Type=forking.

Kind of agree

[Anonymous Coward]

The base OS install of many distributions are pretty complex. For those wanting a 'really simple' OS, you might need to roll your own rather than depending on distributions that include many convenience tools like networking, GUI support, browsers, office applications, and a full range of utilities.

My first unix like OS didn't have networking (UUCP, not ethernet), no gui, X was an add-on package. Office products didn't exist. But it was small enough to boot and run from a single 1.44M diskette. Other than floppy, disk support was added on. This was before USB or even PCI. ... Small, easy, simple, and still took 24 hours to compile from source on my 16mhz 386 with no co-processor. So some things are not so easy even then to support more memory, special devices, large disks, etc.

One reason I went to Ubuntu was 'easy device support' where it did recognize all my devices and I didn't have to download everything for each device (driver for devices, graphic display, etc). Ubuntu has become a lot 'bigger' over the years so I moved to other variations that kept the core of what I wanted and not some bloat I didn't use or like.

Code bloat seems to be a real hazard, once we add all the features we NEED, then we get creaping featurism by people adding things on various WANT lists.

Awesome script!

[Anonymous Coward]

I wish I had you on my QA team. On a CentOS 7 system updated just this morning that admittedly also has a ton of extra packages from EPEL that could theoretically cause this problem, I was able to reproduce this serious systemd design problem.

I've seen this problem before with OpenVPN. I had a bad argument in the /etc/systemd/system/multi-user.target.wants/openvpn@openvpn.service file that I wrote:

ExecStart=/usr/sbin/openvpn -daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf

It was a missing minus in front of daemon. There should be two. OpenVPN outputs the error to stderr. That error message was not saved in the journal. It took me half a day to find the problem because systemd didn't log the error message. This shows a fundamental lack of understanding of the requirements of what an init or service start/stop system needs.

systemd is the wrong direction.

[metzjtm]

Has everyone forgotten about Occam's razor. A lot of simple is far better than a few complex.

systemd guys prove they're assholes again

[Anonymous Coward]

Moderating a guy downward all of the way to -1 that explained a bug and is offering to try to fix it is disgusting. Attacking the people that are trying to help will destroy any open source project. This proves that when Linus said systemd is "much too cavalier about bugs," that he is correct. Why attack the messenger?

Lennart Poettering works for Red Hat. Red Hat should have the best systemd implementation, but we have had several problems, like the not logging stderr one mentioned above, that have stumped their support. The support that we pay a lot of money per year for. A year ago, my CEO approved my Red Hat budget without asking a single question. This year, he is asking a lot of questions, and most of them are about systemd-related problems that have been escalated all of the way to him. systemd is a major problem for Red Hat.

NO

[NewYork]

NO as per http://en.wikipedia.org/wiki/B... and https://en.wikipedia.org/wiki/...

WIFI support on Linux seems great nowadays

[Anonymous Coward]

As long as your card's chipset is supported, Linux seems to play pretty effortlessly with wifi. I had to relearn my wifi setup recently as I developed/started noticing a memory leak in madwifi and had to switch to builtin atheros and hostapd (grumble-grumble). However, it was MUCH simpler than expected, simpler than the old madwifi setup, and worked more-or-less out of the box.

This was done on a headless router, so your GUI of choice may do things differently. The underlying aspects of Linux and wifi seem much improved over past years, in my experience.

(Now, if you just grabbed a card off of a Best Buy shelf and ran into problems with it, that's basically your fault for tripping over the first hurdle.)

The systemd issue may give a clue...

[gweihir]

(Reposted on request, with minor edit...)

What I see going on with systemd is this:
- No technical merits of systemd that are important or critical, just some convenience issues
- Systemd is in hurried development, a stable feature set is nowhere in sight
- The development leads are known incompetents with inflated egos and no communication skills
- There are a number of design decisions that are very, very bad for security and stability

At the same time I see:
- Systemd is pushed strongly with emotional (not factual) arguments
              This is a coordinated and targeted propaganda campaign. A campaign focused on technical
              merits is not even attempted seriously.
- Systemd opponents are ridiculed, insulted and their arguments are not taken seriously
- Systemd is getting very hard to avoid

I can only deduce that there _must_ be one of or a combination of the following going on:
- Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
- Linux did not generate enough support revenue Red Hat and this is intended to fix that
- Red Hat wants total control over Linux and systemd is their attempt to establish that

So if it walks like a duck, quacks like a duck, the most probable explanation is that it is a duck and hence I conclude that something nefarious is going on and the last three items are the most likely candidates IMO. I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves. They must have significant, coordinated help, with significant propaganda and manipulation experience. Whether it is military PsyOps or just commercial PR, the effects are the same. And they are massively negative and destructive for Linux and its community if not repelled decisively.

Re:The systemd issue may give a clue...

[messymerry]

Thanks for this interesting post. Do you know if LInus has published any comments on this??? Sigs are for smoking. In my case see below:

Re:The systemd issue may give a clue...

[gweihir]

Thank you. Linus seems to want to stay out of this:

    http://www.itwire.com/business...

Personally, I think it is a matter of him not having had any real problems with it so far and hence this may change at any time. He has blasted the systemd developers in the past, but not systemd itself.

Re:The systemd issue may give a clue...

[messymerry]

Thanks for the reply. That was a good (long) article. I think I will just take a "wait and see" attitude on systemd for the time being. I am very frustrated by software bloat especially in the browser arena. Also, the dumbing down of user facing software and hiding of controls is very frustrating and somewhat disheartening. This activity serves only to benefit the elites by making it harder to ascertain when inappropriate activities are being conducted. I sincerely hope the Linux community corrects it's trajectory on this and chooses not to participate in this 21st century IT insult. Lots of lip service is given to transparency while at the same time hiding everything that is not nailed down.

Re:The systemd issue may give a clue...

[petrus4]

And they are massively negative and destructive for Linux and its community if not repelled decisively.

Sadly, they are not going to be repelled. Reddit's main Linux sub is almost completely supportive of systemd. Say anything against it whatsoever, and you will be trolled and downvoted into oblivion.

On the other hand, I don't completely agree with you at this point, about systemd being entirely devoid of technical merit, or at least not in the minds of some. While I don't like the idea of it myself, I've encountered several people who've looked at it and think that many of its' features are worth keeping, but that the overall design is bad and needs to be re-worked.

In other words, it's given us some good features, but they will probably need to be re-incorporated into another project, with a better overall design.

Linus Torvalds confirms Linux is too complex:

[Anonymous Coward]

Linus himself says that Linux is too complex. And bloated. I think the word we need to use is "bloated", not complex:
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/
"...Citing an internal Intel study...Linux performance had... dropped about 12 per cent over the last ten releases. "Is this a problem?" he asked.
"We're getting bloated and huge. Yes, it's a problem," said Torvalds.
Asked what the community is doing to solve this, he balked. "Uh, I'd love to say we have a plan," Torvalds replied to applause and chuckles from the audience. "I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse...."

Linus says:
http://www.tomshardware.com/news/Linux-Linus-Torvalds-kernel-too-complex-code,14495.html#comments
"...Torvalds recently stated that Linux has become "too complex" and he was concerned that developers would not be able to find their way through the software anymore. He complained that even subsystems have become very complex and he told the publication that he is "afraid of the day" when there will be an error that "cannot be evaluated anymore...."

So there seems to be some merit for to this article, that error messages are not clear, etc. If you can not evaluate an error anymore, how can you debug Linux? Linus Torvalds needs to do something! Linux is too messy right now, with five different buggy sound APIs, etc etc. I think Linux should have a release with only bug fixes and refactoring, cleaning up the >15 million lines of code. The entire Windows NT 4.0 including graphics, kernel, etc etc is 4 million LoC or so. Linux is only a kernel, nothing more, it should be slim. Not huge. Factor in gnome and graphics, systemd, etc - and you get far much more than 15 M LoC. How much more? Maybe... 50 M LoC?

Windows is getting slimmer (WinMin kernel was the first step in reducing kernel size) and Win10 is smaller than for instance, Vista. Linux is growing, not shrinking.

Yes and no...

[chris_clay]

Linux is more fragmented, but that is because of much higher development activity taking place these days. And this is a good thing, because there are more choices and alternatives, more than ever. However, this also adds confusion to newcomers so we must focus on educating if at all possible. Stick with mainstream distributions, and with the defaults to start with before becoming more familiar with the OS. Is Linux too complex? Only if we install everything on our systems. Start with the minimal installation and go from there. That's how I handle a lot of my server installations, and even using the latest CentOS/RHEL, starting minimal allows the servers to run VERY efficiently and get very high response times. GNU/Linux is unique and allows us to install minimal components and tailor the install to the system. Windows has stripped down versions as well, but is still very bloated in comparison.

FreeBSD and OpenBSD

[obscuro]

I hadn't touched the BSDs (with the exception of Mac) in nearly a decade but recently had reason to dig into FreeBSD and OpenBSD. I installed both, played around and dug into some work related to my goals. This will sound funny, but I almost wept. They were both so straight forward and HELPFUL!! The errors suggested paths for getting it right the next time. The documentation was up to date and made perfect sense. Everything was where and what the documentation said it would be and where I intuitively wanted to look for it. The config files had nice big comments and helpful examples you could uncomment and use. There was just no noise.

I ended up choosing FreeBSD for my project for convenience sake. Some packages I needed were being tested on FreeBSD. But OpenBSD is BEAUTIFUL. If security is your top concerns it's worth ANY hassle to run it.

I've administered Linux on servers and on desktops/laptops since 1998. I ran RedHat, Fedora and then Ubuntu on my laptop from 2000 till 2011 when I got a started using Mac a lot more.

I started out with Linux a little late. In 1996 I bought that Gray Box with the Red Hat on it when it started selling at Fry's. That box came with a book. I was a Windows admin at the time and the mix of dlls, config files and registry entries was just getting annoying. I was playing the the pre-release of NT 4.0 and worrying about all the shit they moved out of userland and into the kernel. I remember going through the Red Hat book that came with that box, reading man pages and falling in love. It made sense. I got excited about knowing where to look and having pretty much ONE set of things to know for all the configuration files and shell work. I felt like if I did my homework and took an action, it wouldn't betray me.

FreeBSD made me feel that way again but MORE. It's an operating system you can master with the necessary services to do anything.

As the opportunities arise I'll be switching to one of the BSDs. I'm already running some of my cloud services on FreeBSD 10.1. There are more services in the cloud for Linux but it's worth the extra bits of work to me. And I'm constantly pleasantly surprised that the work I prepare for has already been done somewhere or is easier than I thought it would be.

If you feel like Linux is getting too complex. There's and alternative *NIX out there worth a good hard look.

OpenBSD is the way, the truth and the light.

[Anonymous Coward]

OpenBSD is the new Linux. Has all those characteristics you say you miss about Linux Simple, clean, readable, sweet! The only drawback is the limited software one can run on it. (e.g. I can't get Julialang to run on it, nor LightTable)

TL;DR

[Anonymous Coward]

"Things used to work some way that I was familiar with. I liked it. Now things are different. I don't like it so I like to pretend that they are worse now, because the alternative is to face my (admitely understandable) failure to keep up with the rate of changes happening"

  Yeah, there is a word for that grandpa. You are old. It's fine, just accept it, Afterwards things get awesome again.

  PS: captcha : "decadent" haha