Maybe if you include third party android OEMs like samsung, but google pixels are as up to date as you can get.

Is there any evidence that the git commits weren't in the ROMs from months ago? The monthly ASB corresponds to when the bugs are publicly disclosed, not when they made it into ROMs.

The only way to get the full set of security preview patches is through GrapheneOS. It's strange Google doesn't ship more for the Pixel OS but that's the way it is right now. It takes them around 4 weeks to make a release and even longer when including the time for adding changes to it so there's a long delay built into the process. They should fix it but are clearly not prioritizing it without media pressure that's not happening. They do a lot better than other OEMs but that's much different from doing a good job.

I want to get some work done: Just as an example, this work consists of reading some email like "pls review this document, and create a presentation in response". I'll follow up the email with an answer and some clarifying questions. Then I'll read the document, making some notes. I'll read some additional documents, google stuff, look up some numbers, do some calculations, make more notes. Then I'll start drafting the presentation, refining it until ready, reading my notes, firing off another email with a few more questions. Then I'll send over the first version of the presentation.

Now all of those things live in different applications. All of those applications might be local file based or web-based. Some can do both. So I could try putting all the relevant files in a folder, holding all the files I need for this task. But wait, when I save an email as a file there, I cannot properly respond to it anymore. It is just a copy of the original email. Same for all the web-based stuff that even allows local copies. If I use hyperlinks, in the URL-as-a-unique-resource sense that was originally intended, I could link it all together in my notes. But many, if not all, modern web applications do not work that way, I cannot really link anything. And even if, most URLs are not stable. If I google something, I'll find a page I can bookmark or copy the URL of, but that page will change. To save the current state of that URL, I'll have to jump through a lot of hoops to maybe get a PDF printout file or something. And changing any document usually overwrites the previous version, so I'll have to do *-copy17.odt or deal with 20 different broken internal mechanisms of "version tracking". I can check everything into git, but then all the applications will have no clue how to deal with it, no proper diff, nothing.

One thing that I actually want was implemented in the first version of PalmOS as a hack: every application could contain links to every other application's content. You could link from a calendar entry to a contact who you wanted to visit. You could link from a contact to a note, detailing your last talk with each other. You could link the note to the last offer you sent the customer. etc. Of course this was rudimentary, but it was a start, which unfortunately died with later versions of PalmOS where those hacks were no longer possible. So for my original example, I want the original email to be annotated with a link to all the files I've created in response, all the web searches I did, etc.

Another thing is the notion of version control, extended to all desktop and web applications. I want to know what I did, when I did it, why I did it, and what related changes go together. I want to see the same thing for all my colleagues. I don't want any "this file conflicts with what your colleague did, which should I overwrite?". I want proper merges. In each application.

The only thing that even comes close to this nowadays is something like Emacs Org-Mode. If you stay strictly in Emacs.

Or is it just that I didn't try enough stuff and there is a real solution?

Edit: You actually inspired me to create a projects portion to my software that specifically adds a lot of this connective tissue that you feel is missing in most software today. As far as version control I can definitely add that as well but it will never solve issues like SharePoint versioning or MS versioning. That unfortunately is an issue MS needs to fix or whatever other ecosystem you work in.

Yes, but it took far less than using your meat brain to prove the Navier-Stokes Clay problem.

I assume that the mathematicians outside Anthropic were hoping to publish an actual human-understandable paper. That could be one way to draw line: you can use AI, but you must also have an intelligible explanation at the end.

(ZFS might be described as the love child of lvm and btrfs, 'cept ZFS got there first)

( Very briefly: you hand ZFS a stack of disks (in mirrors or raidz groups, for redundancy) and it makes a zpool. Then you carve the pool into datasets as needed. Each dataset looks like an ordinary directory and takes only the space its files actually use, so you never guess partition sizes again. And each one can have its own compression, snapshot schedule, quota, encryption, and send/receive backups, etc etc etc. )

Page cache duplication has been greatly lowered in last decade

It seems to work well in a variety of situations: 4GB/single-slow-SSD ancient systems work just as well as spinning rust bulk storage pools with NVME ARC/ZIL caches for my gaming/server/database datasets, and all-SATA-SSD pools can get to near-NVME performance with bonus redundancy for boot volumes and latency-critical stuff. For personal desktop use, I haven't found dedup worth the squeeze in RAM costs and tuning (it works, but it's generally easier to solve most dedup-compatible problems at a layer closer to the cause).

ZFSBootMenu and the ability to roll back to snapshots and restore/maintenance disks from outside of the primary operating system, without having to think about fallback boot drives or physical backup volumes, is a godsend in the "try random sketchy commands that might trash my installation in order to get a low-level driver problem resolved" and "I could take the time to understand what this curl | bash invocation does, but I have better things to do; I want to be able to reverse it if it breaks stuff" departments.

In general, I strongly recommend ZFS for daily-driver use. Its core primitives are quite flexible, it makes redundancy/backups/drive addition/replacement easy, and it works fine on old and under-resourced systems; the mythos of "it requires ECC and enterprise-grade hardware and tons of RAM/CPU to work at all" was always bunk. The enterprise/SAN features are there if you want them, but are off by default, and the core FS capabilities are widely useful. Even casual desktop Linux users would do well to set it up, since there are a lot of rare-but-real ordinary user needs that, if they come up and you're not running something like ZFS, can't be done at all unless you connect purpose-specific hard drives or reinstall your OS.

Especially now that NVMEs are so expensive, ZFS should be considered for its ability to make RAIDing up a set of slower drives (or mostly slow drives with an NVME cache) very easy. That way, you can make your existing disks into something that performs well enough that you don't need to spend money on new hardware.

Just don't install it via DKMS; get a distro that ships it compiled into the kernel or as an installable kernel-paired module. Many such distros exist. The DKMS edition won't eat your data, but you'll get real tired of failed system updates because the kernel changed some source and the compile failed. That happens often; turns out that the volume of the kernel API surface used by something as massive as the ZFS codebase is quite large.

Edit: upon reading back through this, I'm a bit sheepish that I sound like such a breathless shill. I promise I'm not in the ~pocket~ zpool of big filesystem. I just like it.

Not true at all.. but most large object storage redundancy has moved to the application layer. There are still workloads that are a great fit but I agree OpenZFS is currently not well suited as a general purpose FS.

As someone who originally ran it on Solaris when it came out ~20 years ago, and have continued to run it on FreeBSD and Linux, I would disagree.

But even for the "frequently reinstalled cattle"-usecase, LVM has benefits, e.g. snapshots for backups, debugging and forensics.

I use LVM on all my non-appliance Linux systems, [0] both servers and desktops. Given that few (no?) filesystems support online shrinking but every one that you'd use as '/' supports online growing, my strategy is to take a fairly conservative guess at how big my various subdirectories need to be and leave most of my available space unallocated. Later on, if I -say- find that I need more space in '/' or '/home', or prevent a blowup in '/var/log' from eating up all the space in '/' by putting that on a separate LV, etc, etc, it's just a few commands [1] and the job's done.

[0] ...someone else has configured the storage scheme for the appliances, and I'm not going to override their choices...

[1] ...and some data copying in the case of backing a subdirectory with a new volume...

Are you sure? They will seek out open WiFi and other neighboring LG TVs as relays.

But better watch the whole video. Then get snarky again ;)