LWN: Comments on "Woodruff: Weird architectures weren't supported to begin with"

Woodruff: Weird architectures weren't supported to begin with

mrugiero — Thu, 22 Dec 2022 06:25:42 +0000

> Any idiot who decides it would be a good idea to grab a pile of pre-existing code written by a no-name rando with a net worth of a few thousand dollars and stick it in their widget without stopping to ask themselves "should I really trust, without further verification on my part, this software written by some no-name rando whose response to a liability claim would be to declare bankruptcy because the legal fees alone would be more than their combined net worth and gross annual salary?" needs to reconnect with reality.

And that's, IMO, where the regulation should start and stop.
You provide a paid product or service? Either you can prove who provided your supplies or you're directly liable. In other words, a proper regulation wouldn't be about what's required for you to do something, but what's required for those who are supposed to "guarantee" it works correctly.
One of those requirements is have a face and name for everyone involved in the making. If you can't do that for an open source project, then don't use it for your product or you're liable for any defects it may have. The author of such code should still be one with full choice about whether to remain anonymous, it's you as downstream that's responsible of picking only the public ones. Anyone who decides to use the anonymous' code is legally responsible for doing so.

So layering is no longer a thing?

mrugiero — Thu, 22 Dec 2022 06:06:24 +0000

> Imagine a hypothetical situation where the LLVM developers change their code in such a way that it can no longer be used for Rust for code generation. Would you also accept the answer "Well, then go and maintain an old fork of LLVM yourself!"?
>
> Or a big company like Google becomes in charge of the Linux kernel development and make such drastic changes to the codebase that the kernel will only run on ARM and POWER devices. Would you also accept the answer "Well, then go and maintain an old fork of the kernel yourself if you need it for x86_64!"?

You may not like it, but that's 100% how any kind of community effort works. Either you do the work, or you don't. If Google becomes in charge of mainline Linux kernel development and does whatever, either a community of devs decides to fork, or they don't and it becomes Google's shop. Under no circumstances Google decides it's time to think of the poor little users. If you expect that, you'll live floating from disappointment to disappointment.
So, yes, that's an answer I would accept, because just as I value my time and expect you to respect it I owe other people respect for theirs.

> My point is: Linux distributions are made possible because traditionally because stable APIs made it possible for everyone to assemble their system of choice on their platform of choice. Be it Debian with a FreeBSD kernel or an open source fork of Solaris on x86_64. Everyone has been able to use what they prefer in the configuration they wanted with the individual components such as GNOME, Emacs, GCC, libpng etc being highly portable thanks to using stable APIs.

More than anything else, distributions are made possible by people doing the work, not by the spectators booing from the grades.

> Now all of a sudden, the Rust community comes around, takes core projects and rewrites them in Rust causing a conflict with users which use exotic setups. And instead of trying to intermediate according to their "openeness and inclusivity" principles, they just alienate these users and tell them to stop using their custom setups and just use something more mainstrean.

Now all of a sudden, the exotic setup users tell the developers to stop using their tool of choice that makes their lives easier to stick to that stuff they need to keep their exotic setup working, and do it for free while they're at it.
So, why do we expect these devs to keep supporting these users' software when they're not willing to do the same. The first sign of laziness is feeling insulted when someone suggests you should pull up your sleeves and do the things that are on your own interest (and possibly only yours).
Pragmatically there's only three ways to solve this disagreement:
- Fork the original code;
- Implement support for your fringe platform in LLVM;
- Use the old version.
Note how none of them is "make the other person do it for me"?

> The Rust community is hampering their own success as there are projects that would like to use Rust code, but they are currently holding off these plans due to the fears of reduced portability.

Such as?

Woodruff: Weird architectures weren't supported to begin with

mrugiero — Thu, 22 Dec 2022 05:55:17 +0000

> -- Linux kernel port

Certainly.

> -- V8 JIT backend

If Microsoft is to be believed, this may not be necessarily true[0].

> -- Optimized codecs for some popular formats (JPEG, H264, AV1)

This depends. Does the architecture support PCIe? Can it use an existing GPU for that? Is the driver portable in terms of word size and endianess and all that?

[0]: https://microsoftedge.github.io/edgevr/posts/Super-Duper-...

More control over binary builds

epa — Sat, 20 Mar 2021 08:53:46 +0000

I am not saying the binary should be the only thing that exists, rather that the 99% of users who don't want local changes can download a known build. Big projects like Mozilla and Libreoffice follow this model, except where they are packaged by Linux distributions.

Woodruff: Weird architectures weren't supported to begin with

nybble41 — Thu, 18 Mar 2021 16:02:11 +0000

Yes, I agree that a C backend would be useful for cases like that. Though it might be a bit difficult to come up with a subset of C that results in reasonably performant code supported by all those niche compilers and can still represent everything that can be done with LLVM, including some features which were implemented specifically to support constructs from other languages which have no direct equivalent in portable C. (E.g., in Rust an unbounded empty loop is well-defined, but the same is not true in C.) The point was more that, in the future, I think it would be better to plan to implement an LLVM backend for each newly developed CPU—which gives you a C compiler, among others, "for free"—rather than planning to bootstrap everything through generated C code.

Woodruff: Weird architectures weren't supported to begin with

pabs — Thu, 18 Mar 2021 01:01:17 +0000

Another one is the ath9k_htc firmware, that uses a fork of the GCC xtensa code:

https://github.com/qca/open-ath9k-htc-firmware/

Woodruff: Weird architectures weren't supported to begin with

Cyberax — Wed, 17 Mar 2021 16:15:18 +0000

There are at least 3 different C backends for LLVM, in various states of disrepair.

Some time ago my friend tried to use Keil C compiler for 8051 (yeah, they are still widely used). The basic stuff worked outright, simple C++ programs compiled and ran. But it was slow, and the compilation process loosed special 8051-specific extensions that are needed in practice. They ended up abandoning C++ and just writing stuff in pure C.

I've heard that people trying to use LLVM for 8-bit x86 DOS have the same issues.

Woodruff: Weird architectures weren't supported to begin with

johill — Wed, 17 Mar 2021 08:04:27 +0000

> If you already have a decent C compiler for the new architecture then that might help.

There are probably *dozens* of (niche?) compilers for various CPUs. I was recently asked if something like wifi firmware could be done using rust, but given the toolchains involved, there isn't really a chance of that. One system which is documented is for ar9170 (https://wireless.wiki.kernel.org/en/users/drivers/carl917...) and that uses an sh-elf gcc compiler. And this is for an upper MAC, lower MAC stuff is often even more arcane, see e.g. https://bcm-v4.sipsolutions.net/802.11/Microcode/.

Having a C backend would make rust useful in a lot of places like this.

Woodruff: Weird architectures weren't supported to begin with

nybble41 — Wed, 17 Mar 2021 07:32:21 +0000

> My money would be on a C backend for LLVM

If you already have a decent C compiler for the new architecture then that might help. However, if this is an emerging architecture which doesn't have any toolchain yet, wouldn't it be simpler to implement an LLVM backend for that architecture (perhaps as a fork if it doesn't meet the requirements to be accepted upstream) rather than write a new, modern, standards-compliant C compiler from scratch? Implementing the LLVM backend would also enable compilation of various other languages based on LLVM, not just C, so you would get more benefit from (arguably) less work.

Woodruff: Weird architectures weren't supported to begin with

immibis — Tue, 16 Mar 2021 18:10:02 +0000

But people *are* saying that hey, it's pretty neat that this all mostly worked until now, and all you needed was a C compiler as a "standard code generator". Maybe we should design some system that maintains this property, just to make architecture porting easier in the future. (My money would be on a C backend for LLVM)

More control over binary builds

immibis — Tue, 16 Mar 2021 18:07:37 +0000

You would think so, but the binary build has the same problem from the other end: the end user can't tweak the software, even if they want to!

And while Microsoft has a good record with backward compatibility, it's not 100% - if they change the system *anyway*, the end user (no matter how technical) often has little ability to diagnose or fix the problem. If Linux followed the Microsoft model, the Raspberry Pi simply wouldn't exist.

So layering is no longer a thing?

immibis — Tue, 16 Mar 2021 18:03:02 +0000

Really, all that is needed here is a backend for LLVM that outputs C code, which you can then compile with your platform-specific C compiler of choice.

Woodruff: Weird architectures weren't supported to begin with

nix — Mon, 15 Mar 2021 14:52:30 +0000

I'm sure you know this already, but the way one does this is to cross-build (or, since that is often difficult, build atop an ARM chroot with binfmt_misc set up to redirect things to qemu-user-arm): this works fine unless your build process requires something like extensive multithreading that qemu-user still does badly (so, 99% of build processes are fine). Then tests, and only tests, are run via ssh to an SBC which shares that chrooted filesystem with the host (and it's not as though OpenGL-capable SBCs are hard to find or costly, though if you want one with open source drivers that might be harder). This is not even slightly new in the embedded world: DejaGNU has long supported this model via its "remote board" concept.

Woodruff: Weird architectures weren't supported to begin with

flussence — Mon, 15 Mar 2021 05:48:58 +0000

And furthermore, Open Source was never meant to be fun. It was meant to gentrify Free Software, make it marketable to people who don't know what fun is.

Woodruff: Weird architectures weren't supported to begin with

farnz — Wed, 10 Mar 2021 12:05:06 +0000

Freedom 0 still applies - you can use the software as supplied or as modified by you for any purpose you like.

We're talking about cases where the user of a piece of software wants some assurance that the people supplying them software won't make changes that make their life difficult. You can't just assume that the people you get software from care about your application of it to a problem; if you want them to care, then you need to make sure that they know you want them to care.

This whole mess is about two different groups having different understanding of what they have implicitly agreed to as part of one group using the other's software.

Woodruff: Weird architectures weren't supported to begin with

milesrout — Wed, 10 Mar 2021 02:51:24 +0000

Freedom 0 doesn't say "you can use the software for whatever you like and I guarantee that I'll never release new versions of the software that are different in some way that is inconvenient to you".

Woodruff: Weird architectures weren't supported to begin with

gspr — Mon, 08 Mar 2021 13:35:51 +0000

For the vast majority of the software, Debian's patches are nearly trivial.

Woodruff: Weird architectures weren't supported to begin with

nix — Sun, 07 Mar 2021 23:01:59 +0000

> Also, the Rust repo has the LLVM it works with in the repository (via a submodule). Given the patches they've had to apply over time, using an external LLVM probably wouldn't work out *that* well anyways.

This has improved greatly of late: since about LLVM 10, a separately-compiled upstream LLVM works well enough. (IIRC, there are hardly any patches left in Rust's not-a-fork of LLVM any more.)

Woodruff: Weird architectures weren't supported to begin with

farnz — Sun, 07 Mar 2021 20:13:25 +0000

Disclaimers of warranty are already overriden by local law here, and have been since the 1970s (coming up to 50 years). A product has to be of a reasonable standard given the price charged, and to last a reasonable time, again taking the price into account; it is expected to function as advertised before the sale.

So, the $10 pulse oximeter I own calls out what I can expect of it on the packaging - high error margins, low reliability. There's no disclaimer of warranty, nor a liability waiver; instead, there's setting of expectations so that the company selling the device is clear that they're not liable for anything beyond the functionality of the device, and that the functionality is about what you'd expect for a $10 device. If it doesn't do what they've promised it does to a reasonable standard for a $10 device, then my options are limited to a repair, replacement or full refund at the vendor's discretion in the first instance (I get a right to a refund if they cannot repair or replace) - so $10 at most. The similar device a local hospital uses does indeed cost a lot more - but as you say, that is because they are promising a lot more.

The net effect is that companies become very clear about what functionality you can expect from a device, because full refunds are not something you want to give very often. For Canonical, Red Hat, etc, the result is that you advertise a lower expectation, because you can be held to that; so Exchange would have to be advertised as insecure to escape liability for the hack.

Woodruff: Weird architectures weren't supported to begin with

mathstuf — Sun, 07 Mar 2021 15:25:55 +0000

Our software needs OpenGL tested and generally need hefty hardware to do builds in a reasonable timeframe. We've gotten a few for other projects but we haven't gotten them for this one yet. First up is more macOS and Windows cycles since those machines already aren't keeping up.

Woodruff: Weird architectures weren't supported to begin with

Wol — Sun, 07 Mar 2021 14:11:36 +0000

And identifying the individual concerned will lie between "difficult" and "impossible".

Take sendmail (seeing as we're talking about MS Exchange Server) as a case in point.

Allman wrote it in the kinder, gentler days of the gentleman's internet. Lots of people modified it to do things Eric never thought of. Then came the crackers who abused it.

Is it Allman's fault - for not forseeing the future? Is it the fault of the people who re-purposed it to suit themselves? Is it the fault of the distros, or the software repositories, who made it freely available? Is it the fault of the people who didn't understand how to configure it securely?

Even identifying who those individuals are is fraught with problems.

Cheers,
Wol

Woodruff: Weird architectures weren't supported to begin with

nix — Sun, 07 Mar 2021 13:50:04 +0000

> Basically, yes. Folks have been asking us to provide Python wheels for Linux/aarch64 for a while, but we have no way of testing it

Um... aarch64 boxes literally cost a few quid at this point, now that a lot of the SBCs are aarch64. Surely it's easy to get a way of testing things there?

Woodruff: Weird architectures weren't supported to begin with

pizza — Sun, 07 Mar 2021 00:07:14 +0000

> But no amount of disclaimers will limit their liability below the sum paid in my local jurisdiction.

This is a key point -- If your jurisdiction decided to change the law to override disclaimers of warranty and/or liability waivers, it would affect far more than the likes of Microsoft or "software". I don't think it's an exaggeration to say that it would send most of the economy to a screeching halt, and any software/products/services offered under the new regime will come with a _much_ higher price point, proprotional to the heightened, un-waiveable liability the seller/producer/manufacturer is potentially responsible for.

This distinction is why you can buy device that measures your pulse for $20, but a "medical device" that does the same thing (with the same fundamental components!) costs $2000. The "medical device" is sold with explicit promises of merchantability, reliability, and accuracy, and there are major penalties if it fails even if there was no malice or negligence involved. The development and certification process necessary to meet those requirements is quite extensive, and therefore quite expensive. Plus you have to carry significant amounts of insurance to ensure you can meet those liabilities.

> That said, it will affect people like Canonical, SUSE and Red Hat - if you're selling open source software (even just as a bundle with support), you become liable to ensure it works, or to refund people.

"works" for what purpose, exactly? That's going to have to be explicitly spelled out...

Woodruff: Weird architectures weren't supported to begin with

farnz — Sat, 06 Mar 2021 23:44:27 +0000

And, taking that Microsoft Exchange server issue as an example, Microsoft are the final vendor; by default, unless they could reasonably foresee the issue, they'd be liable to at most a full refund for the licence fees everyone has paid them for licences for those instances. Of course, they could be liable for more - but no amount of disclaimers will limit their liability below the sum paid in my local jurisdiction.

This doesn't mean that it will affect open source - Exchange is a product, but there's no liability on (e.g.) the RSGB for publishing circuit diagrams in RadCom that could be dangerous if constructed badly. That said, it will affect people like Canonical, SUSE and Red Hat - if you're selling open source software (even just as a bundle with support), you become liable to ensure it works, or to refund people.

Woodruff: Weird architectures weren't supported to begin with

mpr22 — Sat, 06 Mar 2021 23:25:10 +0000

The natural strategy for dealing with liability issues around Exchange is to say "this is a commercial product offered for sale, so no, you cannot in fact waive the expectation that what you provide is of merchantable quality".

That liability model breaks down with free software because identifying an entity to which you can both reasonably(1) and usefully(2) attach civil liability will frequently lie somewhere between "difficult" and "impossible".

(1) "Reasonably" meaning that it is fair and equitable to hold the identified entity responsible in tort for the incident that has occurred.

(2) "Usefully" meaning the plaintiffs have a realistic prospect of recovering a useful percentage of their damages from the defendants identified, rather than just bankrupting the defendants to the sole benefit of the lawyers.

Woodruff: Weird architectures weren't supported to begin with

Cyberax — Sat, 06 Mar 2021 23:05:54 +0000

There are efforts to add a Rust frontend for GCC: https://github.com/Rust-GCC/gccrs

Rust is getting pretty stable now, so this actually starts to make some sense. And unlike Go, Rust is a fairly straightforward language, it doesn't need a runtime or GC.

Woodruff: Weird architectures weren't supported to begin with

johannbg — Sat, 06 Mar 2021 22:28:54 +0000

If we take for example this latest hack into Microsoft Exchange server [1][2] which has compromised over several hundred thousands instances worldwide ( which seems to be somewhat hushed since this is probably bigger hack then the solarwinds one ), I would not be surprised that the "manufacture" of a software will be held liable for "faults" in the software ( negligence ) in the future.

Arguably Microsoft in this case should be held accountable for their own negligence towards the US government, it's tax payers ( which probably have spent billions in license fees ) and of course the rest of the world as well.

People also need to realize that as open source has become more widespread and used, it has also
become increasingly affected by societal issues, including, both ethical and political issues ( US gov + Huawei + Google case is probably a good example of such political issue ), all of which will affect how the future framework ( rules and regulation ) surrounding it and how the rest of the software sector is shaped in the future.

https://cyber.dhs.gov/ed/21-02/
https://www.microsoft.com/security/blog/2021/03/02/hafniu...

Woodruff: Weird architectures weren't supported to begin with

farnz — Sat, 06 Mar 2021 21:33:39 +0000

On the other hand, that makes Rust the same as Linux; there's only one complete Linux kernel, but it's not exactly owned by any one company in particular. In theory, someone could buy out Linus and have the One True Linux Kernel, but in practice enough other people are involved that this is not a risk.

Woodruff: Weird architectures weren't supported to begin with

farnz — Sat, 06 Mar 2021 21:29:58 +0000

Equally, though, at least in my jurisdiction, liability laws for anything only expect you to be liable for reasonably foreseeable consequences of your actions, and do allow for disclaimers of liability even for things like buildings and cars. Not total disclaimers, but (for example) the skylights for my house have a legally enforceable disclaimer of liability for faults other than manufacturing defects and undisclosed issues with the design.

The much more likely model for software liability here would be to copy consumer goods (everything from pens through to cars); in that model, the default liability for any product is limited to the price paid to you, and a full refund for the faulty goods is normally the limit of your liability. The only time where you have further liability beyond the purchase price paid to you is when you could foresee that the part you supplied would, when used correctly, cause the extra costs that the buyer has incurred; one way that you can foresee such things is if the buyer explicitly tells you about those extra costs.

So, for example, I buy a washing machine; it doesn't wash clothes and doesn't function. The seller's liability to me is limited to a full refund. I tell the seller that I need a washing machine that works because if I can't wash my clothes tonight, I'm going to have to spend £100 on new clothes tomorrow, and that is enough that the seller has to either refuse to deal with me (allowed, of course!), or is liable to me for £100 above a full refund.

And note that these only apply if the seller is acting as a business, not as a private individual; if I sell you my home-made 6m band dipole aerial, then caveat emptor applies (unless I'm producing aerials as a business).

For a practical example of how all of that interacts, consider the engines sold by Honda for other people to build into products. If I buy an iGXV800 from Honda on their normal terms, they are liable to me if the engine does not function, or fails in use, to the cost of refunding me for the engine in full. However, if I build that engine into a motorbike of my own design and sell it to you, Honda don't acquire any additional liability; if you have a catastrophic engine failure while riding it, Honda are still only liable for the cost of the engine, as they did not foresee the extra consequences of a failure while using it in a motorbike (it's not sold for that use). Had I bought a Honda CB300R motorbike, and sold it to you, Honda could now foresee the consequences of a catastrophic engine failure while riding it, and would have the extra liability that results.

Translated to open source terms, most projects would have no liability still - the default position is that you're liable to supply a full refund if it doesn't work, but as no money has changed hands, that's a non-effect. Samsung would be on the hook, however, if the software in a Samsung phone does not work, even if it includes open source, because money changed hands; even then, the normal limit is the money I paid for the phone. Tesla, on the other hand, could be on the hook for far more money, even if their FSD software is mostly open source, and even if the failure is caused by an open source component, because Tesla could predict that it might crash. The developer of (say) a computer vision component used in the FSD software, however, is only liable to Tesla for what they agreed to (as part of a contract), or the money paid by Tesla to them for the software (probably nothing if it's open source).

So layering is no longer a thing?

NYKevin — Sat, 06 Mar 2021 21:28:32 +0000

"The system" is just a funny way of writing "the layers that are below me." To a kernel developer, "the system" is the architecture and microcode, as well as other hardware and firmware that the kernel knows about. To an application developer, "the system" might be Debian or Fedora. For cloud users, "the system" is AWS or GCP (or one of their competitors), and for web developers, "the system" is Chrome or Firefox (or one of their competitors).

Personally, I think Randall Munroe got this right in https://xkcd.com/1349/. By default, nothing works unless someone makes it work. The fact that software X works on system Y, despite the designer of X never having interacted with Y, is the result of someone else doing a whole lot of work in terms of porting and maintaining GCC, libc, the kernel, etc. It was never "free"; it was just amortized over a large set of other software that happens to have the same set of dependencies as X. If X takes on a new dependency, then that needs to be ported too, but this is not a deficiency in either X or Y, it's just the way things work.

Woodruff: Weird architectures weren't supported to begin with

Mook — Sat, 06 Mar 2021 18:55:40 +0000

There's an important difference between C and Rust at this point though; there are multiple production-level C compilers, but only one for Rust. That means that there is a chance that some group could take over Rust development in the future. In contrast, there are multiple production C compilers, some of which are closed source (and therefore difficult to take over).

That's probably reflective of Rust still being under heavy development; mrustc is smaller in scope (doesn't aim to do borrow checking), and still could not keep up to date with the current compiler. This is not really the fault of any party, of course.

Woodruff: Weird architectures weren't supported to begin with

pizza — Sat, 06 Mar 2021 16:25:41 +0000

> What we are talking about is holding people accountable for their actions. No "license" is going to prevent that.

Remember that absent the "license" you don't have the rights to use my software, period. Only that license gives you that right.

In exchange for the right to use my software, you have you have to agree to not hold me liable should your house burn down.

You chose to use my software, and your house burns down.

Who is "accountable" here, the software author who explicitly stated, in advance, that their stuff can't be trusted, or the person who chose to use it anyway?

Woodruff: Weird architectures weren't supported to begin with

pizza — Sat, 06 Mar 2021 16:18:09 +0000

> Person 2 is the natural target (and, in practice, probably the only worthwhile target) for civil proceedings.

I agree completely; (though "worthwhile" in this context should mean "going after anyone else will get you laughed out of court and on the hook for the other parties' else's legal fees)

Every single scenario suggested as a reason we need "accountability/liability" has been malicious in nature (ie involving mens rea &| actus reus). I have yet to see anyone explain what sort of liability should flow from accidents, why that should extend all the way to the individual software authors (instead of the "owners" of the software) and how the software profession can possibly survive that.

Woodruff: Weird architectures weren't supported to begin with

mpr22 — Sat, 06 Mar 2021 15:02:57 +0000

If you incorporate software into your product without verifying its safety, then in the first instance the natural civil liability for any defective behaviour arising out of faults in the software that you incorporated into your product lies with you, even if someone else wrote it (especially if they wrote it in their spare time, before your product even existed as a concept, and distributed it for free).

Now, if you can prove a sufficient degree of negligence, recklessness, breach of contract, sabotage, and/or fraud on the part of whoever made the software, then it would be natural for some portion (possibly as much as 100% depending on the nature of the defective behaviour, the nature of the tortious conduct, and the adequacy of your attempts to guard against defects in the software) of the liability be transferred to them.

Any idiot who decides it would be a good idea to grab a pile of pre-existing code written by a no-name rando with a net worth of a few thousand dollars and stick it in their widget without stopping to ask themselves "should I really trust, without further verification on my part, this software written by some no-name rando whose response to a liability claim would be to declare bankruptcy because the legal fees alone would be more than their combined net worth and gross annual salary?" needs to reconnect with reality.

Woodruff: Weird architectures weren't supported to begin with

johannbg — Sat, 06 Mar 2021 13:31:23 +0000

What we are talking about is holding people accountable for their actions. No "license" is going to prevent that.

As software becomes more and more integrated part of the society, more rules,regulation and laws will be built around that.

If it did not do that then everybody would just F/OSS their software ( corporation and people alike ) and be free from any accountability.

It might not be what people like or want but it's inevitable evolution, just as has happened in every other industry.

Woodruff: Weird architectures weren't supported to begin with

mpr22 — Sat, 06 Mar 2021 11:00:57 +0000

"not obviously feasible" <---- Er, I meant "not obviously present". Brain. Fingers.

Woodruff: Weird architectures weren't supported to begin with

mpr22 — Sat, 06 Mar 2021 11:00:22 +0000

That scenario displays clear mens rea (the acid was deliberately introduced to the lemonade) and actus reus (the lemonade was offered with the intent that it would be consumed, and it would be reasonably foreseeable that serious injury or death would result from such consumption) for multiple counts of murder under the English common law (let alone modern food safety statutes and regulations), making it profoundly unsuitable for a discussion of the standard of liability where malice is not obviously feasible.

What we're talking about here is more along the lines of:

Person (not necessarily natural person) 1: "I released some software for free. I haven't prepared a formal proof of its correctness, nor an evidence package illustrating its suitability for safety-critical uses, so it's unsuitable for use in safety-critical systems unless you are willing to do all that work yourself."

Person (not necessarily natural person) 2: "Don't care, I'm using it in my driverless car anyway."

Person 2 is the natural target (and, in practice, probably the only worthwhile target) for civil proceedings.

Woodruff: Weird architectures weren't supported to begin with

johannbg — Sat, 06 Mar 2021 08:30:58 +0000

You do realize that you are the in the role of the manufacturer right?
You wrote the code.
You made the code publicly available/accessible.
You end up having to take responsibility/accountability for it.

If a person creates a lemonade and that person then makes her or his lemonade publicly available and accessible under a sign "Free lemonade, drink at your own risk" and all the kids in the neighborhood see "Free lemonade" on the street corner, grab themselves some lemonade and start dying because that person decided to mix some acid into his or hers lemonade.

Is that person free of any responsibility and accountability because that person put up a lemonade stand and had a sign that says "Free lemonade, drink at your own risk" and allowed everyone to watch how she/he poured acid into the lemonade as she/he was mixing the lemonade.

The answer to that is no and one of the reasons why food regulations and laws surrounding that exist in the world.

Woodruff: Weird architectures weren't supported to begin with

pizza — Sat, 06 Mar 2021 00:23:55 +0000

> The question of liability is the easy part and already done: whatever entity sells the product/service to the customer is liable. They bear full responsibility. They may try to legally pass off the risk onto any of their suppliers for different parts, but for the consumer that is irrelevant, they sue the entity they bought the product/service from. If the supplier chooses to use Free Software, then they are also liable for its proper functioning, unless they can find someone to accept the risk for them.

See, I'm fine with that. There's an existing supplier<->customer relationship.

But how exactly can I, by virtue of writing a random pile of F/OSS that I published on my web site, when I have no relationship with the end-user or the company that manufactured $widget_x, be held liable for that widget failing and injuring the end-user, especially when I state up front that my pile of F/OSS comes with no warranty, little testing, and might randomly fail and kill your cat? [1]

If I'm to be held liable for <whatever> then I need to be compensated in proportion to that risk, or I'd have to be downright stupid to do it.

> Now, software companies get away with disclaiming liability because that's seems to work and not too many people complain about it. Regulations tend to be written in blood so unless we see a situation where lots of people start dying due to dodgy software I don't see a lot of regulation occurring outside of where it is already, eg cars, planes, medical devices.

Sure, but it's not "software" failing, it's "safety-critical product X (that happens to be partially implemented using software) failing".

That's the key difference. You're not regulating *software*, you're regulating *product that contain software*.

[1] Yes, I actually state that in the documentation. Should I somehow be liable because the user didn't read the documentation too?

Woodruff: Weird architectures weren't supported to begin with

xnor — Sat, 06 Mar 2021 00:08:19 +0000

> It's a language that has decided to optimize for programmer efficiency rather than program efficiency. That's a perfectly reasonable decision to make.

Except for the large parts where it's the other way around. Evidently, many python devs and users don't accept this "perfectly reasonable" decision because they don't want to sacrifice performance. They want it both ways.

But Python doesn't satisfy that requirement which makes it a bad language.

> the designers have made it comparatively easy- and a part of accepted programming practice- to rewrite performance critical code in higher performance languages.

It's a practice imposed upon Python devs because the language is bad. That it is an accepted practice is irrelevant. It's a bad practice. The problem in the article is just one consequence of this.
Instead of having a clear goal to be only used for prototyping and projects where performance and efficiency does not matter, they worked around the language's bad design and performance issues instead of fixing the language.