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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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)?

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.

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

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.

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.

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.

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.

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.