I think you will need to export $PATH in ~/.profile instead. I'm sure ~/.bash_profile is only for login shells.

Waterfox was acquired in 2020 by Privacy One Group Ltd - the company who also acquired Startpage. That company was a subsidiary of ad company System1... Waterfox was divested three years later, but mud sticks. Personally I don't trust supposed "privacy" focused projects, or their developers, who sell out to advertising companies.  There are more than a few articles out there related to this.

Right wing, misinformation spreading, websites seem to be the order of the day.

No idea why you would regard that utterly biased blog, painting Somali immigrants to the US as fraudsters as "good commentaries".

I guarantee that if I asked 10 random "IT professionals" what "amd64" meant, most wouldn't know, so you're not alone.

AMD actually called it "x86-64 (tm)" :

https://web.archive.org/web/20120308025 … e_715.aspx

Intel implemented their version of x86-64 ("amd64") as "Intel 64".

I'm not 100% sure where the "amd64" terminology originated from, but it may not have been ADM themselves.  I only ever see that used by Linux distributions or FreeBSD for example.  I seem to recall that the Linux kernel sources had the options to build a kernel type of "hammer", which refers to the original x86-64/amd64 CPU.

Not about "patents" as such. Intel started out in 64 bit with IA64 architecture (Itanium), which they later phased out in favour of amd64 (AMD's implementation). Search the web for a more detailed history. amd64 was designed to run 32 bit and 64 bit code, Itanium was pure 64 bit.

Debian "developers" don't "develop", the software. Debian mainly provide the packaging tools and infrastructure.  The package maintainers attempt to fix bugs, but they are usually reliant on patches from upstream.

This is where the OP's argument is most misguided. Debian don't "quality control" every single line of code that makes up a source package, which is in turn packaged and then becomes a Debian release. Due to the nature of the "freeze", Debian releases with numerous bugs and receives ongoing fixes during the lifetime of a release. Sime bugs are never fixed.

Devuan and other derivatives inherit those. Except for maybe Ubuntu, none of the derivatives have the man power to go it alone.

So Debian and by extension Devuan, are not actually responisble for any bugs in the upstream software they may provide. Really this would be better as a detailed bug report to the developers of SLiM.

Looking at the earlier posts in this thread, with respect to /usr/local and /opt :

I know of no OS that uses /opt according to older FSH documenation. There might be, but it's none of the BSDs, macOS or any Linux distribution that I have come across. That same site also has the section for /usr/local and describes its historic purpose and its use today.

Nowadays /opt is for software that fits the description "self contained binary distribution". e.g. the Mozilla Firefox binaries.

/usr/local is for software you compile locally and install into a structure that matches /usr . The idea there is that your locally compiled version doesn't clobber the version provided by the OS. This is exactly how FreeBSD and OpenBSD ports are installed.

So I'm not sure installing packages into /usr/local makes any sense.

If I'm going to go to great lengths to package something, then I'm going to install it into /usr and I'm going to ensure dependencies are handled, and that I have correct conflicts in place to ensure I'm not overwriting anything. However I might not do any of the above, and we're back to where we were 10 + years ago with those user created Ubuntu packages which were frowned on by Debian users. This is why the likes of flatpak and snap appeared...

Otherwise I'm not going to bother packaging it in the first place.

You can drill down to get that info. My point is that, Debian is actually not this pinnacle of design and engineering that some believe it to be. It's the approach of freezing at these specific package versions and then patching, that creates many of these problems, then the backporting of "upstream" security patches to older versions has been shown to be unreliable time and again - i.e. those patching not understanding what they're patching, and not factoring in upstream changes in newer versions and their dependencies which could render the patch useless or detrimental (it has happened).Then there are the plethora of bugs which remain unfixed for the lifecycle of a release, because they either can't be easily fixed without upgrading components to newer versions or there is no one willing/able to do the work.

sudo-rs (sudo rewritten in rust) has had few recent vulnerabilities:

https://security-tracker.debian.org/tra … st-sudo-rs
https://ubuntu.com/security/notices/USN-7867-1

I must have missed the "constructive criticism".

There will probably never be a "Year of the Linux Desktop", because desktops and by extension laptops which run a consumer OS such as Windows or macOS are developed for profit first and foremost and to hold a users hand through normal usage, installtion of software, configuration and setup. That is to say that they are designed and engineered to meet the demands of a customer - and underlying complexity isn't a problem for such OS so long as the UI and getting things installed and working is "easy". The large teams develping such an OS are well paid and the people using it almost always pay for it, either with their money or their data. This model doesn't translate to FOSS software developed by volunteers, who don't service customers at all.

A "free" OS is a whole different ball game: No one is going to develop "Desktop Linux" completely for free - for people who want a Windows/macOS experience, if there are no rewards for doing so - which is why it hasn't happened to date.

Of the projects making the biggest strides in that direction, such as systemd, gnome, KDE, wayland, etc - they have attracted criticism from certain quarters for particular design decisions, increased complexity and/or corporate funding/influence.

Undortunately any efforts towards Linux on the desktop nowadays will be corporate backed aside from simple Window managers. There is the conundrum. To avoid this move away from UNIX style KISS philosophy, means embracing simpler software such as window managers and using the terminal - you can't have it both ways... well you can, but you need to get the skills to do it yourself.

Always easy to blame those people who presumably should have developed and maintained 23 year old software for free...

Be aware: https://lists.debian.org/debian-devel/2 … 00288.html

Rust is already a hard requirement for all except those obscure architectures that are referenced

Rust is a fad and it's adoption has slowed, but "memory safe" is now a thing, regardless of what happens with rust in the future.