Hacker News Reader

You are using a very provocative form for pointing at a very interesting detail here - yes, these people are trying to fix things:

However, to work well for the typical computer user, we’ll be focusing on an easy-to-use system, with stable, reproducable system installs and atomic upgrades. This will most likely be done using OSTree [1], which is like Git for operating systems.

[1] https://wiki.gnome.org/action/show/Projects/OSTree

Have fun on sundays!

I was always under the impression that having to read the update logs and configure things manually was the entire point of Archlinux. At least that was the reason I used it for years.

If you want a system that automatically configures stable updates you should go for Ubuntu. That's what I do now since I deem my knowledge of linux sufficient and just want to get things done.

As I got it, parent comment wasn't about having stable (tested) packages, but automated measures to recover one's ass when a bug slips through (or when you just want to risk or whatever) and update leaves you with unuseably broken system.

This sort of situation has happened to me on various distros, and Ubuntu wasn't an exception.

"Archlinux is a very good distro, but I do not understand why they are forcing users to read update instructions"

Then I would say that you also don't understand the point of Arch Linux.

Are you german?

How do you tell?

I am just asking...

Maybe because those updates might break some other custom packages or custom configurations that you might have?

Maybe because the result might be a bit unpredictable and it's better to be safe than sorry?

Computers by nature were never easy to use. And still they are not. And it's a good thing that they are not.

Technical blog writers write long articles so that people can understand what's happening and so that people can work their way around an unexpected problem.

If you can't understand these points, you are better off using Windows or Ubuntu and calling some technical line for help from more experienced people.

I think you don't understand his point.

There are loads of technologies that already automate safety and allow to be safe than sorry in a way that don't upset users. When something goes wrong, you can postpone the update and continue using your machine.

Yet, when you check on mainstream distros, there are no traces of such tools to be seen. Every update is "pray for it, so you won't have to waste a few hours fixing problems to have system boot again (oh, and PM doesn't officially support downgrades)". All the necessary primitives do exist, but you _still_ have to built your own, every time.

I agree with everything else that you say, except for the minor point about C: we're still using C for the same reason we're still using hammer despite all of our advancement in machinery.

Yes, some of us might be overdoing stuffs with the hammer, some might not know any better. But the hammer is here to stay.

(this comment has nothing to do with this distro, just the general state of software installation and the transmission of such instructions on the internet.)

I'm not sure anybody else gets you, but I'm totally with changing the copy-paste way of transmitting instructions. And I don't mean a gui and a whole lot of clicking.

System Requirements (hw/sw, pre-reqs) / applicability tests (will this work for me?), tailoring instructions to my configuration(s) (automatically), recommended and trusted instructions (using PKI) with data and statistics to back up the confidence I should have, time estimates and ENV-impact statement, testing and follow up discussion, and transactional rollback of any step to previous state of the system.

See instructions. Install instructions. Should be easy as a click. Something breaks, undo should be just as easy.

Copy and pasting instructions is like typing in BASIC from magazine listings decades ago. "Clipboard is the new fax machine"

At the other extreme are "apps" which are nice when they don't break, but opaque and not developer-friendly.

Willing to discuss elsewhere or learning about existing efforts which try to address these problems.

> Is there some "evolution retardant" in our substances that forces us to not adopt new things too fast, as they might be wrong?

I simply can't wrap my head around how this question is being asked in a post that argues in favor of relying on predefined automated processes to maximize efficiency and safety. The "devops revolution" is the "evolution retardant" you're talking about: the engine of evolution is adaptability and incremental innovation. The Arch philosophy optimizes for adaptability over efficiency: by giving users who are so inclined the tools necessary to understand and interact with the inherent complexity of the system, rather than rely on opaque processes hidden beneath simplistic frontends, it enables users to more effectively adapt their tools to their own needs, solve problems by understanding what's actually causing them, develop new techniques that better serve their purposes, and discover new purposes that their existing tools and systems can serve. Approaches which seek to maximize the efficiency of existing tools and processes are necessarily less adaptable to change, and reliance on them stagnates evolutionary progress.

If you're looking at documentation filled with console commands as an analogue of "click here to install the system" automated tools, then you're missing the point: that list of commands isn't there for you to blindly copy and paste into your shell. It's there for you to read and understand, so you can learn how the system and the tools that manage it work, so you can ultimately use them in the way that best serves your own purposes.

> sent to you with a monthly magazin that contains lots of manual input instructions for your modern device (and a lot of comics)?

I'd love it. I absolutely hate the feeling of constraint and limitation I have on e.g. modern mobile devices. I ended up switching from iOS to Android precisely because of the increasingly common frustration that I felt when I knew exactly what I wanted to do with my phone, but couldn't, because Apple didn't expose the functionality that was clearly there for me to control and direct in the way I wanted to. I was artificially locked into someone else's way of doing things, and any particular use case that they didn't think of in advance was something that was just blocked off to me; and the best I could do was petition that someone else to modify my tools to fit my purposes.

I'd absolutely love a phone OS that made it as easy to understand and control the functionality of the phone as Arch makes it easy to understand and control the desktop, and I'd gladly read a regular publication that was consistently full of information that improved my understanding of how it all works.

It's becoming increasingly apparent that there are two distinct cultures of technology: one that seeks to use technology to extend and improve human capabilities, and one that seeks to use technology to replace human capabilities. Arch is for the former, and sealed black boxes that "just work" are for the latter.