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.
In my opinion; of all the sections in an Operating System's installation program the partitioner should be the least vague of all.
At every step of the partitioning/volume management process you should be able to quickly undo or back out of your selection. only when the user is happy with the structure or layout should any change be committed, likewise there should be no ambiguity in the functionality of any aspect of it's operation.
After all it is your data you may be potentially blowing away.
It's been a while since I last installed Debian, so I can't comment on the installation experience there though I can't recall running into any issues. It was a perfectly forgettable experience. The Ubuntu installer was also excellent, and the partitioning aspect was both clean and clear when creating a custom setup.
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!
I was just thinking the same thing and was wondering if I missed that? I have been working on a similar project for keeping bookmarks and haven't found (yet) an easy way to obfuscate directory and file names in a way that doesn't make the tree structure look like a mess but still makes it difficult for the majority of people to "crack".
> 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.
One of the most common challenges that I see engineers face is to effectively empathize with the user. When you know a lot about something, you just see it in a fundamentally different way. This makes it difficult to focus on making it easy for the user to do what they want, not what you think they should want.
When I drive my car, I just want to get from point A to point B while listening to a podcast. I don't care to know how they work. This doesn't make me enfeebled or ignorant, I would just rather commit my learning cycles elsewhere.
Computers need to be the same. Why would we be so foolish as to think that it's a wrongdoing that people are able to effectively use computers without having any clue about how they function?
Literacy isn't about forcing people to learn things, it's about ensuring that everyone has the baseline exposure to help them discover if they have an interest in a topic, and then the resources to explore that topic if they choose.
Remember, one of the key aspects of OO is hiding implementation details because they shouldn't matter. This fascination with exposing them and forcing them on end users is absurd.
We have to accept that some tasks and jobs are not for everyone and that's okay. That could be due to aptitude, skill gaps, education gaps, interest, or dozens of other things, some due to education system, some due to abilities of the individual.. and that's still okay.
The problem with computers (abstracting from accidental complexity) is, that they do what you tell them to do, not what you think you told them to do. You cannot somehow make an agreement or solve it, how it is solved with humans - by communicating. You must formulate your thought exactly.
And that's what most people have a problem with - except for some hard sciences, they never needed to formulate their thought that way.
> Literacy isn't about forcing people to learn things, it's about ensuring that everyone has the baseline exposure to help them discover if they have an interest in a topic, and then the resources to explore that topic if they choose.
That sounds hilariously naive. If we'd let people decide themselves what they want to learn the majority would still be in the sandbox making castles and playing with toys all day.
Its about exposure, not learning enough to be a professional.
For example, I learned some basic mathematics, physics, chemistry, biology, history, geography, etc in school. Until I got to university, what I learned wasn't enough to make me a mathematician, physicist, chemist etc. It did give me a baseline on which I could build and it gave me exposure. This exposure was forced on me, but what I did with it (a computer science degree and a programming career), was something that was left up to me to choose later.
I see computers/software the same way. Its common enough in day to day lives now that I think a baseline of computer literacy and some basic exposure should be required and afterwards the students can choose if they wish to explore more or not.
The exposure doesn't necessarily have to prep them for real work (I'm pretty sure dissecting a frog isn't going to prepare me for veterinary work...), just give them a taste of how things work.
And people have spent years learning how to check facebook.
The problem with this pitch is that it doesn't understand the distinction.
By a lot of people's standards, I am a scientist (just not a domain scientist). I spend my life understanding how things work and figuring out ways to further our understanding of those. It is great. If you ask me about how a computer works, I can talk for hours. Physical phenomena? Minutes. Biology? I can make a crude joke
As for a car? I vaguely understand the principles of a combustion engine, but I couldn't for the life of me make one. My understanding is "You get gas into the engine. You light it with a spark plug. It bursts into flames which moves a piston which moves a crank which moves a bunch of gears and eventually moves wheels". I don't know anything beyond that
Hell, another good example is in the realm of video games. Kerbal Space Program is awesome and does a great job of making people remember why they learned physics. But engines are a black box for the vast majority of us and you genuinely don't need to understand how the fuel gets to the thruster or what happens. It is just a black box where fuel goes in one end and fire comes out the other, with fire generating delta V.
And same here. Most people don't need to know WHY an apple falls. They just have to know that stuff will fall. Whereas the physicists and funky table makers DO have to understand why the apple falls and how it can be stopped.
I think the car analogy kind of falls apart at this point. Using a computer and writing programs for a computer are both interacting with software. Take spreadsheets, for example: is making a spreadsheet analogous to building a car or to driving one? What about drag-and-drop visual programming?
Maybe if you drive an automatic. It took me a long time to be comfortable enough with shifting gears, operating turn signals and what not to leave enough attention for the actual traffic around me.
True, I still can't do manual quite right and it certainly adds danger to my trips. But my point was that people put time into learning how to use their cars because they're killing machines, most computers aren't, but the ones that are usually require some sort of formal training and certification, just like cars.
In the (proximate) words of Alan Kay: "Giving people what they want is marketing, given them what they need is education." I'm more interested in the latter.
But I do very much agree that using a computer should not require any idea about how they function. But that's for using a computer like a tool. For me, computers are not mere tools but a medium. So what you wanna do is to express yourself with computers. And for that you need to know how to do it.
That's unfortunate since I put a lot of work in these paragraphs. I'd love to know what you think would make a better case for improving software literacy.
> 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.
Sorry that the style puts you off. I wanted to make a strong statement that people either strongly agree or disagree with or maybe find ridicoulous. But if it helps me finding peopoe who already agree with me I'd say mission accomplished. The rothers I'll try to persuade with the implementation of those ideas.
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?
People who can break it won't spend the time breaking your homegrown crypto, so you won't get proof it's broken. But it's still broken. If lots of money or lives of political dissidents are at stake, it will be broken.
To have really capable people work on breaking your crypto for free, you have to be an insider. You become an insider by breaking other people's crypto. You can publish a break in an insider's crypto even if you are unknown. After you publish a few such papers, you become an insider and can publish your own crypto other people will spend their time trying to break.
People can learn the state of the art and develop an alternative to the common (NIST) choices which are no worse, but also no better. Some of those are blessed as "national pride ciphers" (GOST, Camellia, SEED, etc.).
Ciphers aren't the place where security most often fails. The failures have to do with implementation. More commonly, they have to do with implementation of protocols and systems using the protocols.
We're specifically talking about the scenario where you have a "tiger team" (strcredzero's phrasing) trying to break it. I interpreted GP as asking just how hard a time the tiger team would have if they don't have source code.
I've seen a few fun articles about people breaking home grown encryption. The question is mostly about how motivated someone might be to find a problem.
Making a secure encryption algorithm requires a lot of presence of mind, and a lot of industry knowledge. If your threat model is incomplete, you lose. If you forgot one tiny thing at one tiny point in the algorithm, you lose.
If you don't have people checking your work, how do you know? If someone is determined to break your encryption, they are capable of spending a lot more time analyzing it than you spent building it. And they only need to find one mistake.
It's definitely better to use the tools that experts have spent lots of time, lots of breadth of knowledge, and lots of depth of knowledge inspecting.
how easy is it to break a homegrown encryption algorithm if you don't have the source code?
A better question to ask is, how easy is it to break the protocols and the software using the protocols? We have secure ciphers. Those aren't where the problems in computer and network security lie.
I fall of at even a proper Vigenère cipher, although I guess I could hack together a terribly inefficient python script to test all options and then print them line by line and start visually scanning for patterns :-/
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.
The Blivet GUI looks like it could fix many of these issues.