ReactOS - yes. That was in response to GP comment that MSFT also makes source of Windows available to the universities. The story was discussed on Slashdot in the past and the source code license has pretty draconian conditions attached.
What do you mean by "completed"? ReactOS aims to be binary compatible with Windows drivers, so ReactOS will be as "complete" as Windows in this regard.
Windows itself isn't always compatible with the 3rd party drivers.
And the stability of XP and W7 is largely attributed to the fact that MSFT has taken over device driver development and maintenance from many 3rd parties.
In other words, ReactOS isn't going to have an easy time with the drivers, even if it is 100% compatible with Windows. Many drivers are not accessible because they are (c) MSFT. 3rd party drivers are often of piss poor quality and wouldn't work well on ReactOS for the same reason they are working poorly on Windows itself.
If ReactOS was ever completed it would be a big problem for Microsoft....
It would never be completed, because:
1. Most of the code in Windows are the device drivers. MSFT has literally thousands developers writing and maintaining the drivers.
2. MSFT keeps updating and changing secondary APIs very often.
Wine IMO is the only sensible approach to simulating Windows, because it reuses the device drivers of the host platform.
But as topic goes, the only thing wrong with ReactOS in academia is that it gives the VMS-isms another life lease.
It has the advantage of being bug-free (relative to ReactOS),
That is actually a disadvantage for an academic OS. When there are obvious problems, there is no need to think much of lab assignments.
Problem is, as system programming goes, Windows is very boring. As you say, it is very stable - but it is also closed-source. Meaning that whatever students implement remains an academic exercise.
Name Conflicts In Automatically Generated Email Addresses?
I know this is a silly question but why not to actually ask the affected users???
30K*1.6% is 480 people. Generating automatically a bunch of e-mails, grouping the conflicting names onto CC lists shouldn't be much of a problem. Put the autogenerated names in the body and use some special prefix in subject line. Ask them to put the desired names into the first line of the response and set dead-line. On dead-line, check for remaining/new conflicts and probably repeat again. That would reduce conflicts to probably a dozen if not less. (Or an internal discussion board or Wiki can be used instead to let people to handle the conflict and in some convenient form provide the feedback to you.)
As personal experience goes... I work in company with 50+K employees and the autogenerated names suck. You pretty much never can tell who is who. And with the constant restructurings, one can't even rely on the name of department in the LDAP.
I have read all the deltas from 5.8 to 5.14 (they are part of the Perl man pages) and there is really nothing major there. Tweaks and fixes here and there. Couple of syntax tweaks from Perl6. Multi-threading enhancements. But nothing what can potentially make Perl more relevant to me now.
Unlike Perl, Python simply has more up-to-date feature set. And better support for Windows.
For example. Literally everything uses Unicode/utf-8 now - but Perl still defaults to binary/ASCII for everything. And Python defaults to utf-8 for the text.
That's how it happens. 10-15 years ago, Perl was 100% useful out of the box. Now you have to pile up some options just to make it realize the default encoding of you environment. Inevitably, to spare the nonsense, one starts using the new tools - like Python - which are more in line with the current defaults.
It'll be nice if there could be a JIT or some other accelerator for Perl.
I have seen some old posts about attempts to port Perl's interpreter to LLVM to be able to take advantage of its JIT facility. As far as I can tell, it didn't went too far. (The most discussion I can find. But about work from 2008-'09.)
Main obstacle for Perl's advancement and progress is the Perl6.
You can't change the Perl5 because a lot of stuff depends on it.
You can't make new version of Perl out of Perl5 because Perl6 is already out there.
All in all, I strongly believe that it is the miserable failure of Perl6 what's killing any potential progress the Perl could have made.
Right now, the best thing which could happen to Perl IMO is a fork of the Perl5. Yet, since user/developer base is declining, I very much doubt that would happen.
Why would there me more or less need for a big sized display depending on how many colors it can display?
As long as the contrast is decent I would love a large eInk display
You alone do not make large enough market.
Large CRTs and panels, before becoming parts of consumer products, where literally exclusively used by businesses for marketing purposes (displays in shops, exhibitions and so on). They bore the high price of very early adopters. And: marketing wants to have colors.
Unless there would appear a market for large B/W panels or the color version of e-Ink would enter production, chances of a large e-Ink panel are very close to zero.
Still better than the weekly news about Firefox version increment.
And I personally like to keep an eye on the development. Imagine the power of the Linux packaging combined with the BSD kernel. Imagine the sound system which doesn't suck. Imagine the storage, if supported at all, crunching data at half the usual rate. Imagine the unaccelerated graphical interface......I digress. But it is still interesting.
Pretty much all platforms have the time_t as long - the type used to represent UNIX time. Pretty much all platforms are now 64bit and thus have 64bit long. And even some 32bit platforms have 64bit time_t. It was problem about 10 years ago - but now it doesn't exist anymore. And the problem was mostly in the compilers: lack of the 64bit integer data type support in 32bit mode.
The only platform where I have seen problem with 64bit time was the HP-UX 11.11 and 11.23 (haven't tested the 11.31). Some functions are failing/hanging when passed time value larger than 2^31. I have also seen similar problems on AIX 5.3 - but IIRC AIX 6.1 has fixed it. But then, nobody cares about the HP-UX or AIX anymore. Linux, Solaris and BSD are OK for quite some time now.
Also, my reason for switching from DEB to RPM-based distro was it seems Debian's core package management tools haven't seemed to evolve much in years while RPM appears to have improved quite a bit.
Apt hasn't involved mostly because, unlike RPM, it got many things right first time.
The delta-compressed updates is a huge deal for me, but also the general speed of the tools.
Delta packages is sure a nice feature, but it doesn't work well with community distros. There is no central authority to "bless" packages and thus there is really no base version to make the delta to.
As to the speed, I personally never had the problem with the Debian itself. They try to get it right before release and besides the initial wave of updates after the release, there is relatively few regular updates. Since I use Aptosid right now (distro of Debian connected literally directory to unstable repository) I can't really tell how it is right now in the Debian itself. (100+ updated packages per week is quite normal for Aptosid. So performance of updates for me is rather/non-issue/, since there is no performance to speak of.)
OpenSuSE's zypper tool also gives a bit of freedom in installing 'unmatched' later versions of libs but if things go wrong, it's easy to trace and downgrade.
That was implemented in Debian looong time ago. (IIRC pinning appeared in Debian 3.0.) The problem is that one has to read quite a lot of documentation to understand how to use the version pinning properly.
"With that in mind, Hartung believes Steve Ballmer will do anything and everything to save Windows, including ditching entertainment and therefore Xbox."
Twisted logic.
If Windows/Office are on decline, why sell the only growing, and potentially profitable, business branch they have?
I looked at the Gunnar Web site and saw no scientific backing of any of their claims. In my opinion, any improvement you'll get from these is 100% due to a placebo effect.
[... skip...]
TL;DR Snake oil glasses, you've been conned.
Google for "photography yellow filter". References are scarce, because the filters were used in B&W photography, in pre-Internet times. But there are some.
Alternatively google for "white balance amber" or ask on DSLR forums/check DSLR books about the shit to amber. Or if you have a DSLR, you can even experiment with it yourself: shoot a RAW and in any RAW development tool, play with the blue-yellow gauge in the white balance.
All in all, as few commented above, those are simply well made yellow glasses. And the effect of yellow filter is known from photography and is not placebo. But also doesn't warrant the Gunnar's price.
I was thinking the same thing - yellow plastic glasses.
My first thought was: yellow filter. The effect of the yellow filter is well known from the times of B&W photography: boost contrast, darken the (blue) skies (so that they do not white out completely). In color or with DSLRs, the same effect is achieved by adjusting white balance settings in the direction of amber: it gives the picture warmer colors.
Some people have mentioned above the Redshift. I personally use on my PC the f.lux and it appears that both programs have almost the same effect as the yellow filter.
This is yet another Steve Jobs clusterfuck. The original Mac was the first PC that used black on white and idiots have been aping it since.
It's not white. In fact, the light background on Macs is not even a color - it is a texture with smoothed horizontal stripes. Not huge fan of it, but it is not THAT bad.
That was one of the first surprising things I found on the Macs: somehow background is light, yet my eyes haven't started aching immediately. Took screenshot, enlarged it and enjoyed that the UI designers are not complete fools.
Newer versions of Mac OS have more of plain colors. But most of the UI still uses some textures for background. The net effect is that even empty space in the UI to the eyes doesn't look glaringly empty. And that's pretty much only advantage of it.
EMMISIVE DSPLAYS SHOULD NOT HAVE BRIGHT BACKGROUNDS!
Well, Amazon Kindle has unfortunately pre-made three choices for you:
1. (Default) Black on light gray. Not great but OK.
2. White on black. And that is hard black on true white. High contrast nightmare.
3. Sepia: some sort of grayish on some sort of yellowish. Low contrast nightmare.
White on black and sepia lay essentially on extremes of the contrast range, leaving as useful only the #1. Without a jail-break, there is no way to create the popular for backlit screens "Light gray on black" color scheme. And that is one of the reasons why I stayed away from the Kindles with the LCD. eInk is OK (but the new Kindle devices with e-Ink sport newish squarish UI which unfortunately is too dumb down; my next device will not be from Amazon).
I haven't looked into Solaris code, but I have seen (with the eyes of system programmer) both BSD and Linux code.
BSD is much more readable - but in larger part because it is much simpler.
But Linux is also readable - if you know how the stuff works. The modularity of the kernel also has an impact, since in a place where BSD has a single readable function, in Linux one might find piece of code with calls to potentially dynamically loaded modules. But that is still the simplest part. Hard part is the "how the stuff works." Linux for performance reasons has many things implemented up-side-down and it takes some time to get used to it.
Over the life time of Linux, there were many discussion about the readability vs. performance. In the beginning readability was mostly winning. But as Linux became more and more popular, later literally de facto server OS, the choice (IIRC Linus was also involved in the discussion) was inevitably falling to the performance. It ended up with something like: few CPU cycles saved in one function, multiplied by million of Linux boxes, equals millions of cycles saved.
BSDs IMO always more cared about feature completeness and long-term maintainability. That I believe led to simpler and more readable code. (By contrast, Linux culture treats code as replaceable and doesn't shy of major rewrites/throwing away old code when needed, because there are more Linux kernel developers than the kernel itself. In BSD world that generally leads to hurt pride and another (short-lived) BSD fork - in Linux it is a daily routine.)
Slashdot Mirror
ReactOS - yes. That was in response to GP comment that MSFT also makes source of Windows available to the universities. The story was discussed on Slashdot in the past and the source code license has pretty draconian conditions attached.
What do you mean by "completed"? ReactOS aims to be binary compatible with Windows drivers, so ReactOS will be as "complete" as Windows in this regard.
Windows itself isn't always compatible with the 3rd party drivers.
And the stability of XP and W7 is largely attributed to the fact that MSFT has taken over device driver development and maintenance from many 3rd parties.
In other words, ReactOS isn't going to have an easy time with the drivers, even if it is 100% compatible with Windows. Many drivers are not accessible because they are (c) MSFT. 3rd party drivers are often of piss poor quality and wouldn't work well on ReactOS for the same reason they are working poorly on Windows itself.
If ReactOS was ever completed it would be a big problem for Microsoft....
It would never be completed, because:
1. Most of the code in Windows are the device drivers. MSFT has literally thousands developers writing and maintaining the drivers.
2. MSFT keeps updating and changing secondary APIs very often.
Wine IMO is the only sensible approach to simulating Windows, because it reuses the device drivers of the host platform.
But as topic goes, the only thing wrong with ReactOS in academia is that it gives the VMS-isms another life lease.
It has the advantage of being bug-free (relative to ReactOS),
That is actually a disadvantage for an academic OS. When there are obvious problems, there is no need to think much of lab assignments.
Problem is, as system programming goes, Windows is very boring. As you say, it is very stable - but it is also closed-source. Meaning that whatever students implement remains an academic exercise.
In LibreOffice, Java parts are being slowly rewritten in Python.
Name Conflicts In Automatically Generated Email Addresses?
I know this is a silly question but why not to actually ask the affected users???
30K*1.6% is 480 people. Generating automatically a bunch of e-mails, grouping the conflicting names onto CC lists shouldn't be much of a problem. Put the autogenerated names in the body and use some special prefix in subject line. Ask them to put the desired names into the first line of the response and set dead-line. On dead-line, check for remaining/new conflicts and probably repeat again. That would reduce conflicts to probably a dozen if not less. (Or an internal discussion board or Wiki can be used instead to let people to handle the conflict and in some convenient form provide the feedback to you.)
As personal experience goes... I work in company with 50+K employees and the autogenerated names suck. You pretty much never can tell who is who. And with the constant restructurings, one can't even rely on the name of department in the LDAP.
I have read all the deltas from 5.8 to 5.14 (they are part of the Perl man pages) and there is really nothing major there. Tweaks and fixes here and there. Couple of syntax tweaks from Perl6. Multi-threading enhancements. But nothing what can potentially make Perl more relevant to me now.
Yes, Perl5 is well maintained. But I doubt very much that we would see any big feature introduced, since it has to remain backward-compatible.
It's not about OO or syntax.
Unlike Perl, Python simply has more up-to-date feature set. And better support for Windows.
For example. Literally everything uses Unicode/utf-8 now - but Perl still defaults to binary/ASCII for everything. And Python defaults to utf-8 for the text.
That's how it happens. 10-15 years ago, Perl was 100% useful out of the box. Now you have to pile up some options just to make it realize the default encoding of you environment. Inevitably, to spare the nonsense, one starts using the new tools - like Python - which are more in line with the current defaults.
It'll be nice if there could be a JIT or some other accelerator for Perl.
I have seen some old posts about attempts to port Perl's interpreter to LLVM to be able to take advantage of its JIT facility. As far as I can tell, it didn't went too far. (The most discussion I can find. But about work from 2008-'09.)
Main obstacle for Perl's advancement and progress is the Perl6.
You can't change the Perl5 because a lot of stuff depends on it.
You can't make new version of Perl out of Perl5 because Perl6 is already out there.
All in all, I strongly believe that it is the miserable failure of Perl6 what's killing any potential progress the Perl could have made.
Right now, the best thing which could happen to Perl IMO is a fork of the Perl5. Yet, since user/developer base is declining, I very much doubt that would happen.
That is excellent. Considering that that particular benchmark is arithmetical and Perl has nearly zero optimizations for the arithmetic.
... and Newt Gingrich has 1M of Twitter followers.
Why would there me more or less need for a big sized display depending on how many colors it can display?
As long as the contrast is decent I would love a large eInk display
You alone do not make large enough market.
Large CRTs and panels, before becoming parts of consumer products, where literally exclusively used by businesses for marketing purposes (displays in shops, exhibitions and so on). They bore the high price of very early adopters. And: marketing wants to have colors.
Unless there would appear a market for large B/W panels or the color version of e-Ink would enter production, chances of a large e-Ink panel are very close to zero.
I'm surprised that a more standard-compliant compiler is a "bad thing" now.
Not "is [...] now." But "was [...] back then."
Purpose of the compiler is to compile existing programs. NOT future programs.
It is counterproductive to suddenly insist on standard compliance when there was previously no standard compliant compiler available.
Still better than the weekly news about Firefox version increment.
And I personally like to keep an eye on the development. Imagine the power of the Linux packaging combined with the BSD kernel. Imagine the sound system which doesn't suck. Imagine the storage, if supported at all, crunching data at half the usual rate. Imagine the unaccelerated graphical interface... ...I digress. But it is still interesting.
Pretty much all platforms have the time_t as long - the type used to represent UNIX time. Pretty much all platforms are now 64bit and thus have 64bit long. And even some 32bit platforms have 64bit time_t. It was problem about 10 years ago - but now it doesn't exist anymore. And the problem was mostly in the compilers: lack of the 64bit integer data type support in 32bit mode.
The only platform where I have seen problem with 64bit time was the HP-UX 11.11 and 11.23 (haven't tested the 11.31). Some functions are failing/hanging when passed time value larger than 2^31. I have also seen similar problems on AIX 5.3 - but IIRC AIX 6.1 has fixed it. But then, nobody cares about the HP-UX or AIX anymore. Linux, Solaris and BSD are OK for quite some time now.
Also, my reason for switching from DEB to RPM-based distro was it seems Debian's core package management tools haven't seemed to evolve much in years while RPM appears to have improved quite a bit.
Apt hasn't involved mostly because, unlike RPM, it got many things right first time.
The delta-compressed updates is a huge deal for me, but also the general speed of the tools.
Delta packages is sure a nice feature, but it doesn't work well with community distros. There is no central authority to "bless" packages and thus there is really no base version to make the delta to.
As to the speed, I personally never had the problem with the Debian itself. They try to get it right before release and besides the initial wave of updates after the release, there is relatively few regular updates. Since I use Aptosid right now (distro of Debian connected literally directory to unstable repository) I can't really tell how it is right now in the Debian itself. (100+ updated packages per week is quite normal for Aptosid. So performance of updates for me is rather /non-issue/, since there is no performance to speak of.)
OpenSuSE's zypper tool also gives a bit of freedom in installing 'unmatched' later versions of libs but if things go wrong, it's easy to trace and downgrade.
That was implemented in Debian looong time ago. (IIRC pinning appeared in Debian 3.0.) The problem is that one has to read quite a lot of documentation to understand how to use the version pinning properly.
"With that in mind, Hartung believes Steve Ballmer will do anything and everything to save Windows, including ditching entertainment and therefore Xbox."
Twisted logic.
If Windows/Office are on decline, why sell the only growing, and potentially profitable, business branch they have?
[...] it is not allowed to interfere with the free market by also participating [...]
A link to the relevant German law?
To date, I thought that was pretty unique to USA.
It is not about "giving" it away.
My reading is that it's precisely about that: gov't isn't allowed to give stuff away.
Though I live in Germany, I'm no legal expert and would appreciate a link to the relevant law.
I looked at the Gunnar Web site and saw no scientific backing of any of their claims. In my opinion, any improvement you'll get from these is 100% due to a placebo effect.
[... skip ...]
TL;DR Snake oil glasses, you've been conned.
Google for "photography yellow filter". References are scarce, because the filters were used in B&W photography, in pre-Internet times. But there are some.
Alternatively google for "white balance amber" or ask on DSLR forums/check DSLR books about the shit to amber. Or if you have a DSLR, you can even experiment with it yourself: shoot a RAW and in any RAW development tool, play with the blue-yellow gauge in the white balance.
All in all, as few commented above, those are simply well made yellow glasses. And the effect of yellow filter is known from photography and is not placebo. But also doesn't warrant the Gunnar's price.
I was thinking the same thing - yellow plastic glasses.
My first thought was: yellow filter. The effect of the yellow filter is well known from the times of B&W photography: boost contrast, darken the (blue) skies (so that they do not white out completely). In color or with DSLRs, the same effect is achieved by adjusting white balance settings in the direction of amber: it gives the picture warmer colors.
Some people have mentioned above the Redshift. I personally use on my PC the f.lux and it appears that both programs have almost the same effect as the yellow filter.
This is yet another Steve Jobs clusterfuck. The original Mac was the first PC that used black on white and idiots have been aping it since.
It's not white. In fact, the light background on Macs is not even a color - it is a texture with smoothed horizontal stripes. Not huge fan of it, but it is not THAT bad.
That was one of the first surprising things I found on the Macs: somehow background is light, yet my eyes haven't started aching immediately. Took screenshot, enlarged it and enjoyed that the UI designers are not complete fools.
Newer versions of Mac OS have more of plain colors. But most of the UI still uses some textures for background. The net effect is that even empty space in the UI to the eyes doesn't look glaringly empty. And that's pretty much only advantage of it.
EMMISIVE DSPLAYS SHOULD NOT HAVE BRIGHT BACKGROUNDS!
*Nod*
Well, Amazon Kindle has unfortunately pre-made three choices for you:
1. (Default) Black on light gray. Not great but OK.
2. White on black. And that is hard black on true white. High contrast nightmare.
3. Sepia: some sort of grayish on some sort of yellowish. Low contrast nightmare.
White on black and sepia lay essentially on extremes of the contrast range, leaving as useful only the #1. Without a jail-break, there is no way to create the popular for backlit screens "Light gray on black" color scheme. And that is one of the reasons why I stayed away from the Kindles with the LCD. eInk is OK (but the new Kindle devices with e-Ink sport newish squarish UI which unfortunately is too dumb down; my next device will not be from Amazon).
I haven't looked into Solaris code, but I have seen (with the eyes of system programmer) both BSD and Linux code.
BSD is much more readable - but in larger part because it is much simpler.
But Linux is also readable - if you know how the stuff works. The modularity of the kernel also has an impact, since in a place where BSD has a single readable function, in Linux one might find piece of code with calls to potentially dynamically loaded modules. But that is still the simplest part. Hard part is the "how the stuff works." Linux for performance reasons has many things implemented up-side-down and it takes some time to get used to it.
Over the life time of Linux, there were many discussion about the readability vs. performance. In the beginning readability was mostly winning. But as Linux became more and more popular, later literally de facto server OS, the choice (IIRC Linus was also involved in the discussion) was inevitably falling to the performance. It ended up with something like: few CPU cycles saved in one function, multiplied by million of Linux boxes, equals millions of cycles saved.
BSDs IMO always more cared about feature completeness and long-term maintainability. That I believe led to simpler and more readable code. (By contrast, Linux culture treats code as replaceable and doesn't shy of major rewrites/throwing away old code when needed, because there are more Linux kernel developers than the kernel itself. In BSD world that generally leads to hurt pride and another (short-lived) BSD fork - in Linux it is a daily routine.)
They should have called the planet "Hell" or "Purgatory."
Might have attracted christian players.