sly010

> The goal of programming is not to write code (however much I enjoy that part), it is to solve problems.

Right, which is exactly why autocomplete is not a huge help.

FWIW ink is not expensive, but traditionally the nozzles and electronics and the printhead are all bundled with the cartridge, making it expensive. The big companies now offer inkjet printers with ink and print head separate (eg Canon pixma) and for those printers the ink (in a literal bottle) is priced much more reasonably.

There are other issues of course, I am not trying to give them slack here. If you don't use self cleaning once a week, the printer head clogs and you have to replace it anyway. If you use self cleaning too much, the waste ink reservoir fills up and your whole printer is toast unless you reset the firmware somehow. But there is a whole community for those kind of things.

Or you could say let's not normalize broken AI in health care related systems, but potato potato I guess.

> I'm sure somebody has written a book already about how ostensibly wealthy societies can fail at basic infrastructure that they previously mastered, driven by greed and complacency and other socioeconomic factors.

How about Foundation by Isaac Asimov.

Hah. At a previous place I found that our cloud cost consisted of 90% storage costs. The data? Tens of thousands of incomplete backups of the in-office file server. 3 years of the NAS continuously trying to back itself up to S3 and failing every time.

I feel you. Protobuf is the organizational equivalent of adding more lanes to congested roads or mandating more parking spaces. It leads to more cars.

Sounds about right. Hiring pipeline is probably too long to guarantee anything, but most people don't work out, so recruiters want to keep good leads in the pipeline as long as possible, just in case something comes up. Never attribute to malice that you can attribute to (in this case organizational) incompetence.

Note that I meant "handling (forward) pressure (or preventing back-pressure) can be done by simply having your system be performant enough. Of course this is not a dynamic property you can adjust at runtime, just wanted to add for the sake of completeness, because it should be part of the mindset. Sometimes a database falling over simply needs a few queries optimized.

> You could have back-pressure in the most optimized system.

Most batch processing systems. But you don't want back pressure in interactive or real-time systems, like graphics, gaming, audio, cars, planes, or even just real time collaboration systems (e.g. Figma). In all these cases back pressure is to be avoided.

Edit: I think the article also misses one of the most important ways to release pressure. And that is scaling throughput either horizontally (e.g. by adding more servers) or vertically (e.g. by optimization of software)

I like the article, but I am not sure that I agree with the terminology: I would not call "buffering" a form of back pressure. Imho there is really only one type of back pressure: the one the author calls "control". The other 2 are just ways to "release" pressure.

Not being able to do N+1 queries would be a feature in my book.

Just take the product of the two independent states. If you had 5 + 5 states, now you have 25 superstates each representing a potentially unique situation. As long as the sub-states are enumerable, the superstates will be enumerable too. One could argue this is exactly where state machines shine, because they allow you to methodically consider every condition.

> I surmise the reason we see it moreso on minivans is because 1) it is particularly difficult to work up enough energy to properly latch a sliding door, due to losses from the 90-degree change in direction at the end, and 2) violently slamming the sliding doors on a minivan is very dangerous to children's fingers.

There is also a third, dumber reason, at least for cargo van slide-doors. The surface area of sliding doors are large. When the door takes that 90 degree turn and moves very fast towards the vehicle, it is pushing a lot of air into the vehicle. The air in the vehicle has nowhere to go, so it acts as an air-spring, slowing down the door. To properly latch the door, you have to really slam it hard. If the windows are down or an other door is open, the sliding doors latches very easily. I thought I was going crazy when my door was closing easily ... sometimes. Some cargo vans even have vents that allow air to escape, but people tend to cover them because they don't know what it's for. But electric sliding doors also solve this problem, by moving slowly and letting the air escape.

TLDR: if you car door doesn't close, open the window :)

You mean the colon?

Is it just me or this should have been called "enhance"?

nitpicking but "changelist" sounds like what meta would call a diff-stack (aka multiple diffs).

don't forget Incident = SEV = DEFCON = 911 ...

Indeed. Reading SICP should be a requirement for starting a YAML company.

This just looks like a frontend over kubernetes.

Code.

or python https://www.python.org/

Assuming no technical obstacle, this would be a very cheap PR move. They should definitely wait until last minute though :)

""premature optimization is the root of all evil" is the root of all evil."

Software often has built in back pressure. Most IO syscalls block, TCP surely does, so everything built on TCP does. Belt is memory. The full belt equivalent of software is OOM. If memory allocation can't be done everything comes to a halt. We could write software that instead of crashing just sits there until memory becomes available... It's the human scale circuit breakers (request timeouts) that cause issues. I guess one has to differentiate between batch processing software and interactive request/response style software. Factorio approximates the former, not the latter, but some of the underlying concepts are still the same.

I don't believe the article says it's electron. Just that gimmicks are a trap an that _other_ terminals are even worse (because they use electron).

One issue with them, (specifically the crossnut variety) is if you don't use the correct tool a crossnut might start spinning in the metal. If that ever happens when your final bolt is already in, it's like having a nut on the blind side. You can't unscrew the bolt. Otherwise they are great, just but the right settings tool and drill the right size hole.

Is it just me, or is this a move towards pay per visit in the future?

And similarly, very few algorithms are better than O(n), because something as simple as adding 2 numbers can be O(n) where n is the size of the number in bits :)

Presumably because it would already have all the necessary code to find/enumerate existing resources.

Re: handling unmanaged resources, you have 2 options:

1. Everything not declared is unmanaged. Deleting is done by a "deleted" attribute of some sort. The resource is declared as deleted.

2. Everything unmanaged is declared as unmanaged. The resource is declared as unmanaged and TF would ignore it.

Either of those would work without extra state.

As a vim user I don't use org-mode, but I take notes in way too many places: google keep, docs and random text-files. Then I always forget about where they are and trying to find them in the wrong place.

So I spend a lot of time daydreaming about something like org-mode that is available across all my devices, perhaps something I can share with my family so we can coordinate.

What I am slowly realizing is it's not the features that I am missing from existing productivity/note/todo mobile interfaces ... it's the keyboard.

I am a keyboard oriented person, so no matter how snappy or feature rich a mobile interface is it will always feel sluggish to me. Maybe it's just a matter of getting used to, but for now I am stuck being un-organized. And tbh, I don't know if there is a solution other than having an open laptop with me at all times. Anyone else feels this way?