I think this article highlights more the importance of understanding system limits in the 1990s versus today. No-one would care to much today if the code review for this feature had “files.count()” or whatever in it, but in the mid 90s that would have been a huge performance red flag because a user would literally hear their hard drive clicking away and see the blinkenlights.

The problem isn’t counting the files (the algorithm in the article also counts the files), but that if you determine that you want to use the ith file only after counting all files, you have to iterate over the whole directory again (or over expected half of it) to find that file.

The mechanism is interesting, but I'm not fully understanding the importance. We say it was done this way because a user would appreciate the speedup. The difference is one traversal versus expected one and one-half traversals. How slow was this traversal at the time for this difference to be significant?

It will depend on details like file system fragmentation (Windows XP could run on FAT32), but it could conceivably make a perceptible difference on a slow HDD when there are many pictures in the directory. You also have to check more error cases, for when the second iteration fails for some reason. The mindset was probably "why complicate the code with multiple iterations and make it less efficient?" when the efficient solution is straightforward and arguably simpler.

Apart from the performance issues, it also prevents a bug. If some files get deleted between the first and the second pass, then you end up with unexpected behaviour and probably a crash.

The current implementation has the same race condition: the sampled file may be deleted by the time SHSetUserPicturePath() is called.

Yes, but the the implementation with the additional iteration also has to have extra checks for that iteration, because it can't blindly iterate to the ith file, as there may not be i files anymore. So the implementation gets more complex overall.

Hard drives are measured in hundreds of IOPS at most. Then you have the 40 billion other things trying to eat those IOPS at startup.

That's why now we need gigabytes of ram to do the same thing we managed in 128Mb back then. I mean sure, there's an AI chatbot in your PDF viewer and ads in your start menu, but the functionality of many daily things is still the same.

Kind of out there, but if you were running a network of agents that are autonomously looking for exploits, then perhaps those agents have decided that a good source of fresh ideas might be to periodically receive Schneier’s newsletter in an inbox they control.

That would be a good guess but the post says:

> All Gmail. None of the addresses has actually subscribed to Crypto-Gram. They could; whoever is sending the emails could easily have confirmed the subscription.

> not always your first exposure

Great point. How many professional sports players credit their elementary aged PE classes to their success in sport (as opposed to say crediting a high school coach)?

Progressive, unbridled access and exposure is key.

> unenumerable amount of knowledge, tips and experience silently disappears

Not to be negative about experts here, but of all industries, isn’t airline maintenance one of the most documented and standard procedure focused of them all? I would hope that someone maintaining a 777 doesn’t have to remember certain tricks or tips outside of what the manuals say, and when mistakes are found, they’d be noted, investigated and republished to all maintenance crews worldwide.

There is a famous story about how an F16 got grounded because an half inch metal pin was missing from the cockpit canopy. Nobody knew what the pin did or if it was even necessary but you can't fly a plan that 'missing a part'. After several days of being grounded they finally reached out to a guy who had retired 20 years ago who told them the pin was a part of a analogue sensor that had been replaced nearly 30 years ago. Only the pin remained as a vestigial organ since it was part of the airframe design.

It doesn't matter how well you document things there will always be tribal / personal knowledge.

Even if stuff is written down you have to know where to look.

I babysat for a military fighter jet mechanic when I was young, he said when they dismantled and rebuilt planes there was a drawer for all the spare parts that were left over.

Rap's Law of Inanimate Reproduction[1] strikes again!

[1]: "If you take something apart and put it back together again enough times, eventually you have two if it."

It's crazy to think someone with that complex of a job needs to be babysat

> but you can't fly a plan that 'missing a part'

It’s a great story, but I assure you there is a pretty high percentage of airplanes flying with missing parts and systems placarded as INOP in both military and civilian aviation.

Before you can placard something as INOP, you must determine whether the manufacturer and certifying authority have included that part in the Minimum Equipment List or Dispatch Deviation List. Mechanics do both get to determine this at their own discretion. Hence the call to the manufacturer for clarification on the necessity of said pin.

To reiterate, you CANNOT fly an airplane with an undocumented missing part. If the part is documented in the logbook as removed, and it is acceptable to fly that way, then it is not missing.

I have been building and maintaining commercial aircraft for a living for 30 years. What is your experience?

Thanks for asking for my credentials, even though you don’t seem to disagree that lots of aircraft are dispatched with imperfections, so many in fact that there’s a defined process and CFRs to cover it.

Because you asked, I’ve been flying, owning, and overseeing the maintenance of our aircraft for 27 years, including understanding my freedoms and obligations as a pilot and as an operator with regards to the legality of dispatch for imperfect aircraft under both normal operations and under special flight (aka “ferry”) permits. I have spent a lot of time across those three decades both socially and in continuing education courses/seminars with both GA and commercial flight crews and A&P/IAs.

Okay, but did you win the Putnam?

Just the once... (kidding, of course)

Ref: https://news.ycombinator.com/item?id=35083

I don't think you guys are really disagreeing with each other. Just that one is using a colloquial definition of "missing" and the other, a technical one.

The 'forest for the tree' here is that when it comes to general operations, a crew chief doesnt generally have the authority to signoff a bird as flight-ready for an unaccounted component. That is the authority of a PMO or a Risk Officer or someone else in flightoos, not a frontline maintenance call. Maybe someone in a maintainence squadron?

An absent (removed) part might be acceptable depending on circumstances, but a genuinely missing part creates hazards and must be ascertained as to its location. A mechanical jam, an electric short, a hydraulic leak, or a Foreign Object Damage to the engine from a piece of metal on the loose can destroy the plane, endanger people and mission. Same concern with tools & bits, can't have any unaccounted for.

I remember touring the assembly line for military jets.

There were posters everywhere about "extra parts" they called FOD.

FOD applies more broadly than that, as well. Candy wrappers on the runway is also FOD.

It stands for foreign object debris, and means any physical thing out of place where it may cause damage or injury. Because of the nature of jet engines, basically anything can be FOD depending on where you put it.

Chesterton's fence is strong with this one

Exactly. Framing completely changes this from an absurd story causing pointless grounding due to loss of institutional knowledge, to an example of good judgement (or protocol) in the absence of knowledge and acknowledgement of the risk of unknown consequences.

What's being ignored is the 1/100 of these stories where this judgement pays off, saves aircraft and lives that make the other 99 worth while.

For all our sakes, I hope your career never takes you anywhere near an airport.

Yeah it’s great to point an AI at a very detailed and specific engineering manual and have it distilled down into bullet points. There’s certainly no room for information loss in that plan! /s

Plus everything important is always written down.

It’s more true in aviation than anywhere else (except maybe space flight), but still.

And if it's written down, it's accurate. 100. Percent. Accurate. /s

You know, if I had to make that bet, I would choose airline maintenance manuals as the test case.

Have you seen the maintenance manuals on an aircraft production line? They're in 3-ring binders, so you can take out and replace pages. They are constantly being corrected and updated. The industry recognizes they're never at 100% (and to their credit mitigation is part of the process).

And because it's accurate the AI will know how to weigh that accurate information against other accurate information in such a way that it will give you a great answer without any help. In other words: any amateur will be able to do aircraft maintenance! What can go wrong? /s

GP did not suggest anything of the kind, though. They talked about "figuring out where to look" which very different. In that kind of use, it doesn't really matter that the model might hallucinate or draw faulty conclusions, as you're not using it figure out what to do, how or why. The only thing it is telling you is where some information is located, after which you go check it out from the actual source of truth. If the reference turns out to be wrong, you'll notice immediately.

I hate AI as much as anybody, but claiming that it's not useful for "distilling volumes of data into a short list of places to look first" is silly.

A former employer owned a combined cycle power plant -when they were having issues (not huge ones, but weird issues or gauge readings) they’d call this old timer and he’d come in walking around ask the operators to make some settings changes and be listening the whole time. And he’d come back and be like “hey the second stage compressor is out of balance” there were all sorts of telematics and manuals, but he could tell what was wrong just by listening…that was invaluable

The diagnostic/service steps you have to write to preclude any requirement of skill/experience make it stupid proof waste a lot of labor in the process. Cheaper to have the guy with the skill/experience show up and listen to the thing.

Well ... It takes four years of education before becoming a taxi driver in London: https://thetaxi.academy/

It takes also many years of study before they will let you touch any living person with your scalpel, and then many years of apprenticeship with actual surgeons when you do touch people with your tools.

I can imagine maintaining a big jumbo jet also requires some specialized practical knowledge you cannot acquire just by reading books and looking at nice little videos.

The problem is not to explain things when everything works perfectly. The problem is getting the ability to diagnose the root causes of defects using all your senses and your intuition. That is not taught in books.

> It takes four years of education before becoming a taxi driver in London

I’ve only been to London once, for work. One of the coolest things I did when I was there was to take a black London cab from the financial district to Heathrow when I was leaving. It was probably a 30 minute drive. The driver had been driving a cab since 1982. He told me all about the requirements and training for being a cab driver and a bunch of other things that I did not know (for example, they own the cars, and they can choose when they work). He was also a wealth of information about London, as you can imagine, and pointed out lots of interesting things as we drove.

It was probably a $50 cab ride, but worth every penny (even though it wasn’t my money since it was a work trip).

I've only taken a London cab once. The bastard got lost!

There are detailed step-by-step instruction cards (task cards) for every single maintenance operation on an airplane. Nobody is reinventing the wheel, they’re carefully following predetermined procedures. Someone has to figure out which maintenance procedures need to happen, but the work itself is laid out for you step by step.

Cool! I did not know that.

Augmented reality glasses, coupled with an AI that can interpret vision would seem to be useful here then.

This seems like a fast-track to making airline mechanics a minimum-wage, any-guy-off-the-street kind of job, which is not who I want touching the plane I'm flying in.

There needs to be SOME accountability. "Oh, but my glasses told me to unscrew this bolt, I was just following orders." is not how I want the future to be.

I’ve had the same thought re: AR glasses with a HUD for mechanics/construction workers, there are a lot of cool possibilities.

We worked on a proof of concept using HoloLens for an engine teardown team at a trucking OEM. Ran into issues around network, security, the Hololens itself and a general disinterest from the teardown team but there's a lot of room to run in this space. It was a fun, if frustrating, project.

> It takes four years of education before becoming a taxi driver in London

That doesn't apply to private hire vehicle drivers afaik.

Private hire is technically not a taxi. They can't pick someone up at a rank or on the street.

Or Uber drivers in London

(In case you're not aware) It's the same thing. Uber operates in London as private hire operator, so their drivers are mini cab drivers. Same rules (now: basic English and rules test, yearly car inspections, MOT every 6 months, cars must have TFL badges, etc).

... who are obviously not taxi drivers, so ... your point?

“Not to be negative about experts here, but of all industries, isn’t software development one of the most documented and standard procedure focused of them all? I would hope that someone maintaining a web service doesn’t have to remember certain tricks or tips outside of what the manuals say, and when mistakes are found, they’d be noted, investigated and republished to all developers worldwide.”

Just making a point that everyone else’s job always seems simple from the outside.

The joke about software developers refusing to enter an airplane running their own code dates back at least 30 years.

Software engineering is unique in STEM in that it has nearly zero regulations. Nobody keeps anybody accountable for quality and there are never any legal consequences. No other STEM jobs is like that, usually there are thousand hoops to jump through to do anything non-standard, but in software there's nothing. You can literally go to prison for forging an aircraft maintenance log, but you can forge JIRA logs to your heart's content and never get prosecuted (at most your employer can sue you for damages but that's it).

That's not a valid comparison.

A Jira log is not part of a Quality Management System (QMS). An aircraft maintenance log is. If you fake data in the QMS, software or not, for a regulated industry, I can assure you that it won't be taken lightly by the regulators.

Try forging the software validation test records for that airplane's flight control system and see what happens.

My point is exactly that there's no such thing as legally required quality management system for software. And that's what makes software development uniquely shitty in terms of not having documentation or following written instructions, to a degree unseen in any other STEM discipline. Trying to explain lack of knowledge transfer in aviation industry by putting it in terms of software industry was the worst possible analogy out of all analogies that could conceivably be made on this subject.

Forging software validation records isn't illegal because you're forging documents regarding software, but because you're forging documents regarding an airplane. Nobody gives a flying fuck about forged records for software that isn't installed on any airplane. It's not the act of forging that's illegal, but the act of installing forged software on a real airplane. Unlike the airplane repair records, where forgery is a crime in and of itself even if the airplane never flies.

Hopefully something happens a lot quicker than with volkswagon!

Just read and internalize the 800k page manual, some of which poorly explains why things are the way they are or is outright wrong.

Ezpz

I implore everyone to take on a nut and bolts (or resistors and transistors) hardware project sometime in their life to learn what it's like working on "Mother Nature OS".

I guess a more relatable way of conveying this is that you can have the recipe from a michelin star chef, but you're still not going to get anywhere close to michelin star quality.

heh the first time i took on a project as a new homeowner (building a deck) i learned this lesson. I spec'd everything out on paper and covered all the bases and felt pretty confident. Then I purchased the wood and so many pieces weren't the size advertised and i don't mean how a 2x4 is not really 2 inches by 4 inches. Some pieces were 3/4" too short, others too long, some straight but most weren't. It took so many trips to/from home depot and went over budget and wayyy over time.

oh and post holes, some are easy and some you hit mystery chunks of concrete(!?). It was like archaeological expedition trying to get deep enough holes in the ground.

I had a co-worker who was an experienced software developer but had never worked on a system that interfaced with the physical world before.

For quite a while, he hated having to test on real hardware because all sorts of failure modes that he couldn't predict: belts stretching, mechanisms hitting each other or not lining up properly and losing position, etc. kept happening and interfering with his nice "this will only take 15 minutes to test" estimates, making it an all-afternoon affair.

OTOH, it was that unpredictability and having to deal with weird stuff that I liked about programming embedded systems.

The mistake of modernity is believing that all tacit knowledge can be reduced to words.

I've worked with a number of clients that have lost senior engineers due to old age or retirement, and the impact is often very significant regardless of how sophisticated their knowledge management infrastructure is. Documentation can not fully replace the insight and situational awareness many of these experts posses and most of the time knowledge management still suffers from the 'not knowing what you don't know' issue. Only well structured 'apprenticeship' programs come close. I know some are going to point to AI, but I've worked in AI for over 2 decades and have extensive experience in Expert Systems and Knowledge Engineering from early in my career. It is not a complete solution. Given today's technology its trivial to replicate 'text book knowledge' but the difficult, expensive problems occur in the margins and its still hard to train AI on open ended / rare occurrences outside of domains that have specific advantages like software engineering. Talented and experienced people are still required. Maybe that will change soon, but AI isn't there yet.

> isn’t airline maintenance one of the most documented and standard procedure focused of them all

I hope you're right :) You probably are too. But even with that, there is a reason it's a profession and not something we ask gig-workers to do, it takes expertise and skill like any other skilled work, even though all the literal actions one might take is technically written down somewhere. Even in such industries, experts would get "hunches" about what is wrong, and are able to quicker pinpoint issues, and similar things. Or "getting a bad feeling" before something is actually evidentially bad, which prevented human disaster more than once in history.

I think if you consider that the job couldn't be done by just anybody who can read and follow instructions, then it might not be as easy as just "follow what the manuals say" and in those cases expertise, knowledge and experience matters a great deal.

Sure, but you are always going to get the "thing makes a strange noise but it isn't doing it now" ticket and there isn't going to be a "occasional strange noise" checklist.

I sense this is not winnable for all Wordle dictionary words. Is that provably the case?

There are actually a very large number of solutions for every word. I once wrote an algorithm to enumerate all possible solutions for a given word and I was surprised at the results.

Don’t forget operations and maintenance. You can have a box of vibe coded custom tools and services, but they’re all going to slowly rot as the underlying dependencies - network APIs, platform APIs, auth handshakes, reverse engineered file & DB schemas - change their behaviors and availability.

Sure, an LLM can fix it, but that assumes your original spec sufficiently described the user requirements and wasn’t just a transcript of the original session trying to figure out how how to interface with all those dependencies in the first place.

> Touching face, chest, groin, etc is forbidden.

It’s really hard to believe that an officer who’s wrestling someone hand-to-hand, possibly on the ground or against a wall, is going to restrain themselves from grabbing face or chest in the heat of the moment.

The first half of the article seemed fine, but then it appeared padded with AI filler.

They even predicted that smartphone users would inevitably ruin the (movie) theater experience (skip to 3:55 and 4:57)

> Then LLMs killed stackoverflow.

I think the common consensus is that stackoverflow killed stackoverflow, quite a few years before LLMs became entrenched.