[aleph_minus_one]

> For whatever reason, distro maintainers working for free seem a lot more competent with security than billion dollar hardware vendors

I don't believe that these billion dollar hardware vendors are really incompetent with security. It's rather that the distro maintainers do care quite a bit about security, while for these hardware vendors consider these security concerns to be of much smaller importance; for their business it is likely much more important to bring the next hardware generation to the market as fast as possible.

In other words: distro maintainers and hardware vendors are simply interested in very different things and thus prioritize things very differently.

[Symmetry]

Years of working in embedded computing have left me with the impression that most hardware companies are just bad at software. I think part of it is that the long cycle times of making hardware push them towards a culture of waterfall development. But years of working with the microcontroller libraries for ethernet PHYs, the bash scripts to build the kernels for SoCs, etc make me perfectly willing to believe they are incompetent with security.

[M95D]

And which are the companies that are good at software? Please, give at least one example.

[hhh]

Apple

[hbn]

Everyone's gonna give you shit for this answer and there's a hundred things I could tell you about their software that pisses me off, but the bar is so low for software these days, their stuff is still in the high end of quality (they need to do a lot to get back to where they were 10 years ago though)

Only other software I regularly use that I think is overall high quality and I enjoy using are the JetBrains IDEs, and the Telegram mobile app (though the Premium upselling has gotten kinda gross the past few years)

[cmcaleer]

These days I use Apple hardware despite Apple’s software, not because of it.

[Telaneo]

They at least were good at software. The argument that they currently still are good at software is getting weaker and weaker.

[scns]

XCode and Tahoe beg to differ.

[mring33621]

Surely you jest, good Sir!

[4nonverbal-alit]

used to be. they're becoming microslop 2.0

[da_chicken]

Sure. New sales means new revenue. Maintenance and support is just overhead.

It's shortsighted, but modern capitalism is more shortsighted than Mr. Magoo.

[lloeki]

It's a cost vs benefit. As long as the cost of such blatant violation of security principles doesn't outweight the benefit of focusing on something else, nothing is done.

https://www.legalexaminer.com/lestaffer/legal/gm-recall-defe...

https://www.youtube.com/watch?v=IA2EBWFCULg

[jbstack]

I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.

[scott_w]

Because that's not how corporate maths works. The comparison is not "what is the cost of this vs our current revenue?" The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?"

Will fixing this issue bring in more revenue than ignoring it and building a new feature? Or fixing a different issue? If the answer is "no" then the answer is that it doesn't get fixed.

[jbstack]

> The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?"

I don't agree with this, because it pre-supposes that there's a limited number of engineers available. The question isn't "shall I pull engineer X off project Y so that he can fix security bugs?", it's "shall I hire an additional engineer to fix security bugs?". The comment above mine suggests the answer to that question is "no, because it's too expensive to do that compared to just paying to clean up security breaches after they happen", which is what I was questioning in my first comment.

[scott_w]

It doesn't matter: the equation is exactly the same. Why would you hire someone to work on a bug fix or security fix when you could hire that same person and have them work on something even more valuable again?

[lencastre]

ah corporate meff, if the claim is lower than the recall cost, pay the claim

[scott_w]

You can complain all you want about it but, unless you can push up the cost of the claim, that’s what corporations will do.

[dgoldstein0]

First they have to hire a developer with knowledge of how to do this right, as they might not even have one. Which could easily eat 10k+ of dev time as hiring good people takes a lot of time.

[autoexec]

You could probably take any user at random from this discussion alone and they'd have the knowledge needed to make the switch from http to https. I'm certain that AMD has all the knowledge they need right now, but even more certain that it wouldn't be hard to hire someone new who does as well

[jbstack]

Ok, but this ultimately just comes down to a debate over the amount of the cost. The principle is the same. Even if we double or triple the cost, it's a drop in the ocean for a company like AMD.

[tw04]

You don’t believe it? It took until the early 2000s for Microsoft to take security seriously and they were a money printing machine.

[jbstack]

I didn't say I don't believe it happens. I'm saying I don't believe it's a based on a cost benefit analysis. I.e. that in a multi-billion dollar company someone consciously ran the numbers and decided "it's cheaper for us to pay to clean up the mess if there's a security breach than it is to hire someone to fix security bugs". The cost of the latter is too low for this kind of logic to make any sense.

I think it's more realistic that in any sufficiently large company the bureaucracy is so unwieldy that sensible decisions become difficult to make and implement.

[bigfatkitten]

That was a brief chapter in Microsoft’s history. Satya Nadella stopped taking security seriously the day he got in.

[zeendo]

This comes down to intentions versus results. Viewed through the lens of results the comment you're replying to is still correct: The result is incompetence. I'd argue that's the only lens that matters when you're on the receiving end of such work.