Mozilla treats Debian devotees to the raw taste of Firefox Nightly
theregister.com
theregister.com
It prompted me to finally wipe Snap fully from my system and install Firefox from the Mozilla PPA. The only other Snap app I currently use is IntelliJ, and that has issues in its Snap packaging according to the mighty Serge, so I'm switching to a tar.gz install for that.
## app-conf/apt/nosnap.pref
# To prevent repository packages from triggering the installation of snap,
# this file forbids snapd from being installed by APT.
Package: snapd
Pin: release a=*
Pin-Priority: -10
### Remove snapd applications and service
snap remove --purge firefox
snap remove --purge gnome-3-38-2004
snap remove --purge gtk-common-themes
snap remove --purge bare
snap remove --purge core20
snap remove --purge snapd
apt-get remove --yes snapd
# This will prevent snapd from any repository
If not, you might run into [this bug](https://old.reddit.com/r/linux4noobs/comments/uj58i5/psa_fix...)
FWIW my solution was using equivs to create a dummy package to satisfy www-browser and installing that.
You should have to do that only once, then Firefox updates itself just like on Windows or MacOS. I ran this setup (Debian stable + Firefox installed by unpacking a tar) for years and never had an issue. Maybe you should unpack it in a directory where your normal user can write files to let Firefox handle the update.
So much easier than faffing about with six bazillion dh-whatever scripts.
If you follow the link in the story to the older story about Firefox ESR on Debian, it describes 2 different ways to install natively-packaged .DEB versions of Firefox $CURRENT on Debian.
I've been meaning to switch, but I'm on a certain RPM-based distro where the Firefox package in particular goes through its own set of QA testing, so I'm happy to stay on that.
So, here I am, stuck with Snap. Eww.
Snap was one of the first things I removed (was a tough fight though). This way of software management is outright hostile to personal computers (as in run by people, as in contrast to servers, mostly run by other programs).
There were some problems with the version from Mozilla PPA though too... cannot recall at the moment. I think some configuration was missing right after install.
I've never had a problem running an "unstable" or "testing" version of a Linux distro.
The main downside is that security updates is on a best-effort basis. The security team's focus is on stable and unstable. Testing will get them, but sometimes a few days late. While I understand their priorities, I also wish that would change.
Secondly, if you don't like change, putting off upgrades may actually make it worse for you. You will have an "OMG, they've changed everything!" shock when you upgrade rarely. OTOH if you run regular updates, you'll get small changes one at a time, boil-the-frog style. You can't opt out of changes, you can only get them in small drops, or a whole bucket at a time.
Long term, this has truth (although it's usually overstated -- most software, even internet software, that I have still works even after many years). But what I can do is decide for myself when to make that change. This is particularly important when features I need are removed, as it lets me still have working software while I look for an alternative.
> if you don't like change, putting off upgrades may actually make it worse for you.
It doesn't. UI changes, particularly, are disruptive. Having frequent small ones is far more disruptive to me than infrequent large ones.
I like package managers in general, but for a select few tools I’ll use a more timely update process.
Of course not. There are no other programms on my linux system, executing remote code. (ok, there is rust (crates), but i avoid it).
> There are so many security implications, everything is so complex that I really think having whatever is the newest release is actually the most stable strategy.
If they would only fix bugs, then yes. In reality they introduce new ones.
1. untar as root into /opt
2. symlink /opt/firefox/firefox to /usr/local/bin/firefox
3. compose a 13-line firefox.desktop and put in ~/.local/share/applications/
Only the first step needs to be repeated when there is a new release.
I'll definitely switch to the apt distribution down the line, though. Package management is one of the main reasons why I use Linux in the first place.
1: https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-n...
The auto-updater is better than Snap, but I'd rather use as few alternative package management solutions as possible.
And that’s where the problem lies. Apt has great documentation, creating .desktop files and their syntax? Not so much
This took me less than 2 seconds to find.
https://specifications.freedesktop.org/desktop-entry-spec/de...
Why doesn't Firefox also package their stable/release version this way? It's just nightly on this Mozilla repo, and extended-support (ESR) on the Debian-administered side.
edit: Oh, the article answers this:
- "Following a period of testing, these packages will become available on the beta, esr, and release branches of Firefox."
On Arch linux, I ended up installing the tar.gz from mozilla and I let the browser update itself. Arch packaging is kind of redundant for this. It just adds time and middlemen that I don't want anyway. If there's a critical security update, it just increases the amount of time it takes for that fix to get to you. Regardless of whether you use stable, beta, or nightly. It does add a bit of hassle for e.g. getting a menu item with the correct icon in Firefox. I do the same with a few other things that know how to self update.
That should work on Debian as well. But a .deb package from Mozilla is nice of course.
So a repository by Mozilla which ships the browser and integrates neatly into apt is a big "Thank you" from me. :)
Glad it helped someone!
RIP classic NoScript...perhaps it mostly works the same now, but when Mozilla updated Gecko (around Firefox 58 I think) they pared back what extensions were allowed to do for security reasons and NoScript had to change a lot before it could work.
Having an up to date browser matters to me more than almost every other package. So I install the binary beneath /opt/firefox, and update it myself whenever a new release comes out. (I even created a simple "firefox-wrapper" package to point to the binary, and provide firefox to avoid any dependency issues and avoid the need to install two versions).
Otherwise I think calibre, the arduino IDE, and the go toolchain, are the only binaries I've got deployed beneath /opt, as they have historically churned a lot too.
Is this actually true ? These days I use FF as my primary browser, but that's recent after a conscious (ethics driven) choice to switch. I kinda got the impression most people are just installing Chrome after install.
I know of a handful of distros that bundle Chromium (e.g. Q4OS) or Chrome (e.g. Linux Lite) but almost every Linux that provides a browser provides Firefox as the default, AFAIAA.
I am a former member of staff at both Red Hat and SUSE, and I have coming up on 30 years of experience on Linux across coming up on 100 different distros.
Among the OSes on bare metal on my home machines are macOS, FreeBSD, RISC OS, ArcaOS, FreeDOS, PC DOS, Haiku, Oberon/A2, ChromeOS Flex, Q4OS, Windows XP, Windows 7, and Windows 10... alongside Ubuntu and other distros.
As for Ubuntu itself, as it happens, I thoroughly dislike GNOME and never recommend or use it.
Among Linux distros which have been my full-time desktop platform were SUSE and Caldera OpenLinux.
My laptops mostly run Ubuntu with the Unity desktop, with Snap packaging removed and disabled, but I am currently assessing a move to MX Linux.
I've been using UNIX systems since 1988 and I still don't like it much. Case sensitivity is a pain, the shell is pointlessly arcane, and I am not a programmer -- not because I can't, because I can but I recognize that I'm not very good at it -- and don't really want an OS designed for programmers.
My favourite OSes over a 41 years in computing so far were VAX/VMS, Acorn RISC OS, and Classic MacOS, although I was a keen user of IBM OS/2 2 for some years.
I am a paid full-time member of staff at The Register, where I have been for 2 years today, as it happens. Before that, I freelanced for them from 2009. Before that I wrote for the Inquirer.
Remaster. Then this is yours. And stays that way, whith some remastering from time to time, due to updates, whatever.
Giggle like a madman for not having to care about all the useless 'make work, make work!' anymore.
Relax.
Edit: While you're at it, deploy https://github.com/graysky2/profile-sync-daemon / https://wiki.archlinux.org/title/Profile-sync-daemon or something like that for FF. That's the icing on the cake, for FF not to access your /home , whereever that may be stored. Works wonders for Sideberry, and preserves your precious SSD. OFC that applies to any distro.
Edit: s/Openbox/IceWM
https://www.theregister.com/2023/09/01/antix_23/
For me, I think it's a mess. Four desktops, 3 file managers, multiple app menus, panels, text editors, etc.
Work out one best item, pick it and use it. IMHO they need to stop shipping 3, 4, 5 or more alternatives for each function. If people have strong enough views, they can go choose their own.
The same applies to Window Maker Live.
It's how distros used to be in the 1990s, and it was a pain then, too... but then most of us didn't have broadband so trying out multiple tools was much harder and slower. Then, there was a reason. Now, there isn't.
Just deinstall everthing that you don't like, install anything that's missing, choose some theme, deinstall the rest...
And remaster. From there on, it's like being made for you, because you made it so :-)
OFC you could say that about any distro, but then you'd lose the specific scripting for booting it from whereever, running it live in RAM, while having persistence in various ways, which is the USP of it.
From that POV your review didn't go deep enough, I think. Sorry ;-)
For me it's like a debian-distro-kit, enabling me to customize the shit out of it fast and easy, while having access to the whole Multiverse of everything that's Debian, it's update and administration mechanisms, and so on.
But usually not needing to. Because it just works. Fast. Because in RAM.
Edit: Which reminds me of Q4OS which you mentioned. Regarding the distro-kit aspect, I once added the Trinity repositories to Antix, installed it, fiddled with some superflous stuff, removed that, and remastered.
BAM! Had a fucking fast trinity desktop running in RAM! Just like that.
Though I'm not using that anymore, because no need. Icewm & zzzfm are enough for me.
For me, that is way more work than I want. I am old and grumpy and want an easy life and tools that work acceptably out of the box.
For playing around, that's different. Thus A2 and Haiku and things. But for work, if it needs that much work to adjust the shipped distro to me, then it is the wrong distro.
There are good reasons I don't run Arch.
Almost paradise, except for 'systemdness', which I can't stand. So there are countless derivatives with different goals and priorities, some of them for running live in RAM, some of them being especially 'free' from an ideological but impractical POV(which I also can't stand), and some of them eliminating 'systemdness'.
Then there are Antix/MX whose goal seems to be to get that stuff running any way they can on any somewhat reasonable system, more or less frugal in case of Antix, rather comfortably in case of MX. While giving a shit about ideology, prioritising availability of all sorts of drivers, connectivity, convenience in very pragmatical ways. While running in RAM for speed(optionally), but still enabling persistence in various ways.
This toolset of them enables me to get up and running on almost anything from very barebones images with the presses of a few function keys, some mouseclicks, some eliminating of unwanted stuff(by mouseclicks, no editing necessary, I checked), installing my stuff, choosing theme/widget/deco/whatever, and be done with it in maybe 30 minutes max initially(including that remaster thing).
From there on it is absolute BLISS for me, because that way I have fast systems, looking and feeling how I like it, without getting in my way, or missing anything. For MONTHS, while still being updated, without reboots. Exceptions are kernel or fundamental library updates. These are just a few clicks in Synaptic anyways, reload, mark, apply, YÄSS, YÄSS!, gieev, gieev meee new stuff! Maybe 3 to 5 minutes daily while I'm slurping my morning coffee or tea? Too much change? Switched some core components meanwhile? Remaster in not more than 10 minutes. Reboot. Done.
BLISS again.
For playing around I'm tempted to try https://github.com/rochus-keller/OberonSystem3 (since you mentioned A2 ;-)) but probably not, because I'd rather enjoy riding my new hyperbicycles more ;-)
I have found several distros over the years that had an out-of-the-box experience that made them usable for me. MX is close, openSUSE with Xfce is a very good distro, but at present, Ubuntu with Unity is the least work of all. Two of my machines are running an install that started out as 13.04 or so. Over a decade of longevity is excellent in my book.
Oberon is a hoot, if very weird indeed. I'd love to see a native Raspberry Pi version.
Sadly I came off my bicycle in April and smashed my right forearm to flinders. The surgeons save it, but it is held together with about 35 pieces of steel, and still very fragile and can't be used for much... except typing. I think this means I have to give up bicycles, and I bought my first car in August. :-/
Had a very badly broken upper arm/shoulder though by industrial accident, while doing everything by the book, following any fucking rule, protective shoes, helmet, reflective clothing. But something weighing a few 100 tons tore free and gave me a fast kick. Shit happens. Had only 7 screws and a plate in, for about 10 years. Limited movement only, and pain. Now an endoprosthetic like an artificial hip joint, but for the shoulder. Full (and fast) movement and load-bearing again, no pain. Can do pushups and pullups.
I'm telling this because doctors initially said that I had to suck it up, that there wouldn't be a better outcome with endoprosthetics. Some decade later, somewhere else, they looked at and into it, asking me If I'd be crazy? 'That stuff has to go out!' Me: 'R u sure? I've been told...' They: 'Forget that! That's all wrong!'
Now there may have been some progress in surgical procedures and endoprosthetics fur upper arm and shoulder joint in that decade, but not that much. I also opted out of robodoc, and had it done by an old and experienced surgeon by hand.
Watch out for medical misinfo and get well. HTH
[1] For whoever doubts that a proper Linux distro can be created through pure Javascript running in a browser, you obviously haven't tried out https://linuxontheweb.github.io/ yet!
What shell it is using? It doesn't seem POSIXy (eg I can't `echo $$` to see the shell pid), and the filesystem is pretty bare
I've previously tried to implement all of those sorts of POSIX-isms, but I've recently been wanting to make the tradeoff where code simplicity and understandability trumps all other considerations. Then, when others start coming on board the project, we can start making determinations about what kinds of "proper" shell functions to support.
So, at this point, "bare yet dependable" is what I'm going for! You can actually get more feedback about the filesystem through the desktop interface. You can show an icon cursor by pressing the 'c' key, and then move it over a file icon. Then, just press the 'p' key to show the properties of the file.
Help page here: https://linuxontheweb.github.io/www/docs/help.html
One guy even made a RISC-V emulator inside VRChat using a shader[1]. Doing it in JavaScript will probably be easier, and I wouldn't be surprised if someone has done that already.
Until you emulate a CPU architecture and boot an actual Linux kernel, it isn't quite fair IMO to call it "Linux".
Your project has none of the capabilities that are very much expected when someone mentions "Linux", even in a broader sense.
In fact, I'm pretty sure your shell doesn't have some most basic abilities that a POSIX shell has (as another comment mentioned). See the manual page of e.g. dash shell and see what I'm talking about.
Emulating a shell can be fun, but it's clearly not the same as running an operating system. You should probably clarify that in the project README to avoid misinformation. Because otherwise, your project claims to be what it's obviously not.
I would tend to look at this project as an implementation rather than an emulation.
The current implementation of the shell is certainly in a highly bare bones state, but that can definitely change over time if that is in fact where the development process leads. If it gets to the point of being able to quack like a POSIX shell, then who's to say that it isn't really one?
If you implement most of it then you would be able to call your project a POSIX shell.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
[2] https://pubs.opengroup.org/onlinepubs/9699919799/idx/utiliti...
And yours contains neither GNU nor Linux, or as I’ve taken to calling it -(GNU+Linux).
It would be one thing if you had implemented a binary compatibility layer similar to WSL1, but what you’ve created seems to be a POSIX-like environment on the web.
I don’t know what the Linux philosophy is. I think it is the kernel of choice for GNU based systems because it existed and was open enough to use, while Hurd was more philosophical (to the point where, when it was needed, it existed more as an idea than a thing).
Linux is where it is because they make pragmatic decisions when when necessary.
Cool stuff
Your project is essentially an incomplete implementation of a shell where all commands are builtins, and the interactivity is limited by what you directly programmed in JavaScript.
What you are trying to make is a lot harder than you think, you first need to emulate a CPU and go from there, not read whatever user types and try to behave like a Linux system, which ChatGPT can do already.