dwheeler

When IBM PC compatibles first became widely available, most economic reports I saw said that there was no economic impact from computers becoming widely available in offices. Word processors, spreadsheets, and email didnt have any productivity improvements... and I think we know better.

It's too early and we are probably not measuring the right things.

Amazing. Sadly, it can't run in real time even on strong real hardware. I wonder if its code could be optimized to run in real time?

> Burning down an apartment building doesn't change what could be done with the lot; an appropriate valuation method for LVT would not give a different valuation for the land depending on what is built on it.

True, but an LVT is a cost. Changes in cost can change what is financially viable to do with a property, regardless of what is currently done with the lot, and thus can impact the land value.

I actually think there's a lot of positives in land value taxes. However, I was objecting to the phrase "The land value tax can’t be dodged by leaving nor can it be passed on to renters" because that is missing key issues.

Land's assessed value is based on what you could do with it. If can be rented at a profit, that's something you can do with it, and its potential matters. If it can't, then that is no longer a potential value of it.

That doesn't make lvt a bad idea, it's just that I think there's not enough acknowledgement of the trade-offs and limitations.

False premise. AIs dont generate anything in 30 seconds that has been widely reviewed and tested.

If you want it to be corrrct, it's always easier to install some existing OSS and instead focus on whatever is unique to you.

> COCOMO says that the cost scales superlinearly with the number of SLoC; my point is that drivers scale linearly because they're effectively separate projects. (In fact, to the extent that they're not separate projects, the cost in fact scales sublinearly since there's a bunch of code being copied and pasted when new drivers are written.) Your tool has this "--multiproject" concept; a better estimate would have identified which parts of the tree (primarily drivers) were functionally separate from the rest of the kernel.

If all drivers were essentially completely independent projects that never interacted with each others, then yes, I'd agree that multiproject would be a better model. And if each was mainly a copy-and-paste of another, then it'd definitely be sublinear.

However, I have a very different expectation. In the Linux kernel, there's a strong pressure to try to create common interfaces that different drivers support. There's also pressure to create common lower-level functions that everyone can call. This reduces total code and reduces long-term maintenance, but ends up creating more interlinkages because the drivers are NOT really isolated separate projects at all. Maybe the drivers start somewhat independent, though I'm skeptical of even that, but I think that's not at all where they stay.

Let's get specific. The Linux kernel groups similar hardware into distinct subsystems. This includes networking, input subsystem (keyboards/mice/etc.), ALSA (sound), V4L2 (webcams/video capture cards), and GPIO.

Each subsystem defines a unified programming interface using standard data structures and callback functions. Drivers are typically split into a core framework that handles general logic and low-level portions. Driver developers plug into the existing framework for common features like power management and buffering. These interfaces often change as new drivers are created that require changes to the interface.

Because in practice there's a lot of interaction among drivers, I would not expect that, after years of driver development, the different drivers would really be independent. Indeed, many have asked the Linux kernel developers to make it easy to have completely separate and isolated drivers, but the developers have resisted because they believe it's important to have the drivers integrated into the kernel to support that kind of constant collaboration between drivers.

It'd be cool to see an analysis to settle the question. Future research for someone else I suppose :-).

No specific number; getting one would require actual analysis.

But I expect it would easily be in the trillions, and probably over 10 trillion.

> I consider this a simplistic analysis, because a closed-source Linux with a straightforward monetary pricetag would be worth a lot less in practice, since it would cease to be the de-facto OS for pretty much all new hardware products.

It's necessarily an estimate, of course. The best way to get effort figures would be to record every minute used for development, and the best way to get cost figures would be to re-develop from scratch. That wasn't practical, so using a widely-accepted estimation system seemed like a reasonable approach.

It's true that this analysis doesn't tell you the purchase price. However, I wasn't trying to estimate the purchase price. I was trying to estimate the cost to develop the software, if it had been developed using traditional closed source practices. If Linux had been developed by a for-profit organization to make a profit, the organization would have planned on charging more that that (in aggregate among all its users), since otherwise they'd be knowingly developing the software at a loss. That doesn't mean that the company actually could have charged this, as it often happens that products don't make a profit, but that's different from intent. And this is all different from value. If a product has value to you that's more than it costs to get, then economically you should consider getting it.

No matter what, these time and money figures can only be rough estimates. However, I think they were useful, because they destroyed a false assumption many had at the time.

In the 1980s and 1990s many people presumed that large-scale systems could NOT be developed as open source software. People did sometimes share software, but it was widely assumed that this could only be successful for small programs. The term "open source software" didn't even exist until 1998. The term "free software" was coined in the early 1980s, so that definitely was a discussion point. However, many people didn't think you could build larger systems with software licensed that way.

Bill Gates published in 1976 his "Open Letter to Hobbyists" that crystallized this argument. He claimed that if software was freely shared it would prevent the writing of good software. He basically argued that closed source software development (not a term of the time) was necessary.

The point of my paper was to show that it was possible to build larger software systems without being closed source software. Even at the time, people were being paid to develop some of that software, but the point was that sharing of software under a generous license did not end software development at all. I think my paper did the job. You can argue many things, but no one argues that open source software cannot be used to build big systems. We have existing systems, measureably large, that refute the claim.

Thanks for the trip down memory lane.

Author here! I was surprised to see this on hacker news, it's a blast from the past.

Ask me anything!

Metamath is short, which does make it easier to verify. In addition, because it's simple, there are many implementions. The set.mm Metamath database, the most popular, is checked by 5 independently implemented proof verifiers.