The newest hire at the id Software, Fredrik L. Nilsson hails from Sweden...
... In 1995 I moved to the San Francisco area and was hired by Pacific Data Images (PDI) as a character animator. Some of the projects I worked on while there are:
"Hello my name is RovingSlug, and I used to be a Kernel Version Whore."
That was way back in the 2.1.x days. Then, I knew all the caveats of the minor revisions, and I knew which particular revisions were more stable than others. Now I'm nearly the opposite. I'm happy to leave my system running for months on end without checking the status of the kernels. I actually have to "cat/proc/version" to see what revision I have fired up.
That attitude is only reinforced with the 2.4.x tree. Pondering a kernel upgrade is like pondering if I want to step into a minefield.
Reading the comments in "2.4, The Kernel of Pain", I know there's still Version Whores out there. They know the obvious stuff like "don't use 2.4.15". And I'm sure there's less obvious stuff, too. Aunt Tillie or whomever isn't going to keep up. If she steps onto the 2.4.15 mine (or its equivalent in the future), she could do damage to her system.
To that end, we could use short, digestible ranking/summary system of the kernel revisions. (Or does one already exist?) Which kernels in the stable branch are really unstable? Which are the most robust?
Many, Aunt Tillie and myself included, would find value in such a system, regardless of a Kernel Autoconfiguration program.
There otherwise seemed to be a 1-to-1 correspondence between review pages and links in the Table of Contents. So when I saw the link on the Conclusion page, "TN + Film", I just thought it was mistakenly linking back to the earlier page "TN + Film (Twisted Nematic + Film)".
Maybe I'm naive, but I'd say two very relevant qualities of an LCD display, hell any display, are size and resolution.
As far as I can tell, few to none of the "Test Tests" pages provide this information.
The "Conclusion" is actually just a summary of monitor properties with no rankings or opinions gathered presumably from a "review" process. Even then, the summary doesn't include size or resolution.
On the first page, there's no description why these values are not relevant nor significant for the review. Instead, there's three paragraphs regarding why Samsung-France is big and mean for not sending a unit to "review". Not only does that seem like last-page material, it seems unprofessional to even print.
Going back the introductory pages, I did find some references to "only of limited interest for a 15" monitor", and a few other references to "768 pixels". So, after correlating and cross-referencing text from a number of pages in the review, I can make the guess that all the monitors have 15" diagonal with max resolution 1024x768.
Considering the quality of both the review process and the journalism, Samsung was right to not send them a monitor. And, I'm right to resume my practice of never visiting Toms Hardware.
Yeah, I thought it was green too. That's why in 16-bit color, it's 5 bits for red, 6 bits for green, and 5 bits for blue.
Hmm, hard to find a definitive source. But, some support for that assertion is here ("10Eh : 320x200 64k-colour (5:6:5)", "111h : 640x480 64k-colour (5:6:5)",...) and here ("16 bit color depth is supported through several different bit arrangements, including 5-5-5 and 5-6-5.").
isn't sending just "X=3, Y=1" simpler? It seems to take 1/4 of the bandwith. You can even send it twice
Well, yes. But (as I understand, and my maths is better than my networking) you then need ACKs to state each data block has been received (i.e. not a stateless UDP connection).
My understanding is that it's still stateful, just in the sense of the entire transmission rather than each packet. So, rather than being hardset to send those four equations, the sender just knows the process to create them. And, the sender keeps creating and sending until it receives that single ACK ("OK! Enough!" instead of "OK, got that one, next?"). If there's some overflow and the receiver gets a few extra packets, no biggie, it's still cheaper than the time and data that would have been spent handshaking along the way.
I believe Divx4 was rewitten from scratch. I can't find verification of that at Divx.com, but this Virtudub doc on codecs agrees:
DivX 4.0 isn't really related to 3.11a. It's a new codec that has been ramped up partly from scratch and partly from the MuMoSys reference code....
Also, from personal experience, at 500 kbps, I get good quality Divx4 video. I'd say it's better than VHS at that rate, except for some problems with very low contrast settings.
... having a fast refresh rate on those monitors isn't worthwhile.
See this article about Mitsubishi's feed forward driving (FFD) technology. (I don't recall what site originally pointed me to the article.)
Summary: By controlling the pixel voltages as a function of both the current frame and the next frame, average response time is reduced from about 35 ms (30 Hz) to about 10 ms (100 Hz). According to a Mitsubishi representative, FFD will be incorporated in mass-production LCD panels starting in the first quarter of 2002.
Unless your target platform has a limited amount of storage.
Then apply Rule #2. But even then only after applying Rule #1.
However, the original article maintains applications for DOS/Windows. The original comment you and I are replying to addresses bloat in the various versions of MS Windows. In those cases, none of your cited examples are relevant.
Rule #1: Premature optimization is the root of all evil. -- D.E. Knuth
Rule #2: Optimize only what is important and necessary.
Out of stability, features, and application size, application size is far and away the least important.
Make the applications do what I want. Make them bug free. If an application ends up being 4 MB instead of 200 KB, but is more stable and/or more featureful, I could care less about the size.
So what. You're ranting about the contents of the arbitrary notion "Operation System".
Rethink through what you typed, reapplying your own words "A computer in a home/business environment should be useful, usable and reliable."
PC's support diverse hardware. For whatever hardware I have, I want applications to run out of the box. That's what is "useful, usable and reliable".
I do not want to have the writer of the software have to directly support my hardware to run a spreadsheet. Or write their own windowing environment. As a user, switching to a whole other user environment for each individual application is not useful or usable. And having N versions of the software for all the N possible hardware configurations is not reliable.
Okay, fine. Let's have someone build some sort of graphical environment that my spreadsheet can run on. That'd be nice. Well, if that graphical environment isn't a standard piece of software, I still have the same problem. There's nothing useful or usable about having to load up other graphical environments to use other sets of applications.
So heck, what's useful and usable is to have one graphical environment that all my applications can run on.
Oh, installing a separate packages of "Standard Components" after installing my "Operating System" isn't very convenient. So, what's useful or usable to the end user is to package all those up as "Operating System and Standard Components".
Huh. Well, unless you're the types prone to arguing semantics instead of substance, there's nothing useful or usable about calling it "Operating System and Standard Components" when just "Operating System" will do.
"want to have the families fail and fight or would they learn from the positive growth of the people within the game"
You seem to have quickly and easily made the assumption that experimenting with making families fail would result in a "bad impact". I don't see why this is the case. Do you have any justification?
"My opponent's reply came instantly, if cryptically..."
Cut+pasting "Fischer Armando Acevedo" into Google, scanning for relevant information, and cut+pasting the information back into the chat window doesn't exactly mesh with "My opponent's reply came instantly...".
Your particular piece of counter-evidence is a lot weaker than it appears.
Arguing by metaphor is not valid. Even so, no real evidence is given supporting the mataphor.
"Most software design is lousy." Evidence? Support? Oh, because the second paragraph describes ugly buildings in detail?
"Beautiful programs work better, cost less, match user needs, have fewer bugs, run faster, are easier to fix, and have a longer life span." Evidence? Support? Of those measures on "beautiful" versus "ugly" programs?
Reading constructs like "Just as a building should be..." pisses me off. We're talking about software. Give me measures of software, not buildings. That point doesn't even apply, since evidence is given for neither.
Why do I care how many NOP's a processor can do per second? That's what the marketing will eventually go toward, anyway.
And where are you taking into account the amount of computation each instruction does? For instance, consider vectorized instructions (MMX, SSE/2, 3DNow!). One instruction, but a lot of computation done.
When push comes to shove, the only metrics that matter are non-synthetic benchmarks tagetted at your intended application. If you're going to do Matlab, go find some Matlab benchmarks. If you're going to do Photoshop, go find at some photoshop benchmarks. If you're going to do Quake, go find at some Quake benchmarks. Ad nauseum.
Fair enough... also note that no one has asked you to pass judgement yet, either. Just consider it an interesting story from a site with the moto "News for Nerds. Stuff that matters." Seriously, what part of Slashdot _do_ you consider to be impartial? Filter everything you read, reserve judgement in all cases, and move on.
Here in America, too. I know many people that bought a Voodoo (1, "classic") to play GLQuake. Tomb Raider was hardware accelerated? I didn't know or care, and apparently neither did anyone else I knew.
It's consensus among the circle of people I know that GLQuake was the 3D hardware acceleration killer app.
A text-based format is a huge advantage. Consider not just transmission of data but storing, maintaining, and manipulating data.
With data as text, you can casually inspect data files with a text view and modify them with a text editor. Text editors are significantly more full-featured than hex-editors for viewing and modifying binary data.
With data stored as text, you can leverage existing text-manipulation tools such as Perl, diff, and CVS/RCS to provide functionality not included in the primary application.
For instance, I had a program in which I wanted to change a particular property of a large number of distinct objects. The editor I was using did not offer search and replace for that property. But because my data was stored as text, it was _trivial_ to write a small perl script to modify what I wanted. The time investment would have been too great if I would have had to discover and target a binary format to do the same thing.
Use your CPU indeed - leverage general tools across many applications. Don't develop a single tool per binary format.
Agreed. Slashdot's presentation totally misrepresented the actual story.
See, rather than applauding the Pentagon for giving away (!) computers (!!) to schools (!!!), and rather than commending the Pentagon for reversing an existing policy (the path of least resistance would have just destroyed those hard drives), Slashdot decided to flex its techno-elitism and show just how snobby some geeks can be.
So, if some people at Slashdot would stop desperately trying to mock any and all mainstream journalism about computers, perhaps they'd see the actual value of this story.
Slashdot Mirror
From Doomworld -- Interviews:
That was way back in the 2.1.x days. Then, I knew all the caveats of the minor revisions, and I knew which particular revisions were more stable than others. Now I'm nearly the opposite. I'm happy to leave my system running for months on end without checking the status of the kernels. I actually have to "cat /proc/version" to see what revision I have fired up.
That attitude is only reinforced with the 2.4.x tree. Pondering a kernel upgrade is like pondering if I want to step into a minefield.
Reading the comments in "2.4, The Kernel of Pain", I know there's still Version Whores out there. They know the obvious stuff like "don't use 2.4.15". And I'm sure there's less obvious stuff, too. Aunt Tillie or whomever isn't going to keep up. If she steps onto the 2.4.15 mine (or its equivalent in the future), she could do damage to her system.
To that end, we could use short, digestible ranking/summary system of the kernel revisions. (Or does one already exist?) Which kernels in the stable branch are really unstable? Which are the most robust? Many, Aunt Tillie and myself included, would find value in such a system, regardless of a Kernel Autoconfiguration program.
Speaking of the merits of Fasttrack, it also provides robust parallel download and auto-resume. Using Gnutella is painful by comparison.
Ah, I did not catch it.
There otherwise seemed to be a 1-to-1 correspondence between review pages and links in the Table of Contents. So when I saw the link on the Conclusion page, "TN + Film", I just thought it was mistakenly linking back to the earlier page "TN + Film (Twisted Nematic + Film)".
Maybe I'm naive, but I'd say two very relevant qualities of an LCD display, hell any display, are size and resolution.
As far as I can tell, few to none of the "Test Tests" pages provide this information.
The "Conclusion" is actually just a summary of monitor properties with no rankings or opinions gathered presumably from a "review" process. Even then, the summary doesn't include size or resolution.
On the first page, there's no description why these values are not relevant nor significant for the review. Instead, there's three paragraphs regarding why Samsung-France is big and mean for not sending a unit to "review". Not only does that seem like last-page material, it seems unprofessional to even print.
Going back the introductory pages, I did find some references to "only of limited interest for a 15" monitor", and a few other references to "768 pixels". So, after correlating and cross-referencing text from a number of pages in the review, I can make the guess that all the monitors have 15" diagonal with max resolution 1024x768.
Considering the quality of both the review process and the journalism, Samsung was right to not send them a monitor. And, I'm right to resume my practice of never visiting Toms Hardware.
Do you really want to fill your life with sophomoric debates with a "spammer"?
Forget about his spam. Forget about him. Do something more rewarding with your time.
Erm, just a sanity check. That's saying human vision differentiates about 89 shades of green (2^6.47) as aptly as 16 shades of blue (2^4.04)? Ouch.
Hmm, hard to find a definitive source. But, some support for that assertion is here ("10Eh : 320x200 64k-colour (5:6:5)", "111h : 640x480 64k-colour (5:6:5)", ...) and here ("16 bit color depth is supported through several different bit arrangements, including 5-5-5 and 5-6-5.").
Also, from personal experience, at 500 kbps, I get good quality Divx4 video. I'd say it's better than VHS at that rate, except for some problems with very low contrast settings.
I couldn't find the link to the trailer movie... can someone point the way?
See this article about Mitsubishi's feed forward driving (FFD) technology. (I don't recall what site originally pointed me to the article.)
Summary: By controlling the pixel voltages as a function of both the current frame and the next frame, average response time is reduced from about 35 ms (30 Hz) to about 10 ms (100 Hz). According to a Mitsubishi representative, FFD will be incorporated in mass-production LCD panels starting in the first quarter of 2002.
Then apply Rule #2. But even then only after applying Rule #1.
However, the original article maintains applications for DOS/Windows. The original comment you and I are replying to addresses bloat in the various versions of MS Windows. In those cases, none of your cited examples are relevant.
Rule #1: Premature optimization is the root of all evil. -- D.E. Knuth
Rule #2: Optimize only what is important and necessary.
Out of stability, features, and application size, application size is far and away the least important.
Make the applications do what I want. Make them bug free. If an application ends up being 4 MB instead of 200 KB, but is more stable and/or more featureful, I could care less about the size.
Hrm, instead of a stripped-down 1.44 MB bootable system, how about a full-featured 650 MB bootable CD-ROM solution? SuperRescue CD.
Rethink through what you typed, reapplying your own words "A computer in a home/business environment should be useful, usable and reliable."
PC's support diverse hardware. For whatever hardware I have, I want applications to run out of the box. That's what is "useful, usable and reliable".
I do not want to have the writer of the software have to directly support my hardware to run a spreadsheet. Or write their own windowing environment. As a user, switching to a whole other user environment for each individual application is not useful or usable. And having N versions of the software for all the N possible hardware configurations is not reliable.
Okay, fine. Let's have someone build some sort of graphical environment that my spreadsheet can run on. That'd be nice. Well, if that graphical environment isn't a standard piece of software, I still have the same problem. There's nothing useful or usable about having to load up other graphical environments to use other sets of applications.
So heck, what's useful and usable is to have one graphical environment that all my applications can run on.
Oh, installing a separate packages of "Standard Components" after installing my "Operating System" isn't very convenient. So, what's useful or usable to the end user is to package all those up as "Operating System and Standard Components".
Huh. Well, unless you're the types prone to arguing semantics instead of substance, there's nothing useful or usable about calling it "Operating System and Standard Components" when just "Operating System" will do.
"want to have the families fail and fight or would they learn from the positive growth of the people within the game"
You seem to have quickly and easily made the assumption that experimenting with making families fail would result in a "bad impact". I don't see why this is the case. Do you have any justification?
They were just playing speed chess. Their concept of "instantly" at that time would have been well below 16 seconds, which is an eternity.
Cut+pasting "Fischer Armando Acevedo" into Google, scanning for relevant information, and cut+pasting the information back into the chat window doesn't exactly mesh with "My opponent's reply came instantly...".
Your particular piece of counter-evidence is a lot weaker than it appears.
Arguing by metaphor is not valid. Even so, no real evidence is given supporting the mataphor.
"Most software design is lousy." Evidence? Support? Oh, because the second paragraph describes ugly buildings in detail?
"Beautiful programs work better, cost less, match user needs, have fewer bugs, run faster, are easier to fix, and have a longer life span." Evidence? Support? Of those measures on "beautiful" versus "ugly" programs?
Reading constructs like "Just as a building should be..." pisses me off. We're talking about software. Give me measures of software, not buildings. That point doesn't even apply, since evidence is given for neither.
Gross.
CPI is worthless.
Why do I care how many NOP's a processor can do per second? That's what the marketing will eventually go toward, anyway.
And where are you taking into account the amount of computation each instruction does? For instance, consider vectorized instructions (MMX, SSE/2, 3DNow!). One instruction, but a lot of computation done.
When push comes to shove, the only metrics that matter are non-synthetic benchmarks tagetted at your intended application. If you're going to do Matlab, go find some Matlab benchmarks. If you're going to do Photoshop, go find at some photoshop benchmarks. If you're going to do Quake, go find at some Quake benchmarks. Ad nauseum.
Anything else is a damn lie.
Fair enough... also note that no one has asked you to pass judgement yet, either. Just consider it an interesting story from a site with the moto "News for Nerds. Stuff that matters." Seriously, what part of Slashdot _do_ you consider to be impartial? Filter everything you read, reserve judgement in all cases, and move on.
It's consensus among the circle of people I know that GLQuake was the 3D hardware acceleration killer app.
"Historical revisionism"? Indeed.
A text-based format is a huge advantage. Consider not just transmission of data but storing, maintaining, and manipulating data. With data as text, you can casually inspect data files with a text view and modify them with a text editor. Text editors are significantly more full-featured than hex-editors for viewing and modifying binary data. With data stored as text, you can leverage existing text-manipulation tools such as Perl, diff, and CVS/RCS to provide functionality not included in the primary application. For instance, I had a program in which I wanted to change a particular property of a large number of distinct objects. The editor I was using did not offer search and replace for that property. But because my data was stored as text, it was _trivial_ to write a small perl script to modify what I wanted. The time investment would have been too great if I would have had to discover and target a binary format to do the same thing. Use your CPU indeed - leverage general tools across many applications. Don't develop a single tool per binary format.
Agreed. Slashdot's presentation totally misrepresented the actual story.
See, rather than applauding the Pentagon for giving away (!) computers (!!) to schools (!!!), and rather than commending the Pentagon for reversing an existing policy (the path of least resistance would have just destroyed those hard drives), Slashdot decided to flex its techno-elitism and show just how snobby some geeks can be.
So, if some people at Slashdot would stop desperately trying to mock any and all mainstream journalism about computers, perhaps they'd see the actual value of this story.