Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Question from a non-Linux user (Score 1) 765

by ookaze (#49216511) Attached to: Ubuntu To Officially Switch To systemd Next Monday

The SystemD crowd are windows devs who hate 8 so much, they finally decided to get into linux. Sadly, they want linux to work like windows, so they foist their shit into it. It does make boot times faster: something sysadmins usually don't give a shit about since you don't reboot servers. Red Hat wants systemD because it will let them abstract linux (the kernel) away to the point where they can control it instead of "the community". In addition, several genuinely nice tools, UUID for disks, are being folded into SystemD so, in order to get those tools, you *must* also use SystemD.

Isn't that supposed to be funny? People on Slashdot actually believe this load of bullshit?
UUID for disks folded into systemd? systemd crowd (developers?) are windows devs? sysadmins don't reboot servers?
If that's the "knowledge" of the new wave of Linux users, I guess old Linux sysadmins won't have to fear for their jobs.

Essentially it's being bundle in with other services.

That's the only truth in this post till now.

Sadly, SystemD is not well tested enough for most people running linux on a server to trust it especially since the guy who wrote it wrote PulseAudio and people are still having issues related to that piece of shit.

Another lie. The main problem of systemd is that there's so much to do given the state of Linux init systems, that it's still a fast moving target, too fast for distros. It will stabilise when most of the features are implemented.

Pros:
* Boots fast

Cons:
* When it breaks, you're fucked
* Obsoletes 20-30 years of accepted best practices and knowledge of how to use linux tools
* No real new features
* Is network connected and running as superuser
* Is unaudited
* Is virtually untested
* Was written by a raging moron
* Is completely unneeded by a large section of people who have run linux for a long time

Essentially, it's the Windows 8 of the *nix world

This shows a lot of ignorance on even how a Unix like system works. Init is launched by the kernel, so of course it runs as super user, and no, it's not network connected, not PID 1 at least. The rest is drivel or nonsense, like it obsoletes 20-30 years of best practices and knowledge, this makes no sense, I can operate my servers with best practices that I couldn't use with sysvinit, and I still use the linux (you mean GNU?) tools the same with systemd.
Executables configuration scripts (init scripts) are not at all best practice, even less when they use configuration files of their own, scattered in several different files, and whose behaviour can be modified by the environment, making for a huge attack surface that can go undetected. That's what you call best practices? And calling people names doesn't make your argument any better.

Comment: Re:What is systemd exactly? (Score 1) 765

by ookaze (#49216277) Attached to: Ubuntu To Officially Switch To systemd Next Monday

That baffles me too.

But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).

You would not understand as you've shown below and above that you're not the audience to even start to understand what it's all about.
The minority you're talking about is the exact same that was maintaining the init scripts before, you can be assured they know what it is about. And I can perfectly understand why these people would ditch sysvinit and init scripts as soon as possible.
systemd is a good thing for a lot of reasons that you will be unable to understand, given what you write below.

I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows:
-About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know.
-The same Fedora box cannot mount /home at bootup. I have to log in as root, and mount it over command line.
-Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.

The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it.
Reading bash scripts is much easier.

Now you're spewing nonsense. This is not your experience with systemd, this is your experience with some specific version of Fedora.
Linux crashes, /home not being mounted and other problems are not fixed by searching Google blindly or reading manuals or reading bash scripts, this makes no sense at all. Reading init scripts wouldn't help you understand what is going on.
There is one thing to do in this case : searching for logs that will give you a hint at your problem (the error at bootup is not enough), to have a start of an understanding of what's going on. That's the basic and you don't even have that. Fortunately you have the sense of not being vocal about systemd when you don't have the basics of system administration. Other vocal people don't even have that common sense unfortunately.

Comment: Re:Why systemd took over (Score 1) 765

by ookaze (#49216177) Attached to: Ubuntu To Officially Switch To systemd Next Monday

Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.

Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.

What you are saying doesn't compute. If the init scripts were working well in the last 20 years, why do you need distro maintainers to maintain them? Why is there the fear of these init scripts rotting away if not tend for?
Real sysadmins who have worked with these damned init scripts and are not lying to themselves know perfectly why.
Init scripts are flawed by design on a dynamic kernel like the Linux kernel, and this problem was there before 2000 already.
That's actually one of the main huge benefit of systemd, with gettiong rid of executable configuration files (init scripts), which are a huge surface attack on any sysvinit system. I have seen countless security issues related to bad things done in init scripts, like for example creating temporary files or directories, which is handled securely by systemd.

Comment: Re:What is systemd exactly? (Score 1) 765

by ookaze (#49216093) Attached to: Ubuntu To Officially Switch To systemd Next Monday

But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.

Yes, these scripts are workaround for the deficient sysvinit, like trying to guard against environment tampering, managing user options without modifying the init script itself (often scattered over several locations), ...
systemd removes these nonsense scripts and replaces them with a simple configuration file (a unit) without any drawback. You can even modify the systemd units, with your modifications usually still valid after an upgrade (it won't work if your unit is renamed to something else than apache2).
This just shows how horrible init scripts were. It's even worse when you know you can manage isolation like chroot, or security features very useful for a web server like hiding filesystems or directories from the daemon.

Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.

This is correct, except for the bunch of people unfamiliar with modern OS operation. Their goal was to reduce this number, which doesn't solve any use case I know for big servers, except reduce attack surface at boot perhaps, this I can agree with.
For smaller servers and limited resources systems, like embedded systems, the efficiency is very welcome. My security frontends say thanks to systemd.

Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.

*Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.

Actually, systemd works far better with my use cases. It works far better with LVM2 for instance, than my shell scripts ever could.
Actually, it works every time now with systemd. mysql and apache works far better now, especially mysql which was a pain to start and especially to stop with the initscripts. Now with systemd it's far better.
I agree there's some tuning to do at first, but not the kind of bad hacks we had to use with init scripts.
The attack surface of init scripts was also huge, without any hope to discover it without constant monitoring. Some init scripts had 4 (yes four) different ways to configure them, each one could be exploited.

Comment: Re:What is systemd exactly? (Score 1) 765

by ookaze (#49215893) Attached to: Ubuntu To Officially Switch To systemd Next Monday

The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems.

There is no such "established-over-decades code in scripts" in the real world, which is why sysadmins around the world constantly had to tinker with these scripts. This is also the exact reason why if no one cares about them, these init scripts will wither and die.
The most important plumbing init scripts are flawed by design, init is flawed in a dynamic environment like the one created by the Linux kernel, which is why everyone wanted to flee it since a long time. But sysadmins and distro makers couldn't agree on anything until systemd.

Systemd is tying into everything from initial boot to how to configure your soundcard.

Actually, systemd doesn't tie into how to configure your soundcard, but if you don't understand what people are talking about, especially systemd opponents, I see why you would think that. You must believe pulseaudio is part of systemd I gather.

On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.

I don't understand why you're talking about Windows here as a party, you're not making any sense.
systemd is free software, so I assure you that you don't have to deal with undebuggable binaries, as the code to these binaries is readily available. Exactly like the source code of sysvinit or the numerous daemons launched by the scripts you're talking about.
Perhaps you believe the init scripts themselves were serving as daemons, but that's rarely the case : these scripts were just there to try (badly) to understand the context to then launch "undebuggable binaries".

It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.

I don't understand what is scary about that. Your system depends on lots of binaries working as expected, starting with your bootloader, your kernel, your daemons, ...
That's the job of a sysadmin, I can assure you they're not scared at all providing they know what they are doing.

I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.

Actually you can still do that with systemd, but even better than before, especially when your keyboard is not qwerty or your character encoding not ASCII.

On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.

Why? I'm on the second side and I do exactly as advertised, even better than with sysvinit.

More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.

This was always the case in Linux, like most of the Linux plumbing ecosystem, which is not a bad thing imho, as long as the projects are active.

Comment: Re:What is systemd exactly? (Score 1) 765

by ookaze (#49215699) Attached to: Ubuntu To Officially Switch To systemd Next Monday

If you have any reason to care how long it takes for your server to boot, you're already doing it wrong.

You are plain wrong added to the fact that you're not a good sysadmin then, or one with very little experience if any.
You need a threshold of time to know if your server will go up or not.
Guess what, a server won't always go up for various reasons, especially when you have init.d scripts patched everywhere with various timeouts, that can break at any reboot. You need to monitor your server startup, and it starts to become tedious when you have tens of server startup to monitor.

Comment: Re:What is systemd exactly? (Score 1) 765

by ookaze (#49215659) Attached to: Ubuntu To Officially Switch To systemd Next Monday

it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.

There is no so called "linux design principle" of do one thing and do it well, and even if there was, it would be the contrary of what you're saying as Linux (the kernel) has a monolithic design. In the case you were talking about GNU, systemd uses the same design as most GNU software, which is a "software collection".
There is no linux principle of "everything is a text file", this is pure nonsense as sure enough, not everything in Linux is a text file (just look at sockets or block devices).
There is a Unix principle that says everything is a file, but not a "text file". You're mixing several things without understanding the purpose of what you're talking about.
Anyway, guess what, outside the United States, often the classic log files are actually binary files. Because what you describe as "text files" are actually "ASCII files" which is an encoding, but if your kernel or tools don't support UTF-8 encoding which is mostly used on Linux, you will extract mostly garbage from log files (all of mine are UTF-8 files, and yes I have log files despite using systemd). But that's nitpicking, binary log files are not a problem with systemd as you can use classic "text files" juste the same with systemd.
Finally, there's no "single subsystem" that takes a large number of roles with systemd, each subsystem in systemd has one role.

In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.

Actually, systemd is an actual huge upgrade for system administrators who manage servers, in the actual world, not in an hypothetical one.
The problem is that actual administrators, to switch to systemd, will have to manage the more or less huge number of hacks they inserted into deficient init.d scripts, which can be a huge tasks depending on if they documented them or not. And probably most didn't...

Comment: Re:What is systemd exactly? (Score 1) 765

by ookaze (#49214831) Attached to: Ubuntu To Officially Switch To systemd Next Monday

What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.

That is my understanding looking in from the outside.

Your understanding is wrong, but you're not to blame, it's understandable because those opposed to systemd have no other argument than to make you believe all the components you cited are integrated into one tool/process. Of course this is false.
systemd, the PID 1 process, manages initializing processes on bootup and scheduling jobs after boot-up, like sysvinit. It has lots of features to do these tasks even when the environment dynamically changes.
Maintaining logs is in another process, managing devices alo in another process, managing network devices in another process ...
So actually, if that's your definition of Unix "philosophy", systemd pretty much is adequate.
There is no Linux "philosophy", but you believe that because Unix "philosophy" (which has as many meanings as there are people using these words) is used to attack systemd, as if Linux and Unix were the same things. Actually, Linux (and GNU) by itself already detracts from Unix in lots of ways already.

Comment: Re:Not just Linux (Score 1) 716

by ookaze (#49039455) Attached to: Is Modern Linux Becoming Too Complex?

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.

Comment: Re:Lack of management (Score 1) 716

by ookaze (#49039409) Attached to: Is Modern Linux Becoming Too Complex?

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.

Comment: Re:Unix was built on top of a few paradigms (Score 1) 716

by ookaze (#49039245) Attached to: Is Modern Linux Becoming Too Complex?

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.

Comment: Re:What do you mean, modern? (Score 1) 716

by ookaze (#49039063) Attached to: Is Modern Linux Becoming Too Complex?

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.

Comment: Re:Why does John shut down all systemd talk? (Score 1) 716

by ookaze (#49038953) Attached to: Is Modern Linux Becoming Too Complex?

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.

Comment: Re: Why does John shut down all systemd talk? (Score 1) 716

by ookaze (#49038745) Attached to: Is Modern Linux Becoming Too Complex?

>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.

Comment: Re:Why does John shut down all systemd talk? (Score 1) 716

by ookaze (#49038723) Attached to: Is Modern Linux Becoming Too Complex?

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.

Simplicity does not precede complexity, but follows it.

Working...