There used to be a web page called "Your Eyes Suck at Blue". You might find it on the Wayback machine.
You can tell the luminance of each individual channel more precisely than you can perceive differences in mixed color. This is due to the difference between rod and cone cells. Your perception of the color gamut is, sorry, imprecise. I'm sure that you really can't discriminate 256 bits of blue in the presence of other, varying, colors.
Rather than abuse every commenter who has not joined your specialty on Slashdot, please take the source and write about what you find.
Given that CPU and memory get less expensive over time, it is no surprise that algorithms work practically today that would not have when various standards groups started meeting. Ultimately, someone like you can state what the trade-offs are in clear English, and indeed whether they work at all, which is more productive than trading naah-naahs.
Your reasoning falls short. Linus isn't the driver of new features. He's the head maintainer. Many other people contribute code they need to do new things. He vets it and makes sure it doesn't break the rest of the kernel. He enables other people to do the innovative things by giving them a well-maintained place to put them.
It's true that Linus is simply the head of the maintenance tree, but the fact that he isn't the driver of new features seems to support my thesis that he doesn't have much need to look ahead very far. That function is generally handled by others lower in the tree, or completely outside of it.
I'm not sure I see my logic failure. Could you elaborate? Am I emulating Eliza?
You're getting grumpy, old man.
Nothing a good card sorter couldn't fix. That's why we use line numbers on our COBOL decks and all that.
Er. UseD. UseD.
No, no, no, no, no! The concept of garbage collecting is a reaction to poor coding practices and reliance on it is laziness. Software engineers responsible for real-time, public safety software should be capable of managing memory in their code!
Meh. Real-time public safety software should not be running in an environment which allows an application to arbitrarily request memory.
I've written code for multiple mainframe online transaction environments and in UNIX C/C++ and Java environments. Guess which one is more problematic when it comes to memory leaks and other similar issues?
I'm hardly suggesting that a mainframe environment is a viable answer, but the approach that such environments take was taken for a reason. Controlled environments are far less prone to programmer stupidity than uncontrolled ones.
One advantage of many airline online transaction systems: An applications programmer cannot do a malloc equivalent.
Programs are created with a fixed memory size, and complex applications are simply a series of program modules which pass data between each other via common memory areas or memory-mapped files.
Memory leaks in such an environment are quite rare.
Linux isn't a corporation. Also, for something as specific as an OS kernel, I'm not sure there's much to be said for looking out in a detailed manner more than a few major iterations in advance. Sure, there are probably features being considered all the time, but that doesn't make them a focus.
Heh. I'll reply to this non-anonymously.
SLS was fun to play with, but sadly that's all I did. I grabbed a boot and root diskette image plus the A and B series diskettes from a local BBS in the Twin Cities sometime in 1993. SPS 099pl13 or something. Moobasi BBS? Anyway, I also grabbed the X series for XFree86, but I couldn't get it to work (I might've had a Diamond Stealth VRAM at the time which didn't play nice outside of Windows), so I mostly just putzed on the command line.
By the time I tried Slackware for my 486, I'd upgraded to a CL5343-based Speedstar 64 because it worked with OS/2, and XFree86 was perfectly happy.
From there, I want to RH4.2 I think. Red Hat was not to bad with fvwm. It was fun to tinker with the various window managers. olwm, mwm, etc. I didn't really use Linux "seriously" until much latter. I was happy with my OS/2 2.1 GA+SP setup, and with Warp 3, so Linux was more a curiosity than a necessity for me.
Well, mostly. I do international business and it's not that difficult without bitcoins. During a bitcoin transfer, there is an that I own bitcoins, and I am exposed to the risk that the bubble bursts at that moment. Not worth worrying about unless the amount is large.
I don't have to apologize for national fiat currency, it's silly too, and I don't keep my assets in cash. My problem with Bitcoin is that it is even less credible than "the faith and credit of the United States government", which has been the justification of the Dollar since it was allowed to float. It seems to be nothing but "wish and it will come true".
No, the small-aircraft owners aren't at risk of messing up their avionics. They are, however, consciously messing up the cellular network for everyone else. You see, you are supposed to be in range of just a few cells when you use your phone, so that we get frequency reuse between cells. If you are at altitude, you are in line-of-sight communications with all of the cells out to the visible horizon on all sides. And the frequencies you are using are probably locked out from reuse over that entire vast area. It would not take very many phones at altitude to disrupt the entire system.
People who received a play-money system from a mysterious unknown person and actually convinced themselves that it has value are now facing a schism over the money market failing to grow without bounds. Unless, that is, the software is modified in a way that might, over time, disincent people from playing the game.
I can't be the only one who is thinking that the only problem is that these folks believe bitcoins have value.
Hell, I thought that the fiat currency of nations was a bad deal. This is an order of magnitude worse.
"Is it really you, Fuzz, or is it Memorex, or is it radiation sickness?" -- Sonic Disruptors comics