Re:Katz writes about things without having 2 clues
on
Selfish Society
·
· Score: 2
And today's winner for most deserving of the title "Anonymous Coward" is...well, we don't know.;-) But here's what s/he spewed:
>Geeks are paid for their knowledge, not physical labor abilities. Physical labor is for people who don't have any real skills
I wasn't talking just about manual labor. Even what we call "manual labor" can often involve more than meet the eye. It takes more training and practice to become a qualified pipefitter or carpenter than it does to sit in an office and create new JavaScript toys, and believe me you'll notice the difference if you hire someone who's still learning. A halfway decent tool and die person is harder to find than a good compiler writer. I'd rather write filesystems than be a cop or a firefighter or a social worker or K-12 teacher - all hard jobs with great social value, and the people who do them make peanuts compared to us.
Lots of people are paid for their knowledge and their hard work and for tolerating danger or physical discomfort, but programmers are just paid for knowledge - and all too many programmers don't even have that.
>I don't appreciate your racist comments towards whites either
I've been hanging around/. for years, and that's still the most idiotic thing I've ever read here. I haven't said anything racist about whites; I merely observed that programming is a mostly white profession. In actual fact, as a white male I'm pretty quick to take offense at reverse racism/sexism, and have been ever since the time when I was denied a job for which I'd been recommended on the basis of my race and gender (University of Michigan, 1984). You're just the perfect example of everything that's wrong with the spoiled little turds who call themselves geeks nowadays.
>It's not "some people", it's all people. Everybody is born with the "hero nature" (to use your phrase), most just don't/can't come to terms with that.
Inability to come to terms with it is, effectively if not essentially, the same as not having it. And it's a good thing, too, because the only alternative most people can imagine to being a sheep is being a wolf, and a surfeit of wolves can be rather...unhealthy.
I don't trust everyone to be a "true invididual" as you put it. Too many people's expression of individuality is to be a selfish jerk.
>I've read a lot of posts on slashdot and elsewhere from pompous Rand naysayers, who almost always seem compelled to throw in gratuitous ad hominems
Oh yes, like your characterization of anyone who doesn't worship Rand as "leeches" and "parasites" is really helpful.
>These posts usually amount to one or two anecdotal references to "people I knew in college."
There's a reason. It's an immature philosophy, favored by immature people, and for that reason it truly is more often encountered in college than in post-college "real life".
>I've read only a few that even attempted a real argument
If you define "real argument" as "something expressed in Rand's terms, using Rand's axioms" that's no surprise.
>If you think Bill Gates is anything like one of Rand's heroes then you've missed the point of all her work.
This is a favorite of Randites. This one guy I used to know always used to say "Read Virtue of Selfishness"...until I did. Then he'd say "Oh, VoS doesn't really describe it well, read Fountainhead"...until I did. Then it was "For the full treatment you have to read Shrugged"...until I did. I even passed his little quiz to show that I really had read and understood it, and I still disagreed with him. "If you disagree with it you didn't get the point" only works so many times.
>Gates is anything like any of Rand's characters, he's a Peter Keating or Gail Wynand
I didn't say he's an exact match, but he's more like than unlike. There are plenty of tycoons whose fortunes are entirely derived from mergers and takeovers and other high-finance games; they're the true second-handers. At least Gates and MS owe their success to something vaguely resembling a creative/inventive endeavour. Even MS's monopolistic practices are no worse than the blackmail of the "heroes" in Shrugged when they managed to achieve a monopoly regarding certain essential items. The only thing Bill apparently lacks is some quasi-mystical "hero nature" that is easy to pick up in a book but astonishingly useless as a guide for real-life social policy.
Rand's writing - including her alleged non-fiction - is full of this crypto-Nietzschean attitude, which some might perceive as almost racist. Some people are apparently born with the "hero nature" and should be allowed to do whatever they want without inconveniences like governments, while the rest are mere sheep (or leeches) who should be glad to live off the leavings and discards of the super-race. One is left wondering how we distinguish the true titans from the pretenders. Is there a test? A genetic assay, perhaps? If we can rely on this natural talent to reveal itself, why do we not already live in a Randian paradise? The Randites, of course, do not have an answer except for their certainty that they themselves are among the Chosen Few.
Re:Katz writes about things without having 2 clues
on
Selfish Society
·
· Score: 4
>the people that run it and work in it have worked HARD to get what they have
Most of the people in the computer industry have no freaking idea what hard work is. Programmers are an overwhelmingly white, male bunch raised in comfy suburbs, from whence they went to college on someone else's dime, spent four years drinking and screwing, then straight into an industry that dumps options and benefits on even the most half-assed of them as though they were gods. Most programmers have never had to perform any kind of manual labor at all, ever, and if they ever felt like they were poor it's only because they were playing little independence games with parents who would be ready to bail them out if things ever got truly rough.
I'm a software engineer, and I currently do very well thankyouverymuch. There are people who've had it a lot rougher than me, but I can at least claim to've spent time outside the "reality distortion bubble" in which programming is done and I never forget what it was like. I am constantly amazed and dismayed at how many programmers act like the salaries and working conditions in this industry are normal. Here's a clue, folks. The median household - not personal - income is considerably lower than the median starting salary for a software engineer coming out of college, who is probably single and generally has zero years of real-world experience. Most people don't get stock options. Most people don't even get flex time. They get their own cube if they're lucky, and dream of some day having their own office. Anyone with the tiniest shred of intellectual honesty would admit that we in this industry are unbelievably fortunate and privileged by any sane standard.
Work hard, my ass. I've worked far harder than most people around me to get where I am, and it's still nowhere near as hard as regular folks have to work to get even half as much. Get real.
I used to know a lot of people in college who were fanatical about Ayn Rand. Then they grew up. I've yet to meet a Randite who thought they were anything short of exceptional. Every last one cherished the fantasy that they were a Roark or a Galt, that their lack of stunning success in life was because they were surrounded by "leeches", and that under the right circumstances their utter superiority would become manifest and incontrovertible. It's a seductive daydream, particularly to nerds who have raised escapism to an art form, but it's no more than that.
Real live humans are much more diverse and complex than Rand's caricatures, and the difference really does matter. The simplistic half-solutions offered by Rand share a fatal flaw with earlier simplistic solutions inspired (ironically) by Marx, which is that they work only for cartoon characters. Bill Gates is the closest real-life approximation to a Rand "hero", and I don't think we need more of him.
By slashdot standards, withdrawing such a poorly thought out piece of crap may seem graceful, but in many other environments people are routinely expected to be graceful enough to refrain from publishing such tripe in the first place.
>You can't practically write OO code in languages that do not directly support it.
Totally wrong. I and thousands of others have been doing this for years, and it seems quite "practical" to us. Languages that directly support OO are only marginally more convenient than non-OO languages such as C; the OO languages' advantages have more to do with standardization of notation than with actually enabling an OO code structure.
>There is a new breed of C programmers, though. They don't assume Unicisms, PDPisms or TheirPlatformisms,
Instead, they have their very own set of blind spots and biases and bad habits. Non-viable mutants are a "new breed" too, but that doesn't mean they're an improvement.
>Some compilers, no matter the architecture, will write executable code on the stack: "trampolines".
I don't think this is "no matter the architecture". The need for trampolines is chip-architecture dependent, and any compiler writer who uses trampolines where they're not absolutely forced to should be shot.
>Just put your buffer in it's own segment, and give it a certain length, and then if it goes over, a segment fault is generated, and it can allocate more buffers. That's how windoze works.
Simply incorrect. Windoze also uses pages. Doing what you suggest would increase memory demand and page faults while decreasing TLB hits, with disastrous effects on performance.
Can you give some examples? Specifically, can you give some examples of where building the new executable code on the heap rather than the stack isn't just as helpful?
>(5) So, I **MUST** release the code showing what I did so others who do know the kernel well can fix it.
Here's the crux of the matter: release it to whom? Release it to people who know the kernel well, who have the ability and inclination to fix the problem? Or release it to people who don't know squat about the kernel, who are more likely to contribute to the appearance of a canned exploit on rootshell than to a fix?
>Carmack gives a good explanation on why wee need more than jsut 32 bit color.
That's a good pointer. Thank you.
What he's talking about is basically roundoff error that occurs when multiple operations are applied to a pixel. He may have a point. OTOH, there's a little voice in my head that says the accumulation of roundoff errors is not really inevitable but is really an artifact of exactly how and in which order those operations are done in a "traditional" rendering scheme. Obviously it's going to be even worse with something like 3dfx's fractional-pixel FSAA scheme. Maintaining higher-precision color information, at least in some parts in the rendering process, may be the easiest solution, but I think we also need to consider whether this accumulation of roundoff errors is a sign that traditional rendering methods are headed down the wrong path entirely.
Never mind that the human eye can't resolve color even that well (about 16bpp, glad you asked). Sure, there are some fun things you can do by treating non-color attributes - e.g. transparency - as though they were colors, increasing the on-paper bpp, but when it comes to the output this little numbers game is of no benefit to consumers.
>besides the enormous amount of CPU and bus bandwidth, there really isn't anything here that can't be found on the average 1999-2000 consumer PC hardware.
Yeah, besides that. Besides the most important determinants of overall system performance, which involve the most difficult design challenges, it's just like a PC. That's like saying that besides the armor plating and the big gun on the front an Abrams tank is just like the family car...in other words it's a totally meaningless statement.
>X has more or less followed the Unix paradigm where 'everything is a file' - which really means that everything is a flat, unstructured lump of text
That's not really what "everything is a file" (EiaF) means. EiaF is really a pretty low-level thing, meaning that all sorts of objects - files, devices, fifos - in a common namespace and are accessed via a common set of syscalls - open, close, read, write, ioctl. This was actually an advance over earlier operating systems which often required that you use different syscalls to get different kinds of descriptors for each kind of entity, and which had multiple namespaces as well. Ew. You can see the power of EiaF not so clearly in UNIX itself, which contains many deviations from the principle, as in Plan 9, which was the "next act" for the UNIX principals.
There are a couple of other principles that you seem to be confusing with EiaF, and I think it's worth discussing them too. One is the idea that files should be unstructured. Again, this is a low-level idea, this time referring only to the "physical" layout of files and to the filesystem interfaces. As a filesystem designer and implementor, I can say this principle is very important. Filesystems have quite enough to do without having to worry about different record types and keyed access and so on - as many pre-UNIX OSes (most notably VMS) did. Man, was that a pain. What gets built in user-space, on top of that very simple kernel-space foundation, is up to you. More complex structures have been built on top of flat files since the very first days of UNIX (e.g. dbm files).
Another related principle is that data should be stored as text whenever possible. This is an idea that's gaining new life with the widespread adoption of XML to represent structured data, and again it's a good one. Doing things this way makes it much easier to write filters and editors and search tools and viewers and such (or to perform many of these tasks manually) than if the data is all binary. It makes reverse engineering of file formats easier, which is a mixed blessing, but it also makes manual recovery and repair easier. Converting to/from text also tends to avoid some of the problems - endianness, word size - that occur with binary data. Obviously there are many cases - e.g. multimedia files - where conversion to/from text is so grossly inefficient that it's not really feasible, but in very many other cases it's just a pain in the ass for the next guy when some lazy programmer decided to dump raw internal data structures in binary form instead of doing it as text.
In conclusion, I'd say that by all means people should try to retain the structure of data. Even better would be if the means for manipulating data could be provided and linked to the data itself in some standard way, like OLE/COM does in the MS world. At the very least, even without a common framework, it would be nice if more programmers would provide libraries with which to manipulate their data files. But please, let's do all this on top of text wherever possible, and let's do that in turn on top of a flat-file kernel abstraction within a single namespace. These are some of the more important principles that led to UNIX being such a success.
First off, you don't want any data locally. That's right. I don't care who has the workstation, the only thing sitting on the local disk should be the OS. All user files, and major applications should be sitting on a remote filesystem.
This is both totally correct and totally, utterly wrong, because you forgot the most important part of making this work, which is caching. X-terminals and diskless workstations were tried for a while, and they sucked. They sucked because they were slow, and they were slow because getting their data off the server. That hasn't changed, either. Available bandwidth has increased, but so has appetite for bandwidth. The solution now, as it has always been, is to cache at the clients for performance, which means that the clients should and will have data - just not authoritative copies of data.
The problem is that, to make this work, you need to use a protocol that maintains all the semantics of local file access, most inportantly cache coherency but also things like locking. This is hard to do efficiently, especially when you have to consider things like recovery and failover, and so you don't often see it done well (or at all). NFS just punted on cache coherency, which is why everyone but a few people who've made careers out of implementing NFS agree that NFS blows chunks. AFS/DFS/Coda were at least designed to do this stuff right, but IMO - I'm a distributed and shared-storage FS designer/implementer - don't do it as well as they should and have suffered acceptance problems because of second-order technical (and some non-technical) issues. Sprite at Berkeley and Plan9 at AT&T have shown that this kind of thing can be done, but it has yet to be done in the context of a commodity OS. Some might argue that it can't be done in such a context, but I disagree. It is in fact one of my goals to create just such a filesystem...if I can ever convince an employer to let me, or find the means to do it on my own.
I'll start writing in a functional language just as soon as it's supported inside any OS kernel that has a large enough user base to be worth developing for. Until then, FP languages are useless to me, though I might of course use concepts and constructs that people associate with FP (even though for the most part those things have been known and accepted as good practice in non-FP contexts for decades).
>everyone was really quite shocked at the figures coming out, and went to some trouble -- including talking to Red Hat -- to attempt to eliminate configuration issues
Interesting. Everyone was on Mindcraft's case for _not_ involving Linux vendors in tuning efforts. Now they go out of their way to do so, and everyone's saying it looks suspicious. While everyone's talking about rigged benchmarks, how about analysis that ends up with one side accused of cheating no matter what they do?
>Of course, manufacturers with no morals (ATI, Megabyte, Intel) can optimize for these types of benchmarks, and thus seem faster than they are
No matter what benchmarks exist, _most_ vendors will to some degree optimize to those benchmarks. This is as true of Quake3 or your COM+ example or SPEC or AIM as it is of WinBench3D. Interestingly, the easier it is for the vendors to look at and understand how a benchmark works, the more specific their optimizations will be, and the least subvertible benchmark would be one where the vendors have _no idea_ what it'll do until it's run. I know that open-sourcers aren't going to like that idea, but there it is.
For years, the computer geeks have totally ignored the issues of how technology gets used, whether society is prepared for it, etc. Suddenly, another technology - one controlled by a different elite this time - pushes its way into the mass consciousness and suddenly...omigod! Technology can be dangerous! Put the genie back in the bottle! We're all going to lose our humanity to technology!
It's not just Katz, either. How many people here actually stopped to think about the ways that computers and the Internet have changed how we communicate, where we get our entertainment, who invests in what, and other fundamental things about our lives, economy and culture? How many people here actually asked whether society was ready for these changes? We're the ones who've been helping tear down the walls that slow technology adoption. The "Frankenstein scenario" is as much our doing as anyone else's.
>do you think that perhaps we should prevent these mergers that lead to monopolistic bullies before the DoJ has to deal with it
Nice thought. Been done.
Mergers and acquisitions are already reviewed with an eye toward the danger of the new entity controlling a large enough share of one or more interlocked markets that it can unfairly block out competition. In many cases approval is in fact withheld, or the merged entity is required to divest itself of certain elements, as is currently the case with AT&T buying MediaOne. This process seems to work rather well, its only major flaw being that it does not apply to a company - such as Microsoft - that achieves its size/influence through plain old growth rather than mergers and acquisitions.
One objection to the current situation is that requiring approval for a merger or acquisition is a form of prior restraint, disallowing actions not because they are illegal but because they create conditions in which something illegal _might_ happen. Being big is not illegal. Even being a monopoly is not illegal. _Using_ your size or monopoly position to stifle competition is what's illegal, which is why Microsoft keeps trying to claim that they achieved their position via innovation. That's not just PR; it's a very specific legal argument. Unfortunately, as we can see from the Microsoft case, addressing antitrust behavior after the fact is extremely time-consuming and potentially costly to everyone, so this may (arguably) be a case where nipping things in the bud is justified even though it violates a cherished "no prior restraint" principle.
Never be satisfied. Never rest on your laurels. Never assume that you know something better than someone else, or that what you know is more important than what they know. Never pass up an opportunity to learn a new language/API/OS/technique because it's "just a fad".
If you can maintain and cultivate this curiosity, or restlessness, or flexibility, or perfectionism, or humility, or whatever you want to call the intersection of all these things, you will continue to see your career progress. The reason so many people look askance at older programmers is because so many older programmers have become ossified and arrogant and complacent. Any employer in their right mind would gladly pay top dollar for an experienced programmer's skills combined with a younger programmer's attitude, and many actually do so.
>There used to be a time when you bought your word processing, spreadsheet, database, publishing, email, and presentation software separately, and could pick and choose the best in each category
Yeah, then _Lotus_ came along with 1-2-3 and started the whole integrated-office-suite thing. You can't pin the blame for this particular idea on MS; they - along with about a dozen others - were just following Lotus's lead.
Slashdot Mirror
And today's winner for most deserving of the title "Anonymous Coward" is...well, we don't know. ;-) But here's what s/he spewed:
/. for years, and that's still the most idiotic thing I've ever read here. I haven't said anything racist about whites; I merely observed that programming is a mostly white profession. In actual fact, as a white male I'm pretty quick to take offense at reverse racism/sexism, and have been ever since the time when I was denied a job for which I'd been recommended on the basis of my race and gender (University of Michigan, 1984). You're just the perfect example of everything that's wrong with the spoiled little turds who call themselves geeks nowadays.
>Geeks are paid for their knowledge, not physical labor abilities. Physical labor is for people who don't have any real skills
I wasn't talking just about manual labor. Even what we call "manual labor" can often involve more than meet the eye. It takes more training and practice to become a qualified pipefitter or carpenter than it does to sit in an office and create new JavaScript toys, and believe me you'll notice the difference if you hire someone who's still learning. A halfway decent tool and die person is harder to find than a good compiler writer. I'd rather write filesystems than be a cop or a firefighter or a social worker or K-12 teacher - all hard jobs with great social value, and the people who do them make peanuts compared to us.
Lots of people are paid for their knowledge and their hard work and for tolerating danger or physical discomfort, but programmers are just paid for knowledge - and all too many programmers don't even have that.
>I don't appreciate your racist comments towards whites either
I've been hanging around
>It's not "some people", it's all people. Everybody is born with the "hero nature" (to use your phrase), most just don't/can't come to terms with that.
Inability to come to terms with it is, effectively if not essentially, the same as not having it. And it's a good thing, too, because the only alternative most people can imagine to being a sheep is being a wolf, and a surfeit of wolves can be rather...unhealthy.
I don't trust everyone to be a "true invididual" as you put it. Too many people's expression of individuality is to be a selfish jerk.
>I've read a lot of posts on slashdot and elsewhere from pompous Rand naysayers, who almost always seem compelled to throw in gratuitous ad hominems
Oh yes, like your characterization of anyone who doesn't worship Rand as "leeches" and "parasites" is really helpful.
>These posts usually amount to one or two anecdotal references to "people I knew in college."
There's a reason. It's an immature philosophy, favored by immature people, and for that reason it truly is more often encountered in college than in post-college "real life".
>I've read only a few that even attempted a real argument
If you define "real argument" as "something expressed in Rand's terms, using Rand's axioms" that's no surprise.
>If you think Bill Gates is anything like one of Rand's heroes then you've missed the point of all her work.
This is a favorite of Randites. This one guy I used to know always used to say "Read Virtue of Selfishness"...until I did. Then he'd say "Oh, VoS doesn't really describe it well, read Fountainhead"...until I did. Then it was "For the full treatment you have to read Shrugged"...until I did. I even passed his little quiz to show that I really had read and understood it, and I still disagreed with him. "If you disagree with it you didn't get the point" only works so many times.
>Gates is anything like any of Rand's characters, he's a Peter Keating or Gail Wynand
I didn't say he's an exact match, but he's more like than unlike. There are plenty of tycoons whose fortunes are entirely derived from mergers and takeovers and other high-finance games; they're the true second-handers. At least Gates and MS owe their success to something vaguely resembling a creative/inventive endeavour. Even MS's monopolistic practices are no worse than the blackmail of the "heroes" in Shrugged when they managed to achieve a monopoly regarding certain essential items. The only thing Bill apparently lacks is some quasi-mystical "hero nature" that is easy to pick up in a book but astonishingly useless as a guide for real-life social policy.
Rand's writing - including her alleged non-fiction - is full of this crypto-Nietzschean attitude, which some might perceive as almost racist. Some people are apparently born with the "hero nature" and should be allowed to do whatever they want without inconveniences like governments, while the rest are mere sheep (or leeches) who should be glad to live off the leavings and discards of the super-race. One is left wondering how we distinguish the true titans from the pretenders. Is there a test? A genetic assay, perhaps? If we can rely on this natural talent to reveal itself, why do we not already live in a Randian paradise? The Randites, of course, do not have an answer except for their certainty that they themselves are among the Chosen Few.
>the people that run it and work in it have worked HARD to get what they have
Most of the people in the computer industry have no freaking idea what hard work is. Programmers are an overwhelmingly white, male bunch raised in comfy suburbs, from whence they went to college on someone else's dime, spent four years drinking and screwing, then straight into an industry that dumps options and benefits on even the most half-assed of them as though they were gods. Most programmers have never had to perform any kind of manual labor at all, ever, and if they ever felt like they were poor it's only because they were playing little independence games with parents who would be ready to bail them out if things ever got truly rough.
I'm a software engineer, and I currently do very well thankyouverymuch. There are people who've had it a lot rougher than me, but I can at least claim to've spent time outside the "reality distortion bubble" in which programming is done and I never forget what it was like. I am constantly amazed and dismayed at how many programmers act like the salaries and working conditions in this industry are normal. Here's a clue, folks. The median household - not personal - income is considerably lower than the median starting salary for a software engineer coming out of college, who is probably single and generally has zero years of real-world experience. Most people don't get stock options. Most people don't even get flex time. They get their own cube if they're lucky, and dream of some day having their own office. Anyone with the tiniest shred of intellectual honesty would admit that we in this industry are unbelievably fortunate and privileged by any sane standard.
Work hard, my ass. I've worked far harder than most people around me to get where I am, and it's still nowhere near as hard as regular folks have to work to get even half as much. Get real.
I used to know a lot of people in college who were fanatical about Ayn Rand. Then they grew up. I've yet to meet a Randite who thought they were anything short of exceptional. Every last one cherished the fantasy that they were a Roark or a Galt, that their lack of stunning success in life was because they were surrounded by "leeches", and that under the right circumstances their utter superiority would become manifest and incontrovertible. It's a seductive daydream, particularly to nerds who have raised escapism to an art form, but it's no more than that.
Real live humans are much more diverse and complex than Rand's caricatures, and the difference really does matter. The simplistic half-solutions offered by Rand share a fatal flaw with earlier simplistic solutions inspired (ironically) by Marx, which is that they work only for cartoon characters. Bill Gates is the closest real-life approximation to a Rand "hero", and I don't think we need more of him.
>Having a distributed OS would take a great load off of distributed application developers.
...and dump it on the OS developers, who already have plenty to worry about thankyouverymuch.
By slashdot standards, withdrawing such a poorly thought out piece of crap may seem graceful, but in many other environments people are routinely expected to be graceful enough to refrain from publishing such tripe in the first place.
>You can't practically write OO code in languages that do not directly support it.
Totally wrong. I and thousands of others have been doing this for years, and it seems quite "practical" to us. Languages that directly support OO are only marginally more convenient than non-OO languages such as C; the OO languages' advantages have more to do with standardization of notation than with actually enabling an OO code structure.
>There is a new breed of C programmers, though. They don't assume Unicisms, PDPisms or TheirPlatformisms,
Instead, they have their very own set of blind spots and biases and bad habits. Non-viable mutants are a "new breed" too, but that doesn't mean they're an improvement.
>Some compilers, no matter the architecture, will write executable code on the stack: "trampolines".
I don't think this is "no matter the architecture". The need for trampolines is chip-architecture dependent, and any compiler writer who uses trampolines where they're not absolutely forced to should be shot.
>Just put your buffer in it's own segment, and give it a certain length, and then if it goes over, a segment fault is generated, and it can allocate more buffers. That's how windoze works.
Simply incorrect. Windoze also uses pages. Doing what you suggest would increase memory demand and page faults while decreasing TLB hits, with disastrous effects on performance.
Executin code off the stack is extremely helpful
Can you give some examples? Specifically, can you give some examples of where building the new executable code on the heap rather than the stack isn't just as helpful?
>(5) So, I **MUST** release the code showing what I did so others who do know the kernel well can fix it.
Here's the crux of the matter: release it to whom? Release it to people who know the kernel well, who have the ability and inclination to fix the problem? Or release it to people who don't know squat about the kernel, who are more likely to contribute to the appearance of a canned exploit on rootshell than to a fix?
>Carmack gives a good explanation on why wee need more than jsut 32 bit color.
That's a good pointer. Thank you.
What he's talking about is basically roundoff error that occurs when multiple operations are applied to a pixel. He may have a point. OTOH, there's a little voice in my head that says the accumulation of roundoff errors is not really inevitable but is really an artifact of exactly how and in which order those operations are done in a "traditional" rendering scheme. Obviously it's going to be even worse with something like 3dfx's fractional-pixel FSAA scheme. Maintaining higher-precision color information, at least in some parts in the rendering process, may be the easiest solution, but I think we also need to consider whether this accumulation of roundoff errors is a sign that traditional rendering methods are headed down the wrong path entirely.
>a pitiful 32 bits per pixel
Never mind that the human eye can't resolve color even that well (about 16bpp, glad you asked). Sure, there are some fun things you can do by treating non-color attributes - e.g. transparency - as though they were colors, increasing the on-paper bpp, but when it comes to the output this little numbers game is of no benefit to consumers.
>besides the enormous amount of CPU and bus bandwidth, there really isn't anything here that can't be found on the average 1999-2000 consumer PC hardware.
Yeah, besides that. Besides the most important determinants of overall system performance, which involve the most difficult design challenges, it's just like a PC. That's like saying that besides the armor plating and the big gun on the front an Abrams tank is just like the family car...in other words it's a totally meaningless statement.
That's not really what "everything is a file" (EiaF) means. EiaF is really a pretty low-level thing, meaning that all sorts of objects - files, devices, fifos - in a common namespace and are accessed via a common set of syscalls - open, close, read, write, ioctl. This was actually an advance over earlier operating systems which often required that you use different syscalls to get different kinds of descriptors for each kind of entity, and which had multiple namespaces as well. Ew. You can see the power of EiaF not so clearly in UNIX itself, which contains many deviations from the principle, as in Plan 9, which was the "next act" for the UNIX principals.
There are a couple of other principles that you seem to be confusing with EiaF, and I think it's worth discussing them too. One is the idea that files should be unstructured. Again, this is a low-level idea, this time referring only to the "physical" layout of files and to the filesystem interfaces. As a filesystem designer and implementor, I can say this principle is very important. Filesystems have quite enough to do without having to worry about different record types and keyed access and so on - as many pre-UNIX OSes (most notably VMS) did. Man, was that a pain. What gets built in user-space, on top of that very simple kernel-space foundation, is up to you. More complex structures have been built on top of flat files since the very first days of UNIX (e.g. dbm files).
Another related principle is that data should be stored as text whenever possible. This is an idea that's gaining new life with the widespread adoption of XML to represent structured data, and again it's a good one. Doing things this way makes it much easier to write filters and editors and search tools and viewers and such (or to perform many of these tasks manually) than if the data is all binary. It makes reverse engineering of file formats easier, which is a mixed blessing, but it also makes manual recovery and repair easier. Converting to/from text also tends to avoid some of the problems - endianness, word size - that occur with binary data. Obviously there are many cases - e.g. multimedia files - where conversion to/from text is so grossly inefficient that it's not really feasible, but in very many other cases it's just a pain in the ass for the next guy when some lazy programmer decided to dump raw internal data structures in binary form instead of doing it as text.
In conclusion, I'd say that by all means people should try to retain the structure of data. Even better would be if the means for manipulating data could be provided and linked to the data itself in some standard way, like OLE/COM does in the MS world. At the very least, even without a common framework, it would be nice if more programmers would provide libraries with which to manipulate their data files. But please, let's do all this on top of text wherever possible, and let's do that in turn on top of a flat-file kernel abstraction within a single namespace. These are some of the more important principles that led to UNIX being such a success.
This is both totally correct and totally, utterly wrong, because you forgot the most important part of making this work, which is caching. X-terminals and diskless workstations were tried for a while, and they sucked. They sucked because they were slow, and they were slow because getting their data off the server. That hasn't changed, either. Available bandwidth has increased, but so has appetite for bandwidth. The solution now, as it has always been, is to cache at the clients for performance, which means that the clients should and will have data - just not authoritative copies of data.
The problem is that, to make this work, you need to use a protocol that maintains all the semantics of local file access, most inportantly cache coherency but also things like locking. This is hard to do efficiently, especially when you have to consider things like recovery and failover, and so you don't often see it done well (or at all). NFS just punted on cache coherency, which is why everyone but a few people who've made careers out of implementing NFS agree that NFS blows chunks. AFS/DFS/Coda were at least designed to do this stuff right, but IMO - I'm a distributed and shared-storage FS designer/implementer - don't do it as well as they should and have suffered acceptance problems because of second-order technical (and some non-technical) issues. Sprite at Berkeley and Plan9 at AT&T have shown that this kind of thing can be done, but it has yet to be done in the context of a commodity OS. Some might argue that it can't be done in such a context, but I disagree. It is in fact one of my goals to create just such a filesystem...if I can ever convince an employer to let me, or find the means to do it on my own.
I'll start writing in a functional language just as soon as it's supported inside any OS kernel that has a large enough user base to be worth developing for. Until then, FP languages are useless to me, though I might of course use concepts and constructs that people associate with FP (even though for the most part those things have been known and accepted as good practice in non-FP contexts for decades).
>everyone was really quite shocked at the figures coming out, and went to some trouble -- including talking to Red Hat -- to attempt to eliminate configuration issues
Interesting. Everyone was on Mindcraft's case for _not_ involving Linux vendors in tuning efforts. Now they go out of their way to do so, and everyone's saying it looks suspicious. While everyone's talking about rigged benchmarks, how about analysis that ends up with one side accused of cheating no matter what they do?
>Of course, manufacturers with no morals (ATI, Megabyte, Intel) can optimize for these types of benchmarks, and thus seem faster than they are
No matter what benchmarks exist, _most_ vendors will to some degree optimize to those benchmarks. This is as true of Quake3 or your COM+ example or SPEC or AIM as it is of WinBench3D. Interestingly, the easier it is for the vendors to look at and understand how a benchmark works, the more specific their optimizations will be, and the least subvertible benchmark would be one where the vendors have _no idea_ what it'll do until it's run. I know that open-sourcers aren't going to like that idea, but there it is.
For years, the computer geeks have totally ignored the issues of how technology gets used, whether society is prepared for it, etc. Suddenly, another technology - one controlled by a different elite this time - pushes its way into the mass consciousness and suddenly...omigod! Technology can be dangerous! Put the genie back in the bottle! We're all going to lose our humanity to technology!
It's not just Katz, either. How many people here actually stopped to think about the ways that computers and the Internet have changed how we communicate, where we get our entertainment, who invests in what, and other fundamental things about our lives, economy and culture? How many people here actually asked whether society was ready for these changes? We're the ones who've been helping tear down the walls that slow technology adoption. The "Frankenstein scenario" is as much our doing as anyone else's.
>do you think that perhaps we should prevent these mergers that lead to monopolistic bullies before the DoJ has to deal with it
Nice thought. Been done.
Mergers and acquisitions are already reviewed with an eye toward the danger of the new entity controlling a large enough share of one or more interlocked markets that it can unfairly block out competition. In many cases approval is in fact withheld, or the merged entity is required to divest itself of certain elements, as is currently the case with AT&T buying MediaOne. This process seems to work rather well, its only major flaw being that it does not apply to a company - such as Microsoft - that achieves its size/influence through plain old growth rather than mergers and acquisitions.
One objection to the current situation is that requiring approval for a merger or acquisition is a form of prior restraint, disallowing actions not because they are illegal but because they create conditions in which something illegal _might_ happen. Being big is not illegal. Even being a monopoly is not illegal. _Using_ your size or monopoly position to stifle competition is what's illegal, which is why Microsoft keeps trying to claim that they achieved their position via innovation. That's not just PR; it's a very specific legal argument. Unfortunately, as we can see from the Microsoft case, addressing antitrust behavior after the fact is extremely time-consuming and potentially costly to everyone, so this may (arguably) be a case where nipping things in the bud is justified even though it violates a cherished "no prior restraint" principle.
?Perl smoothly supports building real system in any and all combinations of those programming styles
Are these things _possible_ in perl? Yes. Does perl _support_ them in any meaningful way? No. Not any more than assembler does.
Never be satisfied. Never rest on your laurels. Never assume that you know something better than someone else, or that what you know is more important than what they know. Never pass up an opportunity to learn a new language/API/OS/technique because it's "just a fad".
If you can maintain and cultivate this curiosity, or restlessness, or flexibility, or perfectionism, or humility, or whatever you want to call the intersection of all these things, you will continue to see your career progress. The reason so many people look askance at older programmers is because so many older programmers have become ossified and arrogant and complacent. Any employer in their right mind would gladly pay top dollar for an experienced programmer's skills combined with a younger programmer's attitude, and many actually do so.
>There used to be a time when you bought your word processing, spreadsheet, database, publishing, email, and presentation software separately, and could pick and choose the best in each category
Yeah, then _Lotus_ came along with 1-2-3 and started the whole integrated-office-suite thing. You can't pin the blame for this particular idea on MS; they - along with about a dozen others - were just following Lotus's lead.