"Probably indistinguishable for web based services"
Probably easily noticeable. Garbage collection regularly causes huge latency spikes. Depending on how well the managed code application is written... usefully not very well.
64 publicly visible posts • joined 16 Apr 2010
Why do Intel shareholders continue to hitch their cart to the dead Gelsinger horse? You would think it would be enough to see how VMWare shriveled on his watch, but no... EMC had to tractorbeam him upstairs to shrivel the whole company. Then back to Intel for... more what? Bright spot: this bodes well for AMD.
"it gives me a nice feeiling I'm not pumping metrics to google or microsoft, except for the search"
I now do most of my searches directly to Wikipedia, because 90% of the time the first link google or bing feeds me is in fact Wikipedia. From time to time I use google or bing to search Wikipedia, because Wikipedia's search isn't actually very good... but good enough when your search terms map more or less direction to a Wikipedia page. This probably accounts for about half the remaining 10%, so google and microsoft can spy on some of my wikipedia searches.
Oh wait, I use duckduckgo for almost all of those, and 80% of my remaining searches. So I only expose 1% of my searches to the evil eyes of google and microsoft, and then in a private browsing page, which won't stop their snooping, but certainly puts a crimp in it.
As a reality check on all these defensive measures, I note that the few embedded ads that get past my ad blocker are really randomly targeted, which gives me some confidence that they are not seeing most of my search terms. Note: the level of creepiness exhibited by googlesoft pales in comparison to Facebook. That stopped when I permanently logged out of Facebook, destroyed all its cookies and removed anything remotely related to Facebook from my devices.
And did I impose any new burden on myself in my low level pushback against evil snooping? I really don't think so. A few extra clicks or buttons. As a sweetener, perceptibly faster loading pages.
> they have decided not to give anyone who chooses to exercise that right any future updates.
That unambiguously violates the spirit of GPL. From where I sit it also appears to be an "additional restriction", forbidden by GPL. If that is correct then Red Hat risks losing the right to redistribute that GPL code itself, ironically the same right they now deny their customers in the monomaniacal pursuit of quarterly numbers.
"a lot of their other patches were rejected as invalid"
I have read the thread, have you? "A lot" is simply wrong. I saw one where they followed the api documentation to the letter. The documentation says:
* If this function returns an error, kobject_put() must be called to
* properly clean up the memory associated with the object. This is the
* same type of error handling after a call to kobject_add() and kobject
* lifetime rules are the same here.
so they submitted a patch to change a kfree to a kobject_put as the documentation directs. The patch was reviewed and accepted. In this case, the documentation was wrong.
There are precious few others. The count might be up as high as two by now. Against this there are a lot (objectively true) of real bug fixes where maintainers either NACKed the revert or said they would just have to do the fix over again if it was reverted.
"since a very large number of patches have to be rolled back..."
Doesn't look like that: https://lkml.org/lkml/2021/4/21/454
Maintainers are mostly NACKing the propoosed reverts, or stating that no harm is done.
What is true: a large number of patches need to be reviewed. But that was always true, and arguably review has gotten slack lately. Howls of protest over the simple proof of that isn't going to fix it.
These researchers didn't "get caught", rather they published a paper. Over the years they have published a lot of good and valuable papers and submitted many patches to fix real kernel bugs and otherwise improve the kernel. See for yourself: https://lkml.org/lkml/2021/4/21/454. (Maintainers replying to these proposed reverts are pretty much all saying "don't revert it, it's a good patch" or "it does no harm".)
It is clear that these guys are not bad guys. They have done good things for Linux, and they were in the process of trying to do another good thing when they made a mistake. Why has an angry mob now set out to destroy the careers of these good people? Surely we are smarter than that.
"Rust had nothing to do with that"
You don't know that. Sometimes a language platform will make a given approach practical and pleasant to implement, compared to tedious in some other language. This effect is seen regularly when migrating a project from C to C++, though you would never be able to convince a dyed in the wool C diehard of that.
Here's the problem with a bunch of software hacks commenting on an aviation issue: regardless of the relative strengths or lack thereof of the development and testing methodology, this software would not have been needed at all, were the Max 8 airframe inherently stable. Which it is not, with horrific consequences.
The reason that both Linus and I home in on that quote and heaped abuse upon the idiot who posted it is, it's an idiotic thing to say. Along the lines of "water is lighter than air". Yah, you can bore everyone to tears trotting out some case where water really is lighter than air, but oh please. Save that for when you really feel the need to be ignored at a party. Same goes for Chinner's unadulterated idiocy, followed up by wasting an enormous amount of bandwidth attempting to buttress that indefensible position.
It's clear that you have only the most tenuous grasp of file system basics. Minimizing write latency is not the primary goal of a filesystem, rather, the goal is to minimize operation latency. That is why nearly all write IO on Linux is buffered, not fsync. Simple fact, which apparently escaped you.
Now if you want to talk about synchronous IO, that is interesting. Just don't labor under the delusion that this is the most important aspect of file system design. And for the record, XFS and by extension Chinner, suck at sync IO.
Maybe you think Chinner is right because you didn't read what he posted, or read it and didn't understand. I quote: "the page cache is still far, far slower than direct IO". No, wrong. Idiot.
There may be specific cases were that isn't a bald faced lie, but in general it's just that: a bald faced like. Chinner. Just ignore.
Yah, well. Maybe. You have to keep in mind that Chinner can be a bit of a dull thud at times, and a flipping dickhead on top of it. Pay attention to what guys like Jan Kara have to say, or some of the less aggressive ext4 guys. Chinner is all politics, all the time, and sadly unsocialized. Makes Linux look like a pedigreed gentleman by contrast.
I'm totally ok with Redhat getting sliced, diced and ground to bits in the proverbial IBM meat grinder. And sow their fields to salt while at it. After all, they gave us Ggnnnnome and Sssystemd (insert Sytherin sounds here) Oh, and RPM... and the ultimate evil: -> Rpmbuild <-!!!
Red Hat can just shrivel and die and the Linux ecosystem will just get out from underneath its cold dead thumb and grow faster than ever before. A pox upon Redhat and a pox upon Redhat's smarmy salesmen who think that copying Linux is stealing from Redhat.
The issue _is_ the aerodynamic instability of the airframe in near stall. If it were not unstable then there would not have been any MCAS and all those people would still be alive. Just retire the 737, it had a good run but by today's standards it is a scary piece of junk.
"makes about as much sense as driving a supercar around with the hand brake on"
For bulk SSD that trades off access time against density, SATA still makes perfect sense. 600 Mbytes/sec is a beefy transfer rate compared to physical disk, but the big win is zero seek time. Use M.2 for your system disk.
"To encode 4 bits you need 16 distinct voltage levels, no?"
Right, and so L)evel has always been a gross misnomer, it should be B)it. A multi-bit flash cell has 2**L voltage levels, using the highly misleading L)evel terminology.
Like this: https://www.cactus-tech.com/assets/images/e/MLC-NAND-Cell---4-States-of-Electrons-9a049c6e.png
You are a bit confused about the distinction between analog and digital. At the nanoscale, its all analog (and at femtoscale it's all digitial again that's a bit deep for this post, just google quantum number). Those rather alarmingly analog-looking traces are coerced into representing digital values via thresholding and latching effects. Ever seen an ether bird? It's a bit like that. A wind-up clock is like that too: the spring is analog but the tick is digital.
Multilevel cells likewise rely on thresholding and latching effects, there is just more than a single threshold value. Still digital by nature, just like single level cells, Maybe the threshold voltages or whatever get closer together in multi-level and risk more errors, or maybe not. Single level logic gets shrunk and packed together as tightly as possible, which also increases the risk of error. Given the same number of bits stored in the same area, it is far from clear that multi-level cells have the higher risk of error, it may be just the opposite.
But wait, what would TheReg be without premature clickbait? It's the entire reason we come here instead of some reputable site, isn't it. Here I am, for example.
TheReg is partially right, even with its trademark suspect reasoning: hard drives are already mostly dead in PCs. Well, except for the really cheap ones and that island is steadily shrinking. And except for media packrats who rely on hard drives to archive their porn collection.
Hard drives are alive and well in server farms. While SSD continues to nibble at the edges, the economics of mass storage that doesn't mind 10ms latency are compelling. That amounts to the vast majority of data storage in the world. With the likelihood of further improvements in areal density, it will be many years before hard drives are as dead as tape.
From time to time Linus shoots his mouth off in a way that is totally inappropriate. This is not one of those times. Technically, Linus is exactly correct. He could have posted without swearing and that would be nice, but there's no burning issue, this time. So: "it's a f*cking disgrace that you are in denial about the fact that it's the *checking* that is broken, not the code, and are making excuses for shit". Right. Pinpoint accurate but better without the swear words. Good for you, for tilting at that windmill.
Here's the equation: Neither Android nor Ubuntu care a wit about X86 compatibility, even a modest power saving is worth infinitely more, and there is a practical certainty that 86x prices will be jacked to the moon by the one source supplier given any significant success. Only Windows care about x86 now, and the Windows on mobile is looking bleak indeed, never mind the present. On server, desktop and high end laptop, nobody wants a crippled x86. So the future market for Atom rounds to zero, and no tears shed.
Count me among those who initially respected him for his enthusiasm (and not for his coding or design skills, which are quite obviously deficient - I give you Bonobo as just one of many examples). But now I regard him as a cynical profiteer whose agenda is and always was to undermine anything non Microsoft. As for his motivation, I can only speculate, but I do know that money talks, and talks especially loudly to those of weak moral character.