• 3 Posts
  • 151 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle


  • Hopefully rpm-ostree is just the beginning. When SuSE Mint, Zorin, etc have some form of ostree tooling, then it’s over for you bitches, and by it being over for you bitches, i mean the need to do a full system reinstall will be over because you bitches can just rebase.

    It truly will be the evolution of distro hopping, codifying a “of fuck, GO BACK” function by way of image handling, rather than barfing your operating system file system hierarchy on to your root partition like some caveman.

    The future… is OCI images and layering, like in containers, because cloud native containers is the way - for the desktop… no, seriously. Stop laughing.


  • The RISC-V is an extensible ISA, so yes. All those vendor extensions are optional, when fabricating the processor, which can be replaced by other extensions over time.

    Both Intel and AMD have had vendor extensions in the designs that they no longer use, even ones that have been “retracted” (i.e whatever in the heck Intel is doing with their AVX extensions).

    But yeah, currently, there are a lot of proprietary extensions, which could still be declared as open hardware as well. So yeah.




  • I’d say that there are some differences, but whereas Plasma 3 to Plasma 4 design-wise broke the mold, going from 4 to 5 was seemingly less of a major version milestone and more of a major version touch up.

    I’ve used both, a long time ago, and I might be off base here when comparing Plasma.4 with 5, but what’s also good about the transition from 5 to 6 is something called skeumorphism, i.e continuously developing a design language rather than making ground breaking changes. Plasma 6.1 hits a little higher mark, but considering all the UI work KDE has gone through the last year, it’s time to reap the rewards and hard work of the community.

    That being said, backend wise, a ton of new stuff has come and even gone. The last years there’s even been an attempt to rewrite a lot of old stuff into modern code, in preparation for Wayland support in somecases- which was a doozy. Wayland is not an easy protocol to implement - or so I’ve heard.

    We lost the cubic desktop, and got it back again, it’s been a wild ride. Kudos to the Plasma team for finally starting to catch up to GNOME in the UX department and that their efforts have been fruitful. I’ll be trying out Plasma 6.1 as my daily driver once it is released as stable.



  • There’s something so lovely about this desktop. I actually uses BeOS back in the day, and I say that to let you kids know to stay off my lawn… it’s where I keep my junk, my highly prized, valuable junk…

    Anyways, when it comes to DE designs, you just gotta love the minimalistic approach to widgets and buttons. It’s so bright and has a somewhat simplified yet classic style.

    But is saying that it’s based on BeOS a bit disingenuous? Didn’t they recreate a lot of it and rely on the Linux kernel? Been a while since I checked in.




  • Maybe I was being too glib. Let me expand upon what I was saying.

    Silverblue and its derivatives (or “Fedora Atomic”) are literally immutable and use an image system to mount read only systems. It uses rpm-ostree to write ostree images. Ostree is an operating system image format developed by the GNOME project (of all folks) and allows you to keep a git-like tree where system images become sort of branches and tags. It’s cool because theoretically you only need to replace files that are updated, even though rpm-ostree will build everything and create an image from the collection of RPMS in ostree.

    Archiso does not do this, and I don’t know how they implement system images or if it’s even a system image solution and not just a dedicated volume or subvolume, but if it was ostree based in some way, you could probably rebase from Silverblue to this distro, without having to bootstrap a new system.

    In effect, toolbox, distrobox, Flatpaks, etc wouldn’t be touched, but neither would the previous system. It would be the previous image and you could just reboot into it if you’d want. If you could rebase from an rpm-ostree system, OpenSuSE’s weird imaging system, if nix suddenly adds ostree support, or even Debian, then at that point you wouldn’t need to reinstall the system at all. Just do a rebase and bam: completely different stack and distribution, with one reboot.

    Right now I can, with some gumption, I can rebase from Silverblue to uBlue, but because of how uBlue signs its images and deals with that in its own way, they recommend starting fresh. I don’t like that idea, because they took an image based system and almost instantly distanced themselves from Fedora Atomic. But I also understand why they need to use cosign.

    I mean if you run btrfs where the root is a subvolume, you could just delete that and create a new root subvolume, maybe just nuke the EFI partition and boot partition, bootstrap the sucker (or install the distribution) and you can switch between distributions fairly easily. Did it earlier this year, no problem. Very cool.

    But I don’t want to do that, even though I easily can. I want to be able to rebase and not distrohop. We’re not quite there, but we’re getting closer, and I’m hoping ostree will become the new standard so that we can easily just flip a switch and be in a different OS stack than the one we initially installed. It would really make Linux seem like one operating system, and if people could easily switch, I think that might make it easier to retain users on the Linux desktop.

    Oh and by the way, you can use uBlue as a basis to create your own immutable Fedora Atomic-based system, that you can distribute if you want :)







  • I can’t for the life of me find anything on the web about “CentOS compose” or “CentOS stream compose”, other than relating to docker-compose, or even podman-compose, which doesn’t seem to be the case. I mean I can find the “compose folder”, with what seems like meta files for building images and package repos, but nothing regarding the actual building tools or the process - only that there is such a thing as a signed compose build, without any clear definition of what the system really is.

    I haven’t checked in with CentOS since they announced Stream, which was some time ago, because I run NixOS and nix environments on my systems, and even though nix is plagued with outdated documentation (which is being worked on - important note), even there we can still find basic definitions for nix, nixops, hydra, etc. There is no disambiguation.

    I’m not going to fire up a VM to do any testing, but if anyone could elucidate I would surely appreciate it :)



  • Oh you can promote your optimism for the future all you want, but I don’t respond well to optimism, and that’s because I’ve seen the light - or rather the darkness - of a market dependant upon venture capital in league with political elites, an unholy alliance forged in an attempt to try and recoup the losses for investments made in beanie babies. Oh sure, the cocaine, sex workers and ritualistic sacrifice are cool at first, as are membership points that come with it, which you can spend in the cabal gift shop for a sex slave to go, but I cannot in good conscience tolerate the terms of service because it requires citizenry in a supposed state.

    And it because of one thing. Do you know what that thing is?