> Most obvious example is Firefox. The Debian Project allows Firefox to update outside the packaging system, automatically, at the whim of Firefox.

No, it's not. Stable ships ESR which has its update mechanism is disabled. Same for Testing/Unstable. It follows standard releases, but autoupdate is disabled.

Even Official Firefox Package for Debian from Mozilla has its auto-updates disabled and you get updates from the repository.

Only auto-updating version is the .tar.gz version which you extract to your home folder.

This is plain FUD.

Moreover:

Debian doesn't ship pulseaudio anymore. It's pipewire since forever. Many people didn't notice this, it was that smooth. Ubuntu's changes are not allowed to permeate without proper rigor (I follow debian-devel), and it's still released when it's ready. Ubuntu follows Debian Unstable, and Unstable suite is a rolling release, and they can snapshot it and start working on it whenever they want.

I'm using Debian since version 3 too, and I still reboot or tend my system only at kernel changes. It's way snappier w.r.t. Ubuntu with the same configuration for the same tasks, and is the Debian we all know and like (maybe sans systemd. I'll not open that can of worms).

pulseaudio is default for atleast kde desktop in current debian stable. Trixie might change that, but its not official release yet

Firefox only updates on its own if installed outside of the package manager. This applies to Debian and its forks. If I click on Help -> About it says, "Updates disabled by your organization". I personally would like to see distributions suggest installing Betterfox [1] or Arkenfox [2] to tighten up Firefox a bit.

[1] - https://github.com/yokoffing/Betterfox

[2] - https://github.com/arkenfox/user.js

>Most obvious example is Firefox. The Debian Project allows Firefox to update outside the packaging system, automatically, at the whim of Firefox.

It seems likely that you personally chose to install a flatpak or tar.gz version probably because you are running an older no longer supported version of Debian.

>These days, the only way to avoid that (crashes) is...

Running older unsupported versions with known never to be fixed security holes isn't good advice nor is ripping out the plumbing. Its almost never a great idea to start ripping out the floorboards to get at the pipes.

Pipewire seems pretty stable and if you really desire something more minimal it's better to start with something minimal than stripping something down.

Void is nice on this front for instance.

Long time Debian fan, current Devuan user. I'm sure it still has it's problems, but it feels nice and stable, especially on older hardware that is struggling with the times. (Thinkpad R61i w/core2duo T8100 swapped in and middleton bios)

I've done something similar at my job. I don't think it implicates privacy because 1) it's a list of misses from the (public) dictionary, and 2) the email is sent as the program, not as the user. So if the user misspells melinoma, you have no information on which user that was.

This might be different if you have 4 users on the system or 400 users.

Also, traditional Unix makes it easy to find out who was active on the system at a certain time (for example with the "last" command, which reads the wtmp log), plus other data sources (historically regular users were often allowed to read most log files by default, and people often used relatively open file permissions by default, which would at least allow for examining other users' file metadata).

That's a very rude thing to say about the President's wife. Notice has been taken.

I'm using it now. It's my primary wm for all my machines. I don't need a "desktop"; I just want something to manage windows. I don't "drag-n-drop". And I don't systemd, plus I kill as much of the rest of their FreeDesktop.Org code as I possibly can.

I've tried to switch to other wms, but I just can't get the same usefulness out of them, and end up switching back.

A lot will depend on where you are in your maturity as a programmer. And what sort of work you want to do.

I've always done well following Don Lancaster's advice: Hit the basics, HARD.

Most modern software "innovations" are really just a restatement of David Parnas' paper from 1971. He suggested programs should be split up so that the data used by modules can't be affected by the other modules. "Data hiding."

Once you get a grounding in the history and literature of programming (which all other professions do without thinking), you'll start to see the "sameness" among all the supposed difference. Once you see the "sameness", you'll know what is truly important to know/master, and what is not.

As a recent grad, I'll tell you that the first thing I learned was to ignore all the "software engineering" stuff that schools teach. The reality is that I would be asked, "Build a tool to do X". So I'd start through the process, building a design and the data flows, starting to build the code. Then I'd get "It also has to do Y." And I'd have to throw away most of what was written.

Eventually, I learned the two rules Ken Thompson taught:

1) give users something useful in two week, not the whole problem solved. 2) when in doubt, use brute force.

That's it. With attention to fundamentals, you can clearly see that "Agile" is just a bunch of fancy words (and vendors selling tools) telling you to do that same thing. Only Ken talked about that in the 70's.

What you'll find is that getting a tool into the hands of users will generate new features based on what it already does. No more blue-sky wishes. And it will allow the tool to evolve into what they really want it to do. Which no one ever knows when they start. All the best software followed that path to greatness. (Which you'll see when you read the history of your chosen profession.)

So learn the history. Learn how computers work (not the "Von Neumann" stuff). Get a computer engineering book and learn about bit-slicing and clocks and microcode. It doesn't matter that you're not a hardware guy; you need to know what your code is actually doing, down on the metal.

Never stop learning. Read constantly. Read books you'll never find a job with, like SICP. (I once had to write a loop in a language without a loop construct. But I had read SICP, so I knew if it supported recursion, I could make a loop. And I did.) Don't read trash. Don't bother with the "current hotness"; if it's good, it's probably just a restatement of the old and if it's bad, it'll go away.

I'll just leave with an ancient aphorism: 40 can't tell 20. There's just a gap between what an older person has learned about the world, and what a younger person imagines the world to be. That different can be called "experience", but the fact is I remember perfectly the pearls of wisdom dropped on my by the "old men"...and 20 years later, I was them. So I offer this small essay, knowing it'll probably be rejected, but hoping that just this once it does some good for someone.

Your essay is filled with strong and agreeable opinions. I appreciate that I get to learn about them from a recent graduate. Thanks.

If you liked this article, Henry Petroski's "The Book on the Bookshelf" is worth reading. He goes into great detail about the history, explaining why books were usually chained to their shelves, etc.

If you don't know the author, his most famous is probably "To Engineer is Human: the Role of Failure in Successful Design". I liked "The Evolution of Useful Things", because now I realize Americans use their forks wrong. The design of the fork follows function, and that curve is there for a reason.

Look at the earliest computers, that is, those around the time of ENIAC. Most were electro-mechanical, some were entirely relay machines. I believe EDSAC was the first _electronic_ digital computer.

As for weird, try this: ENIAC instructions modified themselves. Back then, an "instruction" (they called them "orders") included the addresses of the operands and destination (which was usually the accumulator). So if you wanted to sum the numbers in an array, you'd put the address of the first element in the instructions, and as ENIAC repeated that instruction (a specified number of times), the address in the instruction would be auto-incremented.

Or how about this: a computer with NO 'jump' or 'branch' instruction? The ATLAS-1 was a landmark of computing, having invented most of the things we take for granted now, like virtual memory, paging, and multi-programming. But it had NO instruction for altering the control flow. Instead, the programmer would simply _write_ to the program counter (PC). Then the next instruction would be fetched from the address in the PC. If the programmer wanted to return to the previous location (a "subroutine call"), they'd be obligated to save what was in the PC before overwriting it. There was no stack, unless you count a programmer writing the code to save a specific number of PC values, and adding code to all subroutines to fetch the old value and restore it to the PC. I do admire the simplicity -- want to run code at a different address? Tell me what it is and I'll just go there, no questions asked.

Or maybe these shouldn't count as "weird", because no one had yet figured out what a computer should be. There was no "standard" model (despite Von Neumann) for the design of a machine, and cost considerations plus new developments (spurred by wanting better computers) meant that the "best" design was constantly changing.

Consider that post-WWII, some materials were hard to come by. So much so that one researcher used a Slinky (yes, the toy) as a memory storage device. And had it working. They wanted acoustic delay lines (the standard of the time), but the Slinky was more available. So it did the same job, just with a different medium.

I've spent a lot of time researching these early machines, wanting to find the path each item in a now-standard model of an idealized computer. It's full of twists and turns, dead ends and unintentional invention.

Use the darknet. Get a list of possible texts, then download them. Figure out which one teaches the way you need to learn, then go buy that one. Used.

I think it's important to note that his work used the proper materials and workmanship. It was essentially an "official" sign, just done by a volunteer.

I remember driving through there before and after. I was happy they'd put up a sign, and didn't know until years later about the true story.

I've since seen a couple of other places which tempt me to grab a high-viz vest and fix some things.

Don Lancaster had a software-only method for syncing to the video scan, called the Vaporlock. Which is a play on "genlock", which TV production systems called their hardware to sync to the scan for doing overlays.

Don's technique relied on the fact that the video hardware in the II line scanned memory that was outside the video frame. He put magic values in those extra bytes for each scan line, and his software could detect where the beam was on each line. (I've probably messed up the explanation; it's from memory of 40 years ago...)

The great thing is that you could mix video modes within a single scan line, allowing you to put text on the left edge of a HIRES graph. The downside is that the Apple can't do anything else, because his code is running in an exact timing loop to stay synced.

There were other solutions, but those were all hardware-based.

Even if you never RYOMS, this book shows you how email actually works, down to the bare metal. That's knowledge worth having.