SoylentNews is people
SoylentNews
A number of users have reported that running "rm --no-preserve-root -rf /" not only deletes all their files (as expected), but also permanently bricks their computers (which is not). Tracing the issue revealed that the ultimate cause was that SystemD mounted the EFI pseudo-fs as read-write even when this FS was not listed in fstab, and deleting certain files in this pseudo-fs causes certain buggy, but very common, firmware not to POST anymore. A user reported this bug on SystemD's GitHub issue tracker, asking that the FS be mounted read-only instead of read-write, and said bug was immediately closed as invalid. The comment thread for the bug was locked shortly after. Discuss.
Links:
https://github.com/systemd/systemd/issues/2402
http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/
(Score: 1, Informative) by Anonymous Coward on Tuesday February 09 2016, @02:31AM
It seems this is par for the course, things move along as expected. I need to get off my butt and move to a BSD, possibly a StD free Linux distro.
(Score: 5, Informative) by Anonymous Coward on Tuesday February 09 2016, @03:20AM
> It seems this is par for the course, things move along as expected.
It is. But not in the way you mean it.
The author of the EFI filesystem code says it is not systemd's fault. [twitter.com] It doesn't get more definitive than that.
It is (1) the motherboard manufacturer's fault for doing such a piss-poor job with their firmware that their systems are vulnerable to bricking just through software and (2) The EFI filesystem's fault for not incorporating work-arounds for broken firmware.
It is NOT systemd's fault anymore than it is the fault of anyone who manually mounts EFI in the filesystem read-write, systemd is not the only one to do that.
(Score: 4, Insightful) by Anonymous Coward on Tuesday February 09 2016, @03:33AM
This this this this this. It's comments like this that occasionally make me wish I would sign up for a login so I had mod points.
This isn't a SystemD problem. SystemD has many problems, but this is not one.
This is stupid firmware decisions on top of the Really Stupid Decision, namely that firmware can be changed without moving a physical jumper like in the Good Old Days. Nothing the OS does should be able to brick a computer. If it can, that's the firmware's fault.
This is directly parallel to SQL injections. Your database should never die because some user named Robert');DROP TABLE *;-- signed up for an account. Likewise, your firmware should never allow itself to be harmed by the user, especially not to the extent that it cannot be booted again. If this means adding a jumper to the board, add the jumper. The world would be a better place with firmware update jumpers.
(Score: 4, Insightful) by KilroySmith on Tuesday February 09 2016, @03:57AM
Perhaps I'm ignorant here, but doesn't this bug imply that SystemD is deleting things that it doesn't own? That's a bug. What purpose in life is served by SystemD reaching into the EFI FS and screwing things up?
The fact that there's a firmware bug that gets triggered by this incorrect behavior doesn't excuse the incorrect behavior.
But, perhaps there's a good reason for this behavior and I simply don't know what it is.
(Score: 3, Informative) by Anonymous Coward on Tuesday February 09 2016, @04:23AM
Perhaps I'm ignorant here, but doesn't this bug imply that SystemD is deleting things that it doesn't own? That's a bug. What purpose in life is served by SystemD reaching into the EFI FS and screwing things up?
Yes, you are ignorant. SystemD ain't deleting anything. ALL it is doing is mounting the EFI filesystem read-write - exactly as the title of the submission says.
Any deletion of EFI variables is coming from somewhere else. Like doing "rm -rf /"
(Score: 5, Touché) by maxwell demon on Tuesday February 09 2016, @07:01AM
And why does it mount the EFI file system read/write, when not requested to be the user?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Insightful) by TheReaperD on Tuesday February 09 2016, @08:56AM
It seems to be trying to do something similar to how PRAM works on MACs. A reserved space in the firmware that software can write data. I personally think that it is a really horrible idea but, there seems to be a lot of demand from some software vendors to be able to write data to hardware. Though I can see valid uses for it, such as storing your software serial numbers for reinstall (such as Windows 8/10) I see far more opportunities for abuse.
Ad eundum quo nemo ante iit
(Score: 2) by maxwell demon on Tuesday February 09 2016, @10:47AM
Well, as long as I, as user, can decide whether I want to enable it, I'm OK with such support. But if it is enabled unconditionally, for providing functionality I'm not even planning to use, that's not OK.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Wednesday February 10 2016, @09:52PM
> there seems to be a lot of demand from some software vendors to be able to write data to hardware
and systemd bends over, while $rookie_programmer_writing_code_in_his_spare_time would have had more security concerns. I am not surprised at systemd devs, overenthusiasm and wanting to change the world is understandable. But, fuck, what about RedHat? They write the drivers for linux FFS
(Score: 1, Insightful) by Anonymous Coward on Tuesday February 09 2016, @02:24PM
> And why does it mount the EFI file system read/write, when not requested to be the user?
Why does it mount /dev read-write when not requested to by the user?
You can nit-pick anything to death if you are motivated. None of this would be an issue if the firmware wasn't buggy in the first place.
(Score: 2) by fido_dogstoyevsky on Tuesday February 09 2016, @09:50PM
None of this would be an issue if the firmware wasn't buggy in the first place.
And if systemd wasn't sloppy enough to let that sort of bug through.
It's NOT a conspiracy... it's a plot.
(Score: 2) by HiThere on Wednesday February 10 2016, @04:32AM
Sorry, but theres *LOTS* of buggy hardware out there. When software is designed to run on that hardware it is *expected* to compensate for those bugs.
Yes, it's a hardware bug. It's **ALSO** a software bug.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2, Interesting) by Arik on Tuesday February 09 2016, @06:25PM
Because it's Poettering-ware and that's his philosophy. The 'user' is not intended to be a system administrator, the 'user' is conceived of as completely innocent of all computer skills and the system will be designed to ensure that s/he stays that way. It's nearly inconceivable for him to permit any increase in user control, in any area, because the entire thrust of his development is to disempower the user in every way possible.
Also, I haven't confirmed this so it may just be a rumor, but there was talk about using the R/W EFI disk to enable a remote-control reboot to windows on a dual-boot machine. Maybe that's considered a killer app over in systemD land?
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:34PM
The last comment to the bug report, by Mr. Poettering, explains why writes are enabled:
(Score: 3, Insightful) by maxwell demon on Tuesday February 09 2016, @06:41PM
And when I don't want to issue that command, then there's no point in having it writeable.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 5, Informative) by Immerman on Tuesday February 09 2016, @04:28AM
As I understand it SystemD is deleting nothing, it's simply mounting EFI in the file system as read-write.
If YOU then tell the OS to delete everything in the file system, that command obviously interacts with the RW-mounted firmware in potentially catastrophic manner, if neither the motherboard nor filesystem have appropriate safeguards in place.
Basically, you could cause this exact same problem on a SystemD-free computer simply by mounting the EFI read-write by hand. SystemD is simply taking one step that primes the system to expose the bug in other code IF you proceed to do something that is generally (but not always) considered a Very Bad Idea.
(Score: 2) by VLM on Tuesday February 09 2016, @01:05PM
If YOU then tell
Or a bug.
In this bifurcated era where smart people use pkgng and nix and whatever else and the lowliest of the noobs think "wget http:root_me_root_me_harder.sh | /bin/bash" is also a package manager, there was an example I don't remember and for some reason can't google where some commercial software shell script accidentally pulled a "rm -Rf /"
(Score: 1, Informative) by Anonymous Coward on Tuesday February 09 2016, @11:25PM
(Score: 2) by Immerman on Wednesday February 10 2016, @03:11PM
Indeed. I didn't mean to imply that you had to do it intentionally or directly, only that the user had to independently initiate the action, and that there was nothing systemD-specific about the problem.
(Score: 5, Informative) by KilroySmith on Tuesday February 09 2016, @04:36AM
OK, so this was so confusing to me that I actually spent 15 minutes reading about it.
Linux allows mounting the EFI pseudo-FS. Everybody agrees this is a good thing.
SystemD always mounts it, and mounts it RW by default, because:
When you do your "rm --no-preserve-root -rf /", the EFI filesystem starts erasing stuff - as you've requested. If, however, you're new to a SystemD-equipped system, and aren't used to the EFI FS being mounted, you will unexpectedly start screwing with the EFI FS.
A tempest in a teapot. The only problem I see here is that the choice of default mount for the EFI FS - if they had chosen ro, there'd be no issue, and "systemctl reboot --firmware" could remount the FS RW for the length of time necessary to set the variable prior to rebooting. The choice of rw is dangerous even in the case where the EFI BIOS doesn't misbehave, because unexpected write access to the BIOS variables shouldn't occur.
(Score: 2) by jimshatt on Tuesday February 09 2016, @08:49AM
(Score: 2) by HiThere on Wednesday February 10 2016, @04:39AM
I think that leaving it mounted rw when you don't need it so counts as a bug. But certainly refusing to fix the problem when it starts bricking systems counts as a bug. And an extremely bad one, though the severity of the bug is not so much in the bug itself as in the administrative process holding it in place.
Prior to this event I had thought that the problems being reported about systemd were all "teething problems" and that they would go away as the software matured. Now It looks more like they are being intentionally frozen in place, though one may speculate about the reasons for why this is being done.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 5, Insightful) by pTamok on Tuesday February 09 2016, @11:14AM
There is a principle in security, which is the 'principle of least access' - you get the minimum access needed to do your job.
In this case, systemd opening the efi filesystem as rw when it didn't need to violates that principle: it should, as you point out later in your post, only open the filesystem for rw when it _needs_ to write, given what this pseudo filesystem is actually for.
If you think this argument is wrong, reflect on why some people prefer to use strongly typed languages. In principle, you can write everything in self-modifying assembler, and treat pointers as integers and have all sorts of fun - the point is not whether you can do it, the point is whether or not you should.
Having sane defaults is a good thing.
(Score: 5, Insightful) by Thexalon on Tuesday February 09 2016, @03:08PM
You know, this is the kind of response that truly bothers me. Here we have:
- A known problem with a pretty clear description of what's wrong.
- An obvious solution, namely to mount read-write only when you actually need to, because it's dangerously stupid to have it read-write all the time (as demonstrated by the problem)
And the response from Lennart Poettering is "won't fix, because it might require a bit of extra code for a single obscure feature". That's not the response to a bug that gives me any kind of confidence that Lennart should be in charge of anything remotely resembling a critical component of most major Linux distributions.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday February 19 2016, @02:55AM
You should have seen him defending breaking su because Pulseaudio somehow didn't work alongside it otherwise.
This by using systemd's pam module to alter a xdg environment variable if your ran su or su -l, so that anything that dependend on that variable to tell them where to stash their settings file would stop the initial users settings file.
His defense was that su was a broken concept.
Then later someone offered him a fix to pulseaudio so that the variable change was no longer needed. But this happened outside the bug report discussion, and the people following it had to rely on third parties to keep an eye on the various mailing lists. Eventually i think the bug report died because it was tired to a Fedora version that was no longer supported.
Then they introduce functionality to systemd that mimics su using Linux namespaces/containers.
Seriously, the whole systemd thing is a mishmash of OSX-isms, Solaris idolation, and an attempt to bypass Torvalds on kernel details by countermanding them via the init process (disabling sysreq combos, changing mount defaults, and the list keeps growing).
(Score: 5, Insightful) by bornagainpenguin on Tuesday February 09 2016, @04:16AM
Yeah? Well my response is in agreement with you to a point---nothing the OS does should be able to brick a computer. Can you guess what SystemD just did?
Oh well it's not SystemD's fault you say. It was the fault of poorly written firmware. The manufacturer made this happen.
Maybe. But just as sure as gravity sucks, the manufacturer is going to claim, just like you did that nothing the OS does should be able to brick a computer. Then they're going to ask you if this happened while running Windows. When you tell them you are running Linux they're going to say that running Linux is not supported on that hardware.
Because nothing, NOTHING an OS does should be able to brick a computer, except now thanks to SystemD Linux does brick computers. Great going guys!
You can piss about all you want about whose fault it is, but the fact of the matter is that SystemD enabled it to happen. It was a factor. And now people are without working hardware as a result. Likely unable to get any kind of warranty support on their hardware due to running unsupported operating systems, even if the hardware were brand new.
I wonder how many other standard things in Linux are capable of causing this type of trouble once SystemD has been added to the mix?
(Score: 1, Insightful) by Anonymous Coward on Tuesday February 09 2016, @05:32AM
Yup. Never heard anyone complain about this happening with WINDOZE. Just sayin'. WINDOZE never bricked your shitty laptop here. At least not in this way.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @07:23AM
Actually, You can brick a windooze laptop, exactly in the same way and because of the same fuckup by the motherboard manufacturers. AFAIR it was a twenty-something bat file that You had to write, but still.
(Score: 2) by bornagainpenguin on Wednesday February 10 2016, @01:17AM
Look, it's not about whether or not Windows can be made to brick due to bad firmware. I'm sure that it's quite doable, this isn't the point.
The point is manufacturers are going to be able to claim that their hardware works fine in Windows, so this is the result of running an unsupported operating system on their hardware. Just like Secureboot this is about eliminating the after market use of hardware by way of installing new operating systems. It's about planned obsolescence. It's about passing the buck.
Also, let's be real here. It's not unusual to do a command wipe of the system with "rm --no-preserve-root -rf /" in *nix. It's quite a bit more unusual for some one to craft a bat file of the nature you're describing.
This is callus disregard for the hardware of others by the systemd people and their handling of this situation makes me wonder what other surprises lurk inside.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @11:04AM
nothing the OS does should be able to brick a computer. Can you guess what SystemD just did?
It has always been the choice of the OS whether or not to allow dangerous things which can easily brick a computer. SystemD just made the choice to do so.
I remember dicking around back when Linux was first coming out. Back when you had to write it to a boot sector yourself. When there was no installer. Back then I was experimenting with my own OS (not just a kernel), but at that stage I was working on my compiler and FS and decided to booted GNU/Linux to use GCC to bootstrap my own assembler.
For fun on that GNU/Linux system I decided I'd recreate a music playing program I had used on DOS. One fun thing to do is mess with the CMOS timer to modulate the PC speaker and make it play music. Older machines had a nice big PC speaker, and it could produce far better quality audio than today's little piezoelectric beepers. Back in the old DOS / BBS days computer nerds would exchange .MOD files the way normals did mix-tapes.
Linux forced me to run such x86 assembler programs as root. I made a mistake in my code and learned that bad things can happen even using the bog hardware interfaces. On many motherboards it was trivial to corrupt your CMOS and brick the machine. One could brick the hardware on MSDOS with just a few opcodes. Back then Linux made an effort to prevent non-kernel code from bricking the machine. Sadly, now it seems those days of sanity are long gone. The entropy has cropped up in its maintainer pool, and thus it's increasingly senile brain is giving way to dementia.
All things end. It's bitter sweet watching Linux die. C'est la vie! [osdev.org]
(Score: 2) by mrchew1982 on Tuesday February 09 2016, @05:10PM
The year of the Linux desktop just went down the drain! Thanks systems! (/sarcasm)
Seriously though, in concept I agree 100%… but the reality is that unless you add another init system which would take more time to boot, you have to be able to update your bootloader from software. This dictates that there will invariably be the ability to "brick" your device.
Honestly its not new behavior, ever had a bios flash go bad? That's why the high-end gaming boards include a bios backup feature of some kind, or a socketed chip.
Now, I do agree that there should probably be some kind of hardware switch to prevent wanton rewriting of the boot software. The new Chromeboxes uses a motherboard screw to bridge two contacts.
If it is necessary to write to the bootloader all the time to change variables, it seems preposterous to me to leave your entire bootloader in a read/write state. This is why partitions were invented, store your variables in a separate one with read/write acess and a failsafe set in the read only section with the main code.
Seems to me that the devs are only concerned with one thing, boot speed. They will plough under safety and security to reduce boot times by half a second. It's sad to see the penguin fall for this, hopefully we can pull back a bit.
(Score: 2) by rleigh on Tuesday February 09 2016, @05:24PM
Most of the time, you don't even need to use efivars to update the bootloader. This is located on the EFI system partition, which is a FAT filesystem on your system disc. You only need to access the efivars to change the boot order, or to add, remove or change the loader for your linux install. None of these are regular operations; I've used it twice, ever: once to tweak the boot order (could also be done via the UEFI BIOS), and once to remove an older linux install which was wiped off the disc and needed removing from the EFI settings. So you could safely leave efivars unmounted, or mounted read-only, with zero impact on normal system operation, or on upgrade. The only time you need it writable is during installation of a brand new system, when switching bootloaders (i.e. the EFI system partition file path), and when removing an old system. There are other cases where you might want it writable, but these are atypical; it would be perfectly reasonable to mount it and/or remount it r/w on these occasions; efibootmgr and other tools could do this for you.
(Score: 2) by fido_dogstoyevsky on Tuesday February 09 2016, @10:01PM
Seems to me that the devs are only concerned with one thing, boot speed. They will plough under safety and security to reduce boot times by half a second. It's sad to see the penguin fall for this, hopefully we can pull back a bit.
But speed is SO important. It's not as if anything bad can happen [wikipedia.org] (scroll down to "Ammunition Handling").
It's NOT a conspiracy... it's a plot.
(Score: 5, Insightful) by zocalo on Tuesday February 09 2016, @05:20AM
UNIX? They're not even circumcised! Savages!
(Score: 5, Insightful) by HonestFlames on Tuesday February 09 2016, @11:53AM
This reminds me of all the buggy crap causing suspend/resume fails under Linux for... well I recall it was a long time. It was because of bad / non-standard / crapp DMI table entries in most BIOS.
Windows just ignored the BIOS stuff and did its own thing, which is why we had the "Windows doesn't have this bug" disussion at the time.
There is a clear definition between fault and responsibility that should apply to systemd.
Whilst it is not the fault of systemd that users can brick their systems, it is systemd's responsibility to protect them from this scenario. If someone wants to argue that it shouldn't be systemd's responsibility, then my point is that because systemd know this issue exists and they are in a position to do something about it, they should exercise due caution and put measures in place to limit access into the UEFI data.
(Score: 3, Insightful) by zocalo on Tuesday February 09 2016, @12:51PM
UNIX? They're not even circumcised! Savages!
(Score: 0) by Anonymous Coward on Saturday February 20 2016, @11:24PM
Bingo. The prima donna act is what gets them all the flack.
If you check out how Torvalds reacts to something similar, its a case of mea culpa and going through hell to make damn sure it does not happen again.
You may call it belt and suspenders, or you may call it good engineering practices.
(Score: 0) by Anonymous Coward on Saturday February 20 2016, @11:21PM
Windows either ignores it, or the bugs come because the hardware was tested only on Windows (and MS can't help themselves going embrace, extend, extinguish on everything they touch).
Never mind that on Windows, the ODMs can paper over the bugs with drivers.
What Linux does is pull back the carpets and present to everyone how rotten the floor is.
(Score: 5, Insightful) by q.kontinuum on Tuesday February 09 2016, @06:36AM
systemd exposes this error and makes Linux less suitable as a system
for young geeks. Without systemd, a couple of mistakes must
be made to brick the laptop, one of them to explicitly mount EFI fs rw.
The user needs to conciously decide he wants to modify EFI. With
systemd, apparently is is sufficient to give one stupid command.
rm -rf / is not as unlikely as you might think: People learning there
way around the system do have a tendency to screw it up once in a
while, and I know enough people who would try rm / on a fucked up
system to either let out their frustration or out of curiosity, to see
how far the system gets.
You can call it a bug or not, but it is one of the completely unnecessary
things that makes systemd suck. Really hard.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 5, Informative) by linuxrocks123 on Tuesday February 09 2016, @06:38AM
You are technically correct -- the best kind of correct ;)
There are a number of things that need to happen for this disaster to occur:
- Someone needs to mount the EFI pseudo-filesystem R/W.
- Someone needs to delete files in the EFI pseudo-filesystem.
- The computer has to have buggy firmware.
Hopefully, anyone who manually issues a command to mount the EFI pseudo-FS read/write knows what he's doing. However, if you're not expecting the EFI pseudo-FS to be mounted, and do rm -rf superdir_of_efi_mount (doesn't have to be /), you may unexpectedly render your computer not just unbootable but totally bricked.
The kernel should definitely "fix" this situation, because it's now quite clear that mounting the EFI pseudo-FS R/W is REALLY F*ING DANGEROUS on large numbers of systems with buggy firmware, and the kernel should definitely not make something so dangerous so easy to do.
But it takes years for everyone to upgrade their kernels, and the fix isn't even written yet. In the meantime, sane userspace projects should obviously not aggravate the situation by silently mounting the EFI pseudo-FS read-write without any notice or warning.
SystemD is not a sane userspace project. SystemD is -- as evidenced by the project's reaction -- run by people so narrow-focused and narrow-minded that they refuse to lift a finger to stop people from physically destroying their machines if they can argue that SystemD's current irresponsible behavior is not technically a bug.
Or, as I put it on Facebook:
If the kernel running an ACPI call on a buggy BIOS resulted in the CPU fan turning off and the CPU remaining on in an infinite loop, resulting in melted CPUs, the proper response would not be, "well those systems are buggy; not my problem". And it wouldn't be: the driver for the call would be default-configured disabled, dire warnings would be printed in all caps in the KConfig warning of the consequences of enabling it, and you would have to jump through many hoops to enable the feature for any system not on a whitelist -- and you'd probably have to change the source code itself to disable any blacklist.
This situation is of similar severity, but the fix is easier. SystemD only needs to write to the EFI pseudo-fs for a single command. That command can remount the pseudo-fs rw for the time it takes to perform whatever action it needs, then remount it ro again. That would stop who-knows-how-many people from permanently bricking their machines.
But Poettering of course won't descend into the real world to do something like that. SystemD isn't doing anything wrong -- according to his narrow, meaningless definition of "wrong" -- so it doesn't matter that his software is creating a situation in which users' machines are being physically destroyed. Not his problem.
(Score: 0) by Anonymous Coward on Wednesday February 10 2016, @01:01AM
Both Pottering and Red Hat are all certified incompetant FUCKING IDIOT assholes.
Linux used to be a nice alternative to windoz but now is driving people away, because of the abortion called systemd.
All to make linux less unix and more "windows like".
Myself, I ditched Debian and went to FreeBSD to avoid the inevitable cluster fuck systemd was evolving into, when Debian adopted it.
Today, it makes for some good comedy from the sidelines, but is still sad to see an OS alternative with so much potential turned into such a fucking nightmare piece of shit that linux has become.
(Score: 4, Insightful) by rleigh on Tuesday February 09 2016, @08:48AM
So the EFI filesystem author says it's not systemd's fault. So what? As a software developer, I have to deal with buggy and broken behaviour in my dependencies, and work around stuff which "wasn't my fault" all the time. systemd doesn't get a free pass by being "technically correct" and yet totally failing to provide a safe and robust implementation. Yes, the EFI and the EFI filesystem are broken. But systemd should still be taking pains to mitigate the impact by working around this (mounting it r/o by default, not mounting it by default, whatever). Just brushing it under the rug and pretending that a really serious problem is a "not my responsibility" is a perfect demonstration of the wrongheaded attitude of the systemd developers, and why many of us do not trust these imbeciles to have complete control over the whole Linux system. Their goal does not appear to be maintaining a safe, secure and robust system; this isn't the first time they have fobbed off their responsibilities onto others.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @02:26PM
> So the EFI filesystem author says it's not systemd's fault. So what?
Read the link. Not only does he say it isn't systemd's fault he says it is HIS fault.
(Score: 2) by rleigh on Tuesday February 09 2016, @03:59PM
I know. I think you missed my point. The systemd people should be mitigating the effects of the bug *even though the technical issue is in a separate component*. That's what competent and considerate maintainers do. Their number one priority should be protecting the users of their software from irreversible hardware damage. How disconnected from reality do you have to be to consider passing the buck acceptable? You need to view the problem as systemd's failure to behave well as an integrated part of a wider system, rather than being perfect in isolation. Mitigating the problem irrespective of where the bug lies is their responsibility; they are part of the problem as the party responsible for mounting the filesystem, and they should be part of the solution as well. Not doing so is selfish and inconsiderate, and makes me wonder about their goals and motivations; are they writing this purely for their own gratification, or to serve the needs of their users? Because this is one case where not doing anything makes it clear they don't care about doing the right thing for their users.
(Score: 3, Interesting) by VLM on Tuesday February 09 2016, @01:18PM
It is NOT systemd's fault
Sure, sure. Lets abstract systemd out of the discussion. Its too controversial. Once we do that we can evaluate the wisdom of how this situation is being handled in an abstract sense, perhaps via analogy.
"Its not my fault that I copy strings from one buffer to another without checking for length. I've product tied string copying into the desktop and deeply into the OS so if you don't like how I do it, there's only one choice so stop using the OS. If my string copying decisions mean that people are putting weirdness into the buffer that smashes the stack and roots the box, that's not my problem, that's their problem for putting it there and having bugs in their input sanitation. My problem is copying strings not rooting boxes so talk to the rooting boxes department, all we do is copy strings here. Noob-tier mistakes with string copying are not the only way to root a box, therefore because its not the only source of problems, its not a problem at all. Finally appeal to authority isn't a logical fallacy but is a good way of life and if I can browbeat some random idiot out on the internet into taking responsibility for my mistake, that magically means I am no longer responsible, just like some theories behind voodoo and soul stealing via photography."
I don't even have a dog in the fight anymore so I think I'm giving a fair summary. I used Linux for more than 20 years, watched it get ruined, which pissed me off for awhile, now I use BSDs and I'm happy as can be and wonder why I didn't upgrade to freebsd a long time ago. Thank you systemd for ruining Linux, which helped me upgrade to FreeBSD, sincerely, I mean it.
(Score: 2) by HiThere on Wednesday February 10 2016, @04:30AM
If it's a known existing problem in hardware and the software that is designed to run on that hardware which could easily eliminate the problem declines to eliminate the problem, then it *IS* a software bug. And worse, an intentional one.
I will agree that it's also a hardware bug. But that doesn't mean it isn't also a software bug.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by driverless on Tuesday February 09 2016, @08:45AM
SystemD is its own punishment. QED.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @10:37AM
possibly a StD free Linux distro.
Welcome to Slackware. [youtube.com]
Bob be with you.
(Score: 2) by driverless on Tuesday February 09 2016, @10:43AM
In any case it can't be a bug because systemd has no bugs [freedesktop.org]. They've closed the Bugzilla tracker, so obviously it's reached a state of perfection where no more bugs need to be reported or fixed.
(Score: 0) by Anonymous Coward on Monday February 15 2016, @02:31AM
Incorrect. A different search for "systemd" on that site shows over 500 bugs outstanding, including several assigned to lennart or to systemd-bugs.
https://bugs.freedesktop.org/buglist.cgi?quicksearch=systemd [freedesktop.org]
(Score: 2) by driverless on Monday February 15 2016, @02:43AM
Those are all old bugs that have been ignored since last year or much earlier. You can't file new bugs on that bug tracker because it's been closed. Give it a try if you don't believe me.
(Score: 4, Insightful) by dyingtolive on Tuesday February 09 2016, @02:36AM
Never had this problem in BSD.
Nah, but seriously, it's almost like Pottering is clownshoes. Literal clownshoes.
Don't blame me, I voted for moose wang!
(Score: 3, Insightful) by shrewdsheep on Tuesday February 09 2016, @09:06AM
Except for a few things, I believe that systemd (or something similar) is far superior to the init system. I have come to the conclusion that the main problem of systemd is the arrogance of the community. The kde community is similar, but not libreoffice. It seems to be possible to be an open, welcoming and considerate software community. Perhaps something can be improved by getting them some community involvement people (with those soft skills...). And please, by all means for kde, too.
(Score: 0) by Anonymous Coward on Saturday February 20 2016, @11:31PM
"the init system"
There is no such thing. There is sysv init, there is bsd init, there is daemontools, there is nosh, there is i9, there is OpenRC, and the list goes on and on and on.
Why is everyone so damn stuck up about comparing systemd to sysv as if it is the only other choice?!
The while topic is reminiscent to the Thatcher mantra TINA (There Is No Alternative).
(Score: 5, Informative) by bzipitidoo on Tuesday February 09 2016, @02:44AM
Summarily dismissing a sincerely written bug report, whether it is correct or not, is seriously unprofessional and dictatorial. Though, it's not really news that the systemd dictator acted like, well, a dictator, just like has been happening for years.
Maybe Poettering should go hang with other deniers. He might enjoy the company of like minds who don't "believe" in Climate Change. Or they might all end up hating each other when they try "my way or the highway" on each other.
(Score: -1, Troll) by Anonymous Coward on Tuesday February 09 2016, @03:36AM
> Summarily dismissing a sincerely written bug report, whether it is correct or not, is seriously unprofessional and dictatorial.
Oh please. He spelled out why the filesystem needs to be mounted read-write and said that because of that necessity they will continue to mount it read-write. What did you want, some sort of helicopter-parent approved lullaby?
I swear the systemd haters, gamergaters, SJW haters and the BLM haters all ya'all are the most thin-skinned drama queens on the modern internet.
> Maybe Poettering should go hang with other deniers.
What a bizarre word association you've done there.
(Score: 4, Informative) by hash14 on Tuesday February 09 2016, @03:47AM
Agreed. You're talking about a project that's a censorious dictatorship, and one with no respect at that. Nobody I've seen talking about systemd has a single nice thing to say about Lennart. The only thing that keeps him in his position is that he works for Red Hat and whoever gives him a paycheck seems to like what he's doing... so at least there's one group who has respect for what he's doing, albeit one that we should feel very edgy about.
But because he refuses to ever admit that he's wrong or that he can ever take the advice of another individual*, he just stamps his feet like a petulant child and then wonders why nobody likes him or his software. Everyone's just a hater right? But it's not without reason....
* I can't actually back this up concretely, but I'm just making judgements on some of his more high-profile temper tantrums
(Score: 5, Informative) by Thexalon on Tuesday February 09 2016, @03:52AM
His number 2, Kay Sievers, has been about as bad [freedesktop.org], to the point where Linus banned any further kernel changes from Kay.
For what it's worth, I'm solidly anti-systemd, even if that means I'm building my entire system from source code.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 4, Interesting) by hash14 on Tuesday February 09 2016, @04:04AM
Yeah, we've all been forced off our "comfort platforms". I used to be a Debian stalwart and miss it dearly. I'd love to jump to Devuan, but it looks like even they are having some issues keeping the repository systemd free. So it's Gentoo for me now, and while it's a magnificent project, I'd far prefer going back to a package-based distro. The problem is just that none are reliable (at keeping out systemd) or seem viable in the long-term (Gentoo is doing the most to preserve independence from systemd). And I'll give BSD a try at some point, I just worry that the performance/hardware support won't be quite up to that of Linux.
In any case, I don't even think it's Lennart or Kay who's the biggest danger. It's Greg Kroah-Hartman who's the #2 Linux developer. He's a big fanboy of systemd, has taken to trolling Gentoo developers for forking udev (because *shock* some people don't like systemd), and was pushing hard for the monstrosity that is kdbus to be mainlined in 4.1 - thankfully that didn't happen. But with him at the helm (or #2 at least), I'm seriously concerned about the lines being blurred between Linux and systemd, and how much Linux development in the future will be specifically to cater to systemd. That, in my opinion, is the greatest threat to Linux right now.
(Score: 1) by UncleSlacky on Tuesday February 09 2016, @10:29AM
Just FYI, both antiX and MX-15 are systemd-free (it can be added if desired) and based on Debian Jessie.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @05:45PM
There is also Calculate Linux, a binary distro with a Gentoo base.
(Score: 1) by purple_cobra on Tuesday February 09 2016, @08:25PM
Ditto Manjaro-OpenRC [sourceforge.net], an Arch-derived distro (well, Manjaro-OpenRC is derived from Manjaro is derived from Arch!). I use this on a little Celeron NUC with a cheap SSD and it's pretty good. Being largely Arch, you have access to all the same stuff (e.g. -ck or -pf kernels, etc).
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @05:50PM
On the topic of GregKH, one reason he is so defensive about udev is that he wrote it back in the day.
Yes, Sievers currently had maintainership when it was folded into systemd. But i suspect it had the tacit approval of GregKH.
Rob Landley has an interesting story about an exchange between him, Sievers and GregKH about documenting the /sys interface udev depends on.
http://www.landley.net/notes-2015.html#05-07-2015 [landley.net]
(Score: 0) by Anonymous Coward on Monday February 15 2016, @02:50AM
Because I don't use the full Gnome or KDE suites, I've found it possible to have a Debian 8 desktop with most of my favourite software, without using systemd as the init. Because systemd caused one crash for me, I decided I didn't want it.
In /etc/apt/preferences I put
Package: systemd
Pin-Priority: -1
I installed the sysvinit package to replace systemd, and allowed the installation of the libsystemd0 package.
(Score: 5, Interesting) by rleigh on Tuesday February 09 2016, @09:52AM
Agreed. The way you handle problems like this is very telling.
The worst I've seen myself was a bug in my schroot tool, very early in its development. A user customised the configuration, and encountered a problem which would leave /home bind mounted and then rm -rf the base directory, blowing away /home. If I was a systemd-style maintainer, I could have closed it as "not a bug", telling the user "you were using a non-approved configuration, sucks to be you". What I *actually* did was profusely apologise to the submitter that they had encountered such an awful bug in my software, checked that they had a backup copy of their data (they did, thankfully), and then I investigated how it happened, and once I found the problem I added extra checks and other logic to ensure this would never happen again, no matter how it was configured. (It turns out I found a bug/race in the procfs /proc/mounts code which would make it alter as you read it and skip over a mount; but I worked around it by adding a lock around mounts/umounts to mitigate it changing when the tool was run in parallel, reading /proc/mounts into a buffer rather than line-by-line, and by doing extra sanity checking to ensure nothing was mounted before removing the base directory.) This issue was never encountered again over the last decade. I was profoundly embarassed by my software causing such unexpected damage, and took the steps to immediately rectify it and ensure a repeat would never be seen again. The changes I made were "unnecessary" since if the system behaved perfectly I wouldn't need them; but we don't live in a perfect world, and need to deal with that.
The systemd folks have an even more awful problem. It's not just irretrievable dataloss, it's unrecoverable hardware damage. It might not be "their problem" either, but it *is* their responsibility since they are one of the factors enabling the damage. To treat this so flippantly, irrespective of whether they are right or wrong, is simply disrespectful to the reporter, and quite unprofessional. I have never ever treated my users this way, even when they are "wrong", either as an unpaid amateur in the above example, or as a paid professional. Mistakes can and do happen, no matter how hard we try and how many unit tests we write; none of us are perfect. But there's a right way to deal with a disaster when it occurs, and they have repeatedly failed to do this. Their behaviour is beyond arrogant, and exemplifies the worst stereotypes in the free software world. If they showed a little humility, and looked at the bigger picture of integrating well into the wider ecosystem rather than being "perfect" in isolation, they wouldn't find people like me so opposed to them.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @04:09PM
Well, other than giving yourself a nice touchy-feely warm-and-snuggly feeling inside, of what relevance was this? If they didn't have a backup of their data, you had one to give them? Would you have sent them something to compensate for it, like money or a warm tray of brownies??
(Score: 2) by linuxrocks123 on Tuesday February 09 2016, @04:19PM
My guess is he would have walked them through the process necessary to recover the data, i.e. photorec etc.
(Score: 2) by rleigh on Wednesday February 10 2016, @04:01PM
What's the purpose in such a pointlessly sarcastic comment?
Regarding the example, there's little I could have practically done in the fact of irretrievable data loss. If it's gone, it's gone. Nothing can bring it back. Knowing they had a backup was good for my peace of mind that I wasn't responsible for ruining someone's system. The point is more about what you do to /in response/ to the situation as the developer. In this case, it was fixed quickly and professionally, and the user was in fact pleased that I'd been attentive, responsive and sympathetic to their problem, and happy that it was resolved. They continued to use the tool and also contribute to its development by way of feature requests, testing and patches. I /could/ have been a horrible person, told them it was their own fault, not my responsibility, and closed it as not a bug. And it would have been "technically correct", just like the systemd case here. But it would have been the wrong thing to do. And I'd have most likely lost a user who was quite valuable to the project, as well as making them angry for no reason. Acting like that as a dismissive, disrespectful, arrogant douchbag is no way to run a project and have a good relationship with your users and the wider community. Only people with zero care about the quality of their software and zero empathy would do that, and I would question what they are getting out of developing and maintaining the software it they don't give a damn about the impact of bugs and unexpected behaviour on the people using it. If you were to find a serious problem and report it, I'm sure you'd want the pleasant and productive response, rather than the unnecessarily unpleasant and totally unproductive one.
When I was the Debian sysvinit/initscripts maintainer, if I had ever received a bug report as serious as this one, I certainly would have treated it with the seriousness it deserves: i.e. the greatest. Assuming that we had mounted it r/w in mountkernfs, the default would have been switched and the fixed version would already be uploaded. No arguments about where the responsibility lies and fobbing off our responsibility; if it stops another system from being irreversibly damaged, then you make the change; I'd likely have even written the patches to make the other tools mount and/or remount the filesystem since it's such a severe problem. Sadly, I'm no longer involved in this stuff, as a result of the individuals responsible for the bug in this very article.
What's bizarre is that these people are paid "professionals" working for a major company, and they give worse service than I did as an unpaid but hardworking volunteer! If I gave their treatment to my users in my day job, I'd be disciplined and then fired. It makes me wonder if the management at RedHat actually has any control over what their staff do, especially after previous incidents e.g. the RPM db locking/trashing bug and the maintainer who refused to consider it a bug and fix it, even for paying customers!
(Score: 2, Informative) by Anonymous Coward on Tuesday February 09 2016, @02:54AM
Systemd has pluses. Systemd has minuses. But blob that was pushed on the users without real world full testing, is malware. Hidden functions and features that normal routines bring to surface. I makes me want to push to past laws that if you write it and it acts in broken manor, you are libel for all damages, even with free software.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @04:07AM
Stop installing software that says NO LICENSE IMPLIED OR GIVEN when in the EULA and then you can start suing.
OSS is not forced on anyone, go fork it you nub and stop complaining about how the shitty systemd is.
Complaining about it at this point is just pissing up a rope.
(Score: 1, Interesting) by Anonymous Coward on Tuesday February 09 2016, @04:44AM
Negative sir, forking a distro is non-trivial work and bitching about formerly beloved existing distros is the only way to provide feedback.
Also, nowhere does any Linux distro I'm aware of ever use those words you speak. Ever.
(Score: 2) by maxwell demon on Wednesday February 10 2016, @04:30PM
I'm sure he meant "NO WARRANTY" instead of "NO LICENSE". Of course, if you follow that advice, you cannot use any software at all, as I'm not aware of a single software product, whether libre or proprietary, whether gratis or commercial, that doesn't have such a warranty disclaimer.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by Anonymous Coward on Tuesday February 09 2016, @02:54AM
And you thought MS is the evil mofo that will kill Linux.
(Score: 5, Insightful) by jmorris on Tuesday February 09 2016, @03:42AM
More precisely, Redhat and Poettering intend to kill Linux/GNU/X and replace it with Poettering OS or Redhat/Linux or whatever we should take to calling their new operating system. And they do not just intend to, they are far enough on the plan to say they will succeed, at least commercially. If the UNIX Way is to survive with a Linux underpinning it will be the small fry both old and new from Slackware to Devuan who do it because all of the big organizations have been brought onboard.
Anyone who thinks I'm being overwrought should spend an hour reading their plans once they get the BTRFS part production ready and come back and tell me there is anything of the UNIX Way or what we have known of as Linux in that horror show. It will be more locked down than a carrier phone with signed OS images and package management will be a distro maintainer only activity. NO user adjustable or replaceable parts should be emblazoned on the install disc... except there won't be one of those either.
(Score: -1, Disagree) by Anonymous Coward on Tuesday February 09 2016, @05:07AM
I don't know what world you live in, but let me school you about how things work:
Red Hat has given everything away for free. They made the Linux desktop what it is. Everything you know about Linux-- GTK, Xorg, Wayland, SELinux, 1 out of every 6 lines of code in the Linux kernel, cairo, PulseAudio, NetworkManager, Plymouth graphical boot screens, the Liberation Fonts, the Bitstream Vera fonts, ext3, ext4, grub, glibc, Gnome, metacity, gdb. Unless you've been typing away all these years with fvwm2 and lynx on a BSD and XFree86, then you're a beneficiary of the work that Red Hat does. Fedora is the motherfucking distro that Linus uses to write code. They have set the direction for us; we just choose to change the wallpaper and window manager and pretend that we built our own distribution.
Red Hat is the upstream for /everything/. They employ the maintainers of everything else.
systemd is not Red Hat's attempt to take over Linux. Red Hat already controls Linux. Red Hat *is* Linux. We are all better off because of their work. End of story.
If systemd makes you butthurt so bad, feel free to move to a distro that doesn't use it. Red Hat doesn't mind. They aren't even charging you to use their work. They will keep on making money in the enterprise world, and giving their product to the community for free, without spying on you, without giving backdoors to the .gov, and without forcing you to view ads before using their product.
So while you are pretending to uphold the "UNIX way," you are slamming the only ally that the open source community has been able to consistently rely on for two decades.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:19AM
And are we better for want of any of it?
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:29AM
Lets go down the list:
GTK, Was Pottering involved?
Xorg, Was Pottering involved?
Wayland, Was Pottering involved?
SELinux, Arguably is this a good thing, still, was Pottering involved?
1 out of every 6 lines of code in the Linux kernel, Was Pottering involved?
cairo, Was Pottering involved?
PulseAudio, hahahhahahahahha
NetworkManager, see above. I have a room of servers that still has this bullshit removed.
Plymouth graphical boot screens, Was Pottering involved?
the Liberation Fonts, Was Pottering involved?
the Bitstream Vera fonts, Was Pottering involved?
ext3, Was Pottering involved?
ext4, Was Pottering involved?
grub, Was Pottering involved?
glibc, Was Pottering involved?
Gnome, Was Pottering involved? I genuinely don't know on this one. I could see it given what an unusable clusterfuck Gnome3 is now.
metacity, Was Pottering involved?
gdb. Was Pottering involved?
I'm not sure what case you're trying to make. Most of us dislike Pottering specifically, and that casts doubt on everything else. You're not reducing the doubt. Only increasing the breadth.
(Score: 3, Informative) by cafebabe on Tuesday February 09 2016, @07:31PM
On the reboot after typing chmod 000 /usr/bin/pulseaudio, I gained 16MB of RAM and 3% of processing power. I also lost one redundant place where the volume could be set to zero. And I have yet to find an application which is adversely affected.
1702845791×2
(Score: 5, Informative) by jmorris on Tuesday February 09 2016, @06:20AM
GTK
Wrong. While the first gtk might not quite predate RedHat, it certainly predates RH being a post IPO monster that funds development of an entire OS. Hint: gtk stands for Gimp ToolKit and dates to 1995.
Xorg
Child, Xorg was ported TO linux.
Wayland
From the people who gave us X11 (not Xorg, you do know the difference?) itself, and guess how old that is? Yea, about that.
SELinux
That comes courtesy of the United States Government, specifically the National Security Agency.
1 out of every 6 lines of code in the Linux kernel
Granted. Nobody said they were bad Open Source citizens, only that what they are using their muscle to transform the whole ecosystem atop that kernel into something that bears no resemblance to UNIX. Considering Poettering's very public statements on his hatred of UNIX and everything it stands for this should not be a shock.
PulseAudio
You mean the turd that kept audio playback unreliable on Linux for over five years as they rammed down a replacement for perfectly working software because of NIH and a BS 'need' to be able to drag a stream in progress from the internal speakers to a BT headset? And notice Android, which really can use that sort of functionality, doesn't use it.
NetworkManager
You mean the other total rewrite that has had any networking beyond a single wired ethernet or the developer's Macbooks connecting via WiFi dodgy for five plus years? That turd, the software that never got to a working state before systemd just tossed it and replaced it?
Plymouth
Wow, some stupid eyecandy to keep newbs from seeing the bootup messages.
Gnome
Ok, I will give them GNOME3 since it is a turd that caused the first schism between RH and the users. But GNOME 1 and 2 had a lot of help, which is probably why they were more usable. SUN Microsystems, IBM, etc. all contributed parts of that code.
ext3/4
Redhat wrote that? Where did all those IBM and Lustre names come from on that paper Google found when I asked it who did it? Yea I know RH has done a lot of heavy lifting there, just pointing out there aren't the only ones in the game. Besides, some of us kinda like xfs.
systemd is not Red Hat's attempt to take over Linux.
No, systemd is the first part of a push to remake it into it into something alien to a UNIX user. Something more amendable to their support model.
Red Hat doesn't mind.
If that were true I'd wish them luck, there probably is a use case for their new OS in the cloud where they are focusing. But they are using every trick in the book to make adopting the whole New Tech stack the easy path and sticking to the UNIX Way increasingly difficult.
you are slamming the only ally that the open source community has been able to consistently rely on for two decades.
I have ran RedHat products since the earliest days. I know about their contributions. But they have made wrong moves before. They closed RHEL and they did it with little advance warning. I know, I was there and one of the ones who worked on the forks, I put up the first pages showing how to do a rebuild from scratch including ending the Anaconda game. For years the shipped packages had a very subtle bug in them that made it impossible to actually respin a bootable set of media, kept in as a sort of "your Kung Fu must be this strong to do this" thing to keep the number of unauthorized spins down. A fiendish bash quoting bug intended as a rite of passage, nobody who found it ever posted a fix because we all apparently instantly saw the purpose. But since we now HAD to respin keeping that secret was no longer worthwhile so I spilled those beans in a patched package so others could easily validate my work. I wanted anyone to be able to take RH's SRPMS, validate my fairly small patches and be able to build for themselves so they wouldn't have to trust me.
But I haven't installed a new RH based physical or virtual machine in several years. And since adopting systemd, the Debian based systems I have been using have been frozen at 7 for servers and 6 (no GNOME3) for machines with a GUI. As soon as Devuan announces itself as production ready everything will begin to move there.
This machine I'm typing on is still on Fedora but I now wait until the support ends before upgrading and fighting the issues, by then they are actually pretty managable. On my work Thinkpad though, new things break and others start working again with every update. Whether it docks, suspends, connects to the wired and/or WiFi, plays music out both external speakers, etc. are all hit or miss. Thank you RedHat, you have made Linux just as good as Windows! Next hardware cycle I will be picking a new OS of course, just not enough breaks that I can't fix to drive me to lose a day or two of getting useful things done.
(Score: 3, Touché) by dyingtolive on Tuesday February 09 2016, @06:36AM
At this point I prefer OSX to most linux distros, and that's not something I thought I would find myself saying 10 years ago. :(
Don't blame me, I voted for moose wang!
(Score: -1, Flamebait) by Anonymous Coward on Tuesday February 09 2016, @07:02AM
Have run. "Have ran" is illiterate and makes you look stupid.
(Score: 2) by maxwell demon on Tuesday February 09 2016, @07:23AM
Claiming that a small error makes you look stupid makes you look stupid. Especially when you cannot know whether he is even a native speaker. How well are your foreign language skills? Not to mention that it might just be a typo anyway. Or a classic editing error (where you significantly change the sentence structure and forget to adapt some word).
To be clear, there's IMHO nothing wrong in pointing out errors. It is, however, wrong to claim (or even just to think) that someone is stupid just because he doesn't always use the language exactly according to the rules. Especially if anyone with normal intelligence and minimal language knowledge can without doubt infer what exactly he meant.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Funny) by Anonymous Coward on Tuesday February 09 2016, @07:47AM
+Don't harsh on the grammar natz, dude! Chill!
Maybe he meant "I have ran from Redhat products", a simple typo ellipsis. Otherwise it was an defective perfect, or an imperfect perfect.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @12:58PM
This is an increasingly common grammatical error that I've been hearing in the past few years, and from native English speakers in the US.
The compound verb tense "have/had (main verb)" is being misconjugated. They use the simple past tense of the main verb after "have/had" instead of the proper tense.
Examples:
Incorrect: I had ate enough.
Correct: I had eaten enough.
Incorrect: I have ran 5 miles on a treadmill.
Correct: I have run 5 miles on a treadmill.
I agree, it's basic English, and it does make the person sound stupid-- except to all his friends who speak the same way!
(Score: 1) by mechanicjay on Tuesday February 09 2016, @10:07AM
This machine I'm typing on is still on Fedora but I now wait until the support ends before upgrading and fighting the issues, by then they are actually pretty managable. On my work Thinkpad though, new things break and others start working again with every update. Whether it docks, suspends, connects to the wired and/or WiFi, plays music out both external speakers, etc. are all hit or miss. Thank you RedHat, you have made Linux just as good as Windows!
Seriously, I've been running OpenSuse on my Thinkpads exclusively since 2008. I don't have these issues and everything just works "out of the box". Give the Green Lizard a try.
My VMS box beat up your Windows box.
(Score: 2) by Bill Dimm on Tuesday February 09 2016, @02:53PM
I've been using OpenSUSE for several years, and I've been mostly happy with it, but they did start using systemd a while ago. I have 12.2 on one machine and 12.3 on another (both are systemd) and they both sometimes fail to shut down cleanly (12.2 more so than 12.3). I don't know if that's related to systemd, but it's something that I've never seen before (using Linux since 1995).
(Score: 2, Informative) by mechanicjay on Tuesday February 09 2016, @04:29PM
Yes, the 12.x series was their transition to Systemd. 12.1 was completely borked, leaving you with a damn near unmanageable system, services that wouldn't start (or shutdown), disks that would change their UID at every reboot... 12.2 was a bit better, 12.3 a little better still. For the 13.x series they completed the transition and I've had no systemd related troubles since. 12.x was really a shit show.
My VMS box beat up your Windows box.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:24PM
I've used Windows for longer than that and those problems kinda went out some time into Windows XP. And Windows 2000 was not that bad either (other than the slow boot time on old hardware of that time and some resource limits which supposedly could be worked-around: http://weblogs.asp.net/mikedopp/increasing-user-handle-and-gdi-handle-limits [asp.net] ). Windows 8.x and 10 on the other hand are abominations. And Vista never happened ;).
I did use Linux for desktop purposes too at work for a few years starting from about 2005, and it was an inferior experience for much basic desktop stuff (clipboard management, sound handling, the general way the GUI should work) and only better in other more esoteric ways (e.g. kio slaves). I used KDE because it was less of a joke than GNOME (if you don't think so go look up what Linus said about GNOME around that time). Sad to say the desktop stuff today is still crap (I've reported bugs years ago that were closed with WONTFIX). The server stuff is still OK but I haven't moved to the SystemD crap yet.
You bunch can keep saying desktop Linux is fine but, if things were really that great why have there been so many major forks along with lots of people saying others are screwing stuff up? Are they all wrong and stuff is great? It's almost as if Microsoft is paying Linux developers to screw stuff up every time Microsoft releases crap.
(Score: 2) by gnuman on Tuesday February 09 2016, @04:47PM
PulseAudio
TBH, Pulse Audio source code is poorly documented, difficult to understand. But what it does is work the way audio on linux is suppose to work under ALSA. The problem with ALSA is ALSA had NO USABLE DOCUMENTATION. For a project that important, WTF?? To write .asoundrc config files, you needed a PHD in brainfuck and half the time something was broken anyway because device detection order changed. At least with Pulse Audio there is pavucontrol allowing people to switch stuff around and for audio to work out of the box.
I love command line, but audio on Linux definitely was a PITA before Pulse Audio came around.
(Score: 0) by Anonymous Coward on Thursday February 18 2016, @07:48PM
There was already JACK if you needed more than controlling the speaker volume on your motherboard DAC.
(Score: 3, Insightful) by Alias on Tuesday February 09 2016, @06:38AM
GNU/Linux was around before Redhat. RedHat is not "giving everything away for free.". Redhat gets for free most of what it sells as a product. Granted, Redhat has done a lot of good work by contributing to GPL licensed software over the years, but that has all been simultaneously contributing to their own product. Everyone was fine with Redhat selling RHEL, consisting mostly of code that wasn't theirs because most of that code is GPLed, and Redhat wasn't violating the GPL with RHEL, and probably still isn't.
But don't kid yourself into thinking that GNU/Linux wouldn't be relevant or successful without Redhat. Redhat is only really relevant itself because of Centos, and free software doesn't need corporate allies beyond competitive hardware vendors that document how their hardware works. (And the need for documentation is debatable.). The community took care of itself for a long time before any of the corporate Linux players contributed significantly, and it could do so again. Many of the things you listed that Redhat may have contributed to were around and robust before Redhat got involved. Redhat is *not* Linux. That notion is really quite insulting to the thousands of people that have contributed to GNU/Linux over the years who have had nothing directly to do with Redhat.
Your post sounds like one of those "the internet wouldn't exist without Microsoft" shill posts over on the green site.
(Score: 2) by turgid on Tuesday February 09 2016, @08:42AM
Where I work we are migrating as much as possible off of Red Hat and on to CentOS. They want a license fee for every instance now, including for installations from the days before one was needed ie you could install for free but you paid if you wanted a support contract. Red Hat is trying to do a Microsoft: embrace and extend, creating lock-in. Run away fast while you still can.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Informative) by mechanicjay on Tuesday February 09 2016, @10:02AM
Yeah us too, we're running fast as we can, our RHEL Site Licence expires June 30, we're not renewing. A guy in my group wrote a script which converts a RHEL 7 box to a Centos7 Box. Just needs a singe reboot to load the new kernel and whatnot. It's flipping magic.
My VMS box beat up your Windows box.
(Score: 2) by turgid on Tuesday February 09 2016, @10:24AM
That's a very cool idea. How much work was it? Can he publish it somewhere?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by turgid on Tuesday February 09 2016, @10:52AM
What's the betting they try to extinguish CentOS next? I foresee an army of lawyers descending.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by tangomargarine on Tuesday February 09 2016, @02:56PM
I thought they were already "in charge of" CentOS?
In January 2014, Red Hat announced that it would sponsor the CentOS project, "helping to establish a platform well-suited to the needs of open source developers that integrate technologies in and around the operating system".[16] As the result of these changes, ownership of CentOS trademarks was transferred to Red Hat,[17] which now employs most of the CentOS head developers; however, they work as part of the Red Hat's Open Source and Standards team, which operates separately from the Red Hat Enterprise Linux team.[7] A new CentOS governing board was also established.[8]
(wiki [wikipedia.org])
Can't say I understood that when I heard it happened but it's quite possible I'm misunderstanding.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by turgid on Tuesday February 09 2016, @03:04PM
So it has begun!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @07:45AM
Can one of you mod this shill clown down? We should have moderation "hella wrong".
(Score: 1, Funny) by Anonymous Coward on Tuesday February 09 2016, @12:43PM
If you caught Mother Teresea finger banging a 6 year old Indian boy, I dont care what she has done over the years, shes a fucking child rapist.
Redhat is metaphorically fingerbaning Linux users in the asshole right now. And your only response is "slamming the only ally that the open source community has been able to consistently rely on for two decades."
Obviously we cannot rely on them with this fucking systemd they are trying to fingerbang into you anus, so your point on being able to consistently rely on them has been proven false.
(Score: 2) by tangomargarine on Tuesday February 09 2016, @02:48PM
the only ally that the open source community has been able to consistently rely on for two decades.
Hey, I used to be a Red Hat fan, too. But, like Sun, all good things must end someday.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 4, Touché) by maxwell demon on Tuesday February 09 2016, @07:09AM
Yeah, Red Hat has learned the Microsoft lesson well: Embrace, Extend, Extinguish.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Informative) by Anonymous Coward on Tuesday February 09 2016, @03:24AM
This, of course, is standard operating procedure for that arrogant ass Poettering. Create buggy software, blame others for the bugs, close the reports as invalid.
This is why Poettering should not be allowed within 50 feet of any computer, and for damn sure should not be programming one.
(Score: 1, Funny) by Anonymous Coward on Tuesday February 09 2016, @06:17PM
Me: GOD. I would like to report a bug.
GOD: Yes, many bugs were created to clean up the earth.
Me: No not that kind of bug.
GOD: What kind of Bug are you refering to, my son?
Me: It's named "Poettering" and it keeps breaking things and blaming others.
GOD: Oh him. Yeah I created it. But it's just a test of your Linux community to see how well you can deal with the Devel.
Me: You mean Devil.
GOD: I don't make mistakes.
Me: Oh. Sorry. I'll think more before I .... GOD? GOD? You still there? GOD?
(Score: 2, Informative) by Arik on Tuesday February 09 2016, @03:36AM
Which it is, if you were smart enough to avoid systemD.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @03:47AM
I've only ever did a rm -rf / for shitsngiggles. If I'm reinstalling I'm reformatting.
(Score: 5, Insightful) by hash14 on Tuesday February 09 2016, @03:51AM
https://github.com/valvesoftware/steam-for-linux/issues/3671 [github.com]
Mistakes are very easy to make.
(Score: 3, Interesting) by hemocyanin on Tuesday February 09 2016, @05:47AM
I did it once by accident about 10 years ago -- more precisely, I did an rm -rf * after accidentally cd-ing to / rather than to where I wanted to go, as root of course. Yeah I know. Back then, all it meant was a reinstall which aside from being hassle wasn't the end of the world.
I get that MSI screwed up their EFI implementation, but it's a known issue and to absolutely refuse to make a software package safely handle known issues is just weird in the extreme. Aside from compatibility lists, do we now need lists of hardware that "linux" (for this is how it will be perceived) won't destroy merely by use?
(Score: 3, Insightful) by Hairyfeet on Tuesday February 09 2016, @06:40AM
"do we now need lists of hardware that "linux" (for this is how it will be perceived) won't destroy merely by use?" And THAT is why its a SystemD bug, because of this (frankly retarded, there should be NO REASON to mount it unless you are expressly altering it) bug you've just created a situation where OEMs have a legitimate reason to put on their hardware "Linux is NOT recommended and can in fact break this hardware and will void your warranty" and will be perfectly justified in doing so.
Remember folks a good experience? Gets told to a couple people at most, a bad experience? Gets told to a dozen or more. Of course Larry Pooter and his Masters at Red Hat really do not give a flipping flying fuck what YOU think, you filthy peasants, all they care about is fortune 50 "cloud" customers. Hell read old Larry's postings sometime, he really makes it quite clear what he believes the "future of Linux" is gonna be an the vast majority of Linux users? Would probably feel more at home on windows than on what he and his bosses have in mind which is Linux as nothing but a VM on a SystemD hypervisior, a second class citizen on its own fricking platform!
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 3, Interesting) by q.kontinuum on Tuesday February 09 2016, @06:49AM
As do probably 80% of all Linux starters at least ones or twice, for exactly the same reason. Linux was not only a great operating system, but also a great learning experience once. It invited to try things, to tinker around, to break things, and at least for the past 10 years to always be able to just start from scratch easily, because setting up a new system is a matter of minutes,
Now I have to tell my son to never try anything without spending hours on reading documentation for potential risks?
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 2) by mrchew1982 on Tuesday February 09 2016, @06:00PM
No, he just has to learn how to tear apart the system and reflash the chip using a jtag adapter... ;-)
(Score: 2) by q.kontinuum on Tuesday February 09 2016, @08:12PM
And that would work without
without spending hours on reading documentation for potential risks
? I'm not sure I buy that...
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @04:18AM
At least it does what you ask it.....?
(Score: 3, Insightful) by maxwell demon on Tuesday February 09 2016, @07:28AM
No, it doesn't. The issue is that it mounts the EFI file system read/write without you asking for it.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by Azuma Hazuki on Tuesday February 09 2016, @04:46AM
Either ONLY remount the efivars fs read-write when necessary to change something, or code some kind of special ioctl to do it.
While it is technically true that this is not a bug in the programmatic sense, I would argue that this is a logical bug. The difference being, programmatic bugs are when the program doesn't work, logical bugs are when it works in ways you don't expect. Yes, this is an edge case, and no one in their right minds would willfully issue rm -rf /, but what if some newbie is tricked into it or is hit by a platform-agnostic cross-site-scripting attack that does it?
For this reason I think the SystemD devs should take the opportunity to close this loophole, while trumpeting the opposition's (Windows) continued vulnerability to a similar if more difficult attack. Their reaction baffles me; isn't caring for your customers just good service?
I am "that girl" your mother warned you about...
(Score: 1, Interesting) by Anonymous Coward on Tuesday February 09 2016, @05:09AM
"rm -rf /" is undefined behavior, and a complaint unix system does not need to support it (It can throw a nice error saying not to do that). This is because deleting the current working directory (which is always under / somewhere) is explicitly undefined, and the order of deletion is also undefined. Thus there is nothing wrong with your rm simply refusing to support "rm -rf /", and any unix like OS that cares about its users (not Linux apparently) should simple have this command fail immediately instead of fail after deleting a lot of stuff.
Some BSD variants actually do this (make rm -rf / simply error). It started with SmartOS. There is a fantastic interview with Bryan Cantrill (CTO of Joyent who makes SmartOS) here: https://youtu.be/l6XQUciI-Sc?t=4859 [youtu.be] (Ubuntu Slaughters Kittens | BSD Now 103). Its seriously a fantastic interview (some great history, very funny, and a lot of interesting insight) I recommend watching the whole video _all 2 hours of it). And yes, the line "Ubuntu Slaughters Kittens" is used (in reference to the boot process).
(Score: 3, Insightful) by maxwell demon on Tuesday February 09 2016, @07:39AM
The fact that it was uncovered by an rm -rf / does not mean this command is the only way to trigger the problem. Anything that ends up deleting in the EFI file system will have the same effect.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by tangomargarine on Tuesday February 09 2016, @03:09PM
I was under the impression removing a directory above the working directory in the tree was defined--your working dir would still exist until you cd'd out of it, then it would become inaccessible.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by maxwell demon on Tuesday February 09 2016, @07:37AM
The technical term is "design error".
Well, anything that happens to delete files and include the EFI file system will do the same. Think of some erroneous find that happens to unexpectedly match something in the EFI file system. Or you run some script to detect and delete duplicate files, and by error you have it include the EFI file system and it happens to find a "duplicate" there.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @07:51AM
Poetering is not in the customer service business. He's in Poetering service business and his serfs obey that law. You have to be seriously fucked up when you let people suffer, even if it wasn't your fault (which i still argue is, in this case, partly), when you could fix it easily.
(Score: 2) by q.kontinuum on Tuesday February 09 2016, @10:44AM
That is a wrong assumption, I think. (Or maybe I'm just not right in my head and project to much :-))
First of all, every newbie screws up his system once in a while, and when I need to re-install anyway I would have considered rm -rf a safe way to let out my frustration. Also I might have tried to see how far it gets before it starts missing the underlying system. I usually would actively encourage my son to try any kind of commands on a system, provided the system is not important and can be wiped/reinstalled without substantial losses.
Second, a script might rely on environment variables to delete subfolders (rm -rf $WORKSPACE/$CCACHE). Such a script without any safeguards (if [ -z $WORKSPACE ]) would be enormously stupid, and anyway disastrous, but should at least not brick the hardware.
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:07AM
What is EFI and why does it need to be mounted?
(Score: 1, Informative) by Anonymous Coward on Tuesday February 09 2016, @08:54AM
EFI is the replacement for the BIOS. The efivars filesystem gives access to certain (all?) EFI settings directly from the running system.
It doesn't need to be mounted, and even if you do, it can be mouted read-only. Except that systemd has one feature that maybe five people world-wide use[1] that need it read/write, and thus the default behavior is to mount it read/write. Wouldn't want to inconvenience those five people, when the alternative is risking bricking motherboards for everyone else.
[1] The feature is great for a dual-boot remote server[2], you can SSH in and tell it to reboot to Windows, rather than needing somebody to select Windows in the boot manager.
[2] Why anybody would want to do that, you'll have to figure out by yourself.
(Score: 3, Informative) by mmcmonster on Tuesday February 09 2016, @11:22AM
EFI apparently allows space for a small amount of OS information to be written to it. (ie: serial numbers for software, so that if you wipe the drive and reinstall, it won't prompt you for a serial number.)
Now, whether this is good or not, the OS has to be able to write to this space so that this functionality is not lost. (Unless the OS decides that it's a feature that it will not support. But Linus Torvalds generally doesn't like taking out support for features, particularly if the hardware still exists in the wild.)
I would agree that some safeguards should be in place, but I'm not sure what the correct way is. Probably change /bin/rm so that it doesn't traverse that filesystem?
(Score: 3, Insightful) by maxwell demon on Tuesday February 09 2016, @02:49PM
There's nothing wrong with Linux providing the EFI file system. What is wrong is mounting it R/W unconditionally. Note that this would be wrong even if you could not brick your laptop that way.
What would be the problem if the one option of systemd that needs it simply had the documentation "this option only works if the EFI file system is mounted read/write"?
Then anyone who needs it could manually put an R/W mount entry in fstab, and everyone else could decide not to do it.
A typical Linux system gets more or less unusable if /usr is not mounted. Yet there's nothing forcing you to mount /usr if you don't want to. Not mounting the EFI file system leaves the system usable, with the exception of one single feature, so why force it on everyone?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @09:37PM
Because this is the cheap quick easy way to do this
Welcome to Systemd. Enjoy the ride.
(Score: 2) by maxwell demon on Tuesday February 09 2016, @02:38PM
FTFY
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @09:33PM
Greek girl. Charming young lass. Mounting lowers the pitch somewhat for a short period of time
(Score: 1) by gnampff on Tuesday February 09 2016, @11:19AM
As much as I find some of the systemd stuff weird, irritating or stupid this really is a bug on a different layer.
My sysfs is mounted rw too. Yet even with sudo i cannot just go and delete the power settings folder of my cpu.
I fail to see how this is different. Why would this be the fault of the one that mounts it?
To me this sounds just like blaming xorg or konsole for not stopping me from stupid stuff i order my kernel to do.
(Score: 2) by PizzaRollPlinkett on Tuesday February 09 2016, @12:48PM
Something about the way this story is being presented bothers me. This is an issue with one manufacturer's bad BIOS/EFI/whatever implementation. Apparently, this manufacturer has a history of this sort of thing. As far as I can tell, systemd and linux (and any other OS, since this is a firmware problem) is doing things correctly, but triggering a problem in the firmware. But it's only on one laptop, it's not a systemic problem with linux. Anyway, who does "rm -f /" anyway?
The way this story is being spread reminds me of those alarmist stories about Linux security bugs, and when you finally figure out what it is, it's some misconfigured third-party PHP package.
(E-mail me if you want a pizza roll!)
(Score: 3, Interesting) by maxwell demon on Tuesday February 09 2016, @03:02PM
No, systemd is not doing things correctly. It should not by itself mount the EFI file system (or anything else). Note that this is true independent of the fact that you can brick your laptop with it. There is one, and only one, place where the automatically mounted file systems are to be specified, and that is /etc/fstab (well, except for the root file system which is special, as without mounting that, /etc/fstab cannot be found).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by gnampff on Tuesday February 09 2016, @05:16PM
You do not list sys, proc or dev in your fstab. Yet they are mounted. Some things just get mounted automatically.
I really do not see the the mistake on behalf of our evergrowing init system.
I cannot delete things in the rw mounted /sys so why would I be able to do it in this EFI fs?
Systemd is using the EFI fs just like it probably uses sysfs for something.
Blame the crappy vendor and maybe ask for a horrible hack in the EFI fs so this cannot happen in the future.
Otherwise I (or some evil/broken program) could still mount it by hand and wreck my system which is not much better.
(Score: 2, Informative) by Arik on Tuesday February 09 2016, @06:10PM
That's because those are not real file systems. These are all virtual file systems that make functionality other systems might require a special tool to access available using the normal *nix tools and metaphors instead, they are NOT REAL filesystems that are being mounted willy-nilly however.
"I cannot delete things in the rw mounted /sys so why would I be able to do it in this EFI fs?"
Because the EFI disk is a real storage device, while sysfs is a virtual file system that does not really exist, it's just a trick to make the UI more convenient.
"Blame the crappy vendor and maybe ask for a horrible hack in the EFI fs so this cannot happen in the future."
Yeah, I already did, that's half the problem and should definitely be fixed.
Two wrongs don't make a right, so I won't excuse systemD here, but honestly, anyone who's been paying attention has had more than adequate warning at this point. SystemD is trash, and installing it on a production machine should be seen as a diagnostic of absolute incompetence.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by maxwell demon on Wednesday February 10 2016, @07:28AM
I just checked, and to my surprise you're right. However that was not always the case; I explicitly checked in the fstab of an old OpenSUSE installation that my memory is not wrong; its fstab indeed does contain entries for proc and sys. When did they change this? I consider the old way to be the right way.
The only things that should be mounted by default are those things needed to explicitly mount the rest. Everything else should be mounted only via fstab, no matter how fundamental it is.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Informative) by Anonymous Coward on Monday February 15 2016, @03:12AM
Maybe your initramfs mounts those?
https://stackoverflow.com/questions/34326854/if-there-is-no-sysfs-in-etc-fstab-how-sysfs-is-mounted [stackoverflow.com]
(Score: 1, Informative) by Anonymous Coward on Tuesday February 09 2016, @12:59PM
I run Openrc and it doesn't need to have the uefi firmware mounted as rw just to reboot the system.
This makes their excuse invalid and sloppy. Also it makes their 'it's msi's fault' excuse hilarious.
(Score: 0) by Anonymous Coward on Monday February 15 2016, @03:14AM
Not even to reboot into a different operating system?
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @05:52PM
As I understand it, the problem is that the OS wants to be able to update the BIOS/UEFI. This is a convenience for the very few times one will update/tweak the bios. Fine.
Since firmware is another vulnerable point in the computer (hacker can inject malware into the firmware) why is it writable by default???? Personally, I'd want a jumper on the motherboard that write-locks the bios by default. Either open the box to move the jumper or wire a physical switch (never software accessible switch) to the outside.
If the switch/jumper is write-protect, I couldn't care less what the OS does.
I'm sure someone will now tell me I've completely missed the point.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @06:04PM
(Score: 2, Insightful) by korger on Tuesday February 09 2016, @07:17PM
Many people pointed out that the cause of this problem lies in EFI itself, which allows to be written from the OS. While that is true, a responsible and secure OS would make steps to prevent that from happening, especially by accident. Instead, systemd widely exposes this problem by mounting the EFI fs read/write, all for the purpose of being able to boot into the firmware setup.
That's right, for the sake of one obscure feature, that most people shouldn't be using anyway, they create a huge vulnerability on the system. This reflects the attitude of the systemd developers in general, who prefer features to security. Even if users do not make the mistake of clobbering EFI themselves, malware can easily do that now on their behalf. In a world where malware is an increasingly bigger concern and not just for Windows users, using systemd is asking for trouble.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @08:25PM
What idiot would use that command? Maybe a noob that followed nefarious instructions found on the web, but I wouldn't. If I needed to wipe an entire drive I'd just delete the partition and reformat. Or use a DBAN CD. Or use a hammer and some lighter fluid. The only thing close to this I've ever had to do was a few bios updates, or other hardware flashing, but that's where you check 3 times before actually doing it.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @09:46PM
That is an excessive reaction in the case where you find systemd on your system. Warranted, but excessive.
(Score: 0) by Anonymous Coward on Monday February 15 2016, @04:07AM
Suppose I want to remove the directories foo1, ffoo2 and foo3. I mean to type
rm -rf foo*/
but I mistakenly type
rm -rf foo* /
and am screwed.
(Score: 0) by Anonymous Coward on Tuesday February 09 2016, @08:32PM
I remember a comment I saw on the other site a while back... something like "SystemD: It's like the reliability of PulseAudio with the utility of NetworkManager... but now in charge of your WHOLE kernel"
(Score: 2) by darkfeline on Tuesday February 09 2016, @11:44PM
I wonder how many people actually read the conversation.
I've heard that Poettering was an asshole, but his comments are reasonable and agreeable.
1) There are tools that expect efivarfs to be mounted writable.
2) Only root can write it.
3) Root already can fuck up your system. dd to vulnerable block devices, for example. The kernel may also expose virtual files that can brick hardware, depending on configuration.
4) You can fix this by adding an "ro" entry to fstab.
In fact, this really should be a bug in efivarfs, which should have implemented everything in terms of file writes and not letting file removal affect anything.
e.g., instead of allowing rm /foo/bar, efivarfs should instead do echo 1 > /foo/bar/remove.
Join the SDF Public Access UNIX System today!
(Score: 2) by darkfeline on Tuesday February 09 2016, @11:53PM
Also, "systemd SUCKS". Keep in mind that "UNIX SUCKS" too, after all, the root problem here is that rm does exactly what you tell it to do with no warnings, because that's the UNIX way. Feel free to replace it with a "trash" command that gives you more leeway than calling unlink(3) on every file on your system, or an operating system that always pops up a message "Are you SURE you want to do this? Triple sure? Pinky swear? Press Okay three times and do the macarena."
Join the SDF Public Access UNIX System today!