I would suggest you learn about what are known as 501(c)(12) telecommunications cooperatives. One specific example would be www.rric.net
It would also be good for you to consult the IRS information on this kind of nonprofit organization.

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.

Not only that, it probably does something useful too.

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.