So I grabbed my ventoy-drive, downloaded latest mint ISO on it and instead of doing something productive I planned to do I’ll spend couple of hours at reinstalling the whole system.
With Mint, you should be able to get to a working system that lets you do your paperwork within less than half an hour.
You can set up all your customizations again when you have more time. But it should also be no issue to just copy your old /home folder to the new system between Mint and Ubuntu. Then the only step after installation would be to install the programs you had before.
Yes, I know. Existing drive layout however says that I need to repartition the whole thing and that says that I need to copy couple of hundred GB’s over to something else before reinstallation and so on, so it’s not a half hour job. And while I’m at it it’s better to do it right than half-ass it over a long, long period of time.
In general, linuxes autodetect all hardware, but do not automount all filesystems. This is intended. It is a matter of configuration, and so the different distros have different tastes regarding this topic.
Finally, my life is complete. We have achieved feature parity with Windows.
Seriously, the BSOD QR-code is a great way to have a more inclusive system. Hardened geeks can still sift through the boot log to find problems and newbies can just get help online. Win-win.
Maybe you unplugged the device before unmounting it leaving the filesystem in an odd state? Next time it fails to auto mount check /var/log/syslog for recent error clues.
Now that’s quite an interesting NixOS setup, I’m especially intrigued by the tmpfs root portion. The link you provided was a great read, and I’ll keep this and honestly most of what you’ve described in mind for when I mess with NixOS again.
There are also these two blog posts by elis on setting up tmpfs specifically. Though these posts rather are setup guides, than “talking about the philosophy” of systems design.
This is a very interesting setup would you mind providing more explanation / documentation? Also would you mind sharing your nixOS config? I would love to try it.
My system configuration can be found on git.sr.ht/~sntx/flake. I’ve linked the file tree pinned to the version 0.1.1 of my config, since I’m currrently restructuring the entire config[^1] as the current tree is non-optimal[^2].
The documentation in the README in combination with the files should cover most of what I’ve described, with the following exception: disko is not present to the repo yet, since I’ve set it up with a forked version of my config and the merge depends on finishing the restructuring of my system configuration.
You can take a look at these (non-declarative) installation steps to get an idea on how TMPFS as root can be setup
If you’re interested, I can also DM you the disko expression for it
[^1]: The goal is to provide definitions for desktops, user-packages, system-packages, themes and users. Each system can then enable a set of users, which in turn have their own desktop, user-packages and theme. A system can also enable system-packages for itself, independent of users. If a user is enabled that has a desktop set, the system will need to have display-manager set as well, which should launch the users configured desktop.
[^2]: The current config assumes a primary user, and can only configure a single DE and apply the application/service configs only to that user.
This looks like a whole project. What is the overall goal of this build?
I am very new to nixOS and am interested in it. Specifically for ansible scripts to build out easily replicateable docker hosts for lab. I have also considered it for switching my primary desktop and laptops as being able to have the same OS with everything the way I like it is also intriguing.
Sorry for theate response. P.S. I love your wallpaper.
There’s no overall goal to the project. It’s just the result of me tinkering with my systems from time to time (I’m allocating a bit less than three hours each day to coding on personal projects to improve my skills, some of that time flows into my nixos config).
I am very new to nixOS and am interested in it. Specifically for ansible scripts to build out easily replicateable docker hosts for lab.
I’ve extensively used docker/compose before I switched my systems to NixOS, since then I’ve barely touched it.
The thing with Ansible and Docker is that you mostly define the steps you want your systems to automatically go through to reach a specific state.
Nix[^1] approaches the problem the other way around. You define the state you want to have, and Nix solves for the steps that need to be taken to reach that state.
If you want to try your hands at that concept, I recommend installing just Nix on one of your test machines and trying out development shells/devshellswith it.
For example the SwayFXrepo contains a flake.nix providing a devShell. This allows everyone working on the project to just run nix develop in the cloned repo, or nix develop github:WillPower3309/swayfx without cloning the repo to enter the development environment.
This can be combined with tools like direnvto automatically setup development environments, based on the current directory.
If you want a more encompassing example of what Nix can provide, take a look at:
This presentation by Matthew Croughan on Nix-Flakes and Dockerfiles.
[^1]: The “package manager” that NixOS is build around. Though I think of it more as a “build system” - not to be confused with Nix, the language the build “scripts” are written in.
I have also considered it for switching my primary desktop and laptops as being able to have the same OS with everything the way I like it is also intriguing.
While I personally think NixOS is one of the most potent software in existence, and a computer without feels less capable for me, I do not recommend it easily.
Just take a look at hlissner’s FAQon his system config (which I greatly agree with).
That said, I initially tried NixOS on my PC and pushed the config to a git-forge. I then installed the base NixOS ISO on my laptop and told it to build the config from git. And that worked flawlessly.
In leaving the PC unattended for about 20mins, it went from a full Gnome desktop to my Sway setup.
That’s the point when I was sold.
Sorry for theate response. P.S. I love your wallpaper.
Don’t worry about the late reponse ^^
The wallpaper can be build with nix build sourcehut:~sntx/nix-bg#abstract-liquid btw.
Humm good points in the articles. I think my goal of building docker hosts makes more sense. It is interesting how the took the declarative concepts of something like terraform and kubernetes and built it into an OS. It’s kind of like fedora silverblue but the two took different approaches. Perhaps fedora makes more sense on a desktop. I have a dev and DevOps background and like the idea of being able to more deeply learn Linux without having to rebuild my system from scratch when I bust it.
Can you explain home manager? What about things to consider when installing NIX package manager on another distro?
Perhaps figuring out how to get the wallpaper out of a nix distrobox would be a good learning experience.
Mandrake was pretty cool. The original user-friendly distro. I’ve never used it (was too deep down the rabbit hole running Red Hat to try something “friendly”) but I remember there was a bit of hype going back in the day about it.
Honestly, for a long term usage like this a rolling release distro is better. I’ve never not had massive issues upgrading ubuntu release to release, but I’ve only ever had minor ones on arch and pretty much nothing on gentoo. Arch is bleeding edge, so can’t recommend it to you all that much and gentoo has some learning curve initially. But I’ve heard good things of whatever rolling names are from fedora and opensuse.
There is no problem with using a point release system long term. The problem is using Ubuntu. I’ve never once successfully upgraded it from one release to the next without issues, errors, things breaking or loss of functionality. It’s the main reason why I’ll never use Ubuntu again.
I’ve upgraded several Ubuntu LTS versions to newer LTS and have been running fine. The problems come up when you wait too long and the repos don’t have the needed packages anymore. You can still fuddle your way through even that scenario and retain a fully working system.
You can still fuddle your way through even that scenario and retain a fully working system.
Or at least you used to have that option without too much of a headache. I’m pretty sure you can still do it tho, but the steps required to ‘rescue’ old installation tend to be more complex than they used to be.
For a desktop system, I think something like NixOS is probably the way to go. Keep your home partition then blow away the system and boot if there are ever any issues then install the system from your backed-up system config file and you’re golden.
Ubuntu changes the entire underlying technology too often cause they always try to introduce their own system in place of something that’s already established (Upstart, Unity, Snap, etc.)
My last experiences with Ubuntu were one upgrade that failed to boot after following all the recommended steps, one upgrade where the release notes themselves recommended a fresh install to enable all functionality and a fresh install where the first thing I saw after booting was an error message by Gnome about a crashed service.
I left the distro after that and haven’t looked back. Admittedly, that was quite some time ago. It’s likely they’ve improved since then (but so have all other distros).
I’m glad we have companies helping to push the envelope and try new things. I may not always like the direction they take things, e.g., the Unity desktop turned me off for a few releases, and I always seem to run KDE since gnome went off the rails (imo), but it doesn’t hurt anything and the whole ecosystem is probably better for it. If it hurts then people move to alternatives and hopefully Canonical backpedals, or people move on and Ubuntu withers.
People think “updates are time consuming” therefore prefer LTS because its supported for longer. I parole for quite some time that LTS has no place for private use and rolling release is the right way.
I can’t stand rolling releases (for personal use) and I never recommend them to anyone. To me it feels like being in drift sand.
I need fixed releases to test my documentation (shell scripts) against something. With a rolling release those scripts can break at any time, unless you read the changelog of every package update.
But I also want and use fully automatic updates, so reading changelogs for every update would be the direct opposite of what I am looking for in an OS. I am ok with reading release notes every couple of months for a distribution upgrade though.
I want my systems to be reproducible and that’s impossible with drift sand rolling releases. In my opinion Fedora or Ubuntu have a decent release cycle, I would never consider Arch or Tumbleweed or Solus.
Uhm you never actually used a rolling release distro obviously. Why would you have to read change logs? Also what are you referring to with “test my documentation (shell scripts)”? Why would those not work if package xyz is updated? You are not making much sense, but maybe I am lacking the experience in UNIX to understand your point of view.
Your package manager should tell you about conflicts and even if it doesn’t and something is not working like it did before, you do a simple snapshot rollback and wait another week to update or actually read what might cause the issue. And those incidents are like super rare, at least on Opensuse Tumbleweed (e.g. 2-3 times in a year).
I’ve used Arch Linux and openSUSE Tumbleweed in the past and I have been using Linux for over 10 years …
With each new version of an application there’s the change that configuration files or functionality changes. Packages might even get replaced with others.
You would be surprised how much changes between Ubuntu LTS versions … My archived Ubuntu installation script had lots of if-statements for different versions of Ubuntu, since stuff got moved around. Such things can be as simple as gsettings schemas (keys might get renamed), but even these minor changes make documentation and therefore reproducable reinstallations troublesome.
With a fixed release all these changes are nicely bundled in one large upgrade every couple of months/years, which makes it easy to document and to plan when to do the upgrade.
With each new version of an application there’s the change that configuration files or functionality changes. Packages might even get replaced with others.
Even if this would be true, how would that impact your configuration? It doesn’t full-stop. If you want to access those new features you simply need to check how to activate them in your config file. Or are you making config edits in /etc/ ?!
Your next paragraph I don’t understand, it seems specifically aimed at some kind of self “maintained” script, which as nothing to do with rolling release or distributions.
It impacts my documentation. If, for example, gsettings set org.gnome.software allow-update false no longer works, because they changed the key from allow-update to updates-allowed, then my documentation no longer works correctly. Same when new technology is introduced, e. g. a switch from Pulseaudio to Pipewire. With a rolling release distribution these changes can happen at any time, whereas with a fixed release these changes only occur when a new release of the distribution is made and I upgrade to it.
I don’t have the time to continously track these changes and modify my documentation accordingly. Therefore I appreciate it if people bundle all those changes for me into one single distribution upgrade and write release notes with a changelog. Then I can spend a day reading the release notes, adjust the documentation, apply the upgrade on all devices and then move on for the next couple of months/years.
which as nothing to do with rolling release or distributions.
I tried to explain to you why I dislike rolling release distributions. That’s why I tried to give you one example where a fixed release distribution is more suitable in my opinion.
I understand that these things might not matter to you, if you only have one computer (or so) to maintain at home or maintaining home computers is your hobby. But I have four personal computers and multiple devices from the family to maintain and system administration is no longer my hobby …
LTS does have a place on the desktop: Learning how to daily drive linux. I started with kubuntu non-LTS and didn’t know you needed to manually start a full-upgrade to not get moved to backport repos. Of course that came crashing down on me at the worst time and I took a break from linux. But I did learn enough that I can use arch now and it’s been great.
I don’t understand what it means to "not get moved to backport repos, but this seems ubuntu specific. What you need is proper rollback/snapshot mechanisms in place. Looking at Tumbleweed which offers it out of the box. For Arch you can set it up yourself or use something community made like EndeavourOS.
I haven’t been paying attention on the rolling releases scene, but I’m pretty sure there was no mature option back when I installed that thing in 2019 or so other than Debian Sid (and daily driving that used to be an adventure in itself, but it’s been years since I last had a system like that). With ubuntu since at least version 14 upgrading from stable release to another was pretty stable experience, but that’s not the experience I’m having today.
But regardless of that you can still daily drive it as your distribution and many do. That’s why I said it’s an adventure of it’s own, but if you know what you’re getting into and accept the reality with Sid it can work. Personally I don’t want to use it at this point in my life, but I used to run it for several years when woody was getting a bit old on packages and sarge wasn’t out yet (and I think I just continued with sid after sarge release).
Iam using Tumbleweed for close to 10 years now and it was pretty mature from the start. You can’t go wrong with rolling release + perfectly configured btrfs + snapper by default.
You might be correct, but I haven’t found one that I’d like (not that I’ve really looked for one either). Maybe you know if there’s any Debian derivatives which do rolling releases?
I like cinnamon and I’ve been running mint on my laptop for quite a while and I like it, so I’m going with it right now and plan for my next distro-hopping needs more carefully when installing.
But in general I’d say that Ubuntu is far from what it used to be and the TLC the latest version wants is just something I’m not willing to put up with. If something breaks on a update then it breaks, but at least give me an option to choose when it happens.
I just had pacman uninstall itself the other day during a routine -Syu. I was finally able to figure out how to fix it, untar the pkg to / and then tell pacman to install pacman with —overwrite.
You won’t. Arch has very little glue that holds it together and the components are quite robust. Buntus of this world, on the other hand, have plenty of glue to enforce their way. And it might be good for first timers, but definitely gets in a way as you start learning the system. My last annoyance like this was disabling gdm - it just kept coming back. Some script somewhere was making sure thr service was running no matter what.
Rechecked this now, and it’s at about 5% now. The statistics seem a bit weird to me, unless there are some big seasonal changes. Your 12% was recorded in June and July. Maybe with less business activity during these months, the Windows share plummets in favor of home users who are more prone to use Linux.
Percentage is not as easy or helpful to work with, when there are orders of magnitude difference between absolute numbers. It hides the absolute number difference for no other reason than unspoken lying of statistics.
My first flavour was Red Hat back in the late 90s. It's a shame I didn't give it more of a go back then. Then Mint for a couple of years in the earlyish 2010s before finally settling on Arch where I've been for almost a decade now.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.