axelriet

"goodpoint"

One thing that LR does well is leverage Adobe Camera Raw and its great support for many raw formats.

>negligible attack surface of a simple-plain HTTP…

…unless you use a general-purpose web server with its own set of challenges as far as policies and configuration. I’ll leave it there.

Because neither C nor C++ creates friction.

The whole memory safety chapter is a human problem first and foremost.

Some humans haven’t written a memory-safety bug in decades, but it requires a discipline the recent hire never acquired.

I always advocated fixing issues at their root. Humans write bugs, fix the humans. Somehow this was always regarded as taboo ever since I started at Microsoft in 2013.

on average :)

There is no formal training (like bootcamp or classes) but the larger org has extensive documentation (osgwiki) and you are expected to learn and ramp-up by yourself.

I don’t think there is any kernel code writing experience requirement but the hiring bar is sky-high, you have to demonstrate that you are a programmer.

Everyone is entitled to their opinion.

VM management does not run on the FPGA; it’s regular Win32 software on Windows, with aspirations to run some equivalent, someday, on the SoC next to the FPGA on the NIC. The programmable hardware is used for network paths and PCIe functions, where it can project NICs and NVMe devices to VMs to bypass software-based, VMBus-backed virtual devices, all of which end up being serviced on the host who controls the real hardware. Lookup SR-IOV for the bypass. So yes, that’s I/O bypass/offload, but the VM management stack offload is a distinct thing that does not require an FPGA, just a SoC.

“customary” referred to the path through the Secretary, as opposed to writing directly to members. Besides that, depending on the nature of the communication, if everything fails, you may need to be sure you talk to people who will unconditionally put the best interests of the company ahead of any other consideration. The Board is one such group. See what Boeing did with the report of the mechanic who saw flaws in the 737 MAX’s door plugs. Was that worthy of a letter to the CEO, then the Board if no reaction? Or just talk to your dismissive manager and let the planes crash? I made a judgment call, which I entirely own.

“customary” referred to the path through the Secretary, as opposed to writing to individual members. I added a clarification at the bottom of the page.

There is a video floating where he demoed Excel, and his title was Technical Marketing Manager. Maybe he pivoted to PM later?

https://youtu.be/ddHDclRfzxM

Base education, he’s an EE.

Hint: there is a small distance, almost zero, between your product being unreliable and losing your most flagship customer and the trust of the DoD.

Factor that there are limits to what I was willing to share in that story, limits that I’ll certainly not cross here.

Now, if you think that I’m wrong and that Microsoft found an entirely different way of shooting itself in the foot, I’d love to hear your perspective.

Nah ;)

The timeline and facts were quite different. Debating an org-wide quality issue on a 100+ member team's alias is not whistleblowing.

The thing with cockroaches is that if even a single one is seen in the dining room and someone calls environmental health, regardless of the restaurant's prestige, they close it with immediate effect until they get their act together and a food sanitation inspection clears them.

At the end, everyone feels better, in particular the customers.

Well, what you describe is plausible, but it would not be a good long-term strategy and is certain to backfire badly at some point.

Then imagine your systems are key support systems with deep implications in government and the military, and the path you outline is not acceptable.

Onboarding new customers on a sinking ship is dishonest at best, criminal at worst.

So yes, I maintain that it helps more than it harms.

Maybe they didn’t have sufficient visibility at the ground level to make proper decisions.

You have all the right words but some are in the wrong order.

Life works in mysterious ways. Whoever you are, bring it on and prove any of my points wrong.

The answer is “intricate politics and misplaced personal interests.”

I never said I didn’t. It was a multi-year escalation and I shared my concerns widely along with concrete options.

The thing is in corporate environments people avoid admitting anything is wrong because that would make them look bad and also disavows the bosses who promoted them, so the true best interest of the company takes a back seat.

It came from the top of Azure and for Azure only. Specifically the mandate was for all new code that cannot use a GC i.e. no more new C or C++ specifically.

I think the CTO was very public about that at RustCon and other places where he spoke.

The examples he gave were contrived, though, mostly tiny bits of old GDI code rewritten in Rust as success stories to justify his mandate. Not convincing at all.

Azure node software can be written in Rust, C, or C++ it really does not matter.

What matters is who writes it as it should be seen as “OS-level” code requiring the same focus as actual OS code given the criticality, therefore should probably be made by the Core OS folks themselves.

It’s org-dependent. On Windows, SAL and OACR are kings, plus any contraption MSR comes up with that they run on checked-in code and files bugs on you out of the blue :) Different standards.

The hardware only understand addresses and offsets, aka pointers :)

Integration tests (I think we call them scenario tests in our circles) also only tend to test the happy paths. There is no guarantees that your edge cases and anything unusual such an errors from other tiers are covered. In fact the scenario tests may just be testing mostly the same things as the unit tests but from a different angle. The only way to be sure everything is covered is through fault injection, and/or single-stepping but it’s a lost art. Relying only on automated tests gives a false sense of security.

?

Search VMS stability, I think the consensus is clear.

Then Google VMS longest uptime, and the record is 28 years. VMS often achieved five nines over 10 years (99.999%) so no irony.

He took a bunch of folks with him from DEC to Microsoft to make NT, and of course his principles.

Nowadays NT is bomb-proof believe it or not.

Most of the crashes are in device drivers and some rare times in the UI code (Win32k) that should not be there, but the kernel itself is solid.

(Yes I am a big fan)

Sorry you felt like that.

And yet, there we are.