dingosity

Yes and no. You have to do the big things right before you can do the small things right. For instance, every flight I've taken on United in the past 5 years (about 10 or so) has been delayed by a mechanical or scheduling issue. Two of them were delayed to the point where I missed a connection.

I do not fly United anymore.

I my mind (and it's likely largely affected by which airports I frequently fly into) it's Delta, American and Alaska competing for my business. Even though I fly to/through DFW frequently, I try to avoid American because of how enshittified their frequent flyer program has become. How the mighty have fallen.

It is a little thing (the enshittified frequent flyer program), but it keeps me from seriously considering flying American unless there's no alternative.

So yes... small things matter (American) but only because big things have already eliminated potential service providers (United.)

I always thought we started fluoridation of water so the Soviets couldn't figure out how much uranium (and later plutonium) we were producing. UF6 is a bi-product of uranium enrichment and it's fairly straight-forward to estimate how much we're producing by taking water samples at the mouths of various rivers. But if everyone is brushing their teeth with fluoride, then it's a lot harder to accurately measure how much is due to enrichment.

This is very clearly a conspiracy theory, but water fluoridation is one of those topics that seems to attract them.

Meh. My experience working there wasn't so much that original ideas were frowned upon as much as thinking/saying you're better than your group-mates for having them was. It's a subtle difference, but I saw plenty of novel ideas take root, but only after an excruciatingly long period of socialization. In the states and in most of Europe, it seems if you have a good idea, you just blurt it out and people say "hunh. that sounds like a good idea. let's do that thing." But Japan and Sweden required A LOT of planning and hemming and hawing about whether the new idea was a good thing to do.

Though obviously, something like

    scp evil_passwd_file terminal.shop:/etc/passwd

or

    scp evil_authorized_keys terminal.shop:.ssh/authorized_keys

is really the kind of thing you don't want. But if you can't copy foo.txt into your home directory, you probably can't copy attacker versions of more sensitive files into sensitive locations.

Happy to see this didn't work

    scp foo.txt terminal.shop:.

I was worried for a second they hadn't thought of that.

meh. nevermind. it's back. guess someone pushed out an update they shouldn't have and they eventually reverted it.

Should have mentioned my desktop is a debian 12 intel system running both Firefox and Chrome. Hitting https://zillow.com/ with Lynx is somewhat hilarious -- it just gives you a 403. I wonder if my IP got blacklisted 'cause I kept hitting it with a desktop browser they don't care about (Firefox on Linux.)

Wow. I clicked on this link thinking "what more can you say about hex grids that we don't already know?" But the author(s) of this guide proved me wrong. While hex grids are fairly straight-forward, I greatly appreciate the effort taken in this deep dive.

And check out the other posts on this site. Good stuff.

Intel decided not to buy them after-all. And they're on... uh... round F? And they no longer have a SaaS multiple. They're still cranking out the designs, but their latest ML focused design doesn't (I think) support the new narrow precision data format. From the outside it looks like they're a bit distracted.

My dev environment is emacs + gcc + gdb + <insert database here> and sometimes <insert fun scripting language here like scheme, javascript, lua or tcl>. I have an EC2 instance I ssh into and as long as my network connectivity is decent it's not a bad experience.

But that's probably not what you're talking about.

Oh man. I want to love this, but SiFive sort of killed me on treating fabless semiconductor companies as SaaS plays.

FWIW. This is still the coolest thing I've seen on the web this month.

The domains just write themselves.

so... uh... you didn't register google.com fast enough and now you want to have a discussion about how it's really owned by everyone and google should be paying rent to you?

i'm actually not trying to be a snot about this, it's just the extreme version of what i view geoism applied to domain names would end up as. if you had a link to an online discussion, that would be cool. probably out of scope for this post, but still sort of interesting.

We've been having fun at the office with the are-you-fucking-high.com domain a co-worker bought. I think the initial idea was to have a bunch of different documents off that domain with humorous notes about the different ways people can be stupid at work. But yeah... it started as a joke and now no one has time to add the HTML.

WouldItBeWrongForMeToFlagThisForWastingMyTime.Com

I had a Compaq Deskpro with an 8086. Noticeably faster than that XT. I bought it used, durt cheap when everyone else was upgrading to 286s. It worked quite well for quite some time. And the AT&T 6300 used an 8086 and the Toshiba T1200 had an 80C86. 8088's were definitely more popular among the cost-conscious, but it seemed after a couple years the clone manufacturers were making 8086 based systems for about the same price as IBM XTs.

Or you could download the source, edit it yourself, recompile it and copy it to /usr/bin without affecting EVERY instance of Make currently deployed.

This seems cool and all, and I seldom critique web page design because... hey... I've developed some very crappy looking web pages. But... the designer of this page made it's width wider than a typical desktop browser window and much wider than a typical mobile phone. I turned my 10" tablet into landscape mode and it was still wider than would fit on the screen without scrolling.

I know all the cool kids are doing this, because it's only old people who care about the ease of reading things on the web. But... please... don't do stupid things like this.

That being said, it's easy enough to open dev tools and unclick the ``width: 68rem;`` clause or open it in lynx which replaces the web designer's styling stupidity with its own, more consistent styling stupidity. The content wasn't that bad.

Oh yeah. I'd agree with that. Maybe the message that should be added to the beginning of the Design Patterns book is... "Some languages support different patterns than other languages. Not all patterns will be useful in all applications or programming environments."

Someone once told me Python supported OOP, so I tried to use Smalltalk patterns with Python. It was not pretty.

Turns out Lisp has different patterns than C++. Who knew?

8 second boot times? That's only 2 seconds slower than my Commodore 64. </snark>

On the less snarky side... I'm sure it's a better system, but just because a core can run at 2.4GHz instead of 1.8Ghz, you have to take power dissipation into account. You have the same problem with overclocking: you can up the clock speed, but there's still only so much thermal energy you can remove from the packaging before you have to throttle the core to avoid melting the solder off the board or delaminating the PCB underneath the package. I'm sure the good people at Broadcom have taken this into account, I'm just commenting you can't just say "oh. it has a 33% faster clock, it's going to chunk 33% more data."

No, it's the children who are wrong.

1. I'm not the biggest fan of the Gang of Four book, but it's a reasonable place to start, especially if you're doing C++, Java or C#. But IMHO, the best way to learn design patterns is to examine code which uses one of the patterns. In the mid-90s I was working on a big Java project and one of my co-workers had boarded the design patterns train. He went out of his way to code in a way that was very obviously pattern-oriented. I did have to do some reverse work to try to figure out how particular patterns were better than other patterns or better than no pattern at all, but it absolutely made it easier for us to talk about the code.

Sadly, I think there's no substitute for "examine other people's code." Software documentation has fallen out of style as the young kids now believe every line of code they generate is a "golden pearl of wisdom, exquisitely obvious to all but the most dense. Oh? You don't understand it? You must be dense."

2. How do you know when to use a loop? Or an if...then construction? It might be hard to remember, but there was a time when you didn't know what a for() loop was. Then maybe you watched some videos or read some books and it made sense and you wrote a bunch of code with loops and then it was second nature, subsumed into the grey matter behind your eyeballs. I think the same thing happens with design patterns, but they're "bigger" than simple control structures, so you need a bit more training.

Also, don't be afraid to use only a few of them. They're supposed to help you, not make you feel like you're an idiot 'cause you haven't encountered a situation where you can use them all. They're not Pokemon. You don't have to get them all.

3. Sadly, I think it's just experience. Again. Read other people's code. Read the comments and issues to see if using the pattern made it easier or harder for other people.

Also... I was just looking at this and I think Dick Gabriel, as usual, has cogent comments to offer: http://wiki.c2.com/?PatternsAreNotTheLesserOfTwoEvils

I wouldn't be surprised. The objective of design patterns isn't just to have a list of structures in your head you can rattle off in coding interviews. It's to provide you (the coder) with a way to think about program structure and function. Think back to when you learned functional programming. You can say "oh. functional programming is about programming with functions," but that's different than the moment you understood at an intuitive level how to construct programs out of functions. And different from the time you were able to reason about the operation of programs that are constructed out of functions.

This is going to sound bad, and it's not intended as a personal attack, but... maybe software engineering isn't your jam?

Respectfully... I disagree. There absolutely are anti-patterns in code and patterns can be useful in efforts to avoid them.

I do, however, agree that "programming to pattern" can be a cringe experience if you're trying to force code into a pattern it isn't intended to hold. And you're right that the original Gang of Four book really was focused on C++ like languages.

Lisp and O-Caml DEFINITELY have patterns. Python ABSOLUTELY has patterns. JavaScript CERTAINLY has patterns. But yes, they're not exactly the same as patterns you find in C++, Java or C#.

Patterns are also useful to communicate concepts to peers. Saying something as simple as "I used an abstract factory pattern on this interface" is much simpler than explaining in detail how your constructor worked. I mean, you might want to write down some details about the constructor, but referencing a standard pattern is a quick shorthand.

I think the concept of patterns is extremely useful. The Gang of Four Design Patterns book is less useful if you're using Python than if you're using Java. But that doesn't mean its useless. And if your code doesn't fit inside a well-defined pattern, that's completely okay. There are more developers who have gone to the trouble to remember a few of the more popular design patterns than in the old days, so it might be easier to communicate your intent if you use a "standard" pattern. But again... design patterns are supposed to help you out, not tie you down. And if you're coding in Python or JavaScript, consider searching for "Design Patterns in Python" or "Design Patterns in JavaScript."

(and as an aside... when they added the "class" keyword to JavaScript, a small part of me died inside. JavaScript was designed with prototypal inheritance (like Self), not class-based inheritance (like Smalltalk.) Insisting that a "class" keyword be added to the language was like arguing for reducing the expressiveness of the language. But I digress. I mention it only to point out "I feel your pain" in issues of other people needing to impose their mental model on an unsuspecting development environment.)

But I believe patterns are useful not so much to help you code, but to help you communicate your intent to others.

Yup. ARM == "Acorn RISC Machine"

Thx for posting this. I was trying to remember where I read this a few years back. Of course it was Bret Victor. Many of the very cool things I've seen in the last decade came from Bret.

It's as if tumblr runs on other people's computers.