Request denied. It's not my job to coddle your, obviously fragile, emotional state. Your car metaphor fails for numerous reasons, not least of which is number of jobs can't at all convincingly be compared to car speed, and memory can't at all convincingly be compared to the radius of a curve in the road; but also that there are laws and physics as delimiters in the case of a car, neither of which apply to building software. In no legal, physics, ethical, or rational context is a user obligated to follow any made up rules. They are not obligated to RTFM. And certainly malicious software is not going to honor your ridiculous made up rules. And your rule is totally made up, it's worth less than thin air.

But maybe you can go whine and bellyache some more about how the rowhammer.js folks didn't follow the rules. Good luck marketing your whining and bellyaching, persuasive writing is definitely not in your skill set.

The default 'ninja' command sets the number of jobs based only on nrcpus + 2, in the example case that's 10 because it was a system with 8 logical cores. If I reboot with nr_cpus=4, then the default 'ninja' command spawns 6 jobs. 10 jobs (20 processes total) eventually wants more than 14GiB of memory which exceeds both RAM and swap, both of which are readily discoverable. This is all discussed in detail in the URL I supplied from the outset, by the way, there's no obfuscation. You could certainly blame the program for not being smarter about only spawning a number of jobs that can actually successfully complete given the resources on the machine. But as it's an unprivileged program, that's not a convincing argument.

Anyway the problem is well understood. If you bothered to commit more resources to reading than whining, you'd see over on the devel thread I originally cited, a paper from 2008 expressly discussing the very problem of interactivity guarantees not existing in the linux kernel, but could be. The author-developers did that very thing, and demonstrated consistent total take downs of linux where the modified kernel system continued to have positive user space interactivity. And a particular note made that this was tedious to demonstrate, because every take down required a reboot of the system running linux, that's how badly it face planted. Known problem. Not a secret. But a big problem for modern usage of computers, rather than insisting all users everywhere are just going to follow arbitrary made up rules to coddle the fragility of the kernel.

There are also other ideas in that thread including running as a systemd --user service with constraints, and now also in Rawhide cgroupsv2 is supported by default which allows quite more sophisticated limiters to be developed. But you wouldn't know that either because you're here whining instead, pining for some past epoch of computing when things were simpler. Fortunately, there are people forward looking, with active imaginations to innovate meaningful solutions for these problems.

Clearly you've missed or forgotten rowhammer.js. Nothing obligates me to follow build instructions. Nevertheless the very prominent build instructions were exactly followed: https://trac.webkit.org/wiki/B... "If you want to build WebKit for production use, you should stop reading here. The rest of the instructions on this page are only suitable for development and testing." I'm not developing or testing webkit. I'm testing system responsiveness for a system strongly biased toward users who require consistently reliable interactivity. Those are the exact commands I used (except for install, as I didn't get that far, the ninja command alone did the system in). Again, it's an unprivileged task effectively causing a system halt. It's not defendable.

Your excuses aren't at all compelling. Malware or even a runaway javascript script in a web browser could achieve this same effect, all it has to do is ask for ~14GiB of resources and the system will try and fail to grant that request, causing the system to implode just like this example. There's clearly distro developer work that needs to happen to solve this problem, blaming the user-developer is unconvincing besides being inappropriate. Really? 2019 and an unprivileged program can just implode a linux desktop? Not acceptable.

I haven't tested it, but I suspect Qubes OS wouldn't have this problem, even though the build would still fail, every user facing program is isolated in a VM so at least the entire system isn't taken down this easily.

Cntl-alt-fn was non-responsive. GNOME Shell, by default this is on Wayland. I haven't tried this on X11 but based on the remote ssh behavior, there's no reason to believe it'd be any different. I didn't try using a different nice value, that sorta defeats the point of the test and also the premise is that the system works fine out of the box. This is an unprivileged program imploding the system within about 10 minutes, and is in every reasonable way in a failed state the moment the mouse pointer freezes.

I was ssh'ing into this test system merely to observe state information with top and iotop, as the build progressed and soaked system resources away. While the build is happening, I'm using the shell and Firefox for normal use. And yes this is easily reproduced. Based on top and iotop yes I have a pretty good idea what caused it, the system ran out of resources. The unprivileged program spawned at least 20 processes on an 8 core system, some of those processes then went on to request in combination resources that exceeded both physical RAM and swap, and the system continued to try to accommodate those requests and then wedged itself into a situation where it may have eventually oom'd in an hour or 10 hours or a week. I have no idea. But at the point the mouse pointer froze, the system was lost and it's not unreasonable to consider it a failed state at that point. But I gave it 30 minutes and it was non-responsive both GUI and by ssh.

I once thought as you do, but it's come up a few times that developers have found their systems totally unresponsive while compiling. So I set out to investigate this and immediately ran into an example that reproduced this problem on the very first attempt: compiling webkitgtk. This is an unprivileged process, and it completely took down the system. As in, the GUI mouse pointer froze, and once frozen stayed that way until I forced power off 30 minutes later. It's reproducible. The remote ssh should have updated every 5 seconds, but it updated every 2-4 minutes instead with a conventional swap on SSD partition. But it was insufficiently responsive to kill the build process.

https://lists.fedoraproject.or...

macOS and Windows both use dynamically created swapfiles, and a separate hibernation file; whereas this is most typically combined on Linux, and isn't dynamically setup, it's decided at installation time.

I've discovered a reproducer on Linux where an unpriviliged compile process (compiling webkitgtk) soaks the system for more resources than it has, and makes it completely unrecoverable, but only if it has swap setup. If there's no swap, the oom killer is invoked fairly quickly once the system is in trouble. Somehow the slowness of swap (to an SSD) makes the system sufficient unresponsive that it's not distinguishable from a crash - the mouse pointer doesn't move at all for more than 30 minutes in the configuration I tested (8GiB RAM and 8GiB swap, a fairly common installer default).

I'm curious if Windows or macOS would accept an unprivileged program requesting so many more resources than what's available, that it effectively wedges the system into a hang.

I do not see how a software update fixes the problem, even though the software fix is also necessary. The MAX has a different stick force in a particular configuration, and MCAS is intended to be a moderator to that stick force so that it's more like an NG series. Ostensibly, MCAS exists to avoid a new type certification, and thus difference training, on the MAX. OK fine. The problem is that this moderator can be (effectively) turned off, and disabling it is explicitly a checklist line item for at least two non-normal situations: runaway trim, and MCAS upset. Disabling this stick force moderator means the pilots are exposed to the actual natural aerodynamic behavior of the airplane, for which they've received no difference training. They are in effect flying an airplane they are no longer type rated to fly. I think that's unacceptable. Whereas if Boeing makes it impossible to disable MCAS and its autotrim commands, that satisfies one part of the type certification problem, but then it introduces a new one which is the NG and original series do not have an automation feature that behaves anything like MCAS. And therefore the pilot needs difference training to understand it. I don't see how they get out from some form of difference training requirement, just by issuing a software update. And if it is required now, why wasn't it required from the outset. Who's pressuring everyone to stop the discussions of difference training being necessary?

It's not a format option in any GUI formatter, probably. And FAT32 is good enough except for that pesky file size limitation. And also it's a bit wonky in that it wants to format the entire block device, rather than a partition. But yes it's quite a sane choice, rw support on all platforms out of the box.

macOS does not have write support for NTFS out of the box. And it has neither read nor write support for ext2, ext3, or ext4. If you care about having a cross platform (macOS, Windows, Linux) file system for that last resort backup/archive, with a built-in driver on those platforms, that also supports large file sizes, you'd use UDF. If you're more of a storage geek, you might consider NTFS by enabling write support. And if you're even more of a storage geek you'd look at OpenZFS.

Yes. The battery is alot more dense than a bird. If a fan blade is even chipped, it can crack and splinter, in which case the entire engine breaks apart internally. There's a recent model simulating this floating around, and it shows the engine fan blades disintegrating in less than one revolution after impact.

Seriously. When are people going to stop pushing hurt me buttons with companies treating them like this? It's funny and sad at the same time.

I think any systemd related slashdot article ought to come with a number or time limit for anonymous coward posts. They all just seem to rile themselves up to ad homs and then talk of death and misery and then it just upends the whole conversation.

Get quotes from Netapp, EMC, and Red Hat.

Correct. This is the commit that fixes the problem. The patch actually goes back farther than it was merged, and then after merge it was two years until another stable release that had it appeared. And still many distros use a version of parted that predates this patch including RHEL 7 and openSUSE 13.2. The only distro I know off hand that uses the correct GUID is Fedora.

I don't know why it took so long. My soapbox version is I think there's a history of partition types being unreliable and pointless because in the MBR scheme there were so few of them that collisions were a given. So on Linux there's the expectation to check the actual contents of the partition to know what it is. libblkid can identify practically anything, and it doesn't care what the partition type is. Because of this, I think the Linux ecosystem has just gotten lazy. And so now on GPT scheme, they just grabbed the existing "basic data" GUID, rather than follow the UEFI spec which says "Each filesystem must publish its unique GUID." So technically the Linux ecosystem still has it wrong by using one Linux partition type GUID rather than one per filesystem; whether using GUIDs in such a granular fashion is helpful, I'm not sure.

Anyway, given the essentially infinite number of GUIDs available, using an existing one was just an extension of this mind set. Plus, parted isn't well suited for being patched to enable arbitrary GUIDs. So anytime there's a new GUID it's like pulling teeth to get the parted folks to add it, and often they actively resist while claiming there's no use case for X GUID.

Microsoft remembers how they took over Lotus' market share for spreadsheets. Lotus had no obscurity with their file format. Excel could read and write it perfectly. Open formats means the product must be as good or better for the price or users can jump ship. Closed formats are a buffer for mistakes or resting on laurels.