spc476

I've been self-hosting since 1999---first with a co-located server (perks of working at a small web hosting company) and now with a VPS. I host not only my own email and web site, but also DNS, SSH, gopher, gemini, and qotd. It's not as much work as you might think. But what works for me might not work for others.

The _MAX and _MIN, along with CHAR_BIT, was defined for C89 (the first standard for C) 37 years ago, so it was possible to choose the appropriate type. I recall using the C preprocessor to define fixed (or at least, minimum) types for needed values:

    #include <limits.h>
    #if INT_MIN == 32767 && INT_MIN >= 2147483647L
    # error too small
    #else
    # error just right
    #endif

It was C99 (27 years ago) where we got the fixed sized integers. So how do you define "relatively" here?

It's probably easier for the marketing department to get a new domain up and running that it is for a new subdomain within their own company. Battling Business Units and all that.

The two major distinctions in computer languages (in my opinion) are declarative and imperative.

For declarative, where you describe what you want, not how to get it, you have Prolog, Make and SQL (maybe others but I haven't heard of them). Yes, they technically aren't purely declarative as they usually have an escape hatch to imperative for performance reasons, but you can get quite far with them just in a declarative style.

The imperative, where you tell the computer how to do something, you have procedural (Pascal, Ada, C, BASIC, Cobol, Fortran) that's your classical programming style of actions working on data. There's object oriented (Smalltalk, Java, Erlang) which structures things a bit differently than procedural, where data is told what to do (via methods or message passing). Functional languages are more about avoiding globals and controlling side effects (and typically are lazily evaluated, but I don't think that's foundational to functional). You have concatenative (Forth, Postscript, Joy) which centers around a point-free style of programming (implicit data on the stack instead of explicit in variables) and data-flow (or array-centric) languages (APL, J, K) which work natively on array data.

Each of these paradigms have their pros and cons. Procedural if you have a lot of actions on a small set of types. Object oriented if you have a lot of types and a small set of actions. Functional if you want easy-to-reason about code. Data-flow to help with parallelism. Concatenative if you don't want to name piece of data. Declarative to have the computer figure things out for you. All of these I can see a reason to use in production.

TCC did several years ago. It could boot Linux from source in under 10 seconds. It's wasn't that big of a C compiler. It's in the 50,000 lines of code range.

Microsoft never removed it for MS-DOS. It just undocumented the calls required for this for years.

In general, yes, the linker (if there is one) would have less to do.

Position independent code (PIC) on the 6809 is pretty easy [1], but it does increase the code side a bit, but the resulting code can be placed anywhere in memory with no changes and still work. As mentioned, Motorola intended to sell a ROM with IEEE-754 floating point routines for the 6809 (as the MC6839) that was PIC. As far as I could tell, they never did sell the ROM, but they did provide it (with source) for anyone to use.

[1] Relative branches instead of absolute jumps, using the index registers to address memory, as well as addressing relative to the program counter. You can still do jump tables, but instead of a list of addresses, they're just a list of relative jump instructions. That type of thing.

I suspect the shadow registers were there to improve interrupt handling, reserve their use exclusively to an interrupt handler, and you could save time in not having to store registers in memory.

At a previous job, the team I was on [1] had a dedicated QA engineer (unofficially---he was the only QA engineer that ever worked with our team). Before we got bought, we worked closely with the QA engineer. He had access to the source repo, could compile and test our stuff, and we constantly told him of new features we were working on to give him a heads up. During this time, we were our customer's (yes, we only worked with one customer, who was paying us seven figures per month for service) favorite vendor. Over the 10 years or so of this time, we had like two regressions hit production, and those were found during deployment and we could roll back immediately.

We then got bought out and new management put in. They siloed QA and made it impossible for us to even talk to them about what we were doing. Within a year, we had one deployment fail four times in a row and went from favorite vendor to "utter trash vendor we can't get rid of." Our QA engineer quit, as well as the rest of the team (I was the last to leave). I'm still surprised they still have that customer.

[1] We were the only team having to deal with SS7. It wasn't easy hiring programmers for it, and I think at the highest head count, we had like five members (including the manager when we had one [2], but not including QA, which was "officially" never a part of our team).

[2] If it was tough hiring programmers to deal with SS7, it was even harder to hire managers to deal with programmers dealing with SS7. I think for half the time I was there (over 10 years) I had no official manager and reported to a director or higher in the company.

I went through the lists. In 1985, of the top 10 movies, you had two direct sequels, two adaptations, leaving six original movies. In 2025, of the top 10 movies, you had two direct sequels, two remakes, three franchises (maybe sequels?), one that is a part II (so sequel?, also an adaptation), one adaptation and it seems one original movie. My, how times have changed.

When in the past you learned that the recommended value for the TTL was 64 and you didn't think any operating system would pick a value much larger than that.