ataylor284_

It is definitely possible on the C64. Here's a video exploring the technique: https://www.youtube.com/watch?v=KX3rVIIaVQk.

Yup. If you call a function with the C calling convention with the incorrect number of parameters, your cleanup code still does the right thing. With the Pascal calling convention, your stack is corrupted.

As much as I love emacs, I think cut and paste is better metaphor for text editing than kill and yank. Once the key combos are part of muscle memory, the value of mnemonics goes down, but they're very useful for adoption. This is an unfortunate barrier for emacs beginners. Even though the usual CUA keystrokes are available (and even the defaults on some popular starter configurations), the terminology creates some friction when reading the docs.

I agree the semantics are strictly superior though.

There were no words for this stuff. People just made it up, and it took years for something to emerge as the de facto standard term for a collection of data persistently stored.

There's an interesting parallel with the emacs editor. Operations we now universally call "Cut" and "Paste" are "Kill" and "Yank". The better terms won out and emacs is stuck with Ctrl-K and Ctrl-Y as not-so-intuitive mnemonics for cut and paste.

One of the great things about C64 BASIC and similar MS BASIC derivatives is it's extensibility. It defines a bunch of pointers, including $0033 this article uses, that control the memory layout. Manipulating them carefully allows you to free up blocks of memory that BASIC won't trash. Or deliberately "trash" for hacks like this.

On top of that, a handful of key internal BASIC routines are called indirectly through pointers. BASIC itself is in ROM and more or less immutable, but by redirecting those pointers you can have it call out to new code in RAM.

Did some development for a server application that supported RS/6000 among other platforms. AIX on RS/6000 was a nice enough Unix but, being used to Solaris, everything seems just slightly off. I think it performed slightly worse for the same price as Sparc hardware for our purposes, but some customers wanted an all IBM solution (we also supported an OS/2 client).

The main thing that stands out was a tool (smitty?) that could do system configuration and IIRC it could show you the steps to do it manually as well.

This is exactly how I feel about Dune. The invented words and world-building are overwhelming at first, but once you absorb them it makes the narrative richer.

Two of my favorites, too, although I'd go with Anti-Fragile from Taleb.

I think Anathem is Stephenson's best. The Diamond Age is also really good. For every one of his books, I just wish he could write an ending that matches the quality of the rest.

The core of this a library called nsync. It appears most of the improvements by Justine are upstreamed into nsync itself which doesn't have any of the baggage of cosmopolitan. Whatever your opinion of the project or author, they've made good effort to not lock you in.

The writeup suggests this implementation is optimized for the not-locked case:

uses an optimistic CAS (compare and swap) immediately, so that locking happens quickly when there's no contention

I second this. OIDC is much nicer and my experience using it with federated identity sources through AWS Cognito was smooth. The sad reality is that SAML is already entrenched in many enterprise environments and unavoidable.

When I had to figure out how to add SAML authentication to a custom application, I built a barebones, no-framework Java application[1] just to understand the webflow. A good way to understand it is to just set up your own IDP like Keycloak running locally and play around with it.

[1] https://github.com/ataylor284/saml-example

More than half of Canada's coal production is metallurgical coal, suited for steel production. Most of that is mined in BC and exported. The grandparent comment and the above response are both true.

Playing cards in some parts of Europe have alternate suit symbols. Spain and Portugal use clubs, swords, coins and cups. My favorite aspect of this deck is that the clubs symbol is an actual club weapon instead of the usual clover.

You're probably right. There's a lot of code for those processors that's not going away.

Too bad though, the 6809 is the pinnacle of 8-bit CPU architecture. It's the result of analyzing the practical shortcomings of the 6800 and other CPUs and redesigning the ISA. It has 16-bit index registers and 16-bit arithmetic, addressing two of the 6502s most annoying drawbacks. Additionally, it has support for stack based locals, position independent code and a LEA instruction. All those make building a high level language compiler much easier than other 8-bits.

I own a Gakken GMC-4 microcomputer, which appears to be a remake of the FX-System. It's a fun little 4-bit computer with a hex keypad for input. For output, there's 7 LEDs, 1 7 segment digit lcd, and a speaker.

It has 16 instructions, one of which is an escape code to a further 16 built-in IO routines. It has 96 4-bit words of actual memory plus some memory mapped registers. Loads and stores can only target the data segment, the top 16 words in memory; it has one 4-bit wide index register that allows indexed access as well.

It's a fun challenge to do something interesting in that constrained environment, but since there's no non-volatile storage of any kind, you have to tediously key in (admittedly necessarily short) programs each time it's powered up.

It's been a while since I've run with that configuration, but setting the variable server-use-tcp to non-nil enables it. On startup, the server creates a file with the connection details that emacsclient can consume. I think it just works if the filesystem is shared between client and server machines but command line options allows the use of a copy on the client.

I don't run emacs in a terminal emulator. Emacs is my terminal emulator. All my terminal programs get run in a (graphical) emacs shell-mode buffer. The rare program that needs full screen control uses term-mode.

It's not the most featureful or fastest terminal emulator, but I can jump around the buffer like any other buffer and seamlessly access it along with the other content I'm editing.

On a remote computer where I can't run a graphical emacs, I either remotely edit files via tramp, or run a headless emacs server process and connect remotely with a graphical emacsclient.

You could do something like this to get dependencies almost for free:

    .depends: $(SRCS)
        $(CC) $(CFLAGS) -MM $(SRCS) -o .depends

    -include .depends

Make's killer feature was conditionally rebuilding based on changed dependencies. Back in the day, it was easy for a medium to largish software project to take many hours, or even days to fully rebuild. C and C++ were especially bad, especially "every file transitively includes every header" type projects. Make saved a lot of that pain, even if linking still sucked.

I love make and still spin up a minimalist Makefile like in the article regularly for tiny projects, but I'd hate to have to actually maintain one for a real world project.

I never used WordStar itself, but the integrated editor in Turbo Pascal used the same key bindings. I haven't used anything related in many years but I'll never forget ^kb and ^kk for marking blocks.

Posix systems, at least, allow a file's timestamps to be set with utime(2) and related system calls, but a problem with this is that utime with an arbitrary time is not permitted in all situations where writing to a file is possible. Backing up those files would either need a separate strategy or have inconsistent behavior.

Moving files to backup instead of copying is better. First, the file modification dates remain meaningful. When a backup is made, the backup file has a last modified date of when it was last changed and the new copy has the current time. It is also reversible if creating the new file fails for some reason. The backup file can moved back to the original location with a single file system operation and retains the right modification date.

It's also more robust in case of errors. Emacs can write new data to a temp file, confirm it succeeded then rename working to backup and new to working. You never have a situation where the working or backup file ends up half written.

Yeah, it's a seamless experience to run a program in shell-mode that invokes $EDITOR and it just pops into a new buffer. Edit, hit C-x #, and you're back at the shell.

This is great, but I think a detail about the Commodore 64 wrong. While the VIC-II is indeed bank switched and can only see a window of 16k, the character ROM is only mapped into 2 of 4 possible banks.

The whole thing is confusing since the CPU and VIC-II both have bank switching that operate independently. By default, the VIC sees the character ROM and the CPU doesn't. You can map the character ROM into CPU memory, and it always shows up at $D000. But the VIC-II has it's own banking configuration, which has 4 settings. The 16k VIC-II address space can see exactly one of the 4 16k blocks of RAM: CPU addresses $0000-$3FFF, $4000-$7FFF, $8000-$BFFF, or $C000-$FFFF. In config 0, the character ROM is hardwired to $1000 in the VIC address space only. Same with config 2. But if you use 1 or 3, the VIC-II sees only RAM.

This is burned into my memory, since a common trick was to set up the system as follows:

    1. Set up screen RAM at $C000 
    2. Load a custom character set (usually tiles for game graphics) to $C800-$D7FF
    3. Configure the VIC to bank 3 ($C000)
    4. Set the offset registers on the VIC for screen RAM and the charset (now in RAM)
    5. Use the RAM under the IO space and Kernal ROMS ($D800-$FFFF) for sprites

If you switch to bitmap mode and don't use sprites, you have the whole 16k from $C000-$FFFF free for bitmaps and you just need to set the VIC offset register to flip pages.

This is part of an emerging trend that's a threat to the current symbiosis between open source communities their commercial sponsors.

Many of these companies have nurtured a lot of goodwill with the community and built successful businesses around enterprise customers. Once they're entrenched in the enterprise software business, there is value to be had by cashing in that goodwill and maximizing shareholder value. Even if their current leadership is unwilling to move in this direction, there are plenty of existing enterprise computing companies (e.g. IBM) and private equity firms who will.

The 386 is the minimum viable processor for a lot of applications. 386SX class machines are the baseline for the modern x86 architecture: 32-bit internals, real MMU capabilities. It could probably handle a lot of legacy Win32, Win16 and DOS industrial apps. The heat issues could be a concern but lower power and solid state storage could still be a reliability win when replacing aging hardware.

Woz's software is fun to read if you like 6502 assembly. Wozmon and Apple II Integer BASIC are great, but my favorite is Sweet16. It's a 6502 program that implements a virtual 16-bit CPU in about 300 bytes. It's a step between the tedious 8-bit limitations of the 6502 and and a fully interpreted environment like BASIC and was part of the Apple II ROMs. Nobody really wanted a slower ML or a more difficult, faster BASIC but it's a brilliant bit of code.

Commodore had bought out MOS by this point and manufactured 6502 chips themselves, so the drive CPU was "free" in a sense.

Also it's worth noting that the Commodore DOS talked about in the article was implemented and ran entirely on the drive, not the host computer. Commodore computers only understood a simple serial protocol and DOS commands like rename, delete or format disk were just sent as text commands on the serial command channel, which were interpreted and run by drive itself.

The computers had no concept of a filesystem at all: displaying the disk directory involved a hack where the drive would construct a fake BASIC program and stream it to the computer when a special filename "$" was loaded. That's why displaying the disk directory on a Commodore computer would clobber any BASIC program in RAM. A common blunder was to list the directory before saving and losing your work.

While the disk drives were smart, the tape drives were dumb. Tape drives came first and were designed along side the computer architecture starting with the PET. The disks were an add on later once disk drives caught on as the home computer medium of choice. The computers actually had a significant amount of precious ROM space dedicated to tape drive operation which was completely wasted in the later C64 timeline when most users were using disks exclusively. Some later ROM replacements like the excellent JiffyDOS system repurposed the tape code in their ROMs to provide a built in fast loader and DOS wedge (a whole other rabbit hole).

A better comparison would be the Motif/CDE GUI that commercial Unix workstations were using at the time on workstation-class hardware. I think NeXTSTEP still wins on style, particularly since X desktops were a garish mix of raw X, Xt toolkit and Motif apps all coexisting.