xenadu02

> Actually pre-ANSI C technically didn't have function prototypes,

Thanks, I completely forgot they weren't called prototypes originally.

The percentage of times I prompt claude "what about checking if there are any child processes running?" or "Would using a lock here greatly simplify the design?" only to have myself be correct is approaching 100%. That is it isn't just claude sycophantically agreeing with me. The code itself becomes smaller, simpler, and more reliable with fewer bugs.

The agents tend to produce working code but the larger the scope the bigger the mess they tend to make. They will happily evolve toward a local maxima but leave world-destroying bugs lurking in the implementation.

The other issue is that claude regularly ignores explicit instructions in CLAUDE.md or in prompts. It will "helpfully" decide to just start doing whatever it wants or reinterpret instructions completely differently than it did the last 100 times.

It has nothing to do with losing control or trust. LLMs are not conscious. They have no executive function. They aren't even thinking. They're just models predicting the next word in the script. They are very useful tools but that's all they are: tools.

Not just this it is important to remember that there was no "aha!" moment where C was created whole-cloth by writing the first compiler in B then cross-compiling.

The language B was evolved in-place by adding new features, then editing the compiler source to make use of those new features, then repeating. They simply started calling it "New B". At some point the language had evolved sufficiently that they decided to call it C.

The semantics of arrays were inherited from B and simply never changed. Part of me suspects this was also because it was seen as "clever" at the time. Look ma, we let arrays turn into pointers! Isn't that clever?

When you look at pre-ANSI C function prototypes you wonder "where are the parameter types?" because there are none. The compiler didn't bother to check. Part of that was perhaps for implementation reasons but a big part of that was the feeling or culture inherited from B: in that language you just had words of memory. You were free to interpret any word of memory as any data type you liked. So duh of course it is up to you to decide how many parameters your function received and of what type. If the caller supplied a different number or different types? Don't do that.

If you are coming from that sort of world clever tricks like arrays decaying to pointers or automatically converting between data types and sizes seems perfectly natural. Anything C offers above and beyond that is an improvement from B after all.

That's fair. I had hoped GF was not entirely giving up but was going to wait until the tech for new nodes was proven and cheaper to obtain. It seems that is not really possible at the moment because anyone who is involved in that supply chain doesn't maintain the ability to stand up new processes on older nodes. Way too busy standing up new nodes.

So much for efficient free markets.

I remember in elementary school being amused by the idea of handedness so I decided to practice writing with my left hand as well. I'm not great at it but even to this day I can write legibly with my left hand from that little bit of practice as a child.

Anyone can get much better at using their non-dominant hand (if they have one) with just a bit of practice. The effect is much much stronger when you do so as a child.

Cryptographically secure random number generators are equivalent to encryption itself. If you could predict anything about the plain text by analysis of the cipher text the algorithm is compromised/broken and useless. That's the whole point! Saying that /dev/random has "exhausted entropy" is as useful as saying "the fleep didn't florp the gorpobittin!". Completely useless words strung together without any meaning.

A CSPRNG is just an algorithm that uses some entropy as a key and feeds back on itself to generate a stream of random bytes. It is a way of expanding a small bit of entropy into a much larger sequence of random values.

From that you can derive the underlying objection here: estimating entropy, blocking /dev/random, and all the other noise is equivalent to saying "cryptography doesn't work". It is both wrong and pointless.

The only place it matters is at boot when there is no hardware source of randomness _which excludes pretty much all PCs which have hardware generators_. You need a true random key to start the CSPRNG but that's it. If you don't have a hardware unit you use time of arrival of the next network packet. Or the frequency of keystrokes on the keyboard.

Now you might ask: why bother seeing the entropy pool at all? The answer is Perfect Forward Secrecy. By mixing in new randomness you are effectively slowly swapping out the key used for the encrypted stream. Thus even if someone is able to compromise something based on guessing the random number sequence your CSPRNG generated their guesses will get more and more wrong as new entropy enters the pool eventually becoming useless. This is a defense-in-depth policy though, not a practical attack mechanism.

On linux it is unfortunate that /dev/urandom has the property of silently vending non-random bytes on hardware without an RNG just after boot and that /dev/random was designed to block when the magical fairies say so but of the two failure modes /dev/urandom is the least bad because practically most hardware (even embedded hardware these days) simply can't encounter its failure mode.

I've made this same argument so let me make a counter-argument:

There are some ways to get this off the ground much quicker. One or more companies could buy an existing non-leading-edge fab like GlobalFoundaries. That buys a lot of expertise so you're not starting from zero.

DRAM also benefits from being very regular and relatively simple. It used to be what you bring up on a new process node to help prove things out.

It also isn't impossible to reduce reliance on ASML if you're willing to throw money at it. That's definitely a super-long-game move but it could be done.

I'm not going to argue that someone is going to do any of this but if demand is sustained it is possible.

For some time I've been curious why none of the major UPS manufacturers offer LiFePO4 UPS units. They'd be smaller, lighter, and have a longer run time all else equal (dramatically lower shipping charges). Batteries wouldn't need replacing nearly as often.

Yet as far as I can tell none of them offer anything in this area except at the extremely high end. Even Ubiquiti's UPS offerings are garbage simulated sine wave with lead acid batteries.

Are UPSes such a niche product there's no money in it? Are they really content to just give up the whole "power station" market to upstart competitors?

Even aviation jump packs (that connect to aircraft ground power ports) offer lithium versions and that's an industry that moves like sloths toward new technology!

You have however many people who you seem to believe have no useful work to do in their current roles. You aren't bleeding money. Is that not the time to invest in new products? To take moonshots?

Is this not admitting that they simply can't come up with any new ideas to invest in? That their intellectual capacity has topped out?

Profitable companies laying people off like this tells me they're done innovating and now it is time to milk the cash cows for all they're worth.

Are you sure about that number being ex-fuel?

FWIW I'm not interested in flying commercial with non-union pilots so that airlines can become cheap labor body shops.

I'm also not interested in saving money by having Boeing outsource to kick as many people out of their machinist union as they can (and screw those people out of retirement and healthcare benefits).

I got my pilot certificate last year (zero plans to go ATP/commercial). Its a lot of work. Then you've got years of getting paid pennies to earn your 1500 hour ATP. Then you've got more years of taking the crap routes and not making super dollars. Much like a doctor its after you've put in 10-15 years that it starts really paying off.

The union also protects pilots from blame culture and trying to game metrics. If it isn't based on seniority then what metrics do you use? And do you want pilots to start making flying decisions based on on-time percentage instead of safety?

If your business needs to screw over labor to survive you don't have a worthwhile business.

You can always route writes to a writer node with streaming WAL replication to all the reader nodes. Works for some workloads and systems, not for others.

For that matter if you write your system with the correct abstraction you can switch to Postgres _later_ if it becomes necessary. For every system that really did need to scale 10,000 are pointlessly overbuilt - worrying about scale when it just didn't matter.

Yeah that's true, it doesn't require a physical implementation per-se.

It does specify cross-talk specs and frequency response. IIRC Cat-5E was 125, Cat-6 250, Cat-6A 500Mhz. But copper is copper and all else equal well-made copper of a given size is going to carry those frequencies regardless. Cat-5E can carry 500Mhz just fine. They don't mix some magic sauce into the molten copper before casting & drawing into wire that changes its frequency response. The real limiting factor (IMHO) and where the actual manufacturing really matters is cross-talk.

In more general terms "runtime" means the userspace facilities above and beyond the standard system APIs (which often translate directly into syscalls into the kernel). It is a set of agreed-upon data structures and functions for operating on them and often includes facilities and patterns for extending the system with your own data structures.

For example the C runtime has a notion of what a "string" is: it's binary layout in memory and the conventions around it (e.g. an array of utf-8 bytes terminated by a null).

A runtime can be very thin or very complex. The dotnet or Java runtimes are massive by comparison. To the point they generally JIT the intermediate language to produce executable code (whether ahead of time or on-the-fly). Go's runtime has its own notion of threading built on top of the system notion of threads.

A self-contained static binary embeds any runtime implementations it needs into its own binary so it is still using runtime facilities but needs no external libraries.

A standalone or "bare" program can mean one that is built using only syscall primitives. Of course that can be taken further: you can build a true baremetal program that is designed to be copied into memory by the bootloader so it runs without a kernel or OS underneath it. This is, after all, what an OS kernel is: just code built such that the bootloader can jump to a fixed (or designated in metadata) address, handing off a pointer to info about the hardware (such as a DeviceTree) in memory and that's it.

In the early PC days BIOS was basically a set of functions built-in to the hardware (or more often flashed onto EEPROM). More or less a minimal sort of runtime + device drivers that knew how to read keyboard input, print characters to the screen, etc.

Almost everything is built on abstractions. In modern systems EFI or equivalents is a form of runtime + device drivers for early boot and the kernel. The kernel forms that for userspace. And a userspace language runtime can be something like a mini-OS for the code it runs. Going the other direction CPUs themselves are much more like a collection of networked PCs than you might expect.

A race to the bottom on pilot pay won't help anything. Well it may lead to less qualified pilots. You can ask Boeing how well screwing over labor has worked for them if you like.

All US airlines have the same labor costs for pilots and it isn't their highest cost anyway. That would be fuel.

If you want to divvy up costs that way: Boeing is probably the biggest problem. Both them and Airbus eat up all possible excess profit on the back end via the cost for airliners. Break up Boeing, bring back competition in airliner manufacturing. People who want to screw over labor don't usually frame things in those terms for some reason.

IBM is also the reason MS-DOS doesn't support "-" for options and why it doesn't have devices in the "\DEV" directory on all drives. Support for "/" as path separator survived though!

Many MS folks used Xenix and were fans of Unix and very early DOS had SWITCHCHAR and AVAILDEV config.sys options for these things. But AFAIK IBM threw an absolute fit about it and forced their removal.

The DEV issue is specially annoying because DOS 1 didn't have directories - thus it could not have been much of a compatibility problem. But instead DOS/Windows is stuck being unable to support creating files named "CON" or "COM1" because it assumes device files exist in all directories.

Spirit has filed bankruptcy twice in the past year. Bondholders aren't going to accept any purchase plan unless the buyer is going to vastly overpay.

They probably believe they'll get more money back from selling the aircraft. If American or United want a new airplane they place an order and wait 5 or more years for delivery. No airline has excess airplanes available to take new routes. They are so expensive just a handful being idle (outside of expected maintenance winodws) would erase all profit. That means if there is a new opportunity it can take a very long time to go after it.

Airlines from around the world will line up to buy every single one of Spirit's airplanes because it means they can have one _today_. A few might even pay premium prices for them.

Airlines are a cyclical business. Boeing and Airbus gobble up every spare dollar on the back end and customer pressure eats up the front end. Then you're subject to all sorts of random shocks outside your control without much ability to adjust your fixed costs. A difficult business to be in.

Is the disconnect here that in many datasets there is some implicit distribution? For example if we are searching for english words we can assume that the number of words or sentences starting with "Q" or "Z" is very small while the ones starting with "T" are many. Or if the first three lookups in a binary search all start with "T" we are probably being asked to search just the "T" section of a dictionary.

Depending on the problem space such assumptions can prove right enough to be worth using despite sometimes being wrong. Of course if you've got the compute to throw at it (and the problem is large) take the Contact approach: why do one when you can do two in parallel for twice the price (cycles)?

> The most important question was the structured cabling in the walls; was it CAT-5E or CAT-6, or even CAT-6A? Remember from the last post, 10GBASE-T might work over short runs of -5E (even though officially it's not meant to be able to).

This is not quite correct.

The primary problem is cross-talk. Copper wire itself will carry the relevant frequencies up to 100m without issue but even with balanced pairs the balancing is not perfect and the "dirty paper precoding" is not perfect so some cross-talk will occur. How long you can go with Cat-5e depends on how well the wire is twisted, how many wires are bundled together, are there any loops or tight bends, and other factors. Cat-6A guarantees less cross-talk with more twists, better balancing, and a plastic separator inside the cable to make the cross-talk more regular and thus easier to cancel out.

Bottom line is: for almost any normal home or apartment any quality Cat-5e cable properly terminated will carry 10GBase-T without issue. In fact if you have problems I would first re-terminate the cable before assuming you need to run new cable. Cat-6 or 6A just isn't necessary.

As a PSA: beware of "CCA". I've noticed Amazon and eBay are absolutely flooded with cheap chinese electrical and networking cable that shows nice shiny copper in the pictures but is actually "copper clad aluminum". If they mention anything at all they code it as "CCA" cable without explaining what that means.

CCA cable cannot, by definition, be ethernet cable. I won't get into the full technical details but the standard was amended to clarify that only pure copper wires are acceptable for ethernet. Personally I would not dare use CCA for anything. It has lower performance, lower current-carrying capability for the same wire diameter (inherent in aluminum), and introduces the risk of oxidation and loosening of connections as people will treat them as copper connections when aluminum needs special installation procedures and connections to avoid them coming loose over time. For electrical connections especially this not only can but absolutely will lead to a fire over time if not treated with the appropriate care. All it takes is a little bit of mechanical action scraping off the thin copper layer and you now have an effectively aluminum wire - a time bomb ticking away.

This comment is completely incorrect.

kqueue VNODE events are delivered so long as your process has access to the file. There is no "same-process" notification filter.

I have no idea why they aren't using kqueue but that works on macOS and FreeBSD. It has for years.

You want EVFILT_VNODE with NOTE_WRITE. That's hooked up to VNOP_WRITE in the kernel, the call made to the relevant filesystem to actually perform the write.

If you're interested you can use kqueue on FreeBSD and Darwin to watch the inode for changes. Faster than a syscall, especially if all you need is a wakeup when it changes.

Most edible bananas are seedless and most cultivars (human grown) bananas are genetic mutants with triploid chromosomes (though a few are tetrapolid or diploid). Getting them to produce functional reproductive structures at all let alone viable seeds is very difficult. There are ongoing efforts to cross-breed with their wild cousins and to preserve genetic diversity.

This is wildly inaccurate.

Windows 3.11 was a hypervisor running virtual machines. The 16-bit Windows virtual machine (within which everything was cooperatively multitasking), the 32-bit headless VM that ran 32-bit drivers, and any number of V86 DOS virtual machines.

Win9x was similar in the sense that it had the Windows virtual machine running 32-bit and 16-bit Windows software along with V86 DOS VMs. It did some bananas things by having KERNEL, USER, and GDI "thunk" between the environments to not just let 16-bit programs run but let them continue interacting with 32-bit programs. So no, Win9x was in fact 32-bit protected mode with pre-emptive multitasking.

What Win9x prioritized was compatibility. That meant it supported old 16-bit drivers and DOS TSRs among other things. It also did not have any of the modern notions of security or protection. Any program could read any other program's memory or inject code into it. As you might expect a combination of awful DOS drivers and constant 3rd party code injection was not a recipe for stability even absent bad intentions or incompetence.

Windows 2000/XP went further and degraded the original Windows NT design by pulling stuff into kernel mode for performance. GDI and the Window Manager were all kernel mode - see the many many security vulnerabilities resulting from that.

I do some machining as a hobby (I get enough of computers at work and elsewhere) so here's a similar tip:

Don't treat your lathe faceplate as a precious artifact. Need to clamp an oddly shaped part to it? Drill and tap some holes. That's what it is for.

Is that reamer too long to fit? Cut it shorter.

Modify your tools to make you happier or more productive.

What if the modification doesn't turn out well? Great! You learned something. Make the next one better.

IOKit was almost done in Java; C++ was the engineering plan to stop that from happening.

Remember: there was a short window of time where everyone thought Java was the future and Java support was featured heavily in some of the early OS X announcements.

Also DriverKit's Objective-C model was not the same as userspace. As I recall the compiler resolved all message sends at compile time. It was much less dynamic.

> Someone will fulfil the need as there is a high incentive to.

Unless the capital cost to compete is too high and the risk of the existing manufacturers undercutting you is very real. Plus it can take 5-10 years or more to build a new fab, debug/iterate your process, then start shipping product.

Markets are prone to natural distortions. This is one form of that. It can be perfectly natural for all potential competitors to choose not to compete no matter how much demand exists.

Frankly I'd expect nationalization of some of the DRAM makers before we see the rise of useful competitors. The more likely scenario is government pressure, up to and including arresting executives, to rattle the cages of the existing players who are way better placed to expand production quickly for relatively low capex. Not that I think any action is likely in the short term. My guess is the existing players are betting on an AI bubble pop so they don't see the use in really expanding capacity only to be left with idle fabs later. None of us really knows.

I think you have to temper the skepticism a bit though.

SpaceX has dramatically lowered the cost of launching things into space. They are still the leader here. They can put a kg into orbit cheaper than anyone, even heavily subsidized state operations (EU and China).

Their order book continues to be full. Every single launch vehicle they roll off the line was pre-sold years ago, including its re-use flights.

I agree that Elon is their biggest potential problem and a big risk but their launch business is sound and wildly successful. If you believe access to space will be a growing segment of the economy in the future it isn't exactly a bad investment.

I remember all the people putting Tesla down when they IPO'd. I bought $4k of stock (all I could afford at that time). Sold $100k of it a few years ago, still have the other half worth near $220k. Their numbers at IPO time were garbage and it wasn't clear they would even survive. Then they started shipping hundreds of thousands then a million cars.

YMMV, consider all sides and make your own judgement. Just be careful about trusting the anti-SpaceX case. Even if everyone is technically correct about them it can still be a huge miss not to invest! The future is not static and if they can put the raised capital to productive use the IPO could end up being a fantastic deal. And FWIW I also agree the largest immediate risk is they are over-valued. Only time will tell on that front.

It is important to remember that Microsoft created some of this chaos to begin with. Other aspects can be attributed to "the industry didn't understand the value of $x or the right way to do $y at the time". And some of this is "nonsense you deal with when the internet and automatic updates is not yet a thing".

Why did programs overwrite system components? Because Microsoft regularly pushed updates with VC++ or Visual Studio and if you built your program with Microsoft's tools you often had to distribute the updated components for your program to work - especially the Visual C runtime and the Common Controls. This even started in the Win3.11 days when you had to update common controls to get the fancy new "3d" look. And sometimes a newer update broke older programs so installers would try to force the "correct" version to be installed... but there's no better option here. Don't do that and the program the user just installed is busted. Do it and you break something else. There was no auto-update or internet access so you had to make a guess at what the best option was and hope. Mix in general lack of knowledge, no forums or Stack Overflow to ask for help, and general incompetence and you end up with a lot of badly made installers doing absolute nonsense.

Why force everyone to share everything? Early on primarily for disk space and memory reasons. Early PCs could barely run a GUI so few hundred kilobytes to let programs have their own copy of common controls was a non-starter. There was no such thing as "just wait for everyone to upgrade" or "wait for WindowsUpdate to roll this feature out to everyone". By the early 2000s the biggest reason was because we hadn't realized that sharing is great in theory but often terrible in practice and a system to manage who gets what version of each library is critical. And we also later had the disk space and RAM to allow it.

But the biggest issue was probably Microsoft's refusal to provide a system installer. Later I assume antitrust concerns prevented them from doing more in this area. Installers did whatever because there were a bunch of little companies making installers and every developer just picked one and built all their packages with it. Often not updating their installer for years (possibly because it cost a lot of money).

Note: When I say "we" here that's doing a lot of heavy lifting. I think the Unix world understood the need for package managers and control of library versions earlier but even then the list of problems and the solutions to them in these areas varied a lot. Dependency management was far from a solved problem.

I recommend ANSI rated cut protection gloves: https://www.mcmaster.com/9915N987/

I use them when working with sheet metal. They are high-dexterity. Thin and flexible. Steel threads are woven into the fabric. McMaster has a variety of high dexterity gloves - fingerless, insulating, cut-resistant.

> You might want to take some time off the internet, I can smell your liver from here.

I'm not sure what that means? Liver? Is that a drinking thing? I don't really drink so I dunno.

> Time to take a chill pill and learn to live with it.

I don't agree. Changes in trends can start many ways and one of them is by tech people complaining to other tech people.

It wasn't originally possible to hijack the browser's scrolling function (or history). Just like the early days of GUIs and windowing systems: some people take those tools and make an absolute mess. If no one ever yells at them for it they and those around them won't learn to be ashamed of making messes.