dragonfax

Well I'm not a physicist, but we all travel through time at the speed of light. With a much smaller speed of light, I think relativistic speeds would be much easier to achieve. I.e. you could age noticeably differently than your family on a solo car drive to get groceries.

Loved it myself. Brought a friend that grew up on Looney Tunes and he had a blast. Couldn't stop laughing the whole time.

It's pretty much constant jokes except for a few emotional bits that actually work, surprisingly.

Yeah, I found Orwell's easier to understand and quite fast to read as well, but I think it's just because of the style of writing of the first one. It's from an earlier style of prose that I'm just not used to.

I also don't have a problem with large words as long as I'm well familiar with the words. The length of a word has nothing to do with the complexity of its meaning. We just have a limit to the number of pronounceable combinations of 5 letters.

I was an early adopter of the TiVo. You can hook up a terminal to those things. A dumb terminal or terminal software on your computer using your own serial port. There was a terminal/serial port in the back (baud 2600)that took the form of a 3/4" audio plug.

It was a Linux system, but all their own software running on it was written in TCL.

I don't think they were using TK though.

Pretty fun to hack around with. Since it was connected to the phone line, when a call came in it could get the caller ID off the line and display it on the TV screen.

I know at least old Apple systems had a full Forth interpreter in their bootloader.

Just to add my favorite fool-proof method to the others already listed here.

A meat probe and the 30-second flip technique is a stupid-easy way to a perfect steak every time. Just make sure you've got great ventilation. Also salt the meat 1 hour before.

No, it's like that on desktop too.

Reminds me of word processing on DOS back in the 80s and early 90s. Pre-WYSIWYG.

Shouldn't it be called something like "Copilot Voice"?

Huh, somehow I had no idea that Obsidian wasn't open source. I guess I was fooled by the open source plugins.

Claude Code (subscription) has Agent Teams built in. Teams of Agents communicate with local files that they use as inboxes and task list. Has tmux and iTerm 2 integration. https://code.claude.com/docs/en/agent-teams

They can rack up some extra tokens if you leave agents going idle. Because they loop, checking for new messages for them.

This fellow reverse-engineered exactly how it works and then abstracted the pattern into an MCP server that any Harness/agent can use. https://github.com/cs50victor/claude-code-teams-mcp

People always warn that this setup can corrupt your stuff, which I understand you definitely wouldn't want to try to share Git via Google Drive.

Given that it's paywall, there's a good reason for that. (gift link below no longer works)

Using Claude Channels can make it easy to inject prompts and get just the response back without having to identify it in the terminal output or fight with the TUI.

But they're not well designed, and some things just have to go in through the terminal interface like slash commands (i.e. `/clear`)

The law of Software Envelopment. Jamie Zawinski in 1995 stated that "software inevitably expands to include email functionality, or it is replaced by software that does"

Clearly, that's not the case anymore. Nowadays you just swap out "email" for "LLM"

Oh my gosh, he's trying to stay awake but having a hard time so he keeps tiping over.

Nice! I'll read up on it.

As software engineers, I get the feeling we’re moving almost entirely away from code.

The backwards horse is my fault, period. I didn't read the direction.

1. Start with root to bind the port below 1024.

2. give up root because you don't need it any further.

3. Only accept non-root logins

4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.

HARD AGREE (to your disagree)

Claude Code has "plan mode" for this now. It enforces this behavior. But its still poorly documented.

Its a prequel to the novel actually. But I don't think the advertising makes that apparent enough.

Its a walking simulator for the most part. (For those that know what that means) Think of it as a journey you take part it. But there are a few choices you can make to change a bit of who dies, and a affect a slight change in the ending.

I enjoyed it thorougly. And felt it was a great representation of the retrofuturistic world the book presented, and stayed mostly in the style of that era.

I've seen UDP used for great effect in video streaming. Especially timely video streaming such as cloud gaming. When waiting a late packet is no longer useful.

Do

  Location: Santa Monica, California
  Remote: Yes (and local hybrid)
  Willing to relocate: No
  Technologies: Golang, Python, Javascript, Ruby, Java, AWS, Kubernetes, Postgres, Mysql, CI/CD, Serverless, Microservices, Scalability, Distributed Architectures
  Résumé/CV: http://resume.jason-stillwell.com/
  Email: [email protected]

Senior Software Engineer with 25 years of experience at big names like Ebay, Paypal, Twitter, and Zendesk. But also with small startups such as Wheels (micromobility) and Buildzoom. Mostly in backend and feature development roles, and more recently, cloud and infrastructure.

I too couldn't recognize him. I had to dig around the main site and verify that this is indeed the Peter Gabriel that we all know.

Abuse was mostly written in Lisp. 2d side scrolling action game from the 90s that was unusual in being commercial with a brick and mortar release but also supporting Linux. It uses keyboard for direction mouse for aiming at the same time, which was also kind of unique at the time. The code is open source, complete with modernization, but you have to dig around for it nowdays.

https://en.wikipedia.org/wiki/Abuse_(video_game)

Any external API that could reasonably take a long time to return (because of the work its doing) should have an asynchronous API. I.e. you submit the request to start the work and can later do another request to check if its complete and get any results. Rather than waiting on a live request.

Good practice for using external APIs is to NOT use any default http client settings and always provide your own timeouts to what you consider reasonable for connections and responses, as well as using a context system with deadlines so you can time out any requests that are taking more than a reasonable time to complete. Making your described surprise long expensive requests into nothing more than short errors (which hopefully you'll pick up on after a while, as long as you've got your alerting system setup right).