I really like LXQt for VMs. It is lightweight and fast enough to provide a very snappy environment, even beating out something like XFCE. With LXQt I get the minimally viable desktop environment with a panel, notification handler, etc.
Though most recently I have been using XFCE specifically because its notification widget gives me more info in the preview.
Does musescore fit your needs? If you want a piano… you should probably get a midi input keyboard. If you don’t need 88 keys and real-time playing, you can deal with less octaves.
Ram is pretty much your limiting factor. I run the latest version of Debian on a machine from 2008 but it only has 1.8GB of ram so for a desktop it is a little sluggish.
If you want a for-real free device your bes bet is a RISC-V Single Board Computer. RISC-V is open architecture meaning no hardware level spyware built Into Intel’s chips.
Chris over at explaining computers managed to get kdenlive to render a video with one and some other cool stuff, you should check it out
Digital keyboards (at least contemporary ones) use embedded systems that require software. OP wants a piano/digital keyboard that uses open source software.
I don’t think it exists (I don’t know of any). The software for these systems is going to be highly coupled to the feature set of that digital piano and the benefit of modifying the software is low. So it’s unlikely someone has made a open source digital piano.
If it exists its either a very small project, a manufacturer has chosen to release their software as open source or an adaptation of keyboard/synthesizer software. Although many libraries for such software are likely open source.
Am I going off the deep end by considering Fedora Silverblue or Kinoite?
I started my Linux journey on Kinoite, which unfortunately had some issues at the time of installing; after which I rebased to Silverblue, I have since ‘mained’ Silverblue while experimenting with a couple of other distros through dual-boot or on spare devices. The first two weeks were really hard as I literally knew nothing about Linux. The fact that documentation is -generally speaking- lacking doesn’t help either. But if I was able to surpass that initial barrier, then I’m sure you can too.
But, motivation is important! Why do you even consider an ‘immutable’ distro?
I don’t really understand what new I would need to learn
You’d have to replace sudo dnf install *package-name* with flatpak install *package-name*. If, however, the package is not available as a flatpak, then -following Fedora’s initial guidelines- one should install it within a container through Toolbx(/Distrobox). After a container has been created (toolbox create *pick name for container*) and entered (toolbox enter *chosen name for container*), one simply behaves within the container as though how they would in a traditional distro. As a last resort -in case installing within a container is not possible, well supported or doesn’t work as intended- one can layer it (rpm-ostree install *package-name*).
Furthermore, /usr can’t be touched (at least not easily), except for /usr/local. And some features, like UKI, aren’t supported yet.
or really what benefits it would have.
Updates are atomic; it either happens or doesn’t, there’s no in-between state. Even a power outage or a random crash doesn’t change that. This ensures your system isn’t broken if something unfortunate befalls it.
Additionally, the system (for the most part) is reproducible; I can rebuild my system from scratch (barring configs; unless your dotfiles management is sublime) and it is exactly the same as the one that has been running since the inception of Silverblue. Cruft, state, bitrot etc can finally be left behind…, but we’re not their yet. There’s still some amount of these present in Silverblue’s current model. But we’re embracing OCIs and Silverblue’s primary contributors know what’s up over at NixOS and (hopefully) are working to make Silverblue ever so slightly more stateless. Even if a lot of work is still required, it’s infinitely better than the traditional model as it has gone from an uncountable amount of possible states to a countable amount. And the mathematicians under us know that such an improvement is infinitely times better. Another benefit of where we are currently with reproducibility would be that it allows us to combat bugs effectively.
Security benefits due to more parts of the system being read-only. This is however (somewhat) offset due to lack of the aforementioned UKI support. Hopefully, the well-defined nature of an image-based distro will eventually make more robust system-integrity checks possible.
Not necessarily exclusively granted through/by ‘immutability’, but system maintenance has been a joy. Most of the time, it just works anyways. But, if somehow something breaks, then I can easily rollback; either through the terminal if I was able to get inside. Or through the GRUB-menu if the ‘broken’ deployment doesn’t allow me to get inside. Furthermore, you can even pin a confirmed working deployment through sudo ostree admin pin *number* to select the deployment to keep around for longer. I recommend everyone to keep around their first deployment after installing Silverblue, if used wisely it’s one of the closest things to a factory reset we’ve got within the Linux space.
Arguably there’s a lot more to talk about, but these are probably the primary benefits.
If Fedora runs fine, I see no reason why openSUSE wouldn’t. Friends of mine use regular Manjaro with the same Framework. Just keep using openSUSE if that’s what you feel most comfortable with.
I used Silverblue for a bit but got very annoyed by its rpm-ostree command. I think it’s too complicated for a simple single user setup.
Why did you find the need to use the rpm-ostree command¿? Isn’t the purpose of immutability to use flatpaks and containers to get all your apps/software
Well for me it auto updates and stages in the background. There is config file /etc/rpm-ostreed.conf in which you can set the AutomaticUpdatePolicy to stage. Then it will automatically check for updates once a day(I think) and will download and stage it. The update is then applied when you shutdown or reboot
I had similar frustrations with a game. It’s very easy to make mistakes while you’re a beginner in editing such files (I don’t know if you are).
One advice is to make sure to keep the data the same length.
If that doesn’t help, observe the file’s structure a bit more. Maybe it uses a checksum somewhere for the data you want to edit, or it is just stored elsewhere and you were editing the wrong thing.
Make a save. Make the data to change (in the shortest time possible) and make a new save. Compare these for what have changed.
But also, what is your problem?
Does the value just don’t change, or the save becomes corrupted?
Do you obtain this file from the file system, or do you need to extract it from some kind of a container file, and then implant back the modified version?
SnowRunner’s asset files cannot be edited unless you unpack and repack them with winrar. Anything else (as far as I tried, windows tools at the time) and it won’t work.
If you wanna switch to Silverblue, i would highly recommend the universal blue images, they have a whole bunch of different DE version, specialized versions for example: bazzite for gaming, and they also have framework specific images for most of them.
with ublue i dont have to layer a single package over my basic image (silverblue-nvidia).
All the apps are installed as Flatpak, except the ones that dont have one run on Distroboxes (distrobox is included in ublue images and highly recommended over the default toolbox in silverblue)
For a home user with recent hardware in my opinion the system to beat is openSUSE Tumbleweed. It is a stable and rolling distribution, that is, it has the best of both worlds.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.