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