The location information is used so that redshift can alter the colour temperature during the day (less needed) and dusk, evening and night (very needed).
The location information is used so that redshift can alter the colour temperature during the day (less needed) and dusk, evening and night (very needed).
Those of us using Redshift are not doing so for a one off colour temperature set, but because it is continually updated through the day and night.
You can tell it your location manually or have it done automatically.
Redshift is open source. It does not have binary blobs, patents, a business model and similar crud that f.lux does. Adjust your paranoia/expectations as needed.
I use CF.lumen on Android and Redshift on Linux and I have to regularly shift the fake locations I give them in order to have them do what I want. At least with Redshift on Linux I can script it...
In any event it is open source, so you can change the code as you deem fit :)
Yep, that’s great!
So, why not just ask for the location instead of bundling 200MB of crap to get it?
It would be absurd for Redshift to include its own networking (don't forget proxies and SSL), GPS, and other code. On Linux (Ubuntu especially), all those dependencies are installed by default and used by many other components. "crap" is the last thing to describe it.
OpenBSD doesn't have them by default which is why they show up. Redshift does support specifying your location on the command line or config file. gentoo has use flags where you can explicitly include (eg +geoclue) or exclude (eg -geoclue) components. I suspect OpenBSD doesn't, so it came down to whoever authored their port deciding to use geoclue by default.
It is an entirely reasonable decision. You use this software on personal machines (ie not servers), and people move around. Defaulting to something that usually works right is fine.
You are of course welcome to do a competitor, and show us all how much better it could be :-)
It makes more sense to have a core app that does the basic functionality and can be run from CLI, and then separate out the the various components that perform different duties and require more dependencies etc, in a modular architecture. It's just better software design and you avoid a lot of pitfalls and hassle to end-users and integrators - just like the issue described by the OP.
Solar noon details here: http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV...
Isn't this a perfect example where using more than localtime() is pointless? Just because it's dark all the time outside you don't want your screen to be red-ish all the time. And in summer you want the effect if you try to sleep, even if the sun is still relatively high.
I generally have a hard time getting to sleep, and most mornings feel like I've been run over by a steamroller, so I don't mind a little red tint if it makes even a tiny difference in the quality of my sleep.
[0] https://en.wikipedia.org/wiki/Delayed_sleep_phase_disorder
I can understand wanting the screen to tint reddish when it's 9 or 10 pm, because I should be going to bed soon.
I don't necessarily want it changing colors at 4pm when it starts getting dark here in the winter. At 4:00, I still need to be up for another 6-10 hours.