Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:Put it to rest (Score 1) 282

I agree with your first paragraph, in so far as men not being forced to provide for children that aren't theirs. Your second paragraph is, in a word, nuts.

Paternity fraud is nowhere near the same level as violent rape, nor should it prosecuted as such. Paternity fraud is equivalent to pyramid schemes, long-term cons, or any other form of white-collar fraud, and that is the level at which it should be prosecuted.

That's your opinion, that's not mine.
The basic purpose of mammals is passing on their genes.
If a man rapes a woman, violently or not, he may destroy her ability to pass on the best genes she can by messing with her ability to reproduce.
A man who raises children that aren't his own is completely denied the ability to pass on his genes, it's even worse than rape on a woman.
If he's married, it's even worse, as the initial goal of marriage with a wirgin woman, is to assure the husband that he provides for his genes, so it destroys completely any marriage vow.

I can think of at least three things that would bring me greater shame than knowing the child I've been raising isn't mine.

I agree with that, especially in our times where males even marry women who already have kids and don't want any more.
It's sad to see so many emasculated men in western societies.

Comment Re:so for some simple thing like having text error (Score 1) 89

"I think Windows continues to be standard because of "herd mentality" without technical merit"

At the end of the day, the vast majority of computer users don't care about technical merit. They use Windows because the alternatives are not better enough in any meaningful way to motivate them to learn a new OS and replace the software they already own. Particularly an OS that, no matter what advances are made, still requires far to much command line usage to accomplish common tasks or fix issues. Powerful it may be, but that command line triggers despair in your average user. Linux is great when it "Just Works", but when it doesn't, the thin veneer of usability on top of the OS starts to show through.

Way to throw away a good argument in the OP just so that you can say the same bullshit again.
People using IOS or Android computers (tablets, smartphones, ...) without problem proves how misleaded you are.
These arguments were wrong 15+ years ago already.

Comment Re:so for some simple thing like having text error (Score 1) 89

I have to do some "direct [MY] thinking and find a creative, hopefully simple, solution" to get normal stderr debugging with systemd?

No, systemd doesn't eat your stderr, don't worry, that's just troll's nonsense.
As for daemons launched by systemd, it's far better than most other inits, as instead of being lost in arbitrary places, your stderr is _consistently_ put in the same place, the upstream default being in the journal.

Is that not a huge warning sign?

Of course it is. If you're a sysadmin and believe this, it's a huge warning sign that you're very bad at your job and should document yourself a lot more.

Funny you bring up windows, Matthew, I think Windows continues to be standard because of "herd mentality" without technical merit, maybe systemd has similar problem?

People should fell shame when someone not knowledgeable in a field knows more than the ones supposed to know a lot.
Document yourself, and come to your own conclusion. Besides, an OS like Windows is nowhere like an init or plumbing tool.

Maybe more simple and straightforward runlevel hierarchical solutions already mostly fleshed out would be better for developing into something more useful and less unpredictable especially in emergency situations than systemd?

No, any seasoned sysadmin that knows what they are doing can tell you what you ask for is not possible.
The design of these things, like for example how sysvinit was used, was flawed from the start. And it keeps getting worse.

Comment Re:O RLY? (Score 1) 89

I used to complain loudly when windowed desktops became the norm and I was "forced" to use them. That was a losing battle. I learned something from that. Pick your battles.

fighting against systemd a fight worth fighting because it's a security nightmare. security should always trump petty quibbles.

He's right, pick your battles. And anti-systemd trolls have picked their battle as in fact, none of them is fighting against systemd, except if they consider spewing nonsense and trolling is fighting. They all fled the battle to OS without systemd actually.
What's cool about anti-systemd people, is that you just have to take the contrary to what they say to know what is truth.
So yes, systemd is a huge improvement security wise compared to sysvinit or even other executable configuration inits.

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.

Slashdot Top Deals

"'Tis true, 'tis pity, and pity 'tis 'tis true." -- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

Working...