BarbaryCoast

According to the rev history for VIM, persistent undo arrived in version 7.3, released in 2010. So Chisnall may have used it since 2000, but he didn't have persistent undo for at least two of the books he wrote. And it means it wasn't "maintained for almost 20 years", it's at best 16.

But it is a nice feature.

I do that by using version control. I have it hooked to my editor so that "save" is "check in". Now I have persistent, versioned, copies of all my states independent of whatever tools I happen to be using.

Uh, what do you mean, you can't use a scanner via USB? Did they stop putting USB ports on computers? (I haven't bought a new one in a while.) Or does your OS not provide the software to connect to it?

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

What a horrible web site. I hit "reload", and I now have two copies of the LH Menu. In IFRAMEs. I was able to see a couple of the items, then that broke. I click and nothing happens.

Some people just can't be trusted with HTML.

OK, so way at the bottom it says this:

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

"For the purpose of....covered application stores."

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

This is no longer true.

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

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.

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.

That's interesting as a programming exercise, but HP's plotters all had a built-in language called HP-GL. And there's a GPL'ed tool that will emit HP-GL. I just can't recall what it's called. Seems like it was built in to some normal printing tool. HP Laserjet printers also supported HP-GL, so that was a nice way to get your plots without having to buy a more expensive dedicated plotter.

There's a bug in the detection script. The line:

if [ "$path" == "" ]

should be

if [ "$path" = "" ]

If he's "searching Earhart's plane", doesn't that imply that he's found it? Or is he searching a plane he _thinks_ was Earhart's, trying to find confirmation from the contents of it?

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

Thanks for that. I can't read the article, probably because I block WASM (and Javascript) for security. None of my ebook readers have Internet access (for security and for privacy), so none of those internet-only epub files would work for me.

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.

...and now you know why I don't run systemd. I believe their thought process is: what would Windows do? This is an example. For instance, the desktop shell still crashes often. In the old days, this would lock up the keyboard and mouse, and you'd have to power cycle. But MS "fixed" it by simply adding infinite restarts to the system. Now we have systemd. When something crashes, there's no need to fix the bug, just restart it.

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.

Glad to be of help. I think the only one I have (yes, I kept all my SBS books) is Miss Pickerell Goes To Mars.

I read these as a child in the 60's. When Purple House Press re-issued them, I snapped them up. They've also re-issued some other favorites, like the Alvin Fernald series. I like to buy direct from them, so they don't have to share the money with amazon.

Now if someone would re-issue the Miss Pickerel series...

What's wrong with Pic? Been around for decades.

I scrolled to the bottom to find his bottom line, which is that "you can't run an email server".

Which is interesting, since I do exactly that. I've been running from a low-cost VPS for 10-15 years, and have zero problems delivering emails.

But I'm also not trying to do any UCE, which may be the use model the author is speaking about.

Michael Lucas' "Run Your Own Mail Server" should be published soon; I'll be interested to read his experiences. And Steve Gibson runs his own email server from GRC.com (colo'd server), without any issues. And that's definitely a commercial use, since it supports his software products.

They had (have?) some Hopper's on display at the Huntington Museum. I realized that even the best art books are unable to reproduce the stunning colors of the originals. It was the visual equivalent of CD audio versus live performance - just not the same at all.

Most of this guy's questions could have been answered by reading the very Wikipedia article he cites. For example, "a HEPA air filter must remove—from the air that passes through—at least 99.95% (ISO, European Standard) or 99.97% (ASME, U.S. DOE) of particles whose diameter is equal to 0.3 μm". So, yes the H13 filter meets this spec (99.95%), and the E12 does not. If he didn't trust the Wikipedia authors, he could always follow their references to check for himself.

The question of whether H13 vs E12 actually matters is likely to depend on application and environment. Providing factual information, perhaps taking the position that the IKEA filter is "good enough" despite the review, would have been welcome. Then each reader can evaluate all those factors for themselves.

Whenever I checked his quotes from The Wirecutter, I found that WC had it right, and blogger had it wrong. I stopped reading in detail after the first two sections, then just skimmed the rest.

Wanted to bump this. It's the book I recommend when someone asks, "How can I learn networking".

My next favorite is the Top-Down book everyone above mentions. I like that it starts with loading a web page, instead of bits on a wire. And they have pcap files so you don't even need a lab.

The Stevens book is the standard text for programmers writing network code.

Beej's Guide (https://beej.us/guide/bgnet/) Is how I learned.

By the time you get here, you'll know enough to know which book to read next.

Wordpad was essentially just the Text Edit control, wrapped in some GUI cheese. Unless they plan to remove that control, it's trivial to re-constitute the program. When I took a Windows programming course, this was actually one of the homework assignments.

"Of what use is a new-born baby" Michael Faraday, asked about electricity.

There's also David Pye, and his thoughts on "useless work", and how that builds a better world. See "The Nature and Art of Workmanship".

The difference between Windows and Unix is the design of the OS. Unix famously handles "everything as a file". In Windows, everything is an "object" of some sort. This means that to be efficient in Unix, you need to be focused on files and text. But in Windows, you need to understand the OS objects, and how to work with them. Powershell excels at that. Someone ported Bash to Windows, but I'm still not sure why. It's a better shell than "CMD", but neither are well-matched to the Windows abstractions. I've never tried Powershell on Unix, but I suspect it'd suffer from the same "impedance mismatch" as Bash on Windows; it's just not designed to work on the right abstractions.