Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:28 websites? (Score 1) 137

To me it was obvious from day one that this "news" did not make sense. It doesn't on so many technical levels (like assuming the nameserver being one root server for all .kp, though it is never explicitely said).

One more attack against NK, completely oblivious to reality.
Everything that goes out about NK in western media is only pure propaganda, and it's clearly apparent, when on every news about NK, nobody dares saying anything against this propaganda, everything is exactly one voice of conspiracy theories like "this one or that one have been killed surely" like it's a fact.
Despite every single one of the stories like this one having been proven to be completely false.
It's terrifying to see people react like they were in the same despotic regime they believe NK is, because they know they are.
The only thing that protects NK from destruction by the USA like many other countries, is their nuclear weapons and China's support.

Comment Re:Does not replace mount (Score 1) 541

We really don't want systemd to do its "dependency logic" for mounts. Case in point: have a btrfs RAID, physically remove one of its disks and mount with -o degraded. A basic operation that doesn't involve an init daemon and is impossible to get wrong, right? Not on systemd. If your RAID happens to be in fstab (ie, any real case other than when running from rescue media), systemd will helpfully instantly unmount it again. There's no known workaround for this bug other than commenting out the mount in fstab (or upgrading to sysvinit...).

If you insist on calling this a bug, unfortunately for you, that means it is a kernel bug, and more specifically a btrfs bug. And there are three workarounds :
- managing the mount manually, which is the most sensible thing to do as all your braindead operation was manual anyway;
- fixing btrfs so that it reports degraded fs as degraded, and not as dead;
- making a user space daemon that manages btrfs, like for LVM;
The most stupid thing to do is to shoot the messenger systemd, and of course, that's what most system illiterate people like you do.
And they advertise their lack of knowledge on forums to really show people how stupid they are, instead of educating themselves.

I don't get how one could possibly screw this up. So systemd runs a daemon statting all your mountpoints just so it can unmount them if it believes some dependency isn't met?!?

Like most systemd opponents, you don't know what you're talking about and it's instantly showing.

Where rsyslog goes to great lengths to ensure logs survive a system crash, sometimes even in annoying ways (like disk spinup on laptops) and uses append-only plain text logs that are readable even when heavily corrupted, systemd not only makes corruption and total data loss nearly guaranteed, but even goes out of its way to disable data consistency features (checksums, protection from torn writes, transactions) because "performance" and spams you with warnings if you manually turn them back.

It shows that you're not understanding *anything* technical, when the link you gave contradicts what you said in the same sentence. The systemd journal is doing append-only plain text logs that are readable even when heavily corrupted. One difference with other logging tools, is that systemd actually informs you when your logs are corrupted. If you even understand logs and know their history, they were always designed to not advertedly affect the OS, so that performance was always the primary goal before reliability, thus why syslogd with UDP and the like. The log system should not put your system to a halt like it did on btrfs because btrfs, well, is just not production ready yet. They actually did that because a systemd user did a bug report. A true sysadmin with a true problem, not an ignorant whiner on a forum with no understanding of Linux.

Comment Re: Does not replace mount (Score 1) 541

This is where most of the disagreement lies: It has not turned out to be the worse model. SystemD supporters are mostly concerned with the desktop (re. the user-does-stuff-with-thumbdrive rationale given for the mount manager). On the desktop, the SystemD approach makes a certain amount of sense.

That's a false statements at several levels. The first false statement is saying "systemd supporters", framing it as a political choice. Actually, "systemd supporters" are "systemd users" that know what they are talking about practically not just in theory, and most of the time the opposite camps are people that don't know of what they are talking about. Most of them are completely computer illiterate, or at least don't understand anything about system administration, and they're instantly spotted. The second false statement is saying that "systemd users" are mostly concerned with the desktop. That's plain nonsense, and even someone who is computer illiterate understands that Linux distributions like Debian and RHEL are not mostly concerned with the desktop and still switched to systemd, and are not going back any time soon.
The systemd approach is very simple : always tell the admin when sth is going wrong. Most sysadmins have a staggeringly low technical level, I discovered this years ago.
They didn't have to care before, because their broken setups where working most of the time by chance, but spectacularly broke at times. And these people were unable to even understand why their setup was wrong, because with sysvinit and all kind of broken helpers, problems where put under the rug and nobody was aware of anything going wrong unless they went deep looking in the logs. systemd shows them their setup was broken, and doesn't silently ignore errors like sysvinit and shell scripts did. That's why all these people are mad at systemd which shows their bad skills (that they advertise on forums, being so illiterate) and claim that servers don't need systemd, because, you know, hardware or network never breaks on their servers.
Every competent sysadmin (and distro ones are among them) has had to fight an impossible battle to make things work most of the time with sysvinit, not a single one of them will claim that all was working with sysvinit. I sure don't, even though I customized lots of servers, like the ones that say all was working well, and then contradicting themselves by saying they can't modify init scripts anymore.

But many Linux users care first and foremost about one use case, and one alone: the server. And on the server the UNIX way is the right way. The only sensible way, actually. On the server things like auto-mounting a thumbdrive so a user can diddle with it are not a thing. As are most other things SystemD is trying to do. Here SystemD is only one thing: a superfluous, possibly dangerous OS on top of the OS.

This is a perfect illustration of what I said: philosophical debate to counter technical things. What is the "UNIX way"? There's no clear technical definition.
Anyway, we don't care on Linux, as Linux is not UNIX, and never worked the UNIX way.
Anyway, you don't even have to use this mount utility, and the most important thing is that whining about it won't change anything anyway.
And systemd is not an OS, but that's the kind of things computer illiterate people do.

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.

Slashdot Top Deals

"You show me an American who can keep his mouth shut and I'll eat him." -- Newspaperman from Frank Capra's _Meet_John_Doe_

Working...