leeter

I'm already keeping an eye on what NVidia gets into next... because that will inevitably be the "Next big thing". This is the third(ish) round of this pattern that I can recall, I'm probably wrong about the exact count, but NVidia is really good at figuring out how to be powering the "Next big thing". So alternatively... I should probably invest in the utilities powering whatever Datacenters are using the powerhungry monsters at the center of it all.

My suggestion is aim for compatibility with cppwinrt, but not anything else. That way devs can freely intermix and get the best of the utilities of both.

Looks like a good start. I'm not actually sure I'd use it on windows however. CPPWinrt has a really decent coroutine support library with tools like winrt::resume_background() [1], I use it extensively even in desktop apps because it makes using the windows threadpool (which is active by default for all windows processes since at least windows 7) trivial. I've basically moved most of my threading code onto that unless I need a dedicated thread to hold a context for some reason. But, that's a windows specific thing as far as I know.

[1] https://learn.microsoft.com/en-us/uwp/cpp-ref-for-winrt/resu...

Dang can we get an update to the title to reflect this?

Can they be cleaned up? Yes. Is it economical? Probably not. But, in theory one could bring them up in a sealed box, then incinerate them on the ship. This would require literally building a ship for that one purpose with very specialized equipment and government supervision so not even a single shell walks off. IIRC France and Belgium have successfully disposed of equally corroded gas shells from Zone Rouge.

Note: While none of the Annex 2 countries that are signatories have conducted tests since 1996; the treaty never took effect because it was never ratified by all the required countries. Most notably the US, China, and Russia (although all three signed). In 2023 Russia officially withdrew, allegedly based on the US non-ratification. At least one political candidate for the presidency in the US has advocated for resuming testing. It is not inconceivable that testing could resume in the near future.

Opinion: I don't think the US would if Russia or China didn't first. China likely won't for the same reason the US doesn't need to: they have super-computers and the sims line up with the data from prior tests. Russia might however if only to saber rattle, although they likely don't need to either. Russia however is likely not in any hurry to have a test failure right now. So while testing could resume, I wouldn't put money on it.

> People also don’t use IPv6 because they think NAT is a security feature.

Literally had a sales engineer parrot this at me awhile back. I had to point out that the service they were offering was on the open internet. It only got worse from there. Le sigh...

I'm not disagreeing at all. But Hanlon's Razor applies:

> Never attribute to malice what can better be explained by incompetence

You can't leak information if you never give access to that zone in any way. More than once I've run into well meaning developers in my time. Having a .internal inherently documents that something shouldn't be public. Whereas foo.example.com does not.

I can't speak for others but HSTS is a major reason. Not everybody wants to deal with setting up certs for every single application on a network but they want HSTS preload externally. I get why for AWS the solution of having everything from a .com works. But for a lot of small businesses it's just more than they want to deal with.

Another reason is information leakage. Having DNS records leak could actually provide potential information on things you'd rather not have public. Devs can be remarkably insensitive to the fact they are leaking information through things like domains.

Is this the same software Curious Marc is using to emulate a DSKY/AGC for their apollo comms project? Or are they using something custom spun up to support the hardware they are working on?

> Even on a later pentium

MMX helped a lot here, I remember my Pentium MMX 233 had no trouble playing games and playing music. To give you an idea of how crapy that machine was otherwise... it was a Packard Bell with an onboard ATI chip that barely qualified for 3D acceleration. The Pentium 166 (non-MMX) we had would chug on things that the MMX just didn't care about.

> I had to minimize throttle priority on my web browser because smooth scrolling requires a ton of juice. Still does to this day looking at power consumption on an iPhone.

This still to this day amuses me. Metal and DX12 both have calls designed to support this natively on the GPU by allowing the application to shift the rendered area of a very specific box (without rerendering the entire screen) and then render behind in the blank. As far as I know only Safari on iOS does this even close to properly and even then it has other iOS Safari related quirks around that that Apple refuses to fix.

The pedant in me wants to point out that most 486s couldn't play MP3s (they just don't have the horsepower, an AM-586 or a DX4 maybe) and you'd need a Pentium. /pedant

OK now to my real point. Vista is actually a really good call out of MS being inconsistent about this. The major changes in Vista (Moving graphics drivers largely out of the kernel, simplifying what sound drivers could do) were all predicated on the fact that hardware vendors are notoriously bad at software. This cannot be understated just how bad they are, NTKernel was originally intended such that vendors would make their own HAL.. one tried and it was so bad MS just NOPE.jpg'd that and did it themselves. So for MS to double down on a system that relies on the same known to be horrible at software vendors is just hilarious to me.

No this is kernelspace, an so while all addresses are 'virtual' an unmapped address is an address that hasn't been mapped in the page tables. Normally critical kernel drivers and data are marked as non-pagable (note: The Linux Kernel doesn't page, NTKernel does a legacy of when it was first written and memory constraints of the time). So if a driver needs to access pagable data it must not be part of the storage flow (and Crowdstrike is almost certainly part of it), and at the correct IRQL (the Interrupt priority level, anything above dispatch, AKA the scheduler, has severe restraints on what can happen there).

So no an unmapped address is a completely different BSOD, usually PAGE_FAULT_IN_UNPAGED_AREA which is a very bad sign

Interesting, very interesting. Curious that the PI spec doesn't include update dates on the versions. The MP spec was introduced in 1.5 and I have no idea when that was released.

Intel did a prototype of a multiprocessor UEFI application that would start up cores and UEFI itself does support synchronization on the assumption that applications/bootloaders will start other cores before calling ExitBootServices. However, there are no protocols as of 2.10 (the current spec[1]) that I can find that would bring up another processor. That said searching it can be a bit arcane.

[1] https://uefi.org/specs/UEFI/2.10/index.html

This is fine if you're only running on a single core, however if you're a multiprocessor OS you still need to deal with legacy when bringing up the other cores. Intel and AMD should consider a mode that disables that and brings up the other cores using a 64bit SIPI. While I applaud Intel on the X86S idea... I think there is room for bits of that without throwing out all the backwards compat. An X86SC which drops real mode and only supports 16bit 'real mode' in virtualization.

Yes, I see the argument that if you go to that point you might as well just use emulation. However running mixed 32bit/16bit code (Windows 98/95) becomes problematic just because of performance reasons. DosBox does well, but good luck supporting games for the Pentium 3 era that still used 16bit libraries because of course they did. (16bit Installshield was so common going into 64bit that MS just has code to replace it so 32bit applications can still be installed despite having a 16bit installer)

> ArianeSpace's insistence on not earnestly working to innovate led to them already having had a gap in domestic capability

Yes and no, there are plenty of EU space startups. What Ariane has done is starve them of government funding to build a competitive EU based market. So I'd say it's drawing the investment into a hole.

Just a quick sample of EU space firms I'm aware of:

https://en.wikipedia.org/wiki/Rocket_Factory_Augsburg

https://en.wikipedia.org/wiki/Isar_Aerospace

https://en.wikipedia.org/wiki/HyImpulse

It depends. Fully soaked ground will actually preserve wooden piles (wood decay is aerobic and requires oxygen). This is why Venice and New Orleans are both built on them (sinking issues aside because they have other issues). The piles in both cases are quite stable because the ground is completely soaked. Where you run into issues is where water and air meet. I would imagine wooden piles in just water would have issues with shipworm (in appropriate venues). But the ones in fully soaked soil seem to last just fine.

I suspect, but don't have data on, that wooden piles may actually last longer in those exact circumstances due to galvanic issues with concrete and rebar or metal pilings.

Allegedly there are already off list SKUs from both AMD and Intel that don't support 16/32bit code and boot up without the legacy bits. How far they went in that? I don't know. I'd hope they removed LDT etc. and reduced GDT to just ES and GS (or just used an esbase and gsbase MSRs).

Oh it doesn't, AMD and Intel gave up on that awhile back. v8086 mode might... but I'd guess it has quite a bit of errata. Everything else has most certainly changed. CPUs don't support the A20 gate for example. Nor do they truly support real mode (they boot in 'unreal mode' now). If you want a 386 compatible you're looking at ALi or DM&P CPUs that are basically Pentium/486/386 clones.

I'd argue the break started with the Pentium Pro, at that point things shifted architecturally.

If that's the case I'd encourage you to take away a few lessons from Salesforce:

1. IT is not your customer. The business is, and they don't know how to write code. Based on what I saw thus far; this is your biggest weakness. The only way to extend the platform at the moment is to self-host and write code.

2. Avoid baking crazy logic into the system now that you'll be unable to fix later *cough* SF 'standard' objects *cough* that will behave in very weird ways.

2(a). Person Accounts look like a good idea. But, they aren't; and never will be. They just create a lot of complications later when someone gets married or starts a business.

I agree... with the exception of PersonAccounts... those need to go die in a dumpster fire

I wish them the best, but I think they would have been best not drawing the comparison to Salesforce. IME people buy Salesforce not for the CRM but for the force.com platform. The ability to seamlessly build business logic over the entire flow of a business is Salesforce's bread and butter. CRM is a small part that definitely gets heavy use, but it's only a small part of the larger picture.

If they had a way to quickly spin of LOB apps like Salesforce does, and had implemented a CRM on top of that... I'd say they would be much more apt drawing the comparison. Particularly if that doesn't require code to do. I know a LOT of companies that would pay dearly for such a hosted platform, GPL or not.

Me: "We should use SCIM, our IDP and our App both support it" PM: "No that's too complicated, we'll roll our own provisioning and never worry about de-provisioning because they won't be able to log in due to SAML anyway!"

I can't tell you how many times I've had that conversation... but I'd need at least both hands and a foot.

Retrotech:

Adrian's Digital Basement (retrotech repair)

RMC The Cave (retro curation and stories)

Cntl Alt Rees (retro eclectic)

Jan Beta (repair)

LGR (eclectic)

Mr. Carlson's lab (repair of generally older RF, but some newer)

CuriousMarc (repair, testing, stories. Did a complete repair of the Apollo Guidance Computer)

They are however (by dropping the 32bit versions of Windows) dropping 16bit support. Which still exists in 32bit Windows 10 along with NTVDM (AKA DOS emulation). So I guess it's the end of the line for MSDOS?

Yes and no, the ship and crew might have survived. But the steel wasn't thick enough to block all the radiation. Moreover traditional ship design up until that point didn't handle Nuclear Biological, and Chemical threats well. They weren't really designed to be completely sealed. It's important to recognize that the assumption that the next war would be atomic killed a lot of technology paths because the people with the money assumed it was a waste of time to continue in those directions. By the time the military started to re-explore those paths the tech had languished. It's why the Iowas went back to sea with the Mk8 fire control computer, a completely analog computer. Because nobody had really bothered to build a better one for large caliber shells since WWII.

But it's important to note that before the Iowas were given their final retirements into museum ships the Navy made sure to basically document everything they could about firing large caliber guns. Because when they initially pulled them out of mothballs in the 1980s they were woefully inaccurate, but by the time they were decommissioned for the final time they could hit a proverbial fly on a flag pole (allegedly).

The other part of it was that the Soviet Union didn't really have a surface fleet to really speak of. They invested heavily in submarines, so consequently the US Navy focused heavily on ASW. So... nobody really knows how 16" of modern armor would fair against modern weapons, it's literally never been tried. Whereas you can find pictures from way back when they were testing guns, of how various shells fared against various thicknesses and types of armor.

Long story short: We've forgotten most of what we knew about surface warfare, and we're starting to forget what we knew about shipbuilding and design. The US has outsourced all it's naval architecture and shipbuilding so long that the necessary skills are either all retired or lost.

First and foremost I applaud the effort. I think this is a worthwhile concept. However, I think this is something that would be better if the FCC delivered a report asking for specific things to congress. Because while we can look at this just through the IOT lens I think that's very shortsighted. There are CNC shops still running DOS and Windows95. So what happens when the new fancy CNC they are buying today running Windows 11 embedded goes out of support from MS? These are things that are intended to be in use for 30+ years.

So to me there needs to be a formal process in the law for dealing with abandonment, and minimum support duration.

1. Minimum support duration: This needs to be in federal law and enforced by private right of action, and more specifically one that cannot be waived or arbitrated. This cannot be something that the FCC or FTC must enforce. This must also be binding with valid legal remedies if the company fails to comply or no longer exists. Which leads me to my next point.

2. Abandonment: The law must require that if an OEM abandons a device that sufficient information (including PCB schematics and PCB BOMs!) are made public that both individuals and third party commercial operations can supply support. Again, this must have legal remedy to enforce. My preferred remedy if a company completely fails to provide anything is loss of copyrights to that specific software. Thus negating all the digital locks provisions of the DMCA in regards to that specific hardware. If the company provides the necessary information under an appropriate free software and/or documentation license then they maintain all copyrights. They only need submit the information to the library of congress and a third party such as archive.org; they do not need to host it themselves. Nor would they be required to provide any support after that point. Furthermore, any components not currently in production would have to be made available until such stocks are depleted.

Having a formal abandonment process for a device including a formal notice of termination of support, and releasing appropriate documentation and necessary information to the public provides a massive boost to both ongoing security but also to reducing waste.

It's a complicated issue. Part of the problem is nobody really wants to fix it because the costs will be enormous. When and if the regime falls it's going to take tens of billions of dollars in aid to keep it from destabilizing South Korea. Not to mention the massive refugee crisis that will occur. I'm pretty sure that's one of the many reasons why China hasn't dealt with it. Because the vast majority of refugees would go north across their border.

China has made it clear they aren't particularly thrilled with the idea of having someone not under their thumb next to their border as well. As a consequence of that... the "best" scenario would probably be China invading. But "best" is definitely in scare quotes as that could go VERY wrong very very quickly. I think the PRC is aware of that too. So unfortunately that means the DPRK will starve, because the realpolitik is such that solving the issue is just not a tenable solution for all the other parties.

> Right now, Apple Silicon tops out at 12 cores (8 performance and 4 efficiency). If I'm a data center, I'm going to likely prefer an AMD EPYC with 64 cores (and 128 threads) over an Apple M2 with 8 performance cores. I can slice that AMD EPYC into a lot more VMs.

I think it's worth calling out how important this is. Once you get past a certain die size and core count interconnect or "fabric" latency and bandwidth starts to have a much bigger impact on loads than core speed and throughput for code not optimized for that processor. Where M2 is... Apple doesn't have to deal with that at all. AMD on the other hand has gone all in, hence chiplet designs. But yeah Apple wants nothing to do with that, hence they seem to be going for very wide but limited core count designs.