[HN Gopher] OpenSUSE Kalpa
___________________________________________________________________
OpenSUSE Kalpa
Author : ogogmad
Score : 145 points
Date : 2026-03-17 13:54 UTC (9 hours ago)
(HTM) web link (kalpadesktop.org)
(TXT) w3m dump (kalpadesktop.org)
| dizhn wrote:
| Interesting they are hosting on codeberg. Opensuse has a pretty
| established hosting/build architecture provided by Suse.
| Zambyte wrote:
| I was going to guess that it may be easier to get new
| contributors on a general site like Codeberg, but it seems like
| they're just using Codeberg pages to host the actual website,
| not using it for the bug tracker or anything like that.
| Interesting choice indeed.
| iberator wrote:
| Codeberg is AMAZING. fast and super simpler. KISS
|
| Just works
| quantummagic wrote:
| This web page doesn't do a good job of motivating the reader.
|
| I understand what the Plasma Desktop Environment is. But what is
| "atomic and transactional Linux"? What are the advantages to the
| alternatives? What other projects are similar? What is the
| motivation for this project in particular? Most importantly, why
| should I want to use it?
| mhitza wrote:
| Yes, all projects in this sphere should communicate better.
|
| An atomic distro is one in which the updates are swapped
| atomically at reboots. They also go by the name of immutable
| distros. Only the "system" partition is immutable.
|
| Most popular I would say is SteamOS followed by the Fedora
| variants (Silverblue, Kinoite) and derivatives (Bazzite).
|
| They are still limiting in daily use, rough around some edges.
| theragra wrote:
| Yeah. I use bazzite, but had to overlay like 5 apps. Flatpaks
| are often disappointing or just do not exist. AppImage is
| awesome, too bad it is used rarely.
| stryan wrote:
| > what is "atomic and transactional Linux"?
|
| Linux distros that are updated with full system snapshots
| instead of package by package, similar to Android. The key
| difference is most of / is mounted read-only[0] and is only
| changed by distribution provided updates so you and the distro
| team always know exactly what's running.
|
| > What are the advantages to the alternatives?
|
| Greater control and stability since its essentially always
| running in a supported configuration. Easy roll-backs to a
| previous update if something goes wrong. You always know
| exactly what your system is running if you want to keep it in
| sync across machines (more useful in a server setting).
|
| > What other projects are similar
|
| Kalpa is a "sibling" project to AeonOS, which is atomic
| OpenSUSE but with Gnome (and other changes, which I'll get to).
| There's also the Fedora Atomic line of Fedora Kinoite and
| Silverblue (KDE and Gnome respectively), U-Blue, Bazzite,
| SteamOS, and more. I think most major distro lines have an
| Atomic variant at this point.
|
| > What is the motivation for this project in particular?
|
| For Kalpa specifically, it's to offer a KDE alternative to
| AeonOS. Originally there was just AeonOS, which was OpenSUSE
| MicroOS (an atomic version of OpenSUSE Tumbleweed) with GNOME
| installed. Aeon has diverged greatly from MicroOS though and I
| think it no longer uses it as an upstream. AeonOS also refused
| to support KDE[1], so Kalpa was created. Kalpa still uses
| MicroOS as its upstream and I'm not sure if there's any plans
| to change that.
|
| > Most importantly, why should I want to use it?
|
| I use it on my personal laptop because it lets me have all the
| benefits of a rolling distro (up to date packages) without the
| stability concerns. Updates apply automatically in the
| background and I know when I reboot I'll always have a working
| system available to me.
|
| [0] /etc is mounted as an overlay FS so you can still make
| changes to it. /var, /usr/local, and /srv are also still user-
| writable. I think /mnt is too but I forget off hand.
|
| [1] Aeon is generally anti-customization and does its best to
| only offer one way of doing things. This is to prevent
| configuration drift and reduce the maintenance burden per
| snapshot. GNOME also has a more regular release cadence, which
| makes it much easier to integrate than KDE (or so I've been
| told..)
| MrBuddyCasino wrote:
| Is there a relationship with concepts such as NixOS?
| jamesgeck0 wrote:
| It's closer to the "sealed system volume" model that macOS
| uses. The core OS filesystem isn't (normally) writable,
| although you can finagle it to add drivers and such.
| lejalv wrote:
| Would the A/B filesystem approach a la Android be a good way
| to distribute Linux with ZFS-on-root without all the angst
| from DKMS modules versioning?
|
| [Maybe unrelated, but just occurred to me (some horror
| stories have prevented me from trying ZFS-on-boot in linux
| after Ubuntu botched it with their Zsys "adventure").]
| ninth_ant wrote:
| If i understand the intention of a zfs root combined with
| an a/b approach -- it feels like this btrfs root and
| immutable gives you the same benefits but with better
| mainline support.
| pmontra wrote:
| It's buried in the About page, but it uses different
| terminology. They definitely have to review their copy.
|
| > Automatic Updates: Updates never touch your running system,
| only taking effect on reboot.
|
| > Resilient: Due to the atomic nature of updates, if something
| goes wrong, the system will automatically roll back to the last
| known good working state
| mardifoufs wrote:
| Wait I thought being able to update without rebooting was a
| good thing? It was a relatively common argument against
| windows
| tosti wrote:
| Wait until Linux can run itself from the top while keeping
| your work intact.
|
| See https://lwn.net/Articles/1033364/
| tmottabr wrote:
| That depend on your needs.. linux can do live update if you
| need that, usefull on servers..
|
| But atomic versions as more target to desktops or
| containers where you need to have know working setup and
| when you upgrade you replace it by newer one..
|
| So you dont update per se... You install the new version in
| a separated partition and boot into it the next time you
| restart.. Same with containers, you just destroy it and
| recreate with the new version..
|
| If the new version fail you boot back to the old original
| version that is know to be working and have not being
| replaced..
|
| The ideia is to ensure a known to be working system is
| always available..
| ziml77 wrote:
| It's never been a great argument. Even non-atomic Linux
| distros have you reboot after updates. It's just the safest
| way to ensure that everything is running with the updated
| packages. You're kind of in an untested state if you have
| mixed versions of applications and their dependencies
| running.
|
| Plus, updates aren't the only thing that require reboots.
| Various config changes will need a reboot or at least
| require you to log out and back in. Even just adding your
| user to a group needs you to end your session for the
| change to apply.
| mixmastamyk wrote:
| User group can be updated within a terminal when needed.
| zozbot234 wrote:
| >But what is "atomic and transactional Linux"?
|
| It's a glorified Live CD, with added "persistence" for user
| data. Updates are done by replacing the system install (which
| is readonly during normal operation, just like a Live CD) and
| rebooting, with an A+B mechanism enabling seamless updates
| during operation, as well as rollback if the new install fails.
| It's the modern "cattle not pets" approach to system
| administration: every system is running a well-defined
| ("atomic") Live CD equivalent, not something bespoke that's the
| unpredictable result of partial updates and/or edits on the
| running system.
| finaard wrote:
| No, updates are done by creating a snapshot of the read only
| mounted root, and applying the packages via the usual package
| manager in there. The snapshot only becomes active at reboot,
| and if starting fails it'll revert automatically back to the
| last known working snapshot for the next boot.
|
| Things like /etc are writeable, so you don't need to reboot
| for simple configuration changes.
|
| You can run it just like always with all packages installed -
| it's just not recommended as the additional complexity on
| updates increases the risk that manual intervention is
| needed, and tooling is good enough that for a lot of stuff
| you don't really need it there. Like, toolbox or distrobox as
| podman based containers running in the host namespace (either
| as user or root), allowing persistent installation of debug
| tools, without having to reboot.
| tommica wrote:
| Really well explained - I use fedora kinoite, and have had
| hard time grasping how the immutability exactly works when
| compared to traditional setup.
|
| I would add to this that homebrew is a nice tool for being
| able to install software that are not in flatpaks and if
| you do not want to add too many layers to the "os-tree".
|
| The fact that home is shared between all the distro- and
| toolboxes is a bit annoying, because I would like to have
| stronger isolation from the host in some projects.
|
| Also doing basic polyglot stuff is a bit messy, if you have
| toolboxes like "node" and "php". But if you have project
| based boxes, then you end up with billion copies of node.
|
| But what a pleasure it is to just update the base image and
| have things work, or rollback if something fails. Hell, you
| can even rebase the base image to some other setup, and
| most likely have your system work.
| yangikan wrote:
| Is there a linux distribution that comes with mac keybindings
| and make it easy for someone with muscle memory to use both?
| PufPufPuf wrote:
| There's https://kinto.sh/ you can install on any distro. For
| visual similarity, GNOME is already quite Mac-ish, but there
| are distros like elementaryOS that go further by e.g. moving
| window controls to the left side.
| coderedart wrote:
| I daily drive kalpa and also installed it on my family
| computer. I landed on kalpa after a long time researching, so,
| let me dump an overview of this new distro tech.
|
| # Terminology
|
| 1. Immutable: The core OS (/usr directory) is kept in
| "pristine" condition by disallowing modifications.
| - Discourage installing packages or removing packages.
| - well-tested (as most users are running the same OS with same
| package version) - System upgrades are an entirely
| new immutable copy
|
| 2. Atomic/Transactional: Similar to atomicity in databases,
| where a bunch of operations are bundled into a transaction
| (atomic =indivisible unit), and it either succeeds completely
| or it fails completely. Just like that, a system upgrade
| succeeds or it doesn't. There's no partial package updates.
|
| NOTE: kalpa in particular, uses suse-microos tech called
| Transactional-Update
| https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha...
|
| # Atomic styles
|
| 4 mainstream models of immutable distros:
|
| 1. declarative-config: ALL your system configuration in a
| config file eg: package versions, network config, user accounts
| and so on. eg: NixOS, BlendOS
|
| 2. OSTree-based: You use cloud/container (OCI) technology (eg:
| docker files) to layer upon existing layers (eg: pre-baked
| system images). eg: fedora's atomic spins, vanillaOS,
| endlessOS. So, fedora coreOS is the base layer -> atomic spins
| like silverblue/kinoite layer desktop packages like gnome/kde
| etc.. -> the infamous gaming distro "bazzite" layers gaming
| packages like wine/steam/drivers etc. and so on.
|
| 3. Btrfs-snapshot-based: You take a btrfs snapshot of your root
| partition before upgrading, so that you can boot into it if the
| upgrade fails. eg: suse-microos family (kalpa belongs here),
| chimeraOS
|
| 4. systemd-mkosi based: You essentially "curate" an entire OS
| filesystem in a directory using mkosi and deploy it as an
| immutable disk image. eg: kdelinux
|
| NOTE: systemd-mkosi is the vision of systemd maintainers as
| mentioned here: https://0pointer.net/blog/fitting-everything-
| together.html . There's a whole bunch of system features in
| development to achieve this ideal.
|
| Most of these distros (except btrfs-based) simply use the A/B
| root system. They just maintain two root partitions/images, put
| any upgrade into the "other" partition, mark that as live and
| the current partition as backup. If the boot into the new
| partition fails, they just boot into the backup partition and
| just wait for next upgrade.
|
| As they don't allow usage of system package manager, you are
| supposed do package management at _user_ level. For gui apps,
| you resort to flatpak. For other utilities, you usually pick
| homebrew or language-specific tools like cargo, pip /npm etc..
|
| # The magical tool called Distrobox
|
| This runs containers in userspace and tries to integrate them
| into your system as much as possible.
|
| A lot of software development requires system level services or
| shell access or install dependencies etc.. You obviously can't
| do that on host, as system package management is essentially
| forbidden and half the point of immutable distros is to keep
| the host "clean".
|
| So, you create a container and do all your development in
| there. If it gets too dirty, you just delete it and create a
| new one.
|
| Personally, I use an arch container for development, as it has
| all the bleeding edge packages and the convenient AUR too.
| vscode (from flatpak) supports connecting to containers using
| official remote extension. I also run a media server inside it.
| You can also install any system packages or cmdline utilities
| you want inside it (eg: codecs, ollama, etc..).
|
| # Why kalpa over others?
|
| - Great KDE polish that suse is known for
|
| - btrfs tech is mature and was already used in suse for years,
| the atomic system is very simple to understand and you can just
| pick the snapshot you want at boot menu.
|
| - Despite being immutable, customizing the system (eg:
| installing a driver, kernel modules, firewalls etc. ) is easy
| too. - just enter a transactional update shell
| - this creates a new mutable snapshot of the current system and
| chroots into it - run all the commands you want
| inside the shell. eg: install/remove packages, enable services
| etc. - exit shell. This will mark the transaction as
| success/complete and set the snapshot as live for next boot.
|
| - Minimal by default.
|
| - Updates are fast/tiny, as they are just routine rolling
| release updates from tumbleweed repos.
|
| There are some problems too:
|
| - single maintainer
|
| - less popular, compared to alternatives like fedora-based
| atomic spins.
|
| - It's based on tumbleweed, so, you get _lots_ of tiny updates
| (almost daily). Fedora based, for example, have weekly /bi-
| weekly updates.
|
| - still in alpha stage (but once you set it up, it's rock
| solid).
|
| - Immutability is still a new concept, and flatpaks are rough
| around the edges. Expect bugs. Mutable/traditional distros are
| still easier to use, as that has been "the way" forever.
| stryan wrote:
| Kalpa is great and hits way above its alpha status; I've been
| running it on my laptop for months now with zero issues. It's
| been really nice to not have to worry about updates, just gotta
| reboot it every now and then and most things just work.
| wasting_time wrote:
| Which things do not "just work"?
| spacemule wrote:
| I can't think of anything that doesn't just work in that it's
| broken in some way. There are things that are different. I've
| been using MicroOS with Plasma for at least 4 years now on my
| personal machine and my work laptop. At some point they
| changed the name to Kalpa. There were some times in there
| where things were broken and it needed to roll back and pause
| automatic updates for a few days, but otherwise it functions
| just as expected.
|
| A couple of annoyances exist. For example IDEs want to use
| the system's shell, so you have to make a custom entry to use
| your distrobox. Tools like python, node, tofu, etc are
| installed in a distrobox and then exported with `distrobox-
| export -b $(which $BINARY)` so that you can call them from
| the IDE.
|
| For me, it's worth those few rough edges. When I install an
| OS for non-technical people who just need a web browser, I
| install Kalpa. It looks close enough to Windows to be easy to
| use, and it's never broken in a way I can't explain over the
| phone or a text how to fix.
|
| It even passed the wife test in our house. It took a few
| years of marriage to convince her that her laptop shouldn't
| take 30 minutes to boot and open Chrome. She let me switch
| her over to Kalpa (it may have still been called MicroOS
| Desktop then) a few years back. That old laptop is still
| kicking and fast enough for her needs. Had she stuck with
| Windows, it'd be a brick now because of the requirements for
| upgrading to W10 and 11.
| giancarlostoro wrote:
| I wanted to try an Atomic Linux, I think I tried the Fedora
| flavor, nothing really worked for me for some reason, I gave in
| to Arch and tried it a la EndeavourOS. Have not looked back
| since.
| ogogmad wrote:
| You might know this, but unfortunately, if you leave an Arch
| install unused for enough time, and then run an update, you
| might not be able to boot into a working desktop.
|
| [EDIT]
|
| Oh, and I had a lot of problems installing Kalpa (from the
| submission) - all which I got fixed by using ChatGPT.
| giancarlostoro wrote:
| I've left it for a long time and also run it daily sometimes,
| still no issues. My understanding is brick level changes
| usually are fixed quickly.
| fhn wrote:
| brick level changes will render the device unusable. You
| dismiss it like it was no big deal to brick a device.
| giancarlostoro wrote:
| Eh I misspoke, I don't think you can actually brick
| anything with this, its just it might not boot properly,
| you can still format over it, or fix it if you run a LIVE
| Linux disk to rollback. You also always have an option to
| run previous system configuration.
|
| The more I think about it, I don't even use Pacman, I
| just use the other tool that comes with Endeavuor, which
| is a face to Pacman and probably shields me from doing
| doofus things. Pacman is easy to screw up an update with.
| 0134340 wrote:
| EOSupdate is basically just a yay and pacman script, as I
| understand it.
| ogogmad wrote:
| How long is a long time? I left mine for 2 years.
| ziml77 wrote:
| I left an Arch install sitting for a few months and came back
| and had trouble getting the updates to properly install.
| Seems the advice around it is basically just don't go that
| long without updating.
| pamcake wrote:
| Bollocks. This can happen for any distro or OS. Stick to
| distro packages and this isn't notably more true for Arch
| than for most other distros or OSs.
|
| If you build and install packages from AUR, or use dodgy
| repos like Manjaro, then risk of update woes will increase
| significantly.
| 999900000999 wrote:
| This is a cool idea, but it's not clear what problem it's
| solving. Tumbleweed is already great
| benrutter wrote:
| I was trying to figure out the change as well - I've only used
| Tumbleweed through WSL before. Does it provide a desktop
| environment preinstalled or is it a 'bring-your-own' deal? (if
| not, that seems to be the big thing that Kalpa brings to the
| table?)
| 999900000999 wrote:
| Tumbleweed comes with desktop environment options. You can
| select from a few.
|
| I guess you get the atomic system, but with Tumbleweed you
| get snapshot backups anyway.
|
| One of the main advantages of Tumbleweed is the extensive
| testing pipeline. I'm not sure how a derivative would be able
| to offer a similar experience
| whalesalad wrote:
| "I have a minor inconvenience -- I know, I'll create an
| entirely new distribution where 99.92% is identical to the
| base"
| amlib wrote:
| How else are you going to improve the linux gene pool?
| Breeding linux distros ain't gonna cut it :)
| ogogmad wrote:
| Being able to roll back updates/upgrades that go wrong, is
| not just fixing a minor inconvenience. There's also something
| about the critical part of the system being less mutable.
| Desktop Linux has been way too easy to break in the past.
| awoimbee wrote:
| Tubleweed has snapshots and rollbacks too by default. But
| yeah immutable distros are good for beginners so they don't
| destroy their system!
| whalesalad wrote:
| The OS this is based on, Tumbleweed, is what provides that
| capability. I do not think there is anything novel here.
| mhurron wrote:
| Kalpa is an immutable distro based on MicroOS with KDE as it's
| desktop environment.
|
| MicroOS and its derivatives are all based on Tumbleweed.
| MicroOS was intended to be used for container workloads. Aeon
| grew out of that with a GNOME desktop, Kalpa a KDE desktop.
| Because they were focused in a way Tumbleweed is not, they are
| a more opinionated distro. On the other hand, Tumbleweed is a
| rolling distro that wants to be all things for everyone.
| sach1 wrote:
| This rules but the landing page could benefit from a Download Now
| type button for the iso page.
| zokier wrote:
| This blog post might provide useful context:
| https://sfalken.tech/posts/2024-06-08-how-do-aeon-and-kalpa-...
| TiredOfLife wrote:
| What's with the Ventoy hate. Every linux distro can be installed
| with Ventoy except for SuSe ones
| jackhalford wrote:
| I've had trouble installing proxmox with ventoy, I had to
| install debian and then proxmox as a package. AFAIK there isn't
| really an alternative to ventoy?
| wpm wrote:
| I like the iODD virtual disc drives, I have an ST400 that has
| been pretty reliable aside from complaining when the iso
| files are too "fragmented".
| LiamPowell wrote:
| It silently messes with the kernel boot flags which breaks the
| boot process If you do get it to work it silently adds extra
| broken repos which make it impossible to install packages.
|
| Why would any distro want to support a tool that intentionally
| breaks things? Ventoy could just boot ISOs without messing with
| them and everything would work fine, but the developers insist
| on injecting garbage.
| spookie wrote:
| You really shouldn't trust ventoy.
| tosti wrote:
| SuSE doesn't ship ventoy and the installer does boot and work
| just fine. It's likely a bug in ventoy. SuSE doesn't test that
| and why would they?
|
| Perhaps ventoy doesn't like SuSE.
| raphinou wrote:
| I've installed https://getaurora.dev/en/, another atomic Linux
| distro, for a non technical user and find it really good. I've
| read arguments that its architecture was better than kalpa, but I
| don't find it back and I have no sufficient knowledge or
| experience of both to have an opinion.
| wongogue wrote:
| For the uninitiated, it's another UniversalBlue project just
| like the popular Bazzite. It focuses on a general computing
| usecase instead of gaming.
| butILoveLife wrote:
| Has anyone had a good long term experience with Atomic?
|
| I admittedly only used it on a 13 year old gaming computer and
| couldn't get the GPU drivers because... you know containers.
|
| This is something trivial with a regular install. (Especially
| with LLMs to assist)
|
| I want to like Atomic, but it feels like an Apple-like regression
| in computing.
| sph wrote:
| I have run Fedora Silverblue on my workstation since 2021 at
| least and I wouldn't go back to a regular distro ever. I'll
| jump ship for an immutable distro not based on RPMs (or APT)
| which I loathe.
|
| The secret is that all your power is within a distrobox
| container. All my dev tools, Emacs are in an Arch Linux
| container.
| yjftsjthsd-h wrote:
| The difference between this and apple is that at the end of the
| day it still believes the user should hold the power. With
| Kalpa, you _can_ persistently modify the operating system using
| transactional-update, you 're just strongly advised to keep
| that to a minimum.
| sherr wrote:
| This appears to be a "pre-beta" site, so this will be why it is
| not polished yet. From the documentation page :
|
| "note: These installation instructions will be changing, with the
| Beta release of Kalpa"
|
| A bit rough around the edges - so probably unfair to publicise
| too prominently yet.
| shevy-java wrote:
| Isn't OpenSUSE for sale? At the least distrowatch said this
| recently.
| hiprob wrote:
| What do you mean by that? SUSE products are for sale, OpenSUSE
| products are free.
| tosti wrote:
| A private equity firm aptly named EQT bought SuSE from their
| previous owners in 2018. Now they want to sell it off.
|
| Ofc the distro can be installed for free. Owning the business
| sets you back some $6 billion.
| KeyBoardG wrote:
| Are they still managing versions and rollback via BTRFS
| snapshots?
| stryan wrote:
| Yep, using snapper, same as tumbleweed.
| vishnuharidas wrote:
| A screenshot is the bare minimum for such things.
| steve1977 wrote:
| It's an atomic Linux distribution with KDE. A screenshot would
| look like any other KDE screenshot.
| drnick1 wrote:
| I am not sure I fully understand the usability trade-offs when it
| comes to these "atomic" distros. One the one hand, security seems
| to improve markedly, since the root filesystem is largely
| immutable. On the other hand, it does seem that a lot of
| straightforward things become harder. I generally dislike
| flatpaks and favor a low-level, bare-metal approach to things and
| atomic distros seem to go against that. Maybe I should just run
| some experiments in a VM.
| coderbants wrote:
| The idea is that the immutability of the operating system leads
| to greater stability. The partition should (in theory) be
| exactly as the distribution expects on every computer it's
| installed to, which limits the potential for user changes
| breaking anything. The benefit to the user is that it's a lot
| harder to shoot yourself in the foot by running the wrong
| script.
| Vinnl wrote:
| For me, the point is not security, but maintenance. Whenever
| system upgrades have gone wrong, it's almost always been a
| partial update, and that just no longer happens.
|
| I've found doing work in containers made things straightforward
| enough, as a developer. Though I still somewhat think that
| that's just moving the problem - I'm not quite keeping those
| containers up-to-date. `distrobox assemble` helps a bit though.
| Pwntastic wrote:
| i misread the name as "Kapla" and thought it was a reference to
| the Klingon word "Qapla'"
| gethly wrote:
| since flatpacks/snaps/appimages are containerized-ish, i see no
| point in these immutable distros any more. also, cosmic is where
| the focus of linux desktop should be, not kde or gnome.
| mixmastamyk wrote:
| Perhaps another "container," for the basic system.
| miggol wrote:
| Been running Aeon, the Gnome version of Kalpa, on my personal
| laptop for about six months now. I came from Tumbleweed so the
| learning curve wasn't steep. Overall the experience has been
| good!
|
| The one major issue I had from the start was non-free Bluetooth
| codecs like AptX. That required me to taint the base image and
| add a non-official repo. It was messy but that was mostly down to
| it being a learning process, if I had to do it again I could
| probably do it with a single run of `transactional-update shell`.
|
| The installer is super minimal and surprisingly user-friendly.
| One thing I remember is that there was zero partitioning choice:
| just use the full disk for encrypted btrfs and you get no swap
| (but zram swap is on by default). If you use OpenSUSE with secure
| boot enabled (as intended) then hibernate is prevented by
| `kernel_lockdown` anyway.
|
| Snapper by default is nice, but you also get that with
| Tumbleweed. I ran into no applications that I couldn't get from
| Flatpaks or export from a distrobox, the latter being mostly for
| obscure stuff I need to compile myself. And my main toolbox hosts
| my Emacs environment that I spend most of my time in besides
| Firefox.
|
| It's hard to recommend a MicroOS desktop over Tumbleweed, the
| latter being a great all-purpose distro as it is. But I'm hoping
| the benefits of forcing this "rootless" paradigm on myself will
| appear when it's time to move to a new machine. Just copy over my
| home directory and distroboxes and I'm golden, I could even
| switch to ARM without hesitation.
|
| The distroboxes help with migrating because if I want to compile
| a newer version of that obscure program from earlier, I don't
| have to hunt down all the arcane requirements again. They're all
| still there waiting for me, in a Fedora/Ubuntu/Arch/whatever
| distrobox, depending on what works best for that program. At
| least that's the theory.
|
| Happy to answer questions.
| ogogmad wrote:
| I did some manual partitioning when installing Kalpa: I added a
| Swap partition whose capacity I set equal to RAM + 2GB, which
| got hibernate working.
|
| I think Hibernate is strictly better than Sleep: Why should a
| computer still use power when it isn't doing anything? And if
| you could get a desktop to recover its state before a full
| reboot without using Hibernate, then why would you need Sleep
| anyway?
___________________________________________________________________
(page generated 2026-03-17 23:00 UTC)