You are essentially talking about what government does when they float a bond to create infrastructure, but instead your concept is a voluntary association of homeowners who agree to enter into an agreement to loan money to the phone company. You could more effectively do this by having the residents form a 501(c)(12) telecommunications cooperative and use that cooperative entity to negotiate with the phone company to fiber up your block, for example. You are still doing the finance, but you do it under a recognized legal entity.

Of course, the best thing would be for municipalities to take over telecommunications pipes to the home as a public service like water, sewers, and roads, but that would require us to remind ourselves of how government is not evil and exists to serve the people. In this kind of scenario, telecommunication companies could become hired help under contract to government to provide maintenance, content, and other things.

It used to be that the conflict of interest was resolved by enabling those who agreed only to provide the pipe to be covered for liability by a concept known as 'common carrier'. If you were simply providing the pipe, and no content, you couldn't be held liable for what went through the pipe. Essentially through corruption and a lack of public awareness, we are not properly enforcing common carrier law through lawsuits against content providers who try to have their cake and eat it too.

Unfortunately, due to the corruption of the public sense and understanding by an MBA-dominated concept of service, many people are under the misunderstanding that the fiscal goal of public service or nonprofit organizations is to fiscally produce excess revenue over expenses, otherwise known as profit. The pre-MBA-dominated understanding of the fiscal goal of public service and nonprofit organizations is that they are to produce the maximum utilization by the public of their programs and services at a balanced budget where revenue and expenses are equal.

Why do we let idiots with MBA degrees tell people in government and public service how to manage their finances and operations using fiscal principles that don't apply?

No revisit is necessary after 8 years. The structural issues with linux on the mainframe are exactly that- structural. How aboout this- go into real mainframe shops in mainframe-committed businesses like insurance, transit reservations, banking, and so on, and find out what the core business transaction systems run on. It won't be linux, and for manifold good reasons, mostly related to RAS. Linux has nothing even remotely resembling the abilities in Parallel Sysplex(zOS), but there's no need to escalate to that- even the most basic device error recovery management in a mainframe operating system is better handled than in Linux.

And by the way, the assumption that with the progression of years comes inherent improvement in technology is by no means a certainty, especially in computing. Ask someone who knows anything about Keykos whether today's operating systems have incorporated even half the concepts they got right. Oh wait- let me not forget- Keykos and many other earlier operating systems aren't covered in a typical CS operating systems course, but that must be because the 'experts' have deemed them irrelevant. The same 'experts' ignore TPF/zTPF as well, which have been happily doing transit reservation systems for over 40 years. So much for progress inherent in the march of years.

There are a number of factors which go into this consideration of Linux on the mainframe. I must admit it was really cool when I first learned of it, having had an MP3000 to myself at an IBM training facilty to learn how to bring up VM/ESA and Linux/390(2001). Then I realized a few things like:

1. Linux cannot take advantage of the advantages of channel-based disk i/o, because it uses Unix i/o approaches which can never be as efficient as the traditional mainframe-based approaches. No one has shown me any evidence that Linux does anything particularly intelligent in its channel program construction and management. Linux assures that IBM can happily sell lots of IFL or general purpose CPUs which are necessary to compensate for this inefficient use of
mainframe resources.

2. Managing workloads under zVM can be great and is extremely well refined, but this requires zVM-specific skills which supposedly no one wants to pay for.

3. For transaction-based work, it's hard to beat TPF/zTPF, but unfortunately that requires some real mainframe skill to implement. And regrettably, zTPF requires Linux and zOS because IBM refuses to convert the programs running on zOS to run on Linux instead. Since TPF/zTPF and zOS both involve onerous monthly licensing charges based on capacity, it's no wonder that TPF/zTPF languish in relative obscurity.

Can they send the bill to you when the lawsuit hits?

Actually this is a common name for this flu in .nl.

SAP closed-sourced SAPDB/MaxDB.

They never provided anything resembling a decent explanation as to why.

I can't understand why anyone is surprised that people trained in computer science are ill equipped to develop
business software.

How many computer science graduates typically have the slightest clue what accounting is, or how it works?

How many computer science undergraduate programs deal with the customary and legal environment of
business?

How many computer science programs deal with the realities of designing and maintaining a datacenter,
in theory and/or practice?

Computer science is a theoretical self-serving discipline designed to produce more computer science
graduate students. Anyone who learns practical, appropriate, and customary reality does so more
often despite rather than because of their education.

Time for a radical reassessment.