That power efficiency is a direct result of the instructions. Namely smaller chips due to the reduced instructions set, in contrast to x86’s (legacy bearing) complex instruction set.

With something like this, how do you handle the period of time while copying? I mean you can’t really leave it running as it wouldn’t be in a consistent state. A “under maintenance” page instead? Copy to a fresh folder and when done tell the webserver to serve the new location?

If you have a working config, thats exactly the point. Before you built your config, you don’t know. If you deploy silverblue, you know it will work beforehand because exactly this config, including /etc, has been tested upstream before. What you are to your buddy, Fedora Atomic is to me. The difference is, it is not just one person that tested some config they decided on on their single piece of hardware, it is the effort of a full blown distro team.

No, just because it is reproducible doesn’t mean you are able to (re)produce something that works. With something like fedora silverblue you know that this specific composition of packages and their versions has been tested, and that all the other users run this exact composition as well.

When you roll your own composition, where you install whatever stuff, you may be the one finding out that there’s some conflict between package a version u.v.w and package b version x.y.z.

I encourage you to go to town with whatever crazy setup you come up.

I just want to note that the reboot-to-update mechanism also has its positive sides, as ancient as it may seem (we do not succumb to windows level backwardness, because that fails to reap the benefits despite requiring so many reboots). Namely, you get atomic updates, hence the name “fedora atomic” for example. That means you have no transient periods where your OS is running in an inconsistent state. Like when you update a traditional distro, the new files/libraries/binaries/kernel-modules do not match anymore what is in RAM, including the currently running kernel. That leads to stuff like the nvidia driver / cuda not working until reboot, running applications failing to load a library they need now etc… The vast majority of times this is no huge problem, but in theory the only way of maintaining a system with it never running in basically undefined state is with atomic udpates.

And the firmware inside that rp2040 is stored on plain old flash memory. So while the data may still be on the memory chip, the controller chip dies at just the same pace than every other usb drive - and then you can’t access it.

My Linux journey started when Ubuntu was in its single digit versions. I don’t remember the exact version I used first, but it was >15 years ago.

Of course I had a long distro hopping phase, that got finally ended by Arch. Because Arch breaks less, at least if you don’t molest it. Upgrades of versioned distros always had hickups or problems, and I grew tired of having to do a larger troubleshoot session once or twice a year. Arch has only very minor hiccups once in a while, and they’re typically always the same. 99% when the update doesn’t run through the keyring changed and you have to update it first, .9% is a bug with like a new release of the DE or something that gets fixed upstream in a couple days. And .1% is you have to look at the news because some manual intervention is required, like removing a package and going for something else or whatever. That is when you keep your system free of cruft and go with a popular DE.

Just 1.5 years ago I finally left Arch after a loong time. For something that is very new and different: fedora atomic (silverblue). Technology wise it is superior in my mind, and in my last years of using Arch I had most things in Flatpaks and containers anyways. But if you want a classical distro, Arch is definitely amongst the very well working ones.

The more packages you install rpm-ostree, the likelier your system will break. You effectively turn back to a traditional distro that relies on a package manager, so all the things that can go wrong with a package manager are bound to go wrong. The whole point of fedora atomic is to offload the OS composition (so all the complicated packages stuff) higher up the chain. So that not everyone mixes up their own combination of packages installed, but instead you get a (semi-) fixed combination of packages that has been tested to work already before it lands on your computer.

The uBlue images are just different package combinations - but still you’re not the only one rocking the packages combination of bazzite for example, so it is rather unlikely you’ll run into a problem that only you and nobody else has.

This to me is also what sets fedora atomic apart from Suse MicroOS for example. With MicroOS you still have a package manager messing about with the system, and once it makes a mistake that gets buried in your system forever, except if you notice, roll back and fix it. As where with fedora atomic the mechanism how your system layout comes to your computer is similar to how git works (ostree) or images (like docker, which is what ublue ships). So if there’s a mistake in how your system is layed out, the next time you rebase/update you are guaranteed to end up with a the intended system layout.

Hm well, I caried a Yoga l390 in a Backpack for 3.5 years and opened+closed it many times a day. That thing is now 5 years old. It’s not being used daily anymore, but still multiple times a week. And it still works perfectly in every regard. Only the hinges became a bit less stiff and the battery capacity went down a bit. But those are a given with that age and amount of charge cycles.

Since 1.5 years I have the pleasure to work fulltime with a fully specced x1 Yoga, that also has to go into the backpack every day. Of course that’s not very old, but it also has zero problems, only the silver paint at the corners started to wear off slowly from carrying it around.

The stylus that stows in the case is annoyingly small (and you need a seperate normal sized one for extended writing), but other than that it has all been very positive for me.

Take a look at the Lenovo Yoga models. There are very well built thinkpads out there that fold over and have a stylus + touchscreen

There’s also CadQuery, which I find more intuitive to use than openscand: https://cadquery.readthedocs.io/en/latest/intro.html

Well, doing none of the many chores to transform his pedo club into something socially acceptable, and instead killing his boredom by holding talks about a topic that has neither anything to do with church nor is he remotely qualified to say anything about, is on a whole other level of disrespect, isn’t it?

Research what happened to Upstart, Mir or Unity. It won’t take long until snap becomes one of them. Somebody at canonical seems to desperately obsess over having something unique, either as a way to justify canonicals existance or even in the hopes of making the next big thing. Over all these years they never learned that whatever they do exclusively will always fall short of any other joint efforts in the linux world, because they always lack the technical advances, ability/will to push it for a prolonged time and/or the non-proprietary-ness. So instead of collaborating like every serious linux vendor, they’re polluting their distro with half-assed, ever changing and unwanted experiments. They’re even hijacking apt commands to push their stupid snap stuff against the users intent. With the shengians they’re pulling Ubuntu cannot be relied on, and with that they’re sabotaging their own success and drive away any commercial customers that generate revenue.

This is the correct answer, every device you use a bitwarden-client regularly on automatically becomes a backup

Also I think nobody so far weighed the energy consumption of e.g. using copilot against the environmental footprint of a human doing the legwork manually

Specifically the shitty IPU6 situation is on Intel, and is invariant to any laptop manufacturers. I also have a Thinkpad X1 with that issue. So for that the situation that one manufacturer would support it properly (i.e. upstream) and others don’t can’t exist, as soon as anybody puts it upstream it works for everybody. Thankfully there’s some progress (search for libcamera) and in the not too distant future it should work ootb. For fingerprint readers it is a different story though, as there are many different ones, so that one is on Dell indeed

One possibility would be Huginn I guess https://github.com/huginn/huginn

You have this view because your hardware is from an era where fingerprint reader largely weren’t a thing and webcams were connected via internal usb. The issue is not that the Linux kernel drops anything (between you and op, you’re the one with the old hardware). The issue is, that fingerprint readers became a commodity without ever gaining universal driver support, and shengians like Intel pushing its stupid IPU6 webcam stuff without paving the way upstream beforehand

As far as I understand, in this case opaque binary test data was gradually added to the repository. Also the built binaries did not correspond 1:1 with the code in the repo due to some buildchain reasons. Stuff like this makes it difficult to spot deliberately placed bugs or backdors.

I think some measures can be:

• establish reproducible builds in CI/CD pipelines
• ban opaque data from the repository. I read some people expressing justification for this test-data being opaque, but that is nonsense. There’s no reason why you couldn’t compress+decompress a lengthy creative commons text, or for binary data encrypt that text with a public password, or use a sequence from a pseudo random number generator with a known seed, or a past compiled binary of this very software, or … or … or …
• establish technologies that make it hard to place integer overflows or deliberately miss array ends. That would make it a lot harder to plant a misbehavement in the code without it being so obvious that others note easily. Rust, Linters, Valgrind etc. would be useful things for that.

So I think from a technical perspective there are ways to at least give attackers a hard time when trying to place covert backdoors. The larger problem is likely who does the work, because scalability is just such a hard problem with open source. Ultimately I think we need to come together globally and bear this work with many shoulders. For example the “prossimo” project by the Internet Security Research Group (the organisation behind Let’s Encrypt) is working on bringing memory safety to critical projects: https://www.memorysafety.org/ I also sincerely hope the german Sovereign Tech Fund ( https://www.sovereigntechfund.de/ ) takes this incident as a new angle to the outstanding work they’re doing. And ultimately, we need many more such organisations and initiatives from both private companies as well as the public sector to protect the technology that runs our societies together.

Ah thank you, that wasn’t obvious to me from its website