No idea how to do this properly, but it’s definitely possible. Maybe a USB to IDE adapter makes more sense than going through SATA as it can just expose the floppy drive as a USB stick.
But then again CD drives have been around for ages as well and work properly on linux, so do your research.
The steps will probably look like this:
Autodetect when a floppy is inserted
mount it (possibly combined with the first step)
automatically run a script after mounting
writing the script, which will read the contents of the drive and control your player (chatGPT should be able to do that for you with a bit of trial&error)
The floppy drive is seen automatically and still fully supported in Debian 12 x86_64. You might have to mount the diskette to actually read it, but you can do that in fstab to do it on boot or ondemand or mount it manually.
You should be able to get it to automount with autofs and unmount when it hasn’t been read for a certain amount of time. I would suggest mounting the disks read only so they don’t get corrupted it they are removed without unmounting them though.
Why over-complicated? I’m genuinely curious, as I think it sounds pretty cool that you can install apps from different package managers in containers, but export them to use them in your main environment.
Technically, only apt exists, as per Debian. The filesystem is ext4 but with two system partitions, so that you:
have one backup partition
can install updates to the unused partition for seemless and atomic updates
Be immutable whilst offering easy updates
It gets compared to NixOS because NixOS is also an immutable distribution and the package manager is equally as flexible as apx (even tho apx also allows you to use nix)
Multiple package managers outside of apt/dpkg from Debian get managed automatically using the apx tool, only if you wish to use it. Otherwise, for the desktop they promote the use of Flatpaks or AppImages.
Looks bad in comparison with Silverblue where I can pin many previous version. Thanks to OSTree, you can downgrade to any point in the history or even switch back to an older release.
The A/B Partition method and OSTree are both great, but have different strengths
VanillaOS described it in their FAQ once:
Vanilla OS uses an A/B structure (ABRoot), which transacts updates atomically between two root micro partitions. The benefits of this system are the guarantee that the system is altered only when the entire transaction is successful (concept of atomicity), furthermore, the double root partition structure allows you to roll back to the previous state, directly from your boot, you will always have a home to come back to.
This structure, unlike others, is compatible with already existing distributions and does not require a complex setup and allows easy re-initialization of the system without data loss.
The 40gb total are both already reserved, and a normal user isn’t supposed to modify it so it shouldn’t fill up.
For desktop apps, Vanilla will primarily stick to Flatpaks, so Firefox will also be a Flatpak.
VanillaOS already has a custom boot menu that can be used to switch slots in case an update went wrong, so that you can go back to your older, but working system.
The partitions are also not synced.
If you install something using abroot (e.g an update) it will only be installed to the unused slot. So if you run abroot --update or use the included updater, and you’re in Slot A, it’ll modify Slot B, and vice versa.
the reason for more than one elif is for different package managers like apt, yum and dnf, other than that it just skips it if the package is detected.
Afaik it uses cli to find the temperature. i couldnt set the temperature with nvidia-smi so i had to use nvidia-settings
Yes the loop is nice, but you know your packagemanager and that this package will not disappear randomly, so keep it out of this service script, its just an extra break point and wastes resources :D
The output here lets us know that systemd is running the service file and starting the script just fine. The echoed GPU temperature is making it to the journal, but the gpuTemp variable isn’t being updated (staying at 0) because of a problem executing nvidia-settings. Specifically, it wants a display: “The control display is undefined”.
Although if echo DISPLAY in your terminal gives you a different value, use that. There’s a possibility that that will just push one error further down the line, but it’s something to try.
Alternatively/additionally, you could try changing the User= line to your own username to see if it picks up the environment your manual executions work with.
As soon as I get home I’ll do it. Afaik if you try to run it normally without root access it spits out errors about not being able to set the fan speed because it uses nvidia-settings as a dependancy. Also failed to mention this is a Wayland script, not xorg
It seems that Debian-rock64.img is an armhf image (i.e 32 bits) and Debian-arm64.img is (obviously) an 64 bit image… so go for the latter if your board has 8 GiB ram and up and the former if 4 GiB ram and under.
Not sure what you mean. This issue only affects rips made after the hardware upgrade. Rips made prior (with the same DVD drive and from the same CDs) play perfectly fine. I doubt transferring the files to a different device changes anything.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.