tytso

People will do a small amount of work for free. But if something requires dozens or hundreds of programmers working full time, the chances of this happening is much less.

And if you want something which just works, it means you need a huge number of people doing grunt work, and that's the kind of thing that people are less likely to want to do in their free time.

This is ultimately a business model problem. There are FOSS projects out there; some of them are even listed in the article. The problem is that making it "Just Work(tm)" is hard; it's a lot of work, requiring a large number of engineers. And funny thing, engineers prefer food with their meals.

Saying "FOSS world" we need XXX is pretty useless. As a FOSS mainatinaer, the answer I always give people demanding their favorite pet feature is, "clean, maintainable patches are appreciated", ChromiumOS is free software; someone could take it use it as the basis for something like ChromeOS. But the author of the article has basically admitted that the derivitives of Chromium would quickly fail if Chromium stoped being something that they could free ride off of. Shouldn't that tell you everything about what the problem is with this picture?

Single malt was the currency of choice when bribing and/or placating SRE's and hwops folks. For example, if a SWE botched a rollout that caused a multiple SRE's to get paged at 3am, a bottle of single malt donated to the SRE bar was considered a way of apologizing.

Well, by that argument it's trivially easy to run emacs on a binary and change a pathname --- or wrap a program with another program to "fix a bug". Easy, no?

And yet, the people who insist on having source code so they can edit the program and recompile it have said that for programs, having just the binary isn't good enough.

There was definitely a certain amount of "I told you so" vibes, but I don't blame the author. It appears that he was attacked by a lot of Ello founders and fans for raising some cautionary notes. And as it turns out, he was right and they were wrong.

We would all like to have a model where users don't get charged money, and yet are not the product. But I haven't seen a model that works to date. In some cases, I don't mind my personal date getting sold; in other cases I pay money because the service is valuable. But I certainly make backups since I don't assume that even when I pay $$$, that the company might not go poof in the night....

But one of the four freedoms is being able to modify/tweek things, including the model. If all you have is the model weights, then you can't easily tweak the model. The model weights is hardly the preferred form for making changes to update the model.

The equivalent would be someone which gives you only the binary to Libreoffice. That's perfectly fine for editing documents and spreadsheets, but suppose you want to fix a bug in Libreoffice? Just having the binary is going to make it quite difficult to fix things.

Simiarly, suppose you find that the model has a bias in terms of labeling African Americans as criminals; or women as lousy computer programmers. If all you have is the model weights of the trained model, how easily can you fix the model? And how does that compare with running emacs on the Libreoffice binary?

They don't have to be low-end. You can buy higher-end Chromebooks, but they cost more money. Do people remember the "netbooks" that were-super cheap Windows laptops with 10 inch screens? Even if you install Linux on it, with the 512MB or 1G (or maybe 2GB for the really highly spec'ed out netbooks), there was real limits to what they could do.

If you want something super-cheap, then perhaps it won't be useful 5 or 10 years later. You get what you pay for; this isn't unique for Chromebooks.

Unfortunately, the supply chain often goes 3 and 4 levels deep. And by the time you get to companies that far in the supply chain, (a) no one has ever heard of that company, so the trying to threaten them with reputational damage doesn't really work (it will be some random set of chinese characters for a company in Shenzhen, for example), and (b) it will turn out that the team that wrote the device driver for that particular subcomponent in the SOC was disbanded as soon as the part was released, and 4 years later, half are working for a different company, and half were died during the COVID pandemic.

Sure, if you could set the Wayback machine back in time, and require that device driver be upstreamed, with enough programming information so it's possible to maintain the device driver, maybe it would be possible to upgrade to a newer kernel that doesn't have eleven hundred zero-day vulnerabilities. But meanwhile, back in the real world, very often there's not a whole lot you can do. So this is why it's kind of sad when people insist on buying Nvidia video chips that have proprietary blobs because performance, or power consumption, or whatever, instead of the more boring alternative that doesn't have the same eye-bleeding performance, but which has an open source device driver. Our buying choices, and the product reviewers that only consider performance, or battery life, etc., drives the supply chain, and the products that we get. And this is why we can't have nice things.

It might be worth taking a look at Bensonwood (https://bensonwood.com). They do some very impressive, high-end pre-fab homes, and they solve the "must fit in highway lanes" by shipping walls that have windows, electrical wiring, plumbing, etc., all already pre-installed in their factory in New Hampshire. When we investigated using them 3 years ago, they didn't support pre-installed CAT 5 wiring or Optical Fiber, but I wouldn't be surprised if they can do that now. :-)

This is all done using computer-controlled manufacturing equipment, much of which is imported from Europe, where they are much more advanced on this front than in the U.S. One of the advantages of having computer controlled nail guns and vaccuum operated "wall flippers" is that the construction tolerances are far tighter than if you have humans nailing in the shingles, sometimes while on a ladder 15 feet above the ground.

The downside, of course, is that they only today have their one factory in New Hampshire, and while the walls can be shipped trucks on highways, if you want to build a large, luxury pre-fab home in Arizona, the trucks have to travel a long way, and that adds to the cost. This hasn't stopped some of their customers, though. Take a look at their web site for some example houses that they have built --- it's a far cry from what most people think of when they hear about "pre-manufactured houses". These are not trailer park homes!

Cgroups are a lot more than just "namespaces". It is also the mechanism by which you can constrain how much CPU, Memory, Network Bandwidth, Storage IOPS or Throughput, etc., processes in a particular cgroup or container can use.

Disclaimer: I work for Google but nothing I say here is Google's opinion or relies on any Google internal information.

I'm not surprised that Workspace accounts weren't included in the initial rollout. Workspace setups have interesting requirements that aren't necessarily there for personal accounts. For example, under some circumstances, if an employee gets hit by a bus, and there is critical business data which is stored in the employee's account, an appropriately authorized Workspace admin is supposed to be able to gain access to the employee's account. But what is the right thing to do for passkey access? Especially if the user uses passkey to authenticate to some non-:Google resource like, say, Slack which has been set up for corporate use? Should the workspace admin be able to impersonate the corporate employee in order to gain access to non-Google resources via passkey? What about if the employee (accidentally) uses their corporate account to set up a passkey to a personal account, such as for example E*Trade? Maybe the Workspace admin should have a setting where passkey creation is disabled except for an allowlist of domains that are allowed for corporate workflows? It's complicated, and if I were the product manager, I'd want to take my time, understand all of the different customer requirements (where customer === the Workspace administrator who is paying the bills) before rolling out support for Workspace accounts.

motion sickness is a major barrier

I recall a story from a colleague who knew some folks who had worked on the game System Shock (this was in the early nineties). System shock was one of the first games that had an engine that implemented real 3D physics; so when you threw a grenade, it would describe a real parabola. And you can lean around a corner and sneak a peak without exposing your entire body to enemy fire, and when you did that, the 1st person shooter rendering would realistically reflect that. They had an experimental version of the game that was hooked to a virtual reality headset at the time, and gave up on it because, as one of them joked, it was "virtual reality, real nausea".

This was 30 years ago, and things haven't improved since then.

There is an old AI joke about a robot, after being told that it should go to the Moon, that it climbs the tree, sees that it has made the first baby steps towards being closer to the goal, and then gets stuck.

The way that people who are trying to use ChatGPT is certainly an example of what humans _hope_ the future of human/computer interaction should be. Whether or not Large Language Models such as ChatGPT is the path forward is yet to be seen. Personally, I think that model of "every-increasing neural network sizes" is a dead-end. What is needed is better semantic understanding --- that is, mapping words to abstract concepts, operating on those concepts, and then translating concepts back into words. We don't know how to do this today; all we know how to do is to make the neural networks larger and larger.

What we need is a way to have networks of networks, and creating networks which can handle memory, and time sense, and reasoning, such that the network of networks has pre-defined structures for these various skills, and ways of training these sub-networks. This is all something that organic brains have, but which neural networks today do not..

As I said, there are apps that need a Posix interface although my contention is the vast majority of them are "lift and shift" from customer data centers into the cloud. Sure, they exist. But from a cost, efficiency, and easy of supporting cross-data center reliability and robustness, the Posix file system interface was designed in the 1970's, and it shows.

If you have an app which needs a NoSQL interface, then you can do much better by using a cloud-native NoSQL service, as opposed to using Cassandra on your VM and then hoping you can get cross-zone reliability by using something like a Regional Persistent Disk. And sure, you could use Cassandra on top of cifs/smbfs or nfs, but the results will be disappointing. These are 20th century tools, and it shows.

If customers want Posix because they don't want to update their application to use Spanner, or Big Table, or GCS, they certainly have every right to make that choice. But they will get worse price/performance/reliability as a result. You keep talking about ossification and people refusing to refactor the storage stack. Well, I'd like to submit to you that being wedded to a "posix file system" as the one true storage interface is another form of ossification. Storage stacks that feature NoSQL, relational database, and object storage WITHOUT an underlying Posix file systems might be a much more radical, and ultimately, the "proper stack refactoring". A "modern containerized cloud workload" is better off using Cloud Spanner, Cloud BigTable, or Cloud Storage, depending on the application and use case. Why stick with a 1970's posix file system with all of its limitations? (And I say this as an ext4 maintainer who knows about all of the warts and limitations of the Posix file interface.)

Of course, for customers who insist on a Posix file system, they can use GCE PD or Amazon EBS for local file systems, or they can use GCE Cloud Filestore or Amazon EFS if they want an NFS solution. But it will not be as cost effective, or performant as other cloud native alternatives.

Finally, just because you are using "oss lib/software" does not mean that you need "Posix-complaint storage". Especially inside Google, while those internal customers do exist, they are a super-tiny minority. Most internal teams use a much smarter approach, even if that means that an adaption layer is needed between some particular piece of OSS software and a more modern, scalable storage infrastructure. (And for many OSS libraries, they don't need a Posix-complaint interface at all!)

Posix-complaint means sticking with an interface invented 50 years ago, with technological assumptions which may not be true today. Sometimes you might need to fall back to Posix for legacy software --- but we're talking about "modern containerized cloud workloads", remember?

No one asked for a "block device"? Um, that's table stakes because every single OS in the world needs to be able to boot their system, and that requires a block device. Every single cloud system provides a block device because if it wasn't there, customers wouldn't be able to use their VM, and you can sure they would be asking for it. Every single cloud system has also provided from day one something like AWS S3 or GCE's GCS so users can store files. So I'm pretty sure you don't know what you are talking about.

As far as "proper stack refactoring" is concerned, again, the key is to make a business case for why that work is necessary. Tech debt can be a good reason, but doing massive refactoring just because it _could_ help other teams requires much more justification than "it could be beneficial". Google has plenty of storage solutions which work across multiple datacenters / GCE zones, including Google Cloud Storage, Cloud Spanner and Cloud Bigtable. These solutions or their equivalent were available and used internally by teams long befoe they were available as public offerings for Cloud customers. So "we could have done it a different way because it mgiht benefit other teams" is an extraordinary claim which requires extraordinary evidence. Speaking as someone who has worked in storage infrastructure for over a decade, I don't see the calcification you refer to, and there are good reasons why things are done the way that are which go far beyond the current org chart. There have been a huge amount of innovative work done in the storage infrastructure teams.

I will say that the posix/nfs/smb way of doing things is not necessarily the best way to provide lowest possible storage TCO. It may be the most convenient way if you need to lift and shift enterprise workloads into the cloud, sure. But if you are writing software from scratch, or if you are internal Google product team which is using internal storage solutions such as Colossus, BigTable, Spanner, etc., it is much cheaper, especially if you are writing software that must be highly scalable, to use these technologies as opposed to posix/nfs/smb. All cloud providers, Google Cloud included, will provide multiple storage solutions to meet the customer where they are at. But would I recommend that a greenfield application start by relying on NFS or SMB today? Hell, no! There are much better 21st century technologies that are available today. Why start a new project by tying yourself to such legacy systems with all of their attendant limitations and costs?

In my part of Google, we use TPM for "Technical Program Managers" instead of PgM.

In general a TPM at Level N will have the technical skills of a Level N-1 SWE. So many TPM's have a CS background, and a good TPM is an amazing partner/resource for a TL to have, especially for a large, complex project which spans multiple teams and multiple departments.

For my Hybrid SMR project, my TPM came out of a HDD vendor, and was very well versed in the technologies of HDD internals. At the same time, he could navigate all of the bureaucracy and process to get test racks ordered, populated with servers, and installed in data centers. He could also create the capital budget plan and get it submitted and approved through finance so I could concentrate on the technology. A good TPM is critical for the success of a large projects; I couldn't have done it without him.

Oh, you can certainly do big projects. My project[1] spanned 3 departments, and involved dozens of engineers, and required that we work with multiple hard drive vendors (our first two partners for Hybrid SMR were Seagate and WDC) on an entirely new type of HDD, as well as the T10/T13 standards committees so we could standardize the commands that we need to send to these HDD's. So this was all a huge amount of "new shit" that was not only new to Google, it was new to the HDD industry. You just have to have a really strong business case that shows how you can save Google a large amount of money.

[1] https://blog.google/products/google-cloud/dynamic-hybrid-smr...

[2] https://www.t10.org/pipermail/t10/2018-September/018566.html

On the production kernel team, colleagues of mine worked on some really cool and new shit: ghOSt, which delegates scheduling decisions to userspace in a highly efficient manner[3]. It was published in SOSP 2021/SIGOPS [4][5], so peer reviewers thought it was a pretty big deal. I wasn't involved in it, but I'm in awe this cool new work that my peers in the prodkernel team created, all of which was not only described in detail in peer-reviewed papers, but also published as Open Source.

[3] https://research.google/pubs/pub50833/

[4] https://www.youtube.com/watch?v=j4ABe4dsbIY

[5] https://dl.acm.org/doi/10.1145/3477132.3483542

We have some really top-notch engineers in our production kernel team, and I'm very proud to be part of an organization has this kind of talent.

Here are the latest development statistics from the just-released 5.19 kernel. (Please consider supporting Linux Weekly News by subscribing if you find content like this useful; one of the benefits is you can help share subscriber-only content to friends and colleagues via Subscriber Links):

https://lwn.net/SubscriberLink/902854/b788a6a3d77aba7a/

If you scroll down to the Most active employers in 5.19 by commits you'll see:

1. Intel 10.9% 2. (Unknown) 7.5% 3. Linaro 5.7% 4. AMD 5.5% 5. Red Hat 5.2% 6. (None) 4.3% 7. Google 4.1% 8. Meta 3.5% 9. SUSE 3.1% 10. Huawei 2.9%

The statistics are slightly different if you count by lines of codes changed, but either way, it's not all FANNG companies, not by a long shot. There are plenty of people who get started coding via kernelnewbies.org and other resources.

I work at Google so my perspective is to be biased, but that's not what I see.

I work on infrastructure, and so a few years back, when I proposed a major project, I had to demonstrate how it would save *many* times the fully loaded cost of the engineers on the team, by reducing the Storage TCO for all of Google (for example). It was not enough for the project to "break even" --- the benefits had to do more than just exceed the "nominal" SWE cost. It had to be multiple times the cost of the SWE's, to account for the opportunity cost of those SWE's --- SWE's are a constrained resource, which is why a project needs to save $$$ (or increase profits) by many multiples the fully loaded SWE cost. (That project has since been completed, successfully, and I got a promotion to Sr Staff Engineer out of it.)

The reason why SWE's are a constrained resource is becaused finding good SWE's is non-trivial. As a TL, I don't want to waste my precious approved headcount on people who just want to rest and vest, or people who believe in the crazy talk of only needing to work 30 minutes each day. I'm trying to find highly motivated, smart, and talented SWE's who can also be team players. And if they need to have domain expertise (say, be proficient kernel engineers), it's super-duper difficult.

So I don't see any indication of people getting hired just to starve statups of talented engineers. We need every single talented engineer we can get for the projects that we want to accomplish. And in the time when we may need to slow down our growth, it may mean that we will need to slow, or shut down some projects. That may suck, especially if it's a project that we had invested a lot of passion into. But it's certainly no reason to panic. Slowing down growth is not the same as layoffs, and there is no shortage of work for us to do.

I very much doubt whether the MIT Press Office cares about what Hacker News thinks of their brand. What they do care about is what Sarah J. Student's parents think when they are trying to encourage their progency to attend Harvard vs Yale vs Stanford. And positive press is good towards achieving that mission, even if it is a bit click-baity. And since all universities are playing this game to one degree or another, it's asking quite a lot for one univesity to unilaterally agree to disarm.

The other "brand" that universities care about is the their reputation by their professor's peers when it comes to hiring the best talent for their departments, and with the granting agencies who are deciding which research proposals they should fund. And here, what matters is the peer-reviewed publications at various academic journals and conferences. Whether a university's press office puts out a press release, which then gets mangled by various newspapers, doesn't really have negative or positive effect when it comes to how a university's research work is measured by the People Who Really Matter --- namely, other professors and the people who dispense the cash. Hacker News falls into neither of these two categories.

Keep in mind that the MIT Press office != the professors at MIT. It's actually quite common for any University's press office to be clueless about the research being done at the university, and it is their job to make as big of a splash as possible.

This is much like the oft-cited issue that the reporters aren't responsible for the headlines --- that is picked by the editors to make as big of a splash as possible.

As far as "patenting a technology from the 60's", even an incremental improvement on an old idea is still patentable. The real test is whether the patent cited the prior art, and you can bet that MIT Press Office didn't read the patent application before breathlessly sending out the press release.

Indeed, the statement of slavery not providing any economic benefits as a whole is a country-level statement. Whether or not there exists certain large slaveholders, or business people in the North who made their family fortune building ships for the slave trade, or worse, trading slaves, who did benefit from slavery is not really subject to debate.

The hard question from a reparations perspective is suppose that business person left the bulk of their family fortune to a particular church diocese. Let's further assume that donation was made in the form of the trust fund, so it's very easy to identify the source of a particular trust fund would not have existed but for the fact that this business person was part of the slave trade. What moral obligation, if any, does the church diocese have to repairing the harms that this donor may have inflicted on a group of people more than a century ago, given that in the meantime this church diocese has been enjoying a continuing income stream that originally had its roots in the slave trade?

One could argue, "none at all", and one could also point out that there was an awful lot of good being done by the works enabled from the income stream of that trust fund. Dismantling that trust fund (if it can be legally done; there might be donor restrictions that might make this difficult/impossible) would eliminate the good being done via that trust fund. But one could argue that this is a similar argument made by the British Museum when it was refusing to return the Elgin Marbles, and that it is a bogus one. Or someone could argue that no matter what the value of that trust fund should be, it pales in comparison that the harm that has been done, and so you shouldn't even try. Others might argue that at least admitting the truth of how an organization has benefited by past injustices is the important thing, and that reparations is not so much about money, as it is about repair --- acknolwedging and making at least some effort to repair the damage to the community by past injusticies.

After all, if someone burns down your home, what gets lost is far more than the monetary damages; it's also the emotion impact of having your home being lost, and objects of sentimental value, such as photographs, jewelry once owned by your mother, etc., which can't be compensated using mere money. All of that is true. And yet, having a true and sincere "I'm sorry" by someone who is genuinely sorrowful and repentant, can mean an awful lot.

Bottom line is "reparations" is a deeply complex topic, and it is not just about writing checks. In fact, that's arguably the least important part of the whole process. It's unfortunate that this is the part that most people who are against reparations focus upon.

They way you phrased your "simple question": "Then why don't they give the option to enable this in a "work mode" and not turn it on for everyone by default?" assumed that Google had turned it on for everyone, and it read as if you thought that was unreasonable and outrageous.

It might be nice if people assumed good faith, as opposed to assuming that anything that $BIG_COMPANY might do is unreasonable and evil. Certainly many people on these threads immediately leapt to the assumption that it was enabled for everyone and was trying to coerce people into some kind of DEI hell that conservatives hate.

Actually, it is only going to be enabled for "work mode". It is not being turned on for everyone by default. Certainly not if you are talking about the consumer version of Google Docs, and not even all paid versions of Google Workspace. So not only does your employer have to pay for the feature, they may have to pay extra if they are currently purchasing one of the cheaper tiers of service.

Specifically, it is only going to be enabled for these editions of Google Workspace: Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Education Plus

It is *not* going to be enabled for: Google Workspace Essentials, Business Starter, Enterprise Essentials, Education Fundamentals, Teaching and Learning Upgrade, Education Standard, Frontline, Nonprofits, G Suite Basic and Business customers

Even for those business accounts where this feature is enabled, the Workspace Admin for that domain can turn these stylistic suggestions on or off. (And you can turn off the inclusive language suggestions, while leaving other suggestions, such as for "concise language" on or off. There is a certain amount of granularity as to which classes of stylistic suggestions are enabled or not.) And users can also turn it on or off for themselves, regardless of what your Workspace Admin has decided about the defaults.

So sorry for bursting your righteous outrage bubble, but the intent is to enable this for those companies that might want to nudge their employees towards using more professional style of language. And if you don't like that, you can always leave and go work for some other employer....

In practice it's not hard that hard to solve if you only are supporting a limited number of CPU architectures (e.g., all the world's x86) or only one bootloader. Even if some of the BSD systems support multiple architectures, in practice, they are mostly used only in x86 servers --- and are mostly judged by how well or poorly they work on x86. In contrast, Linux has to work on a very large number of embedded architectures, and some of the CPU architectures don't even have a fine-grained CPU cycle counter, let alone something like RDRAND. And some architectures have practically no peripherals that provide unpredictable input, and some of them very cleverly generate RSA keys and x.509 certificates as the very first thing they do as part of their "out of box" experience.

If you can assume that you're always running on x86 architecture, with RDRAND and RDSEED, and pretty much all desktops, servers, and laptops have TPM chips (which have their own hardware random number generator) and are using UEFI boot (which also has a random number generator) --- and while maybe one of these are either incompetently designed, or backdoored by either the NSA or MSS, hopefully not all of them have been compromised, it's really not that hard.

The challenge has always being on the crap embedded/mobile devies, where manufacturers live and die based on a tenth of a penny in BOM costs..... (and where they tend to have hardware engineers writing firmware and device drivers, and contractors implementing their Minimum Viable Product, and no one ever goes back to retrofit security....)

Part of the whole point of this blog was to explain why it's not possible to explain and satisfy their curiosity, because the reasons can't be disclosed externally outside of the company (either because the reasons are under NDA, or involve lawyer's concerns over terms or conditions, or because the company doesn't want to call out some project leader as a toxic jerk).

The blog post is a general answer of why sometimes people's curiosity can't be satisfied; pamphlets are so 18th century, after all. Sure, that's what the authors of the Federalist Papers used, but in the 21st century, we use blog posts instead of pamphlets. :-)

Googler here, so here's a sample size of one.

1) I personally use Google, because it works for me. I will admit freely that part of this may be that I've gotten used to framing queries such that it works with the search engine that I'm used to using, and that's probably true for many people commenting on HN.

2) Every so often, these posts will inspire me to do my own non-scientific experiments such as using the same query, say, "Dua Lipa Levitating" or "Go modules vs packages" on say, DDG, Bing, and Google. When I did this experiment most reently, I generally find that Bing and Google are both more personally useful for me and DDG is less useful (but as the old latin saying goes, "De gustibus non est disputandum"). I will note that DDG had the more obstrusive advertising at the top of the results (Stubhub and Urban outfitters), and Bing and Google did not have any adds that I could find for that first query.

Given my personal evaluations, it tends to cause me to discount what many of the DDG enthusiasts have to say about DDG being is way better, simply because it doesn't accord with my own quickie experiments. But hey --- maybe it's because they enter in search queries differently than I do.

3) Given the hyperbolic and/or highly emotive nature of some of the comments about "holding users hostage" and complete lack of nuance over "violating users' privacy", again, it causes me to have a hard time taking everything else that rhwy have to say seriously.

4) I sometimes suspect people are remembering the past with rose colored glasses. I remember the search quality of Alta Vista (and with all due respect to the people who worked on Alita Vista and having had friends who worked there), the results were pretty crappy, and Google's results were heads and shoulders above somoe of the other competitors that were available back in the day.

5) All of this is my personal opinion; and users should feel free to use whatever search engine they want, and competition is a good thing.

Since you live in San Francisco, a number of companies (I know for sure Facebook and Google) have ways where you know somone who works at that company, and who can vouch for you, they can help you get control back to an account that has been lost or taken over by someone malicious. Maybe you know someone at those companies? The companies themselves generally don't advertise this, because it obviously doesn't scale, and they'd be concerned with people who try to strike up a "friendship" with an employee just so they can backdoor access to an account --- this is something that can be used as a security attack vector as well! (So it works best for, "I've known this person for the last X years, and last month they completely lost control over their account. I can say for sure they are who they say they are and not a conman or a state-sponsored intelligence agent." sort of thing.)

Other than that, what I try to tell everyone to use 2FA authentication, and not just SMS text messages or TOTP's, but FIDO Security Keys to protect your digital identity. Never reuse passwords and use a password manager, yadda, yadda, yadda.

Or (3) companies that make $$$ or save $$$ from using Postgres could hire kernel developers to implement a better solution for buffered I/O. The problem is that the companies who are serious about I/O recovery use Direct I/O, so engineers that are employed by those companies have plenty of other improvements such as io_uring, improving general storage performance, adding support for inline encryption engines to improve performance on mobile devices, etc., etc., etc.

People seem to forget that Open Source does not mean that users get to demand that unpaid volunteers will magically do work for their pet feature requests. It just means that the source code is available and people are free to improve the code to make it better fit their use case. A proprietary OS is like a car whose hood is welded shut, and only the dealer is allowed to service it. An open source OS means that you can take the car to whomever you like, or even service the car, or improve the car, yourself. It does not mean that you get to have service or improvements to your car engine for free.

The other thing to note here is that Postgres was issuing fsync(2) calls from different processes, and some of those processes were ignoring the error return from fsync(2). If there is an I/O error, fsync(2) will tell userspace about it. However, there is nothing in POSIX which states that once a file has an I/O error associated with it, the fsync(2) system call will return errors forever and ever, Amen. So Postgres was being a bit dodgy with error returns as well, and was demanding that something that POSIX clearly never promised.

You can boot a system with a btrfs root file system without having the btrfs-progs installed.

Good luck trying to use SELinux without having the policy installed; it's guaranteed to be non-functional. And given that the SELinux policy is distro-speicific, it's not like you can take a random Linux distribution, and enable SELinux and expect it to work. You enable SELinux on the boot command-line, but without the policy installed, it will be dead in the water. And configuring the SELinux policy is extremely non-trivial. It's several orders of magnitude more challenging than running, say, "mkfs.btrfs".

That is exactly operating system does, which is the topic of discussion. Linux >OSs such as RHEL as an example.

If that's your definition of an OS, then there are plenty of Linux distributions --- aka, an "OS" by your definition --- that do *NOT* have SELinux built in, because they don't have an SELinux policy defined that will work with that distribution's system daemons.

Therefore, by your definition SELinux is not "built in" to all versions of Linux (specifically, "distributions"). Q.E.D.