You make a very compelling argument. I've been thinking of at least trying it out before, but have been leaning towards it more and more over the years. A couple of questions though, if I could bother you with them?

How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?

And how programmable is the configuration of Qubes? I like the idea of NixOS for example, but given how comparatively little activity there is in the actual nix rather than the packages, and across so few developers, I worry what would happen if someone got hit by a bus or something. But I still like programmatically configuring computers over manual monkey patches, because I have the memory of a gold fish. :p

> How is remoting performance e.g. via VNC/RDP or particularly via Moonlight+Sunshine (intended for gaming and such)?

I've used RDP w/ remmina and found the performance somewhat poor but usable-- I think it does too much video writes, so it's more like playing a video I expect Moonlight+Sunshine would be equal or worse. Xpra seems to work better than RDP for me. I didn't try to optimize the RDP since I tried xpra and it was better. (I use it to control remote GUI amateur radio software like WSJTX)

There are workarounds I didn't mention for video performance, e.g. handing direct hardware access to a GPU to a specific VM. But this obviously has security consequences and I don't have much experience with it.

Qubes itself is very thin. The most popular template vms (that you actually run apps in) are Fedora and Debian. The qubes system vms run on Fedora. So I think on the VM OSes themselves there is no maintenance concern-- so for example, you're not dependent on the qubes project for packaging software generally. (Though you do use qubes produced templates of the OS installs-- as they have some configuration to handle the overlay filesystems, clipboard, file transfer, networking, etc).

There is also work that people are doing to make NixOS a first class app vm image and even people working on being able to use it for dom0.

The qubes maintained stuff is dom0 and the glue that handles stuff like copying between VMs, wiring up networking to VMs, etc. Most of it is python. I've found relatively little need to mess with that stuff. Its configured via text files that are processed via (mostly) python scripts. Beyond the active developers there is a user community that has a lot of experience doing fancy stuff with the infrastructure, like adding support for ephemeral VMs that exist only in ram (for anti-forensics). I think that speaks positively to the maintainability of the system.

Ultimately because qubes is a system of VMs based on commodity OS migrating OUT shouldn't be fundamentally hard.

FWIW, I migrated in to qubes (from Fedora) by making an app VM for my existing laptop, copying the home into it. Then initially running everything in that one VM. It's not a good way to use Qubes, but it had me full on it in a couple hours with no loss of capability. From there it was easy to start moving things into other VMs until I no longer used the original.

It does: https://fossil-scm.org/home/doc/tip/www/shunning.wiki.

"Fossil purposely makes it difficult for users to delete content."

Those operations are explicitly declared special, not something you do many times per day because you had a typo in your print statement. I guess technically you can do it often, but the tooling does not make it easy at all, and you are going against program's recommended best practices.

Those two pipe dreams sound really cool! Do you have a website or something to lurk you via if you eventuality get around to those? I find it difficult to keep up, as it were, using form histories and other social media platforms.

If you are going to quote a dictionary, please first ensure you are quoting it properly and without misrepresenting the contents and b) that in cases wherein a definition has multiple potential meanings it lists the different uses from common to uncommon.

As per the actual 1828 Noah Webster's dictionary, which you can find here https://archive.org/details/noah-websters-1828-dictionary-el..., on page 7828, the definition of "Milk" is:

MILK, n. 1. A white fluid or liquor, secreted by certain glands in female animals, and drawn from the breasts for the nourishment of their young.NWAD MILK.2 2. The white juice of certain plants.NWAD MILK.3 3. Emulsion made by bruising seeds.NWAD MILK.4

And, just in case the commonality of milk being milk from a cow, see also the other shorthand definitions noted on pages 987 and 988 of the table of contents.

MILKEN, a. Consisting of milk. [Not used.] MILKER, n. One that milks. MILK-FEVER, n. A fever which accompanies the first flowing of milk in females after childbirth. MILK-HEDGE, n. A shrub growing on the Coromandel coast, containing a milky juice. MILKINESS, n. Qualities like those of milk; softness. MILK-LIVERED, a. Cowardly; timorous. MILKMAID, n. A woman that milks or is employed in the dairy. MILKMAN, n. A man that sells milk or carries milk to market. MILKPAIL, n. A pail which receives the milk drawn from cows. MILKPAN, n. A pan in which milk is set. MILKPORRIDGE, MILKPOTTAGE, n. A species of food composed of milk or milk and water, boiled with meal or flour. MILKSCORE, n. An account of milk sold or purchased in small quantities, scored or marked. MILKSOP, n. A soft, effeminate, feeble-minded man. MILK-THISTLE, n. A plant of the genus Carduus. MILKTOOTH, n. The fore tooth of a foal, which is cast within two or three years. MILK-TREFOIL, n. A plant, the cytisus. MILK-VETCH, n. A plant of the genus Astragalus. MILK-WORT, n. A plant of the genus Euphorbia; spurge. MILK-WEED, n. A plant, the Asclepias Syriaca. MILKWHITE, a. White as milk. MILKWOMAN, n. A woman that sells milk. MILKY, a. Made of milk.

Specifically note the commonality of milk dash thing when it refers to plants. Not that it's particularly relevant, aside from the actual commonly used definition of milk already provides an example of milk being commonly understood as milk. As an additional example, look to the definition of mentioning almond milk on page 2134. Specifically note that it says milk of almonds, and not just milk.

AMYGDALATE, a. [L. amygdalus, an almond.] Made of almonds. AMYGDALATE, n. An emulsion made of almonds; milk of almonds.

As you can see, I care way to much about milk.

To the letter of the word? Perhaps. To the spirit? Hmm.

Strange then that you reject critique elsewhere. Accessibility is not just a checkbox, it's to consider and test the actual use of it.

Or perhaps you shouldn't get defensive of critique on your "design vision" such that you just write them off entirely like it has no value? You might like driving in the opposite lane, but rules say otherwise, and best practice can be likened to it because it's been decided on or landed that way due to multiple people being involved in the process of deciding those rules. Just as with best practices. There are best practices in design too, you know.

Anyhow. Depending on the viewport your panels do get in the way, it's 1/3 of the screen on mine for example. If you're going to hide the panels, hide them properly. That you show them at the top and bottom automatically, fine, though they could be smaller on mobile. However, you could at least consider the UX of using it on smaller viewports. If I want to scroll up a little bit while reading, they pop into view, making me have to scroll down to hide them again. Meaning I have to scroll higher up than intended, so I have enough space to scroll down. Another common user pattern is to slowly continually scroll too, and a tiny jitter upwards causes them to reappear, but requires comparatively massive downwards scrolling to hide again. Your site is not the only one to do this, but it's just bad design. Vision or no, and it's no justification, just an excuse. And then, what about left handed people? It's easier to accidentally click into the message box field, which opens up the keyboard and you'll have to close it. Pair this with it taking up the majority of thumb space for scrolling, given its size, and, well. Is it unreasonable for people to tell you it's aggravating? No. And this is without considering, and doing the minimum for, people who may suffer with controlling devices for whatever reason. Not by "bending over backwards" as some would have it, but at least taking such into consideration.

It's fine to have a vision of your intended or wanted design, but it's also important to be willing to reflect on how your vision may not necessarily be good design, depending on how one judges it, rather than just deflecting critique.

First, these kinds of "issues" should be explained privately (as people normally do) and not publicly on Hacker News. For me, this already weakens your feedback considerably. Second, the article is designed to be read from top to bottom. Third, there are no hard and fast rules of good design. There's a spectrum of gray between black and white. Fourth, thanks for your feedback. Even though it might not seem like it, I made a note of it a couple of days ago to reflect on it. But your persistence is discouraging me.