I guess I just don't understand what problem this solves.

Some people just can't be trusted with HTML.

"This title does not impose liability on an operating system provider, a covered application store, or a developer that arises from the use of a device or application by a person who is not the user to whom a signal pertains."

This is obviously a law so poorly written that it'll never pass a court challenge. Assuming anyone brings one.

I'd like to see that definition. My OS doesn't have an "application store", so I doubt it's impacted by this law.

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

And there's the inclusion of non-Free software in the base install, which is completely against the Debian Social Contract.

The Debian Project drastically changed when they decided to allow Ubuntu to dictate their release schedule.

What used to be a distro by sysadmins for sysadmins, and which prized stability over timeliness has been overtaken by Ubuntu and the Freedesktop.Org people. I've been running Debian since version 3, and I used to go _years_ between crashes. These days, the only way to avoid that is to 1) rip out all the Freedesktop.Org code (pulseaudio, udisks2, etc.), and 2) stick with Debian 9 or lower.

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.

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.

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.

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.

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'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.

if [ "$path" == "" ]

should be

if [ "$path" = "" ]

On the other hand, if he's "searching FOR Earhart's plane", this contradiction resolves itself.

This might be "legal", since XHTML was intended for the web, but I assume Google's using it to collect more user interaction data that they can sell to data brokers.

FWIW, PDF is simply Postscript that's been compressed. As far as I can tell, almost all documents these days are created with Microsoft Word, TeX, or Postscript. I'm lumping things like PageMaker and LaTeX in with the base they were derived from.

My favorite new misfeature is PulseAudio. These geniuses actually built code for a multi-user, multi-tasking OS...which will only run for ONE user, and then only if that user is logged in. So forget running cron jobs, and sounding an alert if something needs attention.

This is all code produced by FreeDesktop[.]org. Thanks to them, your industrial strength, mission-critical server OS is now only suitable for single-user desktop systems.