Then a visit with your doctor, to discuss cholesterol levels and hardened arteries.
Then a visit with your doctor, to discuss cholesterol levels and hardened arteries.
battered & deep fried
Oh no, it’s worse than that… we use the metric system to measure the customary system…
The Mendenhall Order marked a decision to change the fundamental standards of length and mass of the United States from the customary standards based on those of England to metric standards. It was issued on April 5, 1893, by Thomas Corwin Mendenhall.
[…]
Mendenhall ordered that the standards used for the most accurate length and mass comparison change from certain yard and pound objects to certain meter and kilogram objects, but did not require anyone outside of the Office of Weights and Measures to change from the customary units to the metric system.
https://en.wikipedia.org/wiki/Mendenhall_Order
Technically every unit in the US customary measurement system is just a weird conversion factor of an equivalent metric unit. At this point 1 yard was defined as 3600/3937 meter, which means 1 inch = 2.54000508 cm. By 1959 everyone finally agreed that this was stupid and redefined it as 1 yard = 0.9144 m (1 inch = 2.54 cm).
All measurements in the US are based on standard reference objects provided by BIPM.
Because it’s a 1-lane road, you’re going 20 under the limit and refuse to use any turnouts.
Oh, so all those examples about AI destroying the world by making paperclips… this is what they were talking about!
'O brave new world, that has such people in ‘t!’
The nuke plant is, of course, Historic Chernobyl No. 4, now a war memorial.
For individual projects the way this usually works is one of the larger companies that rely on the project hires the developer as an employee to maintain the codebase full-time and help integrate it with their internal processes.
Larger projects might form their own company and sell integration & support to other companies (e.g. Red Hat, Bitwarden).
Otherwise you’re basically dependent on donations or government grants.
There’s a Wikipedia article on this subject: Business models for open-source software
And there’s various industry opinions:
Demystifying the Open Source Business Model: A Comprehensive Explanation
How to build a successful business model around open source software
Open Source Business Models (UNICEF course)
I think monetization is easier for user-facing software though, which a lot of this material is written around, and harder for projects like libraries.
Fantastic. Hadn’t heard it before.
And it only covers a period of 51 years (1948-1989).
Learning not to take everything so seriously.
“Vhat are you… sinking about?”
If you meet a bear in the woods today, you met a bear. If all day long all you meet is bears…
you’re also a bear.
As others have pointed out you can do this, but there are at least two major advantages to the way Linux distributions use package managers:
Shared libraries - on Windows most binaries will have their own code libraries rolled into them, which means that every program which uses that library has installed a copy of it on your hard drive, which is highly inefficient and wastes a lot of hard drive space, and means that when a new version of the library is released you still have to wait for each program developer to implement it in a new version of their binary. On Linux, applications installed via the package manager can share a single copy of common dependencies like code libraries, and that library can be updated separately from the applications that use it.
Easy updating - on Windows you would have to download new versions of each program individually and install them when a new version is released. If you don’t do this regularly in today’s internet-dependent world, you expose your system to a lot of vulnerabilities. With a Linux package manager you can simply issue the update command (e.g. sudo apt upgrade
) and the package manager will download all the new versions of the applications and install them for you.
The guy that invented the Kaiser roll, obviously.
Arch often seems to ignore the fundamental rule:
Linus is in the right. Arch developers are frequently in the wrong.