Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:Is this actually a problem? (Score 1) 15

Why do you think they wouldn't accept it?

Again, for the same reason you don't like it: people who think 800 line functions are a good idea will not accept that they are wrong.

Here in this conversation, I am not going to be able to convince you that you are wrong......you would argue until you got tired of it that 800 line function are a good idea.

tl;dr: this has already been discussed and justified by systemd devs, and what you see is the result.

I'm surprised to see these kind of discussions about systemd here.
Actually I'm not anymore. I've come to expect that people critical of systemd always have a take like systemd devs are incompetent morons.
That's why they always end up being months if not years behind the systemd devs in thinking about Linux plumbing.
That leads to stupid waste of time like uselessd, when the far more competent systemd devs took the right way after some good analysis and study.
I'm just lousily following the systemd devs ML, and every single time a technical subject about systemd comes outside of the ML, I find that it was alreeady discussed, debated, thought through and resolved or a stance taken in the ML.
This is yet another case here. Why functions calling are not always a good thing with a plumbing program like systemd PID 1 has already been discussed and explanations given on the ML. And I happened to agree completely with the conclusions. Part of the reasons have been given by a poster here, and I recall there was reasons related to security, like avoiding useless and exploitable stack operations when it was not necessary.

I can attest that the patch would be rejected, as eveything said here was already discussed on the ML or elsewhere, and the result is not just an accident.

Comment Re:Systemd on slashdot (Score 1) 242

Have a look at the hundreds of inscrutable little config files under systemd's hood and be horrified.

Not if you are used to the hundred of big initscripts under /etc . I know I never was intimidated by systemd config files.

Somewhere in there and the thousands of lines of C code is the reason that systemd cannot handle a degraded raid or btrfs filesystem gracefully, but even the authors of systemd cannot find it for over a year.

You are wrong, the problem lies in the Linux kernel and btrfs implementation, the developers explained this long ago, but you're too computer illiterate to understand the explanations given by developers. You surely didn't understand that systemd by default won't use a policy that can lead to data loss, no matter how loud you yell at it. And these problems are partly policy problems, managed everywhere (even with hardware RAID) by daemons or services, that won't let you boot by default, you have to configure them to do it.

If the init scripts have gotten that complex, it's surely self inflicted damage. Just rip it all out and go with a simple script that just does what is actually necessary.

"Just do it" is the answer of clueless people that have no experience or knowledge of what they're talking about, especially when they're saying this to people with lot more experience, like distro sysadmins.
Initscripts are inherently broken in a dynamic environment, just starting with race conditions.

Comment Re:Systemd on slashdot (Score 1) 242

If you are arguing for systemd, have you ever tried using inittab or customizing runlevels? It is powerful and demanding, but not impossible. As a core *ix paradigm it forces you to skill up to the next level of mastery over your systems and understand how your processes behave.

systemd seems to abstract away that knowledge of how processes behave, like wishing for less challenges instead of more skills.

Do you realize that every single one of the anti-systemd crowd is not advocating what you are talking about (really using init), but the crazy crappy way with symlinks and everything used by every distro that used sysvinit?
You're right of course, but what you describe is roughly the same work that has to be done with systemd: trimming these insecure faulty initscripts to one invocation line.
Sometimes it's not possible and requires a shell script, but the work is the same with systemd and truly using sysvinit.
But sysvinit is really too limited compared to systemd, and would need lots of shell scripts to work properly, just to bott a Linux system, and most importantly, sysvinit needs a competent sysadmin custom configuring it.

Comment Re:Systemd on slashdot (Score 1) 242

Along with being willing to pay for a good system admin, a company has to be willing to pay for test hardware in order for IT to be successful. I've definitely worked in situations where I didn't have that, and was expected to do more with less, and then complained at bitterly when there were coughs. Sorry, kids, if you want it done right, you should pay for it to be done right. If you want it done wrong, I'll do my best.

They should always be on the lookout for ways to smooth processes and verify documentation.

And document processes — but it's easy to document your way right out of a job if your management is sufficiently short-sighted. I really enjoy writing documentation, and take some pride in it, but I'm leery of getting carried away any time it's not the point of a fixed-period contract. Even making too many templates can get you replaced with a mouse monkey. Now I know why so many design files don't have any guide lines left in them.

This there is the true reason why so called "old sysadmins" despise systemd so much: it makes everything much more simpler and faster to do correctly, and allows them to be replaced far more easily by less paid individuals.
I never thought of that, but now it's clear. Because true sysadmins could never say so many absurdities about systemd if they really tried it.
Though I think these syadmins are thinking to much into this, you still need to be a competent sysadmin to manage systemd, the countless clueless mistakes made by very bad old sysadmins (if even you can call them that sometimes) seen in bug reports are there to prove it.
I'm not worrying at all. Systems were impossible to manage correctly with initscripts, one bad sysadmin could destroy everything or compromise the security of your boxes without you seeing anything, I've seen that countless times.

Comment Re:make peace? (Score 1) 242

Seriously, have you even thought about this in any depth?

What's more safe and secure, many tens of thousands of lines of C running in PID0 with root privs, or interpreted scripts each running as root or with reduced privs in their own separate process?

It's obviously the latter.

Dangerous people like you must be discredited at all costs before young sysadmins believe your stupid sentence.
The Linux kernel proves you wrong, and obviously, the shell interpreter used to interpret your shell scripts proves you wrong too.
You're clearly not qualified to talk about this matter, and the obvious answer to your question is the opposite of the one you've given.
Shell scripts have always been unsecure, the countless workarounds that you can even find in the Linux kernel to try to mitigate the security nightmare that are shell scripts should be well understood by most sysadmins, or you're in for some surprises when you'll be a bit more seasoned.

The only compiled code is the shell interpreter, which is well tested and used all over the place with root privs already. And the shell scripts being run are trusted. Now, you can argue all the other points about the downsides of shell vs unit files. But as for security, this one is plain and obvious. All that C is just dying for a trivial buffer overflow or some other standard exploit to allow a full compromise of the system from some valid or even user-supplied untrusted input.

Oh man, you even contradict yourself, but you choose the path of nonsense anyway. Shell scripts most of the time (every time in distributions) need countless other binaries besides the shell interpreter, every single execution of which can be exploited, for example by changing the environment, even with race conditions, sth that is impossible to resolve with shell scripts if you need external ressources or even to write sth. Rootkits are very happy with initscripts actually, but they can't cope with systemd for now, if they ever can. Most of the dynamic state of Linux (disks, network, ...) need binaries anyway to be handled.
The only case when shell scripts work are with a well known customized static setup. Which breaks as soon as you change sth. Been there, done that.
Debian and its famous ifup/ifdown that never worked and will never work is another example: how many new sysadmins locked themselves out of their distant boxes, thinking that they could dynamically change their network configuration?

Yes, all that code is long overdue for a thorough audit; we're living on borrowed time as it is. How long to you think it will be until the first major exploit surfaces? Maybe then we'll have a rethink about the appalling design practices the systemd "geniuses" have foisted upon us. Having so much code running in the most critical and vulnerable part of the system is idiocy of the first order.

Systemd has already been audited and continues to be. Far more than sysvinit has ever been, and initscripts have never been audited.
A lot of initscripts are even full of very dangerious bugs or clearly unsecure, and can't be made secure because then they break and don't work anymore.
Most are impossible to secure. These initscripts need a sysadmin knowing their behaviour and constantly monitoring them to ensure they are actually running, as they just don't work.
No wonder every distro fled as fast as they could from initscripts.

Comment Re:Duh (Score 1) 785

It may remove some work for some people but it adds a lot of work for system managers by new binary logs in formats that can't be processed without special tools and a headache when it has to be reconfigured to suit the specific environment it's going to be used in.

And still there are people swearing by systemd - probably because they never have to provide support on the production systems that runs it.

Another contributing factor is that if it's hard to configure right then there will be security holes causing a lot of headache for system administrators. In most cases as long as you get something working you are satisfied even if you don't know why it's working - and then you may have a security gap the size of Grand Canyon in place as well.

Fortunately systemd arrived for the lots of bad sysadmins like you. That's one big reason why I'm glad systemd will be the default in most enterprise distributions.
Clueless admins like you must have tons of security holes in their custom made init scripts and when they use even the provided ones: that's my experience seeing clueless sysadmins working, they didn't understand anything about their revered Unix and how it works, starting with sessions.
And what you wrote show a complete lack of understanding of init scripts and systemd: what you described is actually reversed, init scripts are the far less secure things. And not even knowing that you can still have your usual log files with systemd takes the cake in cluelessness.
systemd will either remove or force improvement of all the bad Linux sysadmins out there, which is all for the better, and will lead to better secured Linux systems in the wild.

Comment Re:Duh (Score 1) 785

How does this reply to this specific topic: "Again, the point under discussion is neither KDE nor Gnome should depend on a particular init system."?

Your problem is that there is nothing to discuss, as everyone can say up to this day that KDE or GNOME don't depend on a particular init system.
I can compile a complete KDE or a complete GNOME without any dependency on a particular system.
Of course, I'll lose some features if I lack some dependencies. And I'll lose some without systemd.
But that's a distribution problem.
On my hand made systems for example, I lost the geolocalisation tied features of GNOME as I didn't install these dependencies when they required me to install 2 different major versions of these libraries.
Another example is that I lost the ability to use XScreenSaver in GNOME or KDE a long time ago, as at one point in time, it became more complicated to make it run on top of these DE, as it became unsupported. Some distros still support it though, but I made the painful choice to move along. I still use it with my XFCE desktop which I rarely use anyway.

Comment Re:Duh (Score 1) 785

It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.

Unless you mean that Linux is not compatible with your system, you're wrong. Now I'm pretty sure you're clueless or at least inexperienced.

Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried.

So you're definitely clueless. You don't understand what you're talking about. You are in an unprivileged container, but you STILL need a privileged manager in this container, and that manager is systemd. That doesn't mean everything else is privileged. Your system just won't work without a privileged equivalent to PID 1.
prctl is not a systemd prerequisite. Nothing prevents you from using /dev as a tmpfs (you can even lock its size) and you won't have access to CG as systemd will take care of them.
Basically, having your prerequisites doesn't prevent you from running a systemd in a OS container or force you to remove systemd features, as that's not what you're asking for. You're asking for an unprivileged container, which doesn't mean at all that the systemd inside the container has to have anything removed.
Now, nothing prevents you from running systemd containers with sth else than systemd, you'll just lose eveything systemd brings to the table in the process.

Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.

This doesn't make sense: you want systemd within a OS container without systemd dependencies. Use sth else, then! No one is stopping you, you can still use your sysvinit + init scripts, you're on your own anyway with your custom needs.

Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.

You are making a bad impression of yourself actually, what you wrote shows you don't know what you're doing, or what is really asked of you.

I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.

You still show you don't even understand what you're reading.
Apparently you try to use /dev as tmpfs yourself, which you don't need to do and shouldn't do, as systemd is already managing that for all your services.
And they're not talking about dropping mknod unsupported, but about dropping the CAPABILITY being unsupported. Which makes perfect sense, as in devtmpfs, the kernel is making the nodes in your /dev, which you should not touch. But in a container, the /dev is isolated from the base OS, and you have to be able to make nodes in it one way or another, and this is by using a process that have the CAP_MKNOD capability. That's because everything in your container is unprivileged. Or else you will have an empty /dev, so a container that won't work with a Linux kernel. As I said earlier, you don't understand what was asked of you in a unprivileged container, which is exactly what systemd will provide to you. But you have to understand the link you've given to know that.

Comment Re:David Edmundson answers your questions (Score 1) 785

Are you missing the point on purpose? Last time I checked, you could easily pick and choose parts of a DE to install, or what parts of a complete linux distro you wanted to install. Show me where the choice to have only systemd's init system without the other stuff is.

I'm not missing the point, you're clueless. So as to not spam Slashdot, I'll point you to how to do this :

wget https://github.com/systemd/sys...
tar xf v228.tar.gz
cd systemd-228 ; ./autogen.sh ; ./configure --help|less

Then perhaps you'll understand if you make it this far.

Really? They're kludges that don't work well at all? I've just been imagining my suspend working perfectly fine this whole time?

And there's still no reason why, if we want a power management system that provides inhibition locks, that that subsystem needs to be rolled into some monolithic "init" system. For the most part, people don't take issue with any individual part of systemd, they have a problem with the fact that the other crap has no place in something that claims to be an init system.

There are security, stability and constancy reasons, and nothing is rolled into some monolithic "init" system.
You're lucky to have your suspend work perfectly fine, that doesn't mean it was working perfectly fine for everybody, far from it.
That's what you can't understand if you live in your little world. But distro maintainers have to tackle the reality of all the other unhappy users.

Comment Re:Duh (Score 1) 785

If systemd didn't use butt-ugly APIs, it would be a lot easier to mix and match. For exampl, you want to suspend? Call /sbin/suspend which might be an suid binary, or might use a private interface to a daemon running as root (depending on need). That constitutes a nice standard interface.

A nice standard interface with lots of "might" in the definition? suid binary (insecure things we're trying to avoid at all costs)? /sbin/suspend, of which you're not even sure it's there or of its path?
And you called systemd API butt-ugly? Was that a joke post?

Want to manage a daemon? Run a manager and pass it the path to the daemon it should manage. Again, a standard interface that can be used by any init system to provide more advanced functionality.

It seems that everywhere there is a choice between a goofball tangled mess and a simple and easy to use interface, systemd is all over the former.

At least it works, I didn't see your code contributions to resolve these issues.

Comment Re:Duh (Score 1) 785

Looks over at the stock market, Apple's stock price this fine Sunday morning is $117.81.

If that is your definition of "essentially destroyed" then there is absolutely no reason to take advice about systemd from you because someone so willing to demonstrate their lack of clue proves that they don't really know what they are going on about..

Removing in the equation the huge stock buybacks of Apple ($30 B just recently) is a very convenient thing to do.
You shouldn't look at the current stock in a vacuum, it's very misleading.

Comment Re:Duh (Score 1) 785

All I can say is you've either never looked at the systemd code, or you don't know what monolithic is. The problem, of course, is that you can't have things like logind without using systemd init.

I don't need to look at the code, I just have to look at the different process ID running all these tools to immediately understand that they are not one monolithic thing.
And what you call a problem is actually a good thing, as it's necessary for security's sake.
I understand that to you security is a problem, that doesn't mean it should be. Security should be a major concern to any sysadmin, and systemd is a huge improvement compared to any other Linux init in this area.

OK, you don't know what monolithic means. The problem with systemd isn't that it adds features, features are cool. The problem with systemd is the architecture is bad. Unfortunately that isn't something I can discuss with you, because you lack expertise in the area, but if you are interested in learned more, I discussed it in depth here.

Bad architecture doesn't mean monolithic at all. Or did you change the subject?
Anyway, none of this (bad architecture or monolithic) is a problem with systemd. Linux has a bad architecture and is monolithic too, and people have complained about it too. It's specialists masturbating over nonsense. Because to this day, none of these people were able to implement a good architecture and non monolithic alternative to Linux that works at least as well. And it's exactly the same with systemd, which follows development practices of the kernel in this regard.

Comment Re:Duh (Score 1) 785

I've fixed several long time invisible misconfigurations by myself thanks to it.

Taking a cue from above, you must be a shitty system administrator because I have never seen any invisible misconfigurations myself

Why are you (a) misconfiguring your servers and then (b) hiding those misconfigurations? Sounds like you are trying to create job security for yourself.

I'm not hiding them, they were hidden by shitty sysvinit like inits and not strict enough tools. Lots of people have been bitten by them you know. Migrations problems towards systemd are mostly caused by this and init scripts.
This doesn't mean the configurations didn't work, just that they weren't correct but tolerated before systemd, and could be security issue.
But it's obvious you didn't understand the issue, as is telling by the fact that you believe sysadmins always make perfectly correct configurations everytime.
A working configuration doesn't mean it's correct, but I lose my time explaining that to someone that clearly has no knowledge or understanding of sysadmin work.

Comment Re:You're running a distribution (Score 1) 785

Your post is a big tell that you are completely clueless about the issue you're trying to write about: you don't even understand what your own writing!

It sounds like KDE should have moved to supporting pm-utils instead of sticking with upower only:

http://nlug.ml1.co.uk/2014/06/...

No it doesn't sound like that at all. "Support" is WORK! XFCE chose to make the work to support an obsolete unmaintained piece of code. Gentoo, a distribution, like Devuan, made the work to support the same piece of code. KDE chose not to lose time supporting it.
Notice that Gentoo, a distribution that can be run without systemd, made it so that their user could still use new functionality in KDE, because it's the distro's responsability. Notice that Devuan didn't do what it should have done.

Random elements of Linux randomly adopting systemd as a prereq to working is, in fact, the thing that Devuan is fighting, right?

Wrong! Elements of Linux that have to manage the plumbing of Linux are predictably adopting systemd, there is nothing random at all about all of this, only for the clueless. That's what Devuan say they're fighting. They're say they fight the logical thing, so they're completely illogical, so it's only a dogma, or politics. Unfortunately, I don't see the fighting, which could be apparent through code, lots of it.

From their perspective, anything that requires systemd is itself a problem that needs to be exposed and repaired (or forked, as they were willing to do with Debian).

They didn't make Upower work. It requirs code, see? Full functionality of neest Upower requires systemd, so they should have provided the new Upower without requiring systemd (good luck!). It requires a package, so it's clearly a packaging error...

It's not a packaging error. It's yet another systemd issue, and it's totally legit to lay it on KDE for allowing one of their subcomponents to add a hugely unrelated and unpopular requirement to their functionality. Opposing this nonstop systemd creep is literally the entire reason Devuan exists. Not a packing error, a systemd error.

Yet you didn't understand this and say it's not a packaging error, lol! You don't even understand what you're writing!
You say it's a systemd issue, but Upower works perfectly with systemd! You don't even understand what you're writing!
KDE people don't owe you anti-systemd zealot anything, and your distro, Devuan, should have done the work like Gentoo instead of its users complaining upstream.
Your distro should be your primary source of help, not upstream, unless it's a very shitty distro that doesn't provide any support.
Repeating wrong things like "Not a packing error, a systemd error." won't make them true. You're in FLOSS environment here, not in politics.
Temper tantrums just won't work.

Slashdot Top Deals

We all like praise, but a hike in our pay is the best kind of ways.

Working...