I see what you're saying, but I suspect the top-down approach is not the cause of the usability issues with Anaconda. The problems are simply that it isn't always clear which buttons do what, which partitions are about to get zapped, and what the next action should be at any given point. It's not unusable, but it could be easier.
The Blivet GUI looks like it could fix many of these issues.
I agree with all these criticisms. The anaconda installer, particularly the partitioning interface, is not at all intuitive. The first time I installed Fedora alongside an existing OS I thought it was really likely something would get messed up.
Debian's installer is excellent, in my experience.
I looked at the code for pass recently, and thought it was a nice example of something where bash is absolutely adequate.
You point out (in discussing the design of pass):
> There is one slight drawback to all the simplicity, and that is an information disclosure inherent to the design: pass stores all folder and file names in clear text, so even if you fully trust GPG, you should probably not put this repo into a public place like Github, because this may expose your account names and other metadata.
What's not completely obvious from a cursory read is whether gopass improves upon that. Also, the multiple stores feature looks like it might be quite nice, but a lengthier example would be very helpful!
> Software is fundamentally broken. It's limited, never quite works the way we want it to, but it can't be changed, can't be combined and can't be trusted.
In general, this level of hyperbole puts me off. Besides anything else, this sentence is outright false, since much software can be changed, combined, and trusted. I know it's a manifesto, but still, this kind of rhetoric is unlikely to persuade people who don't already agree with you.
The issues you are discussing in this manifesto are not new, and many people have attempted to create tools to tackle those things before. Perhaps try to clarify why you think those tools fall short, in order to persuade people that zells is useful.
> Just as knowing why apples fall down and aeroplanes fly
up, the citizens of the 21st century need to know that
computers are not magical boxes but composed of dynamic
models.
In all honesty, I don't know why apples fall down and aeroplanes fly up. I just know that they do. No doubt that improving software literacy is a worthwhile goal, but I think the author hasn't made a strong case for it in the opening paragraphs.
This is slightly tangential since you specified a conspirator on the inside, but how easy is it to break a homegrown encryption algorithm if you don't have the source code? I assume there are tools (what are they?) that will break a simple caesar cipher if you have more than a sentence or so of plain text to work with. But if you strung together 2-3 broken algorithms and your attacker doesn't know which ones, is it still trivial to decrypt?
I don't think that proves anything at all. If you said to a free software advocate: 'Freedom is pointless because most of us don't exercise most of our freedoms' that would clearly be a nonsense argument. Enumerating open source projects and counting their contributors is barely more coherent than that.
> he's absolutely correct in all of his principles
I don't think principles are matters of fact. A set of principles may be consistent with each other, and/or you may agree with them, but that is not to say that one who holds them is correct.
Worth noting that a GPG signature is of limited (though not zero) use if the signing key doesn't have any signatures. In this respect, Debian contrasted favourably with Fedora the last time I looked.
I agree... given bash combined with a tiling window-manager, I've found very little use for a file manager. The only exception that comes to mind is when browsing a directory of photos, because in that case thumbnails are more informative than file names.
> standing people pack tighter than walking people, therefore all standing ends up with more throughput, at the expense of lower individual latency (for the would-be walkers)
If the would-be walkers derive much greater than average utility from a quick journey, isn't it likely that the all-standing regimen achieves higher average throughput at the expense of lower average utility?
Mathematics also has perfect information, but people find plenty of aesthetic appeal in that. (Though in many respects, competitive chess is not at all like mathematics. An uncooperative opponent and time constraints are important additions to the possibility of beautiful moves.)
The Blivet GUI looks like it could fix many of these issues.