[o8r3oFTZPE]

"For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product."

That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet.

Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "security experts" on how Microsoft has made such amazing strides in securing Windows (a tangent). In the real world, outside the Redmond/Silicon Valley monopoly space, how many mistakes does someone have to make before we start to suspect there might be problems with relying on that person's work. Even more, how many times do we hire someone knowing they have made 500+ mistakes in prior work leading up to their application.

If Microsoft products are so infallible when used as instructed by Microsoft, then why would Microsoft have a heart attack as Snowden suggests. What a remarkable state of affairs we have today where employers such as Microsoft can call their employees "engineers", and yet both the employer and employees are absconded from any liability for the so-called engineer's work. The number of "second chances" Microsoft gets is nothing short of astounding. A bit like the number of pardons we allow to Google or Facebook for privacy infractions. Infinite.

https://www.nspe.org/resources/professional-liability/liabil...

[dmoy]

Most of the people I went to Uni with ended up in fields where the companies are liable for bad stuff, to a certain degree. It does exist. However:

* you get paid a lot less

* the companies and industries move very slowly

* you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things

I mean like Real Engineering fields. What we do in software is not real engineering, not even close. That has pros and cons.

I saw someone else talking about Rust, but I don't think that's what would happen in such a world. Rust is too new, if the company was actually liable for problems, the legal arm of the company wouldn't let you use it. I think what would happen is that everything would slow way down, half or more of the people working on code right now would lose their jobs, hobby programming would either disappear or become very insular and not well-distributed (because if companies are liable, then individual people will also get sued for bad software), and you'd spend most of your time working with small pieces of 30-40 year old technology.

I think that eventually, software may get to such a point. Just, be careful what you wish for.

[nextos]

I completed a MSc in Formal Methods a decade ago, and I've worked in software projects where the level of rigor was equivalent or superior to any classical engineering field. For example, railway signaling or some real time control systems. We handed in complex artifacts that have had zero defects throughout their lifetime (> 15 years).

I believe lightweight formal methods are quite promising and might let software move relatively quickly and economically while retaining some rigor. Look into Liquid Haskell for some ideas that might become mainstream.

[kreelman]

Liquid Haskell looks similar to Eiffel in terms of contracts.

I imagine a whole bunch of power could be derived from this in Haskell. I don't know how heavily contracts were/are used in Eiffel (I don't think it's so popular these days).

It would be great to know if contracts had a measurably useful outcome on projects and what that measurable was (addressed a market that we otherwise wouldn't have been able to, dropped runtime errors to only system based errors, etc).

WRT your projects, I imagine it would be great to see your product out there working with a known level of uptime and quality. I could imagine it's a bit of a shift from the normal "throw it together" of ... a lot of software.

I'd be curious to know what it's like to work on day to day, year to year. I imagine lots of software will still be "throw it together" for a long time yet, but even if the subsystems are formally verified, it could have a useful impact on the software that consumes these (verified) modules.

[nextos]

Liquid Haskell is a bit different from Eiffel. On Eiffel, contracts were designed to be verified at runtime. There were some efforts to verify them at compile time, like Liquid Haskell does, but that's hard unless the whole language and type system are designed for that from the ground up.

As for my day to day job, I think the real difference with common software development was that requirements were very well understood right from the beginning. This allowed us to formalize them into axioms and then derive the implementation in a stepwise fashion using some Standard ML tooling.

I've also worked on proving theorems on existing software artifacts, but that's way harder both in terms of effort and number of defects.

[dmoy]

I personally think it would be excellent if that was the only way you were allowed to code. Though I'd probably lose my job haha. I'd sleep better at night.

[throwmeawayya]

How does liquid haskell compare to typescript?

[CrazyPyroLinux]

Obligatory joke: https://twitter.com/fireship_dev/status/1383835506664906756

[Veserv]

The gp is arguing that companies should be held liable for the harm that they can and do cause. You are countering that argument by claiming that doing so would require all companies to adopt onerous measures. However, that counter argument is only valid if we assume that all companies can cause the same amount of harm and thus have equal liability, and that doing so is unavoidable.

That assumption is deeply flawed. We do not hold toy car manufacturers to the same standards as actual car manufacturers. We do not hold every manufacturer of screws to the same standards as the manufacturers of screws on airplanes. Or rather, we do hold them to the same standards, just we know that certain use cases basically can not cause too much harm in the event of failure and thus in practice the standards needed to mitigate the worst case are much lower.

Software liability does not mean that everybody suddenly needs to take the same care as safety-critical industries. It only means that if you are making safety-critical software and you are incapable of separating the safety of the critical components from the non-critical components. What it really means is the repudiation of the one-size-fits-all lowest common denominator expectation of quality.

[Spooky23]

Liability just means more controls to avoid blame and tighter specifications. Malpractice laws don’t make doctors less dangerous, they mostly encourage ass covering exercises.

I worked at a place that had a formally verified application running on some mainframe. It was wonderful, except that the process was excruciating and maintaining that validation prevented any changes. Every code change cost a minimum of $25,000 2002 dollars.

It was dumb. They would have been better off with a paper process and army of clerks.

[nyolfen]

how does linux fare in this scenario? few things are as critical in terms of infrastructure

[II2II]

I can imagine two possible scenarios for Linux (the kernel): companies either choose to double down on it as a collaborative venture in order to distribute the cost of verification, or it is abandoned in favour of vendors who provide verified kernels at tremendous expense but in hopes of locking their competition out of the market.

As for the rest of the open source ecosystem that goes into Linux (the operating system), it would probably be abandoned.

[jodrellblank]

All the internet backbone routers, endpoint routers and switches, hardware firewalls, VPN concentrators, the SSH daemons, SSL software, RSA keyfobs and the like, the content delivery networks and DNS ecosystem, SSL public trust system, the connectivity providers from ISP networks and national and international fibre connections to cellular and wifi networks, web browsers which billions of people use to interact with untrusted content, (datacenters, AT&T Long Lines building style classic phone system, the postal service, electricity subsystems, food and water supplies...), even staying in tech you've basically got to exploit something else before you get to whatever underlying OS there is and even if you get to it there's not necessarily a need to attack it.

NotPetya which took down Maersk and did $300Mn of damages was apparently spread (through their Windows AD) by compromised admin accounts which they were lax at managing[1] rather than kernel exploits. The SolarWinds Orion security flaws were blamed on weak passwords, not OS kernel exploits. And if getting inside, something like last month's SystemD/polkit exploit[2] shows that attacking the kernel isn't always necessary for privilege escalation.

Linux the kernel is important but it's the heart inside the ribcage, not the first or last line of defense, or the main thing to target.

[1] https://gvnshtn.com/maersk-me-notpetya/

[2] https://github.blog/2021-06-10-privilege-escalation-polkit-r...

[d110af5ccf]

The point is that if legislation were introduced that resulted in liability it would likely completely decapitate the FOSS ecosystem (among other things).

[jodrellblank]

Why would it? If faced with the choice of taking liability for using Linux or rebuilding Amazon shop + AWS + Kindle + Echo on Windows I'd guess Amazon would do the former, wouldn't you?

[zarzavat]

Actually it's simpler. People and organizations would just move to a jurisdiction where such liability laws didn't exist. Apple would move. Microsoft would move. Google would move.

And then the US would be forced to decide whether to accept imports of foreign devices and software (created under the no-liability framework) or to stay with homegrown technology frozen in time.

The best thing you can say about this proposed reform is that it would make a great plot for a sci-fi novel.

[csande17]

Tech companies can't even manage to leave San Francisco's outrageous cost of living and rising crime, much less the United States.

[pvarangot]

You think they are trying? When VC and executives live in walled castles and own multiple rental and investment property?

I mean the hub thing and synergistic collaboration are cool but employees are not 3x more productive because of it.

[sumedh]

> or to stay with homegrown technology frozen in time.

Why would it be frozen in time?

[d110af5ccf]

> Why would it be frozen in time?

Local development would rendered unable to compete with the fast moving zero-liability model that quickly and cheaply delivered the features that consumers wanted. Either it's import would be banned or the local industry would crumble.

[zucker42]

I don't completely disagree but

> you get paid a lot less

Isn't that the point? That is, the argument is right now the money goes to the devs, management, and stockholders, when it rightfully should go to those people damaged by the software (or toward preventing them from being damaged).

> the companies and industries move very slowly

How much of this is due to liability law and how much is due to natural aspects of the relevant technology? Liability law may be part of the reason, but software probably naturally moves faster than other engineering fields.

[etripe]

> Isn't that the point?

If the money is supposed to go towards people preventing damage, wouldn't that include devs?

> How much of this is due to liability law and how much is due to natural aspects of the relevant technology?

I can only speak from my own experience in biotech, but moving slowly was due to a lot of compliance box-ticking that didn't actually contribute a lot to either safety, reducing defect rate or meeting requirements. Conway's law applied: since bio engineers and lab techs move slowly, so did the software org.

[imglorp]

> fields where the companies are liable for bad stuff...

> * the companies and industries move very slowly

The reason the rest of us move so fast is we skip safety, security, quality, and maintainability to get to market. Those things are usually perceived "not bringing immediate customer value".

[throwmeawayya]

> The reason the rest of us move so fast is we skip safety, security, quality, and maintainability to get to market.

And deliver cheaper results.

[failuser]

And still, the Toyota breaking microcontroller code showed that coding practices in Real Engineering are somehow even worse. I hope that improved since then.

[iamstupidsimple]

> What we do in software is not real engineering, not even close.

The only reason our processes and practices aren't much heavier is because the stakes are lower. People do not die if a Tweet doesn't make it through, but they do if a bridge collapses through.

The threat model is also significantly different. If we go back to the bridge analogy, a company like Microsoft has to deal with tens of thousands of people trying to blow it up or find some weakness every day, while a million people are going over it. Just by sheer laws of scale they are going to have a tougher time, Real Engineering or not.

[user3939382]

> People do not die if a Tweet doesn't make it through

True, and what you're saying is generally true. But what were the total consequences of the Equifax breach? We can't even quantify it. Snowden himself in the article mentions activists and journalists being killed because of these vulnerabilities. There are definitely counterexamples.

[iamstupidsimple]

That's true. I suspect part of the problem there is lack of liability and therefore lack of willingness to pay for security. They're just going to lose the best security engineers to Google and Microsoft.

[d110af5ccf]

That is due to issues with how Equifax operated (and related lack of meaningful consequences). It has nothing to do with a lack of liability for software companies.

[quickthrower2]

Is moving more slowly in software a bad thing? I can just imagine an alternative world where people are better off, using sites that look like HN but are secure and work in their best interest.

[Sophistifunk]

There would be no sites. There would be no web.

[tester34]

>I mean like Real Engineering fields. What we do in software is not real engineering, not even close. That has pros and cons.

"Real Engineering" has definition and it fits SE, doesn't it?

Computer industry iterated and managed to reach the point where we can move really fast and do not break computers with bad code. That's result of thousands of hours of engineering effort of previous generations.

>Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings. The discipline of engineering encompasses a broad range of more specialized fields of engineering, each with a more specific emphasis on particular areas of applied mathematics, applied science, and types of application. See glossary of engineering.

[markus_zhang]

How about hardware engineers or software engineers working on hardware? I figured it achieves a certain middle ground. You are still writing code but you get to touch real things and may burn yourself if you work closely with the hardware, plus you need to pay more attention to security.

[vagrantJin]

> I saw someone else talking about Rust, but I don't think that's what would happen in such a world.

I agree.

Let's not use tools as a crutch. Roman engineers built bridges that are still standing today with little to no maintenance. There's no indication that those structures are going to fail anytime soon either. I think we can agree that their tooling was worse than our current bridge building tools.

> I mean like Real Engineering fields. What we do in software is not real engineering, not even close. That has pros and cons.

So the word engineer is probably loaded if not dated, a throwback to engineering's boom in the 19th and early 20th century. No idea why we still use it since software is more like math than anything else. Computer scientist just never stuck.

[denton-scratch]

> Roman engineers built bridges that are still standing today

Roman engineers didn't understand the principles of civil engineering; I'm sure they built a lot of stuff that fell down (survivorship bias). So they started massively over-engineering their structures ("moar rocks!")

[vagrantJin]

> I'm sure they built a lot of stuff that fell down

Survivorship bias is the favourite catchphrase for HN these last few years.

I think you overestimate the importance of academic theory over practicality.

"Moar rocks" is a perfectly reasonable way ro fortify a structure. Because 1000 years from now engineers will be wondering how any of our stuff survived ("moar cement and steel rods!")

So yeah, I have a healthy respect for practicality.

[golergka]

Sounds more like Ada than Rust.

[renewiltord]

So called "Real Engineering" fields kill people at such a high rate. Software engineers are way better. Despite all the value created, a vanishingly small number of people have been killed.

That's the funny thing. As a software engineer, if I have to build something that might kill someone, I just don't do it. But so-called "real engineers"? Bam, condo building down, people dead. Bridge down, people dead. Tacoma Narrows? Experimenting on people.

If "real engineers" were half as good at their job as I am at mine, we'd have a space elevator and people would be going up and down it every hour and the only problem they'd face is that the music is sometimes not that great. But they're too busy killing people to create $10 in value. I'm too busy not killing people and creating $1 million in value. The numbers don't lie, dude. The numbers don't lie. More value made. Fewer dead people.

People don't like to hear it because of the fetishization of this "Real Engineering" nonsense. But it's true. Software engineering's generational scandals are outdone by a "real engineering" project every day.

[c-cube]

Maybe it's because real engineering has higher stakes than a crud app. Condos can kill, bridges can kill, Javascript forms or video game engines generally can't. If they could we'd witness a lot more deaths, despite your confidence.

[renewiltord]

I have a personal philosophy: "if you can't do it well, don't do it at all". That's because I prize my ability at what I do. I am good at it. I am a craftsman. Not like these fly-by-night characters busy dropping concrete on people's heads. Maybe I need to teach these "real engineers" something about building things haha: "If you can't do it without killing people, don't do it". Man, that's a motto for the ages. You'd think you don't have to teach people that, but here we are.

Maybe we should teach them ethics, because whatever class they took on that, it didn't take. As a practitioner of quality and making money with zero killing, I could help.

[Nicksil]

>I have a personal philosophy: "if you can't do it well, don't do it at all". That's because I prize my ability at what I do. I am good at it. Maybe I need to teach these "real engineers" something about building things haha: "If you can't do it without killing people, don't do it". Man, that's a motto for the ages. You'd think you don't have to teach people that, but here we are.

You're trying too hard. It's embarrassing.

[strangeattractr]

Why bother with the software engineering, your moral sensibilities are needed everywhere. It's not every day someone emerges capable of writing a todo app in react without killing anyone

[renewiltord]

HAHA! What can I say? Some of us are made of sterner stuff.

[jazzyjackson]

I see an awful lot of skyscrapers not falling down every day, stands to reason some engineers are good at what they do, no?

[renewiltord]

Oh there are good engineers, certainly. But the field as a whole clearly is immature since it causes more deaths than software engineers do.

[markus_zhang]

I actually agree with you. People keep doing shitty jobs in real engineering e.g. construction. It's just most of the time people don't have the skills to notice it.

[stickfigure]

We tried this with general aviation. Private plane manufacturers all went bankrupt, and now the minimum price for a new airplane is in the hundreds of thousands of dollars.

Apply strict liability to software, and you'll see the same results. Every piece of software will have to be constructed with the care of a medical device. Expect most forms of technological progress to come to a halt. Some part of the HN crowd will post "I want that" from their iphone (which wouldn't exist under such a regulatory scheme).

[SamuelAdams]

I’m reading a book called “An American Sickness” and it discusses medical devices. Turns out a lot of them are pretty poor and often have less testing and verification than most people think.

There’s one story about a hip implant that went bad. Turns out the doctor recommending and performing the surgery was also the patent holder and had a vested interest in getting this particular implant in as many patients as possible. Turns out the patient was actually patient #8 who received this particular implant. Also the implant wasn’t fully approved yet and the FDA simply trusted the doctor to monitor the device for problems.

Also this isn’t isolated. The chapter has several examples of medical devices going into patients and patients experience negative health outcomes. Turns out laws are only as good as the agencies that enforce them.

[aeternum]

Even with perfect enforcement, how do you tell if/when the laws stifle innovation?

If a company makes a bad implant, it's very visible, but all the potentially improved hip implants that never get built because of the barrier these laws create are invisible.

[mehlmao]

Private plane manufacturers went bankrupt, but more importantly, plane crashes have become incredibly rare.

[ARandomerDude]

True but that's the trivial case. You'll never get food poisoning if we outlaw food, never get into a car accident if we outlaw cars, ...

The point is there should be a better way that just pull the plug on anything potentially unsafe.

[pjmlp]

Generally I get food poisoning when the restaurant, supermarket or producer fails to follow the health standards it is obliged by law.

And then I can sue them to death or make a report to health authorities that will act accordingly.

[michaelnik]

In parallel the GA planes used got old. Imagine the same happening for the software!!!

In 2000, the average age of the nation's 150,000 single-engine fleet was more than 30 years. By 2020, the average age could approach 50 years

https://www.faa.gov/aircraft/air_cert/design_approvals/small...

[michaelnik]

I don't know about "rare", since 1999 the broadest "accident" statistic fluctuates around 6 per 100,000h

Notice that "accident" definition conveniently excludes tons of partial failures! (see the legalese of 49 CFR § 830.2 - Definitions.)

To make parallel with broader discussion, the security failing of software could be considered "partial failures"...

[chevill]

>How many mistakes does someone have to make before we start to suspect there might be problems with relying on that person's work.

There's a lot of legitimate criticisms about modern OS security, whether we're talking about Linux/Android, MacOS/IOS, or Windows. However, we can't ignore the scope of these programs. Supposedly Windows 10 is approximately 50 million lines of code and due to its overwhelming popularity it has almost certainly been targeted more often than all of the other OS's listed combined. I am pretty sure all of these operating systems are > 10 million lines of code.

Whose work are you going to rely on instead? The level of security in these OS's isn't equal across the board, but I assure you zero days exist for all of them and barring some kind of miraculous technological breakthrough, they'll continue to pop-up from time to time as long as they exist.

Suppose someone pulled off a miracle by making a security-focused OS that's easy for non-technical people to install and use and actually gains enough traction to establish a market share. If such a thing existed it would likely get lots of things right where others have failed, but they would also likely get lots of things wrong. It doesn't mean we shouldn't try and it doesn't mean we shouldn't encourage both old and new companies to try and improve the situation, it just means that its an incredibly difficult and likely never-ending task. Security is a process, not an achievement.

[failuser]

Does it need to be 50 million lines of code? When you design with security in mind you might have to prune old code and drop some risky optimizations, probably drop some features. Using a higher-level language might help reduce the line count as well at the cost of performance and memory consumption.

[chevill]

>Does it need to be 50 million lines of code?

Probably not and they should try to reduce the size if it makes sense. However, if all of the OS's I listed are above 10 million lines even in the best case scenario a modern operating system isn't going to be anything less than an overwhelmingly large and complex program.

[vineyardmike]

> Even more, how many times do we hire someone knowing they have made 500+ mistakes in prior work leading up to their application.

While i don't disagree with the point you're making entirely, I have made many mistakes in my career and i still get hired and i suspect you have too. Most people make mistakes, and still have jobs.

Realistically, people/orgs make mistakes. Requirements change. Expectations change, security practices change, etc.

Roman bridge engineers would likely struggle to build bridges at the scale and requirements they're built to in 2021 (miles long, tall, huge train weights, etc). Things change in technology jobs a LOT faster than typical NSPE engineering licensees' jobs. Its a different world. There are probably bridges under contruction today that were designed before the iphone.

[api]

Put liability on software and you will halt innovation almost completely. It won't lead to a utopia of provably safe systems and secure languages, but to a dystopia of paranoid risk-averse companies refusing to allow any form of innovation or use any code that is not already in use. Instead of clean bug-free code we'll end up with code that looks like OpenSSL, ugly as hell but relatively bug-free after decades of brute force fixing.

[zizee]

Microsoft and friends would love this, as it would result in such a huge barrier to entry that only those who could pay large amounts for insurance woyld be able to enter the market, with insurance built into the price of the software.

Say goodbye to open source software!

[maliker]

My guess is the ‘users didnt know what they were doing defense.’ Not that you can deploy software in a secure by default stance. But once somebody sets up users and a million other settings inside Active Directory, it’s pretty much bound to be insecure. And then the defense is akin to ‘you werent supposed to crash the car into the tree’.

[bigiain]

I guess they blamed "the army that didn't know what it was doing" for using that bridge wrong too. So it's not _just_ software "engineers"... <grin>

[beezle]

Masterlock is still in business, right?

[ChrisMarshallNY]

Regardless of all that, I would love to see a big improvement in basic software Quality.

Easy to say; not so easy to do. It is actually difficult to answer the [seemingly] simple question “What, exactly, is ‘Quality’?”.

I think I do a fairly good job, there, on my own work, but what works for me, won’t work for most.

[jodrellblank]

It is possible to build a bridge which doesn't fall down during normal use. Has any company demonstrated that it's possible to build large scale software with no security flaws in it? Microsoft haven't, Apple haven't, Google haven't, Facebook, IBM, Oracle, RedHat, Amazon, Cisco, Juniper, The Pentagon, The Whitehouse, The UK Government, the fact that we've heard of Snowden suggests the NSA haven't, banks haven't, airlines haven't, medical companies haven't, Cloudflare leaked memory to the world, Symantec screwed up SSL authority handling, BGP was hacked to steal cryptocurrencies. It's possible to commit to building a bridge and then everyone must wait patiently for the bridge to be finished - there's no push to have the bridge done in 6 weeks because another bridge is being built in the same place and if it appears soon all the traffic will be lost and the build cancelled.

Who even stands a chance? Colin Percival - math prodigy, cryptographer, former FreeBSD security officer - has paid out thousands in bounties for over two hundred bugs in Tarsnap software (not all security flaws) including buffer overflows, divide by zero, double-frees, mistakes in error handling, Unicode string handling error, numeric overflow mistakes, padding errors, user input handling bugs and one "critical security flaw" (against his very high standards) - https://www.tarsnap.com/bounty-winners.html

If someone like that working full time on a very constrained single purpose product can't make flawless software, what sense does it make for you to sneer at Microsoft as if Windows is singularly flawed here?

> "If Microsoft products are so infallible when used as instructed by Microsoft, then why would Microsoft have a heart attack as Snowden suggests."

They aren't, they're Swiss-cheese. So is approximately every other general purpose computing product, software and hardware, with the possible exception of a handful of very small very specific battle-hardened tools. Even the non-general-purpose walled garden appstore devices are Swiss-cheeses.

Possibly their heart attack would be because they are one of the biggest software development companies on the planet with a huge range of products used in tons of companies, so such a regulation would disproportionately affect them more than most companies? "All" Facebook develop is a web page, and very few companies use Facebook or Instagram or Oculus except by sending money and adverts to Facebook. Microsoft would have to secure a ton of large-scale software used on company premises in environments they have no say in. Seems to me the result of such a ruling would be something like Microsoft stopping selling on-premises software entirely and offering only web access to hosted Outlook, Office365, SharePoint, SQL, Biztools, Dynamics, with a ton of extra checks slowing them down, and companies faced with either using Microsoft online tools where Microsoft is responsible for the security or choosing on-premises tools like LibreOffice and Thunderbird and FireFox where they have to take responsibility, their legal and insurance would push them to Microsoft world with even less configurability or interconnectivity than there is now. It may be more secure, it doesn't sound great.

> "Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "security experts" on how Microsoft has made such amazing strides in securing Windows (a tangent)."

Not a tangent; Look at the recent discussion on HN about Windows Defender, and pretty much any security choice - it's full of people bemoaning Microsoft making decisions that are mildly inconvenient on the grounds of "how dare they think they know better than me", "I demand to be able to turn these security features off", "I want control to be able to do anything". If Adobe Reader is vulnerable and lets someone ransomware all your documents, what benefit is it to you if Windows underneath is an impregnable fortress? If someone can steal a user's 2-factor auth backup code from their house and access their remote VPN and exfiltrate data, what good is a perfect OS underneath doing for anyone?

This isn't whataboutism ("others are insecure so why can't Microsoft be"), and although it is somewhat in defense of Microsoft it's not "waah leave Microsoft alone", it's ... what kind of world are you living in where you heavily imply that Microsoft could have done differently and didn't? Microsoft trying to write Windows 3.1 in Pascal or ADA would have had their lunch eaten by every other company which didn't.

> "What a remarkable state of affairs we have today where employers such as Microsoft can call their employees "engineers", and yet both the employer and employees are absconded from any liability for the so-called engineer's work."

You think changing their job titles to "programmer" would improve the situation?

[smolder]

> Not a tangent; Look at the recent discussion on HN about Windows Defender, and pretty much any security choice - it's full of people bemoaning Microsoft making decisions that are mildly inconvenient on the grounds of "how dare they think they know better than me", "I demand to be able to turn these security features off", "I want control to be able to do anything".

I think it's somewhat reasonable to complain about the approach taken to security in Windows. MS had a lot of work to do to stay on top as long as they did, but they were also extremely well resourced and dominant for a significant time, where they could have made bigger systemic changes to prevent swiss cheese getting released in the first place. They could've built their own rust-like language, maybe, built some great static analysis & fuzzing tools, or generally advanced their own internal exploit discovery to beat outsiders to the punch. That we've mostly settled for constant security updates upon exploit discovery in the wild and blindly assuming super old code is safe (until it isn't) seems like a failure to act (a failure of incentives?) and not a necessity.

[jodrellblank]

> "They could've built their own rust-like language"

They tried. Windows Longhorn was to be "entirely" managed code in the early 2000s, by 2004 they walked that back because vendors didn't want to rewrite their software for managed code and there were too many performance issues. Then they scrapped Longhorn altogether. As a research project they built: "Midori is an operating system that did not use Windows or Linux. Was written in C#. Took 7 years to build and included device drivers, web servers, libraries, compilers and garbage collection.". From what I know, they tried harder than Apple+macOS or anyone+Linux kernel and couldn't do it. To then casually say "they could've" is not so convincing. Especially if in this "you're responsible for bugs" world they would have had to have Proto-Rust production ready around the time of Windows NT in 1993 or so.

https://www.theregister.com/2005/05/26/dotnet_longhorn/

https://www.theregister.com/2004/05/06/microsoft_managed_cod...

https://www.infoq.com/presentations/csharp-systems-programmi...

https://news.ycombinator.com/item?id=27809296

> "That we've mostly settled for constant security updates upon exploit discovery in the wild and blindly assuming super old code is safe (until it isn't) seems like a failure to act (a failure of incentives?) and not a necessity."

The blogpost I link below[1] was written in 2004, and he says "I truly believe that the patching fad in which we are currently living is not going to last much longer. It can't. In another couple years, we'll have one full-time patcher to each system administrator. What's odd is that if companies simply exercised a bit of discipline, it wouldn't be necessary at all. Back in 1996 a buddy of mine and I set up a web server for a high-traffic significant target. It was not the Whitehouse; it was a porn site. We invested 8 hours (of our customer's money) writing a small web server daemon that knew how to serve up files, cache them, and virtualize filenames behind hashes. It ran chrooted on a version of UNIX that was very minimized and had code hacked right into the IP stack to toss traffic that was not TCP aimed at port 80. 10 years later, it's still working, has never been hacked, and has never been patched. If you compute the Return On Investment (Or ROI in the language of Prince Ciao) it's gigantic."

And yet the patching fad has got hugely worse since then, and all the factors he complains about - CEOs buying from salespeople, desire for customisability and flashiness - are all still driving the industry hard.

[1] http://www.ranum.com/security/computer_security/editorials/m...

[smolder]

I appreciate your reply. I had heard of Midori but didn't know much. It's good to learn more about those efforts.

Even when I say "they could've", it was in some part wishful thinking that we can even get to a state of the art where constant bug-patching can go away. I believe we can in theory. I also know that the nuance of reality often gets in the way of that kind of idealism.