It is sad to have to say this, but color management as required by graphic arts applications is very poorly implemented under Linux. There is no universally agreed-upon CMM(color management module), and applications do not uniformly implement and respect color management. Also, creating and maintaining ICC profiles under Linux is a difficult proposition at best. The best profile generation package, Argyll, is an open source command line product that is unable to work directly with scanning tables like the i1io, Barbieri, or Colorpartner units. Argyll's UI approach is not anywhere as convenient as products like profilemaker, monacoprofiler, or i1profiler. For those who need to use a RIP, there is exactly one offering available- Caldera.

I wish Linux could support graphic arts and printing for professional printers as well as Win and OS/X.

Sadly the PC world has unitl recently ignored yet another lesson from mainframes- logical partitioning.

The concept is a minimal bare-metal hypervisor which in mainframes is built into the hardware and is integrated with a robust set of configuration tools. It's nice to see at least a shadow of this concept being implemented in something.

Actually, the process Kodachrome uses to produce the color is still based on the fundamental instability which plagues all chromogenic systems- even though the dye coupler is not in the emulsion(as would be the case with Kodacolor and Ektachrome), the fact is that the process is still the same. A dye coupler combines with developing agent by-products in proportion to the amount of underlying silver that is developed. I've always wondered how Kodachrome achieved greater archival permanence; maybe it is because the coupler/developing agent byproduct reaction happens only in processing and the dye coupler does not have a chance to become spoiled while unused sitting in an emulsion.

I would like to know if you are able to color manage your monitor with an appropriate
ICC profile, and if so, how you get this profile properly applied to the virtual display?

None of the virtualization environments allow for applying color profiles to the virtual graphics display.

As a photographer, you will be concerned with proper color management of your monitor, and so you
need a base environment which properly supports this. That base environment regrettably needs to be
a Windows desktop or server operating system.

For well over 30 years, airline reservation, hotel reservation, and other high volume transaction processing(HVTP) systems that are mainframe-based have not used SQL in the core transaction processing system. They use either the built-in key/value subsystem of TPF/ZTPF, or a slightly more sophisticated subsystem known as TPFDB. Using facilities similar to zOS, failover and recovery happen in record time should it be necessary. This successful real-world system and approach deserves the attention of those who would like to learn how this stuff really works.

It's always funny to read things written by people who obviously are inexperienced with high volume transaction processing in the mainframe environment. The systems behind airline, rail, and hotel reservations as well as emergency response messaging often are built on IBM mainframes using TPF/ZTPF as the operating system and
TPFDB(formerly known as ACPDB) as the underlying database. If someone would take the time to study TPFDB, they would notice its nonrelational character, as well as some interesting similarities to what the Cassandra developers unknowingly chose to do. By the way, these systems are happily handling 10K-12K transactions per second without bunny farm racks of servers.

Sometimes progress is not always about what will be done, but understanding the benefits of older things that have been done.

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.

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.