If you look at the spectrum of white LEDs they have a much higher blue light content than compared to other lighting technologies. Often it's an other peak in the spectrum.
Also a lot of street lights have been replaced with LEDs, although probably better than Sodium Vapor since that light source has pretty narrow spectrum.
Probably means we should all be using warmer LEDs, instead of like 5000K, 4000K ect... for night lighting.
An oil well is quite small Area wise compared to the amount of acreage you would need for a coconut plantations to replace the same amount of energy output.
The issue with oil is CO2 and other green house gases and then the occasional oil spill or leak. Land area wise they don’t take up much space
I do think it would be awesome if something like offset printing was more accessible. The number of stages/steps for a press that can used for a color or effect is often just limited by floor space. Although some presses can't have an other stage as easily added depending on the manufacture.
Offset printing can have more colors than CYMK. Sometimes a setup will include multiple additional inks beyond CYMK to produce a color or effect that CYMK alone can't produce. Sometimes those colors will be mixed from other colors as well much like paint.
Problem is offset printing presses are HUGE and expensive and require making plates first. There are digital offset presses, but they generally can't have an other stage added like traditional offset printing, it's capped at however many colors that machine has built in. They also are huge compared to other printers people will have at home or the office.
-EDIT-
It is probably possible to scale down the hardware and do something like digital offset presses. I think it would cool if there was a *small* printer people could connect multiple color stages like a legos and mix up a colors for those stages.
I can tell you there are some places people do notice that a screen can't reproduce all the colors they can see.
Anyone who has mixed paint at hardware store or paint store with a modern paint machine will eventually notice this. A of lot them have a spectrometer to match color from a sample. The software often has a preview that appears on a screen of the sample color. That preview color is often not quite the same and it's often either the limit of the sRGB color space or the monitor.
The data from the spectrometers is eventually converted to CIELAB color points with a D65 white point. Then that little preview needs to be converted to sRGB to display it or some colorspace the system supports.
There also some problems with the LAB colorspace, but they are minuet compared tot the limits of sRGB and display hardware.
Not the OP you responded too, but what the hell! I have not really used windows in a while but that's absurd. That text is massive just for an unsigned driver.
I think somewhat sand boxed is fine, but the user should at the end of the day be allowed to let things out or get out if it.
The problem with things like iOS is the user can't make that choice. Also what you call 'bad' is up to the user. At the end of the day a user should be able to adjust things even at root level or request other software to do that on their behalf. Heck for iDevices owners should be able to load their own signing keys at a minimum for the Boot-ROM.
As for Adobe most people would not expect their software to touch the host file, so it's fine to call them out here. Someone using a utility or tool that you would expect to edit the host file that's fine, and people should be able to use or make such a tool. (The os should not prevent the user/owner if that's what they want).
Yea, that's what I was getting at. The user should be king. Not the application developer, not the OS vendor. The user should be able to easily say yes/no to these things and have the final say.
Yes, I did actually look at Bunki as well before building this. Liked the imagery. :)
What did not quite fit for my purpose was having the asymmetric coroutines as the fundamental layer, meaning that the dispatcher also is tied to that layer. Building the next level dispatcher on top of that is probably possible, but seemed a bit complicated.
I instead started with symmetric coroutines as the fundamental building block and built the dispatcher at the next (process) layer where it can deal with the event queue to determine who goes next. The process level resume() call is always made from some event executed by the dispatcher on the main stack, making the processes asymmetric coroutines even if the lowest level coroutines are symmetric with transfer() calls.
Making asymmetric coroutines from symmetric ones is easy, just yield(void) { transfer(parent); } and resume(target) { transfer(target); } in slightly abbreviated code, while going the other way around requires an extra context switch via the dispatcher on the way there.
Also a lot of street lights have been replaced with LEDs, although probably better than Sodium Vapor since that light source has pretty narrow spectrum.
Probably means we should all be using warmer LEDs, instead of like 5000K, 4000K ect... for night lighting.