Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decisions that eroded trust in Azure – by a former Azure Core engineer

isolveproblems.substack.com

Post reply on HN
Print view View original

681–690 of 697 posts

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#681

Post by dralley »

egorfine wrote: post #652
jasomill wrote: post #639

Earlier quoted context omitted.

Not at all. Most programs only use one or a few hash functions, so grouping each family into a separate crate reduces compliation time for the majority of users. Could also help when auditing the removal of vulnerable hash functions. As for ripgrep, the organization is quite sensible: 1. one crate to define an interface for regex matchers 2. one crate to implement the native matcher 3. one crate to implement the PCRE…

Yes I perfectly understand the reasoning and technically it is sound. It becomes insane once you start thinking of real life implications, specifically supply chain attacks. Although it's only marginally more insane than the other ecosystems.

The alternative is sometimes that people just copy and paste code from libraries that never gets updated.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#682

Post by jnsaff2 »

bytefish wrote: post #319
jamwhite wrote: post #139

This read was a blast from the past. I'm not going to comment on much from OP and instead give a little of my experience there. Straight out of college in 2017 I joined the Compute Fabric Controller (FC) org as a SWE on an absolutely wonderful team that dealt with mostly container management, VM and Host fault handling & repair policies, and Fabric to Host communication with most of our code in the FC. I drove our te…

The first and most important lesson, that I try to each every young developer starting in the industry: Go home after clocking in your hours negotiated in your contract. Drop your pen. Go home. Sleep well. And I hope, that every sensible senior developer in here does the same. Lead by example. Maybe it would prevent a few burnouts in this industry. And if you are a manager, then send your people home after they have…

The important nuance: you need to start going home at the correct time on day one. You can't start doing that when you feel overwhelmed already as the expectations have been solidified already.

The corollary is that you also need to show up on time and put in honest effort during.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#683

Post by staticassertion »

Spooky23 wrote: post #674
staticassertion wrote: post #662

Earlier quoted context omitted.

I have no idea what you're talking about. This has nothing to do with having "better fedramp certs". If you are setting up fedramp or cmmc you will be heavily, heavily pressured and incentivized to do so with Microsoft tooling. "Better" isn't relevant, which is my entire point. The reason people choose Microsoft isn't "it's better for this", it's because every consultancy out there, every government agency or affilia…

I’ve been in the space for 30 years. Nobody is pressuring anyone to buy Microsoft because of FedRAMP, and Microsoft is not even close to having any advantage with respect to FedRAMP vs their competitors. FedRAMP is demonstration that the solution met some assessment of controls in alignment with NIST 800-53. As a checkbox, it’s almost as dumb as FIPS 140, and like FIPS, you need to asses risk for your implementation…

What's the most common architecture you see for CMMC enclaves, especially those built by outside consulting firms?

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#684

Post by worik »

CoolGuySteve wrote: post #680
dbdr wrote: post #676

Earlier quoted context omitted.

Ref counting is deterministic. Rust memory management is also deterministic: the memory is freed exactly when the owner of the data gets out of scope (and the borrow checker guarantees at compile time there is no use after that).

Cool now use the reference on another thread.

If you would use Rust, you would know that problem is solved too.

Rust solves a lot of problems, and introduces others

The promiscuous package management, chiefly. Not unusual for building a imlle programme in Rust brings in 200+ crates, from unknown authors on the Internet...

What could possibly go wrong?

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#685

Post by axelriet »

markus_zhang wrote: post #603
axelriet wrote: post #570

Earlier quoted context omitted.

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 sof…

May I ask, what kind of training does the new joins of the kernel team (or any team that effectively writes kernel level code) get? Especially if they haven't written kernel code professionally -- or do they ONLY hire people who has written non-trivial amount of kernel code?

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.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#686

Post by axelriet »

voganmother42 wrote: post #323
locusofself wrote: post #227

Earlier quoted context omitted.

You also make it sound like getting a JIT approved is getting keys to the kingdom. It's not -- every team has it's own JIT policies for their resources. Should there be far less manual touches? Ideally. But JIT is better than persistent access at least, and JIT policies should be scoped according to principle of least privilege. If that is not happening, it's a failure at the level of that specific org.

200 requests a day, lol

on average :)

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#687

Post by ptdorf »

ludwigvan wrote: post #21

I had the misfortune of having to use Azure back in 2018 and was appalled at the lack of quality, slowness. I was in GitHub forums, helping other customers suffering from lack of basic functionality, incredible prices with abysmal performance. This article explains a lot honestly. Google’s Cloud feels like the best engineered one, though lack of proper human support is worrying there compared to AWS.

GCP's support sucks compared the quality on AWS. On everything else I find GCP very pleasant.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#688

Post by Spooky23 »

staticassertion wrote: post #683
Spooky23 wrote: post #674

Earlier quoted context omitted.

I’ve been in the space for 30 years. Nobody is pressuring anyone to buy Microsoft because of FedRAMP, and Microsoft is not even close to having any advantage with respect to FedRAMP vs their competitors. FedRAMP is demonstration that the solution met some assessment of controls in alignment with NIST 800-53. As a checkbox, it’s almost as dumb as FIPS 140, and like FIPS, you need to asses risk for your implementation…

What's the most common architecture you see for CMMC enclaves, especially those built by outside consulting firms?

I don’t work in defense, and neither does FedRAMP.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#690

Post by registeredcorn »

praptak wrote: post #228
branko_d wrote: post #205

I think this is especially problematic (from Part 4 at https://isolveproblems.substack.com/p/how-microsoft-vaporize... ): "The team had reached a point where it was too risky to make any code refactoring or engineering improvements. I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something." Once you reach this stage, the only escape is to first…

This isn't incentivized in corporate environment. Noticed how "the talent left after the launch" is mentioned in the article? Same problem. You don't get rewarded for cleaning up mess (despite lip service from management) nor for maintaining the product after the launch. Only big launches matter. The other corporate problem is that it takes time before the cleanup produces measurable benefits and you may as well get…

Perhaps an important question is: why is it not incentivized in corporate environments?

I think, however, that perhaps I'm asking in the wrong arena. Unless there are people here reading this who work in the areas of a corporate environment at the level at which those decisions are made, it would really amount to guessing and stereotypes. Generally, I like to think that just about anyone can grasp that a well-made product will sell better due to its nature. I think that there must be some kind of mutual disconnect between both sides where one continues to see improvements important, and the other fundamentally does not (or does not have a functional means to measure and verify it).

Post reply on HN