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.
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.
You do not want Octoprint on a machine that is busy. Otherwise you have load spikes that cause Octoprint to not be able to send the move-commands (gcode) as fast as the printer executes the movements. This problem is pronounced with faster printers and slicers that break up arcs into small straight lines (which is practically all slicers). Otherwise your printer stutters because it has to take small breaks to wait for the next command from octoprint.
What privacy concerns do you have? I’m all for privacy, but I don’t really see where registrars are a delicate topic in that. The most that comes to mind is that some (most?) have a service where they do not give out your name and address for whois requests, but instead the details of the registrar (namecheap has that for example).
True words. The sustained effort to keep something in decent shape over years is not to be underestimated. Now when life changes and one is not able or willing anymore to invest that amount of time, ill-timed issues can become quite the burden. At one point I decided to cut down on that by doing a better founded setup, that does backup with easy rollback automatically, and updates semi-automatically. I rely on my server(s), and all from having this idea to having it decently implemented took me a number of months. Just because time for such activities is limited, and getting a complex and intertwined system like this reliably and fault tolerant automated and monitored is simply something else than spinning up a one off service
And they believe all employees actually remember so many wildly different and long passwords, and change them regularly to wildly different ones? All this leads to is a single password that barely makes it over the minimum requirements, and a suffix for the stage (like 1 for boot, 2 for bitlocker etc), and then another suffix for the month they changed it. All of that then on sticky notes on the screen.
Since you run everything in docker, I guess you have experienced the benefits of containerization. So why not leverage that for your host too?
Fedora IoT is a container-based host that runs on your hardware, with a focus on edge device deployment.
https://fedoraproject.org/iot/ I have it running on two servers as well, and it works great. The only thing I changed is that I layered docker on it instead of using podman, because at the time I had trouble getting my reverse proxy working properly over ipv6
Not to me. Absence of QA allows faulty parts to make it into a plane, it does not explain why there are faults in the first place. For doors and wheels popping off there have to be either lethal part design mistakes, parts made from play doh instead of aluminium/steel, or the people on the assembly line throwing fasteners in the bin instead of putting them on. It’s not like a door pops of because its seal touched soap once and somebody poked an unverified piece of plastic at it. Especially in aviation, where you need to have redundancies.
How does this part (which is what the headline refers to and presumably the most outrageous inspection finding)
At one point during the examination, the air-safety agency observed mechanics at Spirit using a hotel key card to check a door seal […]. In another instance, the F.A.A. saw Spirit mechanics apply liquid Dawn soap to a door seal “as lubricant in the fit-up process,” according to the document. The door seal was then cleaned with a wet cheesecloth
have anything to do with the opening of the article
Just last week, a wheel came loose and smashed through a car, and earlier this year the door from a 737 Max aircraft broke off mid-flight
???
The article misses the whole point, which is that the audit did not uncover the sources of these incidents.
Those are symptoms of sitting at that operation point permanently, and they are a of course a concern. What I’m after is that people think that energy gets put in to the battery, i.e. it gets charged, as long as a “charger” is connected to the device (hence terms like “overcharged”). But that is not true, because what is commonly referred to as “charger” is no charger. It is just a power supply and has literally zero say in if, how and when the battery gets charged. It only gets charged if the charge controller in the device decides to do that now, and if the protection circuit allows it. And that is designed to only happen if the battery is not full. When it is full, nothing more happens, no currents flow in+out of the battery anymore. There’s no damage due to being charged all the time, because no device keeps on pumping energy into the cell if it is full.
There is however damage from sitting (!) at 100% charge with medium to high heat. That happens indipendently from a power supply being connected to the device or not. You can just as well damage your cells by charging them to 100% and storing them in a warm place while topping them of once in a while. This is why you want to have them at lower room temperature and at ~60%, no matter if a device/“charger” is connected or not.
(Of course keeping a battery at 60% all the time defeats the purpose of the battery. So just try to keep it cool, charged to >20% and <80% most of the time, and you’re fine)
“overcharging” doesn’t exist. There are two circuits preventing the battery from being charged beyond 100%: the usual battery controller, and normally another protection circuit in the battery cell. Sitting at 100% and being warm all the time is enough for a significant hit on the cell’s longetivity though. An easy measure that is possible on many laptops (like thinkpads) is to set a threshold where to stop charging at. Ideal for longetivity is around 60%. Also ensure good cooling.
Sorry for being pedantic, but as an electricial engineer it annoys me that there’s more wrong information about li-po/-ion batteries, chargers and even usb wall warts and usb power delivery than there’s correct information.
It is not that easy to understand what you want, to me it reads like you want something like Nextcloud - i.e. your own little cloud, where you can put all your stuff, and view it through the webbrowser or the nextcloud apps, and also keep selected parts of your stuff in sync with your devices (or automatically upload photos take with your smartphone for example).
Backup of Nextcloud (or whatever you want to use) is a seperate topic. Any incremental backup tool would apply though, so there’s much to choose from. I personally use btrbk which uses Btrfs Send+Receive to push incremental snapshots to an offsite server.
Partly yes, but just installing a package without running into conflicts does not yet guarantee a working system. You have to cater for the right configurations too, for example when you think about a corporate setting with all kinds of networking whoes (like shares, vpns and such). I think you could get this to work with Nix somehow, but you want to test these things beforehand, and if you do so using images then you have the thing to ship to machines in your hands already, there’s no need to compose the OS and configurations over and over again for every machine.
Another aspect with non-atomic OS composition on the target is that you have to deal with the transient phase from one state to the next. In this phase all kinds of things could happen, for example an update of nvidia drivers would render cuda disfunctional until the next reboot, as the userspace and kernelspace parts do not fit together anymore. With something like any of the fedora atomic variants, transient phases with basically undefined behaviour do not exist, and the time the system is not guaranteed to be in working order gets reduced to just the reboot.
Nix is cool and definetely better than any traditional package manager. But it is not an ultimate solution, to be honest so far it seems to me like it is living in a nieche of enthusiasts that are smart enough to put up with its unique declaration language. And below that niche you have ordinary linux users that may just be happy with silverblue without any modifications, and above that niche you have corporate doing their own images in CI/CD, CoreOS and all that jazz.
that doesn’t require I keep a full local copy of all the data
If you don’t do that, the place that you call “backup” is the only place where it is stored - that is not a Backup. A backup is an additional place where it is stored, for the case when your primary storage gets destroyed.
/dev/fb is mostly one thing: deprecated. Also it is not really a interface of your graphics card, it is a legacy way kindly still provided for pushing fullscreen pixels to your monitor in an unaccelerated fashion for things that have not made it to kms drm (which at this point is pretty much merely the console emulation on the TTYs). It is not an interface to the graphics card, because it doesn’t provide any capabilities a graphics card has (like shaders etc). In fact for just pushing pixels you can leave any graphics card completely out of your computer if you connect your screen by other means (think stuff like SPI which is common in embedded devices; you can find many examples of such drivers in the kernel source at drivers/gpu/drm/tiny ).
Well maybe you youself are too new to recognize some of the appeals ;)
One large advantage with silverblue is, that the whole composition of the OS does not take place on the target machine. That means that all the issues that could arise will not take place on the target machine, and can be dealt with beforehand. In the simple case this could mean just enjoying vanilla silverblue without having to think about possibly borking the machine. In an advanced usecase this could mean for example building the os images in a GitLab CI/CD pipeline (with well working tooling that exists already for docker etc), then having automatic tests in the pipeline ensure that everything important works as expected. And only if the tests pass, the image will be added to the repositorie’s image registry, where the target machines will fetch it from automatically and rebase to it.
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.