don-code

You may enjoy reading Neal Stephenson's _Anathem_.

In addition to just loading and querying data, spreadsheets are great as database mocks in integration tests. I long ago used XLSQL (note: there is a new XLSQL project unrelated to this one) to mock an Oracle database: https://sourceforge.net/projects/xlsql/.

It might be overkill, but you could run https://zoneminder.com/ in unauthenticated mode, with a single webcam as an input. It'd at least give you a nice Web interface, as opposed to some other solutions which use raw streams over HTTP/RTSP that aren't approachable in a Web browser.

> Imagine if mass-storage devices were cheap enough that you could afford 307 gigabytes for a single movie. Your hardware would still have to support a sustained data rate of 1 Mbyte per second to play it back.

I recently bought a $20 flash drive to store the entire contents of a my friend's late-2000s PC with a 250GB hard drive on. Didn't think much of it.

(Yes, I know the article is from 1994.)

There's an awkward, intermediate step, sort of like what we had with 1G cellular: while the signalling was all digital (but not IP), the actual voice payload was carried on a dynamically-provisioned analog channel.

We had Merlins at my parents' store when I was growing up, and an interesting artifact of the analog channel was that some analog data was possible. For instance, we hung a fax off one of the Merlins (14.4k was fine); I likewise got get 33.6k off it when I plugged in my modem, but could never get 56k. In hindsight, that's because 56k actually requires the line to support digital signalling, which the Merlin did not.

One of my engineering professors still has a Web 1.0 site, "best viewed in Netscape Communicator 4.0 or higher at 16 or 24-bit color". It's actively updated, but hasn't fundamentally changed since the late 90s - some pages still have the Netscape Composer generator tags in them. (For further frame of reference: I last had a reason to go to it over ten years ago now, but still bring it up as a talking piece.

https://people.rit.edu/meseec/

As a Bostonian myself, I'm getting used to the idea that we're the exception, rather than the rule. I typically _do_ see these things when I travel within the country. But I'm increasingly seeing it as a "Boston success" rather than a "San Francisco problem" or "Austin problem" or "Seattle problem", because it seems more like a default state, given the current way of things.

That said, I'm not sure what to attribute that to. It could be the broad availability of drug rehab and housing services. It could be that the climate is inhospitable to living on the street for the majority of the year. For all I know, it could be an aftershock of the city's love affair with redlining, effectively putting me away from where I would see it.

I recently had an opportunity to build an application on top of Lambda@Edge (AWS's equivalent of Cloudflare workers). The prevailing wisdom there was to make use of regional services, like S3 and DynamoDB, from the edge. That, of course, makes my edge application depend on calls to a larger, further away point of presence.

While it's possible to distribute state to many AWS regions and select the closest one, I ended up going a different route: packaging state alongside the application. Most of the application's state was read-only, so I ended up packaging the application state up as JSON alongside the deployment bundle. At startup, it'd then statically read the JSON into memory - this performance penalty only happens at startup, and as long as the Lambda functions are being called often (in our case they are), requests are as fast as a memory read.

When the state does need to get updated, I just redeploy the application with the new state.

That strategy obviously won't work if you need "fast" turnaround on your state being in sync at all points of presence, or if users can update that state as part of your application's workflow.

I'm curious if you've ultimately found your mentor's behavior to be a net positive, or net negative, in your career.

One of the engineers under me often expresses his discontent that I won't give him answers, either. I think he's more than able to get to those answers on his own, and that the value he'll derive from learning how to learn is vastly greater than the value of being able to complete his work faster. On the other hand, he's given me the feedback that the method is excessively socratic at best, and flat-out frustrating at worst.

The hedonic treadmill is at work here. I recently cut caffeine entirely, and while the initial few weeks were awful, I don't feel now that I'm at any significant disadvantage with regards to where I started.

I also worked for a company where energy drinks and coffee became part of my diet, then left of my own volition. Then I left, and they're still doing just fine in spite of none of my team hitting caffeine anywhere near as heavily, so I assume the feeling that I'd get fired or somehow disciplined is/was all in my head.

I had an experience a few years ago, retrieving old data from SyQuest drives. I was unsuccessful getting even a single bit recovered: several drives and several disks ultimately produced zero overlap in readability.

I'm impressed - but not necessarily surprised - by the amount of inline guidance that the system gave. These systems must have been cumbersome to wrap one's head around, more so when there was little precedent for using them. The designers, who likely were quite technical for their time, took those extra steps to understand the frames of reference of the users, and explain the system from that frame.

Contrast to today, where user interfaces have largely lost the discoverability principle, and help is often asking someone else who's ridden the wave to where we are today.

Mail self-hoster here. There's an additional wrinkle, which luckily you may never encounter in the public cloud space: in addition to typically being unable to _send_ mail from residential Internet connections, it's many times also not possible to _receive_ mail on a residential Internet connection.

On the outbound side, many accepters of mail will deny mail from SMTP servers on a residential IP address, as provided by the Spamhaus Policy Block List (https://www.spamhaus.org/pbl/) or equivalent. Unfortunately, there's not much one can do to get off this list - ISPs self-publish their own residential IP space onto it. In order to self-host from home, business-class service or higher is in order. Or, again, use the public cloud, and hope your compute instance's IP isn't on some other block list.

On the inbound side, though, many ISPs block inbound port 25. Since that's the agreed-upon port for mail receipt, there's no real way around this. Several times while I self-hosted off residential, I was able to call Comcast support and ask for the ban to be lifted, but not before fighting through several layers of level one support asking me to configure my mail client differently. The real kicker, though, is any time my modem was rebooted (I owned my modem, too!), I had to call in and request it _again_. My (very small local) ISP in upstate New York also performed this blocking, but _would not_, in the face of any complaining, lift the block.

I was convinced that I was looking at a legitimate error message from IIS until I read it.

There's a running joke about the Indy that it's the Indigo (its much-more-expensive brother) without the "go".

Minimodem is a similar piece of software, but much more flexible. Depending on the quality of your link, you can adjust the symbol rate, as well as the frequencies to signal 1's and 0's.

Still (as said before) not more useful to me than as a weekend project. I used it a few times with my CB radios to see how far I could transmit 1200 and 300 baud.

I am not a parent, but this seems like a good practice to get a child in the habit of, anyway: separating out your devices for work and school. Much like I wouldn't log into personal Slack groups on my work laptop (I learned that lesson!), I wouldn't try to conduct personal work on a school laptop.

Basic debugging knowledge is helpful, but I've found the ability to think about distributed, networked systems all the way down at the system level to be extremely helpful. We all encounter systems that are ill-documented, or complete black boxes, but peering at them with tools like `strace` / `jstack` (when a service is doing something itself with data) and `tcpdump` (when a service is asking another service to do something) opens up all sorts of possibilities.

Yes, distributed tracing tools do a much better job of this, but it's not always a given that a service will be instrumented. The generic tools (almost) always work.

While I've successfully used this method for public APIs, I ran into an interesting one not long ago: where authentication is performed _by IP address_.

I have a switch (I think a TP-Link TL-SG1016PE) with PoE - and a finnicky PoE device that periodically needs a reboot, so I figured I'd replay turning the port on and off in the Web interface. Notably, logging in does not issue me any authentication token, but I can still turn the port on and off - and can still do it via `curl`, too. But as soon as I try it on another machine? Access denied!

(Yes, I could just fake the login process the same way, but that was more work than I had time for.)

I have a "neat trick" of putting a blanket over myself such that my hands and laptop keyboard are both underneath, but the screen is sticking out. Then I run a cryptominer to generate some heat. Inside of five minutes, I'm pretty warm!

We've definitely found use cases for higher-width buses, but seemingly less so for operating on 128-bit integers and pointers, like this article is describing.

Take for instance VLIW architectures (Itanium used 64-bit registers but 128-bit instructions; you packed two ops into an instruction), vector extensions (AVX-512 uses 512-bit registers to hold multiple integers from 16 to 64 bits long) - we've long known these to be viable strategies for long word lengths in a CPU. But the ability to operate on a 128-bit integer directly doesn't seem to have a use case yet.

I have a hard time calling these "upgrades". I had a TI-83 (not Plus) in high school - the Plus gave us ROM, the TI-84 gave us USB, and the TI-84 CE gave us a color screen, which are all creature comforts at best. It's on par with what we'd think of "upgrades" circa Apple II -> Apple IIe.

I _would_ call moving from a TI-83 to the TI nSpire CAS an upgrade - there's a whole host of things that the nSpire can do which the TI-83 can't, like symbolic calculations and matrix math with complex values. I'd also bet it can emulate a TI-84 faster than a native TI-84.

> or if you `unset HIST_FILE`

I figured I'd learn something by putting in the "I'd love to know others" bit, but this is something I didn't know I could do, and is genuinely useful to know!

I had a similar chance meeting on Craigslist in 2012 - I bought an SSD off someone who I'd been contemporary with on some Netscape/Mozilla forums in the early 2000s. This was before Craigslist implemented e-mail address obfuscation (don't get me wrong, this was a good thing), and he recognized me only by my domain name.

For reasons like this, I almost wish software came with a "list of unexpected side-effects of using this software".

Take bash, for instance - each time you run a command (this list is nonexhaustive; I'd love to know others):

1. If you have a `PROMPT_COMMAND`, it'll be run.

2. The command will be echoed to your history file.

3. If you hit <TAB>, arbitrary functions might run (for completion).

I don't know what zsh may do on top of this, but my guess is that it's significantly more than bash. That's not a demerit to zsh - that's exactly what it should do - but visibility would be nice.

While I get and agree with the spirit of the answer, there's one major piece I take issue with:

> Well, what kinds of people work for 1% of a post-A startup? Average people (and below).

The people hired in the A round have no doubt been selected, _and_ self-selected a startup, for their ability to work at the mentioned 20x force multiplier. A 100-person company (let's call that late series B) is running, using the article's own numbers, at a 2-4x force multiplier, and a C-or-later startup with 200 or more people is running at perhaps even a 1.5x force multiplier.

Yes, there will be individuals who bring the force multiplier up, and individuals who bring the force multiplier down, but ultimately, the people in the organization are _above_ average if the organization's force multiplier is greater than one.

Also considering that founding engineers are sometimes some of the first to leave (especially as non-startup culture becomes entrenched), we can't as easily argue that the original 20x engineers are carrying the (0<n<1)x engineers.

Having tried Kubernetes on Raspberry Pi's once (my homelab is all SBCs, not all Pis but all ARM), there are two major pitfalls:

1. K3s may not be too heavy, but basically anything that runs on it is. For all but the most basic jobs, I was still looking at one, or maybe two, apps per SBC. Couple with 10/100 networking on many of these, and there's a lot of extra time/latency spent just on chattering across the network.

2. It's relatively rare that you're using _just_ the SBC - more likely is that you have some peripherals, or some local storage. That limits where your pods can schedule, but because of #1, you still end up with dedicated nodes for dedicated functions.

I ended up pulling the plug on that project early, and went back to scheduling workloads manually. For instance, I have Transmission and Squid running on the Pi with the big flash drive. InfluxDB and Grafana live side by side, and also live next to the SDR (I take in some metrics by radio). It's all still containerized, just with manual `docker run`'s and versioned config files, instead of with Kubernetes.

One of the benefits of CI is that I don't need to make assumptions about the environment I'm operating in - that is, I don't need to worry about a tool like `jq` being installed, whether I have GNU or BSD `date`, or the biggest one in this case, whether I've even installed a commit hook after cloning the repo. It only takes one new hire that hasn't set up the hooks to merge a change that makes the repo fail checks.

I still have a tablet PC from 2005 in rotation, and the lack of 32-bit apps is definitely a killer, but not terrible.

My original reason for reviving it was for use as a whiteboard in Zoom calls, but there's no 32-bit Zoom app - and I'm sure screen sharing while decoding 15 people's video would've been out of the question anyway. So I run a VNC server on it, and share out a VNC session from my work laptop instead.

I've also hit the issue where I've had to compile software for x86 using modern build toolchains. It takes forever, and more often than not, I run out of RAM (only 1GB). To get myself out of a pinch, I've mounted a 16GB USB 2.0 flash drive as swap space. Sure, it makes compiling even the most basic software a multi-hour process, but where this machine isn't my daily driver, it's still easier (to me, at least) than cross-compiling.

It is indeed DevOpsDays, and likewise, our move there from the Park Plaza was the first I'd heard of the term either.