don-code

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

I help organize a yearly event at the Boston Cyclorama building. The building itself hosts about 700 guests, and is designed for art exhibits to be shown on the inner side of its perimeter (the building is a huge ring, with a domed ceiling).

While I've never seen it used to present a single image, I _do_ know that it was originally built to host exactly that - a 360-degree painting commemorating the Battle of Gettysburg.

While I understand and empathize with many of the concerns here in the comments (especially given John Deere's track record in being practically hostile to end users), the promise of farming equipment that can run overnight, in the absence of light, may be a top-five disruptor to agriculture, right up there with fertilizer and engines.

In general I have a lot of respect for pre-WWW, special-purpose protocol design. I don't see it as short-sighted, so much as the world wide web having been _that_ big a paradigm shift.

That said, the date on this one is from 1997. Amazon was already selling books via the Web at that point, so I'm not totally sure what the use case is.

I find _myself_ confused by Windows, when I have to support it - I'm surprised Microsoft expects anyone without support chops to understand some of the questions they're asking.

Several of my family members are in the same boat as the author's: they run Linux in spite of having low computer aptitude. I do typically have to help them with, say, installing software, but so much of their experience happens in a Web browser that it's a rarity (the last install I helped with was Skype, the web app not being terribly great). Given that they're also somewhat change-averse, the Linux desktop has been pretty great for them: the UI metaphor of Cinnamon is more or less the same as Windows XP's or Windows 7's, which is what they were used to, and it doesn't seem at risk of changing anytime soon.

It's also interesting to step through the history on this line - it's undergone several revisions and, of course, also seen some reverts of well-intentioned features.

I am not a parent, but the criticism of the article appears to be around a misunderstanding of statistics, or at least how to apply them. While I agree that criticism is completely correct, it overlooks the human nature of the people receiving the tests. At an already-stressful point in someone's life, it seems almost like bad bedside manner for the medical community, even if in an automated fashion, to tell people that there might be a complication looming.

This _does_, however, seem like a framing issue, more than a utility issue. If the tests are 100% accurate at detecting true positives, they're a great aid. But rather than framing the tests as a be-all, end-all source for information, why not frame them as "a test that suggests whether or not you should get other tests"? That simple wording change would save a great deal of added stress on someone starting or growing a family.

I'm looking to recover from two years of pandemic-induced silence.

In the years prior, I was a pretty active member of several communities, to the point where I could be attending several a week. Many of these have disbanded entirely; some briefly moved online before collapsing due to lack of involvement. I haven't given a meetup or conference talk since early 2020.

There are other, larger communities that have managed to stay afloat (disclaimer: I help organize one of them, DevOpsDays Boston), but their barriers to entry are much higher - formal CFPs and vetting versus Slack pings to meetup organizers. So my plan is to realize that's not an excuse, and act accordingly.

Having unified my work and homelab environments on RHEL/CentOS for north of ten years, I took the opportunity to try out some new options.

We've begun the process of switching out from CentOS to Amazon Linux at work, and the jump actually hasn't been difficult - the tooling is largely the same, boot times are vastly improved (I don't really know what Amazon does under the hood to their Linux distro, but it does show), and with minor changes to some Ansible bootstrap code, we're up and running. Besides, most everything is containers nowadays.

My homelab has come full circle - it started out on Debian back in the 2000s (it was the only distro left with a floppy installer, and I had a few Pentium-class laptops). These days it's a shelf full of single-board computers, and I've found the support for Debian types like Raspbian/Armbian to be _much_ improved over CentOS, whose ARM32 special interest group was but a handful of people volunteering their spare time.

What have others been migrating to?

My parents thought this as well, but it turns out their new gas stove has a safety feature which prevents this. If there's no electricity, a solenoid doesn't engage when you turn the knob, which in turn doesn't allow any gas through to the range.

I'm assuming any modern gas water heater is in a similar boat, with an electric starter instead of a pilot light - and it's much more difficult/annoying to light a water heater than a stove with a match.

I know this is a difficult question to ask, but have you considered taking some of those responsibilities on yourself? It may be more sustainable, long term: computers are always changing, and computers are always taking more responsibilities on themselves (I just bought my parents a robot vacuum that you start and stop through your phone, for instance). You may be much better equipped to respond to those changes than they are, even with your help.

I used Kodi in its very early days as Xbox Media Center. XBMC turned the original-generation Xbox into a cheap and very functional media center PC - I actually didn't stop using mine until I upgraded to HD in the early 2010s.

More recently, I've been running it on a Raspberry Pi 3A in my kitchen. It interacts with my DVR upstairs, so that I can pause TV there and pick it up downstairs. I credit the fact that it was originally designed to run on the Xbox as the reason it works as well as it does on even the original Raspberry Pi.

I actually have quite the opposite feeling for my 35-year-old car - I've tried to keep it as stock as possible. It's still got the period-accurate radar detector (police probably use bands outside of what it can pick up), tape deck (I've never once played a tape in it), _car phone_ (AMPS was dead before I bought the car)... But I get a sense of enjoyment out of keeping it the way it was originally intended.

That said, I have had to make some concessions to the future. It was next to impossible to find stock lamps - they're just inches off the ground, and not made of laminated glass. They'll shatter easily due to road debris. I can buy old, foggy replacements for $200. But I actually ended up buying one-off plastic lamps for $30. At least this way, they'll not only look better, but last longer.

Something I've not seen done, but to me seems like it would be much more useful than a shell script (or maybe would have, in these tools' heyday), would have been to use a tool like Chef or Ansible to manage dev dependencies on developer laptops.

The trouble with shell scripts is that they generally require you to manage the state of the machine - whether or not something is installed, before I go install and configure it. Or, if it's already configured, what configs to leave in place, and what configs to reset.

With Chef, for instance, everything's declarative. I don't say "install this package"; rather, I say "this package should be installed". Nobody ever runs the setup script just once, since the dev environment is constantly changing, and all of those edge cases (maybe I last ran it on rev 3, or rev 7 - how do I get to rev 12?) become hard to manage.

Older Craftsman tools.

I naively bought some of my own Craftsman tools at Sears back in the 2000s - many of which are cheaply made with plastic bodies, or non-durable bits. Basically every Torx screwdriver I bought there is now stripped. The cases are plastic, and use friction to keep tools in place - not that they stay in place anymore.

Contrast that with the '60s or '70s tools with the lifetime warranties (that I inherited from my grandfather, by way of my father having his own set already), which show age only in the "vintage" look. They're just as functional as I assume they were on day one. Everything's made of either steel, lacquered wood, or in rare cases, heavy-feeling plastic.

I actually cut my sysadmin teeth on Windows 2000, and found myself wondering how on earth they could `docker exec` a shell. These were, comparatively, the dark ages of Windows administration, and almost all tasks were done through a GUI.

The implementation is nothing short of genius: they use a Windows version of `netcat` (the common UNIX tool, but compiled for Windows from the Windows 2000 Resource Kit), then use `srvany` (also from the Windows 2000 Resource Kit) to start `netcat` as a system service, but with `cmd.exe` piped to its standard in and out.

Kudos on this solution!

Are there any industries where documenting failure is incentivized? I could easily name a whole litany of things I've tried that didn't work (most recently: trying to use AWS security groups as a bad-actor mitigation technique), but when it's time-consuming enough to give a talk or blog about what I've had succeed, I can't imagine doing either about how I've failed.

These tricks are things that you could still pull off today. The difference is, outside of competitions or the demoscene, nobody _needs_ to pull them off - it greatly decreases your time-to-market to do things in a straightforward way, rather than a novel way. That wasn't true 20+ years ago - the straightforward way often brought you up against hardware limitations.

It might not have been economically viable. The pace of obsolescence at that point in time was so fast that it might have been cheaper, over the course of two or three years, to just buy a whole new system than to retrofit a Pentium to a 386 mainboard.

Consider what else happened in the 386 through Pentium transition:

* The PCI bus became standard; your peripheral cards all needed to change.

* SDRAM became standard; the memory bus became significantly wider / faster, and you bottlenecked on RAM if you used older mainboards.

* IDE, while it was already used for hard drives, was now used for your CD drive too - you probably wanted a CD drive and not a second floppy drive (different controller) in your machine, which was harder if you only had a primary IDE bus.

> How many hundreds or thousands of enthusiasts are needed before it's suitable to be a daily driver?

I know your question was rhetorical, but when I think about this, it took close to 20 years of Linux maturing on the desktop before I felt comfortable handing a family member a laptop running Linux. As an enthusiast, I started running it much earlier, but everyday tasks like "printing" or "using Wi-Fi" prevented it from being a daily driver.

Personal computing, though, had a much deeper hacker culture, that encouraged pushing the hardware to its limits, and doing new and novel things with it. Progress stemmed from that (Windows including BSD sockets, for instance). I've never seen anything similar in the phone ecosystem - as soon as you play outside of the walled garden, you drop off into fringe territory. And the PinePhone, as much as I love it, is by definition outside of the walled garden.

I'm not sure, given the culture around phones, we might ever get to the point of it being viable.

I'm impressed with how much foresight this high schooler had in preparing for the prank. My impression is that most high school age kids would out themselves within the first few weeks of planning due to wanting to boast, here they instead took to testing covertly, overnight.

I'm actually quite thrilled that end users found a way to communicate in spite of "the everyday solution" being down. That gives me some hope that smaller vendors do stand a chance against incumbents, even in Facebook's space.

While I generally agree with the author that the userland monoculture isn't helpful for portability, that argument belies the fact that most people I've worked with _want_ those extra features that GNU gives them. I started using Linux and IRIX around the same time - but I actually didn't really "understand" the difference, because someone had gone out of their way to install the GNU userland.

That's something the article leaves out: while GNU and Linux are many times seen as a unit, there's a rich history of installing the GNU tools on other Unixes, because of the extra functionality they offer.

There is, of course, the argument against portability. At my last job, as the only Linux user on my team, I more than once wrote shell scripts that only worked for me - as soon as someone on macOS ran them, they'd run into a missing feature on `sed`, or a different calling convention on `date`. Which is why, at my current job, I'm very begrudgingly a macOS user - it makes me a better coworker.

I highly recommend Andy Jassy's infrastructure keynote from re:Invent 2020. Among many other things, he discusses why Amazon never gives you a single hyperthread (it's mostly about cache coherency, IIRC).

This is one of the most underappreciated features of Unix's interoperability. Back in college, I carried around a wimpy tablet PC running Linux, but "ran" most of my applications on some random Solaris box in a lab.

This was invaluable to me, because otherwise I'd have had to fork out money I didn't have for MATLAB and the like - or sit in the lab all day, like everyone else.

That seems accurate. I have a mulberry tree (quite tall!), and if I don't pick mulberries every morning during its 4-week fruiting time, I just end up with purple poo all over my yard instead.

While I do appreciate the humor here, it's a personal gripe that conversations on Slack tend to optimize towards speed of responses - and when taken to an extreme, they take the form of:

> This message

> is

> sent over a few lines

(awkward pause)

> so that

> I can get in a point

> before you start typing something

Asynchronous means of communication (Github PRs, Jira tickets, dare I say e-mails) mean that I submit a fully-formed thought as a digest, but Slack sometimes becomes a stream of consciousness - one that I have trouble breaking someone out of.

In a way, it is - I take on an operational overhead of rebuilding an upstream tool, periodically merging my changes with master and rebuilding, etc.

This isn't something I budgeted time for, or something I even roadmapped for, which means the build process is going to be a 30-minute kludge and will likely incur greater-than-normal ongoing overhead.

I remember seeing this in practice at a meetup - I believe it was at the Boston AWS meetup at Vistaprint several years ago. Someone was running FORTRAN web services as CGI applications, inside of nginx, inside of a container, running on top of Docker Swarm. Say what you will - it seems pretty practical.

The Visor was a neat device on account of the Springboard slot. There was an attachment, the VisorPhone, which turned the Visor into what you'd easily recognize today as a smartphone. To boot, PalmOS on the Visor had a working TCP stack, so you could dial out (literally dial out - there wasn't even GPRS on it!) and send/receive e-mail, browse the Web, and so on.