xenophonf

Regarding that VT220, I misremembered. My dad's workplace loaned him a 1200-baud modem and a C. Itoh terminal, maybe a CIT-101 because [this picture](https://terminals-wiki.org/wiki/index.php/File:C._Itoh_CIT-1...) matches my memory. He was a software engineer and occasionally worked from home.

We also has a Wyse 50 terminal. It's how we used the IMS 5000SX, which had both a 10-MB hard disk drive (I think it was called a Winchester) and a 5.25" floppy disk drive. I have a huge stash of 5.25-inch floppy diskettes from back then, including copies of TurboDOS (for the 5000SX) and Apple II games and little BASIC programs us kids wrote, but I've all but given up on recovering anything. The IMS 5000SX and the Wyse 50 terminal are long dead and buried. I've made some half-hearted attempts to boot TurboDOS up under simh, but it isn't the same. If they aren't all corrupt, I suspect my Apple diskettes have a virus of some kind on them, too.

Around 1991-1992, I helped a dentist install an electronic medical record system using a multi-user DOS variant called PC-MOS. We connected Link MC5 terminals via serial to a 386 running SoftDent, if I'm remembering it correctly. I got one of MC5s when that system was decommissioned. Unfortunately, I lost it in a house fire. Then, a few years later, I got another of the MC5s when the dentist was doing some housecleaning. I still have that one, and I'd use it more often if there wasn't something wonky with its serial interface's flow control that causes corrupted I/O.

Stories like these make me want to give modernizing vtrek another try. I'd originally played it on my cousin's 3B2 in the late 1980s after being introduced to the CP/M port of classic trek, which I played on my family's IMS 5000SX. (Oh, how I wished at the time that we'd gotten an Apple II! But that's a story for another time.) I have distinct memories of playing vtrek on my dad's VT220, dialed into my cousin's BBS over Tymenet at 1200 baud. Whereas classic trek, having been written in the era of the ASR-33, was line-oriented like a text adventure, vtrek was a full-screen interactive terminal app, like vi. You'd issue movement commands using the 3x3 block of keys of the left side of the keyboard—Q, W, E, etc. Other keys controlled the ship's scanners, shields, weapons, and warp drive. Those inputs drove the game's event loop and updated the display accordingly. It was great fun, especially for a video game starved kid like me. I was forever pestering friends and cousins to play on their Ataris or Nintendos or Apples or Tandys. I didn't get my hands on a proper gaming computer until the early 90s, when we replaced the 5000SX with a 386.

So I'm sure you can imagine my excitement when I stumbled across an archive containing XENIX ports of a bunch of Unix games, including vtrek. (Thank you, Vince!) I'm not even sure how I managed to find that. Nowadays, Google only returns two search results for vtrek, the XENIX game port archive and a munged version of the original release to net.sources.games, and that's only if you know to include the "duncel" insult the game uses in the search terms. Google Groups searches of net.sources.games will lead you to a series of posts from the fall of 1985, but how would anyone other than an old fuddy duddy like me even know to look there? (Also, Google Groups doesn't have the original Usenet posts, so formatting is all screwed up. It's a vexing problem for the modern programmer archeologist.) Now imagine, if you will, an eager and not inexperienced nerd trying to compile a System V-era game on Linux and FreeBSD circa 2005. This Star Trek quote seems appropriate:

PAIN!

I mean, even the Real Hackers back in 1985 had problems getting it to compile, so I don't know why I thought my experience would be anything other than worse. The termios code in glibc just didn't work. At all. Neither did the sgtty code, which had been broken since at least 4.4BSD. After a good long while beating my head against vtrek, even going so far as to trying to build it on OpenStep 4.2 (from 1997) and FreeBSD 2.0 (from 1994), I gave up. Maybe it's time to give it another go for nostalgia's sake.

The 1985 release per Google Groups:

https://groups.google.com/g/net.sources.games/search?q=vtrek

For an example of how Google Groups screws up posts, here's a patch to vtrek:

https://usenet.trashworldnews.com/?thread=241631

And here's Google's version:

https://groups.google.com/g/net.sources.games/c/Rx_u0q5V5iE/...

The XENIX port (thanks again, Vince!):

https://svn.so-much-stuff.com/svn/trunk/cvs/trunk/games.d/vt...

Hints at how I might get vtrek to work:

https://comp.unix.programmer.narkive.com/KP4z3Ge2/problem-wi...

God bless Thomas Dickey, who's been maintaining vttest this whole time!

https://invisible-island.net/vttest/

Firefox profiles suck. Their UX is so bad. Containers are better but still have their issues. I use Containerise plus Cookie AutoDelete plus Temporary Containers to give me what is effectively per-tab private browsing. The major downside is that I have to copy containers.json (which enumerates all of the dedicated containers I have defined, e.g., for Facebook), my Containerise rules (which automatically puts certain web sites into specific containers), and my Cookie AutoDelete config (which says which cookies to delete and when) among browsers manually. I wish more things supported Firefox's sync feature. I ended up adding them to my dotfiles, so it isn't too painful, but it definitely isn't grandparent friendly.

You can reproduce the release just fine using the lock file published alongside the release. Checking it in creates unnecessary work for devs, who should only be specifying version constraints when absolutely necessary.

The lock file shouldn't be in the repository. That forces the developers into maintenance that's more properly the responsibility of the CI/CD pipeline. Instead, the lock file should be published with the other build artifacts—the sdist and wheel(s) in Python's case. And it should be optional so that people who know what they're doing can risk breaking things by installing newer versions of locked dependencies should the need arise.

> While internal modules and libraries should be kept as generic as possible, external-facing components, on the other hand, are a good place to put business-specific domain logic. External-facing components here refer not only to views but also to any kind of externally-triggered handlers including external API endpoints (e.g. HTTP/REST API handlers).

That goes against every bit of advice and training I've ever gotten, not to mention my experience designing, testing, and implementing APIs. Business logic belongs in the data model because of course the rules for doing things go with the things they operate on. API endpoints should limit themselves to access control, serialization, and validation/deserialization. Business logic in the endpoint handler—or worse, in the user interface—mixes up concerns in ways that are difficult to validate and maintain.

I haven't been able to get useful prototypes out of LLMs, for that matter.

> Great for prototyping

I must be Doing It Wrong(TM), because my experience has been pretty negative overall. Is there like a FAQ or a HOWTO or hell even a MAKE.MONEY.FAST floating around that might clue me in?

In the cases of the adults stuck inside the cars, aren't there mechanical unlocking handles inside Teslas?

Republicans have made deep cuts to---or have even completely eliminated---federal safety investigators and regulators, including the CSB.

From the channel description:

With fewer than 50 employees and an annual budget of just $14.4 million, the U.S. Chemical Safety Board (CSB) plays a critical role in driving chemical safety excellence in the United States. Over its 27-year history, the CSB has investigated nearly 180 major chemical incidents that have resulted in more than 200 fatalities, over 1,300 serious injuries, and billions of dollars in damage to property and the environment, including damage to chemical facilities and nearby homes and businesses. The incidents have harmed communities and caused significant business disruptions, including job losses and reduced earnings for the American chemical industry.

The CSB has shared lessons learned from those tragedies through the agency’s many investigation reports, recommendations, and safety videos. In response to the incidents investigated by the CSB, the agency has issued over 1000 recommendations to make the chemical industry safer, while maintaining economic productivity, protecting jobs, and keeping workers and communities safe. The CSB’s work has resulted in significant safety improvements at facilities throughout the country across a wide variety of industries.

If the CSB’s many safety lessons have prevented at least one catastrophic chemical incident, the money saved by protecting lives, preventing serious injuries and damage to facilities, safeguarding surrounding communities, and avoiding costly litigation and legal settlements far exceeds the CSB’s modest annual budget. The CSB more than pays for itself in costs saved by preventing serious chemical incidents.

> getting several thousand emails per day can only mean they are victim of a spam attack

I think of calling my representative as being like proof of work. It takes a modicum of effort to look up their phone number, compose some spiel, and make the call, compared to delivering spam by the truckload.

From the article:

> Sales track—or simply track, in industry parlance—is an invisible force shaping contemporary literature. Much depends on that number. On the basis of track, published authors struggle to keep going; those just starting out fear their careers will be severed at the root. Track shapes how an agent pitches a book and how editors assess whether to buy it. Track restricts reader choice by dictating which books are served up as the next big thing (and the next, and the next) and by kneecapping writers deemed insufficiently commercial. The primacy of track, in other words, is a barometer for the health of literary culture. Right now, when the industry is especially skittish, the obsession with finding the next blockbuster hit privileges the survival of the few at the expense of the many.

NixOS looks super cool, but it also looks too much like actual work. As a FreeBSD main for two decades, I've played that game already and have the (sadly, now long dead) tinderbox and poudriere installations to prove it.

I'm not sure and don't have the patience to check.

I might go back to Debian. I'm only really using Ubuntu since that and RHEL are what we use at work.

It's bad everywhere. Every time I've upgraded Ubuntu on my old laptop, performance gets worse and worse because more and more junk keeps getting added. Absolutely maddening.

Gygax was an awful misogynist.

https://www.enworld.org/threads/d-d-historian-benn-riggs-on-...

I've long been a ZFS stan, but I am slowing coming around to the idea that I probably won't be able to continue using it at even the small scales I have planned. It's a damned shame.

I'm really mad at Half Brick for killing classic Fruit Ninja. I actually spent money on that game and on Jetpack Joyride, only to lose both sets of purchases. They suck.

I hereby declare August 28 as Leech Day. Everybody save up your favorite weird HN posts for the year, and we'll compile them in an annual celebration of all the nerdsniping that goes on here.

It doesn't prevent altering the data before it gets published, though. Garbage in, garbage out.

https://thehill.com/homenews/administration/5432523-trump-fi...

> I have recently jumped onto the "write python tooling in rust" bandwagon

I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment management, including CI/CD pipeline maintenance, that much more complicated. It was already bad enough when I was trying to compile binary distributions on Windows, and that was just with the Visual C++ toolchain mess that is the Microsoft development experience.

It's a classic Usenet post that deserves linking at every opportunity!

https://harmful.cat-v.org/software/csh

I don't know why you're being downvoted. You're correct, and as the other commenter mentioned, csh programming is evil in the eyes of the LORD. Starting last year, I've been maintaining a bash profile that implements (mostly) the same setup as my tcsh configuration. I suppose I ought to make the final leap into something more modern. It would be nice not to jump through hoops to redirect stderr somewhere different than stdout or [insert your favorite of the myriad examples of csh/tcsh weirdness here]! But I feel irrationally sad about it. I cut my teeth on Unix systems where csh was the default shell—namely, NeXTstep and sunOS 4—and it feels a little like saying the final goodbyes to a dead friend. Silly of me, I realize, but there it is.

That's exactly how I justified our 88-character code line length limit to a colleague. I split my screen into quarters and showed them how that let me keep useful context visible without having to break my focus by switching tabs/windows.

The "no possibility of bikeshedding" thing is critical. I like things formatted the way I format them, but the thought of having to specify and then justify and worse enforce each and every little decision just completely saps any desire I have to do any of it. Black (and isort) are huge productivity boosters. Run and done. Plus, relying on shared tools like that instead of whatever the editor does means I can hang on to Emacs for that much longer while letting other folks use whatever garbage editor they want.

That's right.

https://www.merriam-webster.com/dictionary/to%20wit

It's obviously machine-generated from the linked source materials, and while I'm grateful for the bibliography, I wish I didn't have to click through a million pages to get from the blogspam to the actual content.

I wish tcsh would get more love.

That's only a problem for exhibitors who value money over the inherent humanity of their exhibits.

I'm amused by the idea of donating my body to science, especially to medical colleges for teaching purposes, but I would want to make some kind of connection with that future. I would want people to at least know my name, see my face, have some idea that I am a person, that I want them to use what's left of me to go out and do some good in the world with it.

We're all just made out of meat, but that shouldn't dehumanize us. On the contrary. And running roughshod over human rights to put on a show does not treat its subjects humanely. Worse, that harms the audience, who gets inured to that inhumanity.

What is Copilot Chat but a front end to some Microsoft SaaS offering? There's nothing materially "open source" about that. All the important stuff is locked up behind the GitHub Copilot API. No one can customize the LLM design or training material. It certainly can't be self-hosted. This is just in-app advertising for yet another subscription service that sends your personal data to an amoral third party. There's no community, no public benefit, no commonwealth.