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.

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

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?

“almost all of the most technical employees in framework are using either ubuntu, fedora or nixos. I’m mostly on Windows because we need actually people that are using Windows because our employee base in framework is all Linux users”

• Nirav Patel

https://m.youtube.com/watch?v=EIEc43CxIvY

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.

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.

This covers just the basic cpu instructions, no proprietary extensions, no architecture of additional necessities like a gpu, no proprietary firmare for the gpu or anything else. The instruction set of Arm, x86 or whatever is not a secret though. The freedoms in risc-v are mostly concerning the manufacturers, which can build chips using this instruction set without paying any royalties. From a consumer point of view, that at most means one can at most choose from a more organically grown landscape of risc-v chips. Which in turn bears the risk of ending up in a situation, where all we have is a vast jingle of cluttered proprietary extensions, that make it harder to write libre drivers for than it is for Arm today.

Don’t get me wrong, risc-v is absolutely amazing! But in terms of freedomness, it would take a manufacturer to extend the spirit of open hardware to the complete SOC - and the basic instruction set is pretty much the smallest piece in that.

Yes. But the more advanced LLMs get, the less it matters in my opinion. I mean of you have two boxes, one of which is actually intelligent and the other is “just” a very advanced parrot - it doesn’t matter, given they produce the same output. I’m sure that already LLMs can surpass some humans, at least at certain disciplines. In a couple years the difference of a parrot-box and something actually intelligent will only merely show at the very fringes of massively complicated tasks. And that is way beyond the capability threshold that allows to do nasty stuff with it, to shed a dystopian light on it.

Yes, if it was as object based as it claims, Get-WmiObject would subtract WmiObject from Get. Instead it is like having all the clutchy drawbacks from being object based without reaping any of the potential bemefits.

If you want anything that actually is object based, just use xon.sh - sane and familiar syntax with insane amounts of power just like that

Also lots of command line tools have a flag to output json, and then you can do everything powershell can

Because it’s the same story as with Mir or Upstart: it will die, because its half assed and tailored to Ubuntu, this time with dubious non-free parts even

There’s softmaker office, it’s from a german company: https://www.softmaker.com/en/products/softmaker-office

Have you taken care about the calendar in flatpak having access to the evolution data server in the distrobox?

You can install silverblue, and then rebase to ublue ( https://universal-blue.org/ ). Specifically to the “silverblue-nvidia” variant, and you should get a nice silverblue experience without any of the nvidia struggles, as people at the ublue project take care of that stuff for you.

And yes, distrobox is the goto solution to run stuff that is basically ubuntu-only, or by extension bound to any distro variant / version and not flatpak. This includes graphical applications. Distrobox works great, I do all my work in it.

Choose a font and size, then do screenshots of the same word on kde and gnome. Then open gimp, put each screenshot in a layer, align them and make it show the difference. Then you objectively know if and how they’re different

We recently moved away from Trello and settled on GitLab. Might sound a weird decision at first glance, but you can just create an empty repo, create issues instead of cards and visualize them in den “Boards” view.

Key drivers for doing so were that we rely heavily on GitLab already, and that we wanted a trustworthy solution in terms of data privacy. But I guess you’d have a bit of a hard time selling this to an audience that has no experience with GitLab, so decide for yourself if its viable in your case