Notices by Federated Republic of Sean (freakazoid@retro.social)

The purpose of Docker is not, in fact, to make things easier for us as systems administrators. It's to make it easier for the folks writing and packaging software to force you to treat the software as a black box instead of making their software easier to build, configure, and use.

I don't care if you find Docker more convenient as an open source user or developer. The price of freedom is eternal vigilance, and you're being lazy.

For me, retrocomputing is at least as much about "human-scale" technology as it is about nostalgia.

"Web-scale" is all about turning humans into a commodity, and I'm tired of being a commodity.

@cwebber I think we need to be out in front instead of always chasing proprietary software on proprietary hardware. Focus on the use cases that are harder for proprietary software/hardware companies to make a business case for.

Seems like I finally have a use for the Sharp memory display & LiPo battery I got a few years back: https://github.com/MrBuddyCasino/ESP32_MP3_Decoder

Facetime seems to be the ultimate backdoor. It just keeps serving up new 0days. How many more are still in there? How many more will be added? https://www.businessinsider.com/ios-13-bug-bypass-lock-screen-view-contacts-2019-9/

What are people using these days? Contiki seems to be between versions or not very well documented. ChibiOS? FreeRTOS? Micropython looks pretty awesome and well documented, especially on the ESP32.

The resurgence of gopher and BBSes points toward a different definition of retrocomputing, one centered around text and simplicity rather than old hardware and software in particular.

For some reason I feel a need for retrocomputing to be relevant beyond just nostalgia. I think some others share this with me. Part of it may have something to do with retrocomputing dreams I occasionally have. These almost always center around sine synthesis of my dad's 5150, the Tandy 1000, the PS/2 model 80, and my first Linux box, a Pentium 200.

A DOS machine would be better for a BBS from my POV because that's what I used for BBSing. A Tandy 1000 would be ideal, but I have a 486 laptop that takes up way less space. I just need to figure out a power issue with it. Meanwhile, there's DOSbox.

In my limited retrocomputing endeavors so far I've noticed a feeling of discomfort with things that feel like "cheating". I don't mind using modern technology, but there's a notion of "purity" that ranges from using actual hardware from the era to at least technically plausible to why even bother with retrocomputing.

I feel like using a C64 as a terminal to a Linux box falls on the why even bother end of things. But my goal is to use @ajroach42 's BBS.

I just spent 30 minutes tearing my hair out trying to figure out why I couldn't connect to my APU2 box over the serial port, trying all kinds of serial settings and 2 different USB serial consoles, only to discover that the cable I was using with my null modem adapter WAS ITSELF A NULL MODEM CABLE.

Sigh.

But now it's 9600 8n1 so I can connect to it with my C64.

@codesections Sorry, the correct term is "Googley".

But now this makes me think I should be using Haskell, Racket, Clojure, or some other extremely expressive language. Not that my Python code doesn't tend toward similar levels of expressiveness. I did just write a small parser combinator library for a relatively simple parsing problem.

@codesections You make a really good point, though, not just about Go but about "readable code" generally. Google even has a "readability review" process which requires a certified readability reviewer.

But I do believe that languages should be learnable and code should be readable. Perhaps it's not so much about readability as it is about designers deliberately limiting the expressiveness of PLs to trade off elegance and conciseness for interchangeability.

@ranfdev Oops, turns out I'm wrong. I didn't realize how much Java had stagnated. Well, scratch that one off the list.

Incremental GC does have a pretty big overhead, though. Low-latency GC overhead can be up to 50%. Which is not a big deal compared to, say, Python's reference counting, but it is compared to Rust without GC. And scanning the heap uses a lot of memory bandwidth, making large heap sizes impractical.

My point is not that Go is terrible in terms of features or that some other language is in every way superior. It's that Go doesn't bring enough to the table to justify the fragmentation it has brought to open source. It would almost certainly have been unsuccessful had it come from almost any other source. I suspect most people who adopt it do so because a) Google and b) curly braces.

I don't believe Go was deliberately created as an attempt to gain a bunch of control and goodwill of community developed software, or as an attack on Python. But I do believe these goals are part of the reason Google has invested so heavily in it while attempting to deprecate Python internally.

8. Encourages highly concurrent code through goroutines but provides no isolation between them, creating a security minefield.

7. Reinvents the C runtime so that if you want to link against C code you need to have 2 runtimes, thus creating Java levels of non-interoperability.

6. Its GUI options are so bad that Electron is a popular choice for making GUIs for it.

1. Controlled by a single company whose business is surveillance and which has added surveillance "features" (for example it fetches packages from their cache by default)
2. Slower than Java and has GC pauses
3. Promotes non-free software by making distribution of binaries without source easy
4. Its devotees insist on reimplementing things that already have perfectly good implementations
5. Mostly worthless type system that doesn't prevent null pointer accesses