I think I read somewhere that it just sends shift+super. So you may be able to bind it to whatever. At the same time its a dumb decision because now there's wasted space for a key combo you can easily press on a normal keyboard too

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.

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

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

Well you must have either set up a port redirect (ipv4) or opened the port for external traffic (ipv6) yourself. It is not reachable by default as home routers put a NAT between the internet and your devices, or in the case of ipv6 they block any requests. So (unless you have a very exotic and unsafe router) just uhhh don't 😅 To serve websites it is enough to open 443 for https, and possibly 80 for http if you want to serve an automatic redirect to https.

That's odd, I upgraded my ender 3 with bed leveling and removed the knobs to mount it fixed, because the damn knobs keep moving and then you have to redo the bed calibration. To be honest I can imagine one reason might be that a loosely mounted bed gives you more fault tolerance against the nozzle being too low. I put my bed on two parallel linear rollers for more rigidity, and combined with dual z screws the nozzle has no chance anymore to produce any sort of first layer when it is slightly too low. That made me realize just how much the stock ender 3 is flopping around, but also how this can give you mostly okayish results most of the time without having to deal with a ton of small tolerances.

Haha are you serious? In that case nothing short of full disk encryption and secure boot with your own keys is remotely adequate. Do you realize, that just encrypting your /home is at most a mild obscurity measure? If an attacker has potentially access to your computer and parts of it are unencrypted or unsigned, they could easily install a keylogger that sends out your data and/or password the next time you use your computer?!

If your situation is not just a psychological case of paranoia, but a real threat, then you absolutely need to work on your security knowledge a good amount!

What happens in the Windows world: Microsoft is not capable of creating and distributing a patch timely. Or they wait for "patch day", the made up nonsense reason to delay patches for nothing. Also since Windows has no sensible means of keeping software up to date, the user itself has to constantly update every single thing, with varying diligence. Hence Antivirus: there is so much time between a virus becoming known and actual patches landing on windows, that antivirus vendors can easily implement and distribute code that recognizes that virus in the meantime.

What happens in the linux world: a patch is delivered often in a matter of hours, usually even before news outlets get to report about the vulnerability.

Those 15-25c difference exist to drive the heat energy from the radiator into the air. If one would want to not waste as much energy for this, the actual solution would be to use a bigger radiator that can dissipate the same heat energy per h while being lower temperature. That would need way less additional material and be way more efficient than building another harvesting machine.

I think problems that turn up with time are also things like dependencies moving on, people with a slightly different setup which unfortunately breaks the thing or at least surfaces bugs, or that the author doesn't even use the software anymore because it was hardware specific and they have other hardware now etc... Yes they are not obliged to anything, that's what I think too. I was more thinking in the direction of taking some precautionary measure that makes the project stay more useful (and maybe more maintained) when the original author has long abandoned it.

The learning curve of NixOS is also what keeps me from trying it out, hence I prefer the "take it or leave it" mantra of the immutable fedoras, and try to keep the amount of packages I have rpm-ostree layer on top minimal.

As for Distrobox, yes there's ways it can fail, altough that happened rarely to me. What happens mostly is that the distro inside distrobox goes kaput because that's just what mutable distros beared with a plethora of questionable tooling installed with "curl something | bash" does. But for me that's the point of distrobox: separate all that shady cruft one may need for work/developing/etc from the host os. It's a place for messing about without messing up the computer and with it the bits that need to keep working