Download the .deb from their downloads page and run it, just like you would either a .exe on Windows. Their instructions list that as an option further down on the page. Should be higher up imo
Many, perhaps even most, installation guides for software use commands because the graphical alternatives can vary wildly between desktops and distributions. So using commands in guides is usually the more likely to work.
That said, what Mullvad does is stupid. The downloadable deb and rpm files should just initialize the update repository. That is what Google does with their Chrome download. Basically download the file, double click on it, confirm installation. That’s it. Users don’t need to do that manually for Chrome.
Luckily, there are only a few cases remain for this type of installation. Most regular things should be either in your distribution’s regular repository or on Flathub.
Asking why something is the way it is makes you more of a “Linux user” than many.
You make a valid criticism; there’s definitely a learning curve to installing software if you choose to do it that way (since it’s not similar to other OSs), and it’s not automatically explained to new users by using the OS.
Here’s the understanding of it I’ve come to, if you’re interested:
Like others have said, the .deb file would be the equivalent of an .exe file on Windows. Like many .exe files, unless they include an auto-updater, they won’t automatically update.
A key difference I would like to point out is that Linux package managers often update and manage parts of the OS in addition to extra software. Windows and macOS both update their OS separately.
“Ubuntu Software Center” is similar to the “Microsoft Store” on Windows and the “App Store” on macOS. Like those, it’s user friendly and provides automatic updates, but it also doesn’t have every app. You can ensure those apps are safe because the company behind the OS verifies them.
“apt-get” is the default package manager for Ubuntu. That is the tool doing the heavy lifting underneath, and what those commands Mullvad gave are for.
Mullvad could have provided a script to download and run that executes those commands for you, but then you wouldn’t know what it’s doing, especially with it needing admin permission. With how security-oriented Mullvad’s brand is, I think that’s one potential reason they explain the steps and have the user do it instead.
I’m not sure if this is exactly the same issue I had, but mine ended up being resolved by disabling fastboot on the Windows side. Near as I can figure when I “shutdown” from windows, fastboot prevented releasing control of the network adapter to Linux. Wifi would only work if I restarted from windows, or when fastboot got disabled.
Son of a bitch. Instead of “turning shit the fuck off”, is windows putting the wifi card into some sort of eternal WoL mode when it shuts down? And the wifi card isn’t resetting at boot time (or honoring a reset command) to give the linux drivers a known starting state?
https://github.com/babarot/gomi - replacement for the rm command that has a trashcan, so if you accidentally delete something important you can just restore it
Also, I think you should add a note that ranger should be installed from git because most distros package version 1.9.3 and that is 4 year out of date and has lots of bugs that have been fixed in the git master branch
Yes! Awk is great, I use it all the time for text processing problems that are beyond the scope of normal filters but aren’t worth writing a whole program for. It’s pretty versatile, and you can split expressions up and chain them together when they get too complicated. Try piping the output into sh sometime. It can be messy though and my awk programs tend to be write-only
Ya, but you’re overlaying all that stuff, codecs, nvidia, etc. ublue works out of the box and updates are quicker due to not having to re-overlay everything. It’s just less friction. Also it comes with automatic updates enabled which is really nice (and safe in an immutable, intrinsically rollbackable environment)
Overlaying isn’t bad. It’s kind of what we’ve done the past years anyway.
Does the speed of updates matter in any way? Unless it’s not days, there’s no reason for me to complain update the duration since everything is done in the background.
What’s the difference to the auto update in silverblue?
Ootb fedora doesn’t even have gnome extensions installed. We have to adjust our systems anyway
Personally, I’ve been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.
To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren’t able to use their containers created with Distrobox/Toolbx^[1]^. Sure; a rollback is accomplished relatively easy and I’m sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.
Which, of course, begs the following questions… Isn’t it very inefficient for everyone to fix this issue themselves? Wouldn’t it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn’t it be better if Fedora just withhold the update until it’s fixed? Is this perhaps some pipe dream that will never see the light of day? etc…
The interesting part, though, would be how I (a ‘uBlue-user’) didn’t even notice Podman was causing issues in the first place. “How?” you might ask, well… The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)
This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn’t even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.
You won’t have fedoras signatures anymore.
It depends if you have the luxury to rely on them in the first place.
If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn’t well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what’s been referred in Fedora’s Wiki as) Ostree Native Containers.
Finally, let’s not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue’s maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).
P.S. If I hadn’t made it clear, it’s totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.
So you convinced me, and not being a novice, I didn’t read the install instructions and just went for it. It wrecked my dual boot efi partition. No worries, been there done that before, spent all morning trying to get the eufi shell and grub sorted out. After a few hours of failing, I’m like hey I planned for this, I’ve got a USB recovery for windows, and my actual data is all backed up via syncthing (thanks to this community). Why am I bothering with this nonsense.
Omg… Recovering windows takes foreeeeever. So then I’m reading the kenoite instructions and it calls out that dual booting doesn’t work, here is a suggested partition scheme… Ffs… Anyway for anyone that doesn’t want to waste an entire day on this, rtfm.
FWIW, I’ve put some effort into explaining how a dual boot of Windows 10 and Fedora Atomic (read Silverblue/Kinoite/Sericea etc) can be achieved. While it’s far from exhaustive, it should be fine as long as your specific installation of Fedora Atomic doesn’t require special attention (which happens sometimes with owners of an Nvidia GPU*). After Fedora Atomic is successfully installed, proceed with following the instructions found on the following parts of uBlue’s documentation: here, here and finally pick whichever uBlue image you’d like to install from this list; specific instructions are found directly underneath the text boxes for each individual image, but ensure you’re installing the one with the correct Fedora version (37/38/39/stable/latest etc (which are accessed via tabs)). If you can’t decide on which version you’d like to install, then just go for 39.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.