It's interesting how the previous poster managed to give more information, be polite, and funny all at the same time - and he even used correct punctuation! - yet you felt the need to be repetitive, impolite, and boring.
I refer you to gid-foo's post just above yours; or cyoon's just below; both of which are more insightful and at least correct.
There a 3 forms of incorrectness which you are failing to discern: failure to match the spec (bugs), failure to match the business requirements (bad spec), and poor performance (which this thread is about). These are 3 totally different things and that you could even possibly confuse them is indicative of, well, I don't want to get personal. But in no way should you think that doing one of those 3 correct is an excuse for failure on the others (eg, "the program doesn't do what you need, but there aren't any bugs!"). It's also worth noting that bad performance, in many cases, can kill a project as well as the other two failure modes - not everything has as many spare cycles as AS/400 report generation or web serving on E10k's...
You're right on both counts. But I wasn't confusing arch with optimization; my argument was that no amount of opimization will save a poor architecture - you can't just drop in a faster search algorithm and expect your problems to go away. I brought up DB design because that problem is so visible there. If the schema has deep semantic conflicts, it cannot be saved.
Thanks for the tip on 'quiz them first to make them feel bad' - I feel more like a BOFH already.
I cannot agree more with Mr. Walker (above post) with this one - you are very wrong. Writing apps in your fashion is the 'college sophmore approach' . Thinking about speed, writing proofs or mapping out how plans turn to code, is critical at the outset. If we were to write a DB engine using your methods, we would develop a locking system ("get the functionality right"), and then spend the rest of our lives try to make it scale. Result - MSSQL. If we think about speed in design, then we *start* with versioned tables (MVCC), and then have a massively scaleable system from the first code release. Result - Oracle (and Postgres7!).
I don't write byte-level machine/C++/Java code anymore (you poor bastards!!) - I layout DB schema. And in my world, you are extra wrong, b/c if you lay out a naive schema, and then dump 10 million rows in it, you are fucked. No amount of optimization and denormalization will save you, because you didn't think of scaleability first.
Since my post *was* a personal attack, I don't see why I should have credibility other than that...
Your opinion sickens, but it does not cut. You are, perhaps, the only person free of all such cares; in the meantime, we both are far too anonymous to have such impact.
My "favor" was for neither of them; I told you that already and I wish you could understand that; even if I voted for Bush I would disagree with your statements. Why can't you understand that?
What disgusted me was, as I said, your conviction to judge someone by the rubber stamp of degrees and your assumption that it is "silly" to do otherwise (even while we work in an economy which is breaking that mold). Maybe you don't really think like that; I've never met you and might really like you if I did. But your writing suggested that; and that's what I have to go on.
Before we continue, allow me to say that I did not vote for either Gore or Bush. So put the partisan hat down and deal with me as a person, not a party member.
But if you consider the time these guys DID go to college, it does stand for a bit more than it does now and it's utterly silly to question the intellect of a Harvard/Yale graduate in comparison to someone who dropped out of college all together. If one had to put money on the IQ of one over the other, the smart money goes with the graduate, that's just common sense. For every Bill Gates success story in this world, there are 1,000,000 college drop outs in this country who can't balance their check book.
I'm sorry, but that's the most pathetic thing I've heard all week. You (and I both) dropped out of college; you have a good job (and can presumably balance your checkbook). No doubt you demand that people interact with you solely on your skills and personality, instead of the rubber stamp of a college diploma; why do you hold others to a different standard? Where do you pull numbers about human incompetence? Millions of college dropouts who can't balance their checkbooks? - What are you smoking?
Utterly silly? Harvard and the other Ivy Leagues have a very strong, very old network of alumni; many, many students' parents went to that or another Ivy League school. Is intelligence found predominantly in wealthy dynastic clans? (Is IQ a vaguely useful measure of that?) Is education found only in schools? It would be foolish to claim such, seeing as both of us are self-taught - yet you claim it's obvious that the establishment-taught person is smarter.
Why the vitrol towards people who leave college? A human spirit grows at different speeds in each person - claiming otherwise is stupid. I would prefer that people leave when they need to; return when they can; ie, people need to be in certain places at differing times - in one case, Gore was thinking about being a priest. How could I ever respect someone who didn't explore their dreams?
I already know your response - "Yes, well, common sense says....". Bullshit. You sound like every beaten, tired, pathetic establishment lackey who parrots existing social convention as permanent wisdom or physical law - "That's just the way it is".
You disgust me more than anyone on slashdot has in a long, long time; and I'm sorry that you do.
What the h*** is that IMG tag doing there? And all the other monstrosities like EMBED, WIDTH and HEIGHT attributes, ad nauseum.
IMNSHO, if you want multimedia, use a protocol designed to handle multimedia! I don't see the logic behind multimedia on a text protocol. (Or what used to be a text protocol.)
But you're wrong. I see every reason for a text protocol to specify where multimedia can stick itself.
The tags you've mentioned are aids to presenting text - they separate images from the text, give some specific boundaries on how to deal with images, and the browser can treat them relatively independently. With the HEIGHT and WIDTH tags, browsers can render text and bring images on later - improving the textual experience, because you don't have to wait for all the images to load. In other words, those tags make text the pre-eminent data form over HTTP.
Honestly you're just being silly. Those had nothing to do with big money - big money mostly slid into the abyss of applets, then myriad plug-ins, now patently ridiculous server tools (which I fight daily). In each, html threw a few tags specifying how to isolate the crap from the text - keeping text supreme.
Okay, I'm not heavy into hardware, I just wanted to point out the numerous problems with the P4 - it seems that the processor itself is not one of them!
Tolu, you always have something insightful to say about chip design, but you have to repeat yourself fairly often across articles - have you thought about bugging the/. crew for some permanent space to soapbox?
Just a thought....
The Pentium Pro was the last new core from Intel. And may I remind you - the first issue of the PPro - It beat the Alpha! For like a month, until DEC moved to a new process, Intel beat the king of the RISC chips. So I don't think there is the precedence you seem to see - when Intel brings out a new core, I expect bang - not "it'll scale".
And to reiterate - killing it more than direct comparison to the Athlon is that the associated parts are just out-and-out defunct. The RDRAM system is hideously expensive; when implemented (correctly) by Intel it didn't meet Rambus's projected specs; anyone who gets in bed with Rambus gets a nasty case of lawsuits.
Entirely new boards, no compatibility, either backwards or forwards.
Chip itself is massively more expensive, perhaps to produce as well.
No SMP - goodbye server market. Remember how long it took to get 4-way Xeons? SMP will not be kludged in easily.
VIA, Intel, Rambus, and others are in a really screwed up relationship ATM.
Intel has some large problems here, more than can be overcome by one chip, even the most important chip, scaling to infinity. But hey, I hope they do - what would AMD do without competition?
I'm sorry, XML is here to stay and for good reason. It will become manifest in everything from docs to configuration files. There's nothing to debate.
Given that I use XML extensively already, I can't fault you on that.
I can fault you for stupidity, though.
Nothing to debate? My god, don't you realize that we have to implement these plans? Of course we have voice, and choice, and the ability to debate? What's the matter with you?
Moving on...
Really? Do you also think compilers are the work of the devil? Do you hand assemble source code into binary 1's and 0's?
Oh, I've never seen this before - "you don't support every hurried implementation of my idea, thus you are an old curmugeon". Right.
And just like the guy who posted just before you, you miss my point - I do not like to depend on another daemon, with associated uptime, API, and version conflicts, to load programs; given that you're talking about all the programs I'd be rather concerned. Want XML conf files? Fine - write them, pull some SAX-compliant parser source into your program, compile. Want to add another layer of maintainance to system admins?.... I think I'll pass.
Reality check. What is likelier to be buggy: a one-off parsing routine or a well established and universally tested parser such as SAX? We know the answer to that one since the whole open source movement is predicated on it. The publicly available routine will be less buggy.
Which is why many,many,many open source projects borrow parsing code from older, more stable projects. Are we to assume that all the coders are idiots? Newsflash: SAX is an API, not a parser. Parsers than implement it are not universally tested - you can neither garauntee nor define such a term. Nor 'well established' - XML is rapidly evolving, and 'backwards compatibility will always be maintained' is a common lie. Newsflash: You ignored my point. Systems will be more stable with their parser code compiled in, so there's never a concern with interfacing with other process or the versions thereof. There's a reason system integrations is a 50 billion $USD business.....Whether that parser code is SAX-compliant, or reads rc files, or reads binaries, I don't care. Avoiding the interface to another daemon makes things possibly more stable - the progger can still fuck up his own stuff, but versioning and api incompatibility is the sisyphean rock of sysadmins.
Now that Linux is stable and of amazing quality it is time to start looking towards the future and make sure a good operating system becomes hands down the best.
No shit, sherlock. Now who defines 'best'? If you were listening to the kernel people, not the app space people like us, you would note that 'best' is subjective to context - most optimized for common case, whatever the common case might be for your market niche. E.g., Linux doesn't perform well on 64 processors not b/c Linus is lazy but b/c Linux is optimized for less than 16 processors and fewer than 1000s of threads.
I can't tell if you talk that way or if you're karma whoring.
But more to the point - this is not a kernel-level problem!!! Go talk to the GNU crew - you need to slide this stuff into every library concievable - and by doing so you'll have the best chance to have it adopted by the other unices (which is really necessary in the long term - the unices won't stay splintered, history has shown). But as a kernel extension, this discussion is over.
You've evidently never read the XML specification, or tried to use XML anywhere.
So you wade right into it with an ad hominum attack - how nice.
I'm only going to say this once - XML is *a* solution to the trivial problem of syntax; it does not, however, assault the intractable problems of semantics. Your fantasy of trees magically passed between programs with no knowledge of each other falls down when you realize that each program assigns different meanings to each file/tree/whatever.
Other points: Programs don't have to check their own config files: After 6 years of adminning systems, I feel more secure with each daemon checking their config files than passing it onto an independent parser daemon. Each program gets to test once with the parser code inside the program; if you move parsing out then you move that work onto the sysadmin (or home user) - the world is filled with minor API changes that screw you over. Feel like running regression tests on every piece of software you install? Programs avoid bugs in their parsers: Parsing text is a solved problem. When was the last bug where Apache couldn't parse its own files? Compare that to XML, which is an evolving standard - even if you never have a bug in the XML parsers, who's to say that total backwards compatibility will be maintained? When the daemon changes its config file format: Riiiggghht.. I've seen this happen only a handful of times over the hundreds of software packages I've fucked with. Copying config between applications? Best idea in your post, but most of us will still handcheck it, because of Semantic Complexity. Does postfix's 'address' field mean IPv4, and sendmail's 'address' field allow IP or DNS hostname? When you move to IPv6, does postfix break silently? These are issues that sysadmins everywhere deal with on a daily basis - none of it will go away with a common syntax.
I really don't understand the Linux community's perceived resistance to XML. I think it's because Microsoft was an active participant in the development process, and because many of the early implementations of the XML tools were written in Java.
I think it's because XML is not relevant for most of our problems. I use XML for foreign database data exchange. (I also use Java, so I don't understand your reasoning.) Thus far, I don't have any better uses for it, and I'm not hurrying to find any.
I do like your idea about changing streams to structured streams, though. Most apps these days are moving to shared memory in the absence of any such solution.
Oh, I'm sorry, I thought administering >3000 user heterogeneous networks gave me some kind of experience - guess I was wrong.
I do not think you are incompetent. Let me explain again - if you have bad hardware or a bad driver, and a piece of code hits the trouble spot - bam, the whole system goes down. Not the application, eg, mail servers, but the whole OS.
With your sendmail-on-linux retort - if you are running Linux, and your eth driver misbehaves, then a) kernel panic, or b) kernel decides the hardware is faulty and shuts it down. Probably a; but Linux will take a suprising number of hardware failures before giving up. Sendmail does not crash; the machine does.
If the application crashes, and the OS stays up, the application is probably at fault.
Something I do take issue with - Apologism for poorly-tested applications, with typical excuses like 'oh, bad driver' - sounds like 'Reboot, Re-install, Upgrade' - avoiding both sysadmin and code questions. The original poster said that MS's own people came out - why didn't they say something about his 'unsupported hardware'? They have the largest testing staff of any software company - can't they compile a supported platform list? Or maybe they ok'd his hardware - he did say they found nothing wrong with his setup....
Credibility. Saying things that aren't true (ie., 'exchange is crap', which it isn't)
Oh, I'm sorry. It is. It's also an opinion, formed from my experiences working with it. Want to define a difference between 'fact' of quality and 'opinion' of quality? - there's a Philosophy department out there with your name on it. In the meantime, truth is not yours.
Zealotry - zoom your mind back 6 years. Remember why we were pushing Linux then? Remember how cool it was, even then? Remember the perverse stability; particularly to those raised on MS products? Remember how much more we could do than before?
There are reasons I and others have system preferences. Preferences only reinforced by working with competing tools over the years...the MS2000 stuff is pretty stable, but it's marginally less than the unices (save SCO), far more expensive, and still insanely difficult to administer.
I'm not a zealot - I'm still working with many different systems, and recognize the value of each. I just have opinions. Perhaps you shouldn't assume inexperience because of that.
Should a mail server be dependent on drivers? A mail server listens to sockets and passes text files around; Exchange also holds open its database. None of these tasks should expose hardware-level issues; at least not on a well-written system. The OS is _supposed_ to shield applications from that. Sorry, but if a mail server is crashing constantly, then either a) it is poorly written, with myriad internal boundaries (common in the C/C++ world) that fail when you try to scale, b) the OS is shit (exposing inappropriate parts of the system to applications), or c) the system is administered by massive incompetents (and even then crashing something, not overloading, but crashing an app is usually beyond user incompetence).
I don't think the parent poster was incompetent.
There are many existing issues with NT, but they are sort of working out (MS2000 is actually kind of stable).
Leaving {a)} - Exchange is crap. Quell supri'.
Stirling needs to talk to his dealer about the purity of his rock.
Watch it, boy. I only cut my rock with the finest of hallunciatory substances.
But seriously, good rebuttal. I thought, a few years ago, that the point of the internet was that we weren't going to have to listen to the pontification of misinformed losers terrified of tech encroaching on their business models.
I remember reading on the topic of excessive joins in a Sybase Admin book once (excelent book on "practical" database, since it shows you exactly how one company solved all the DB problems)
And what book was this? (I really want to read it).
On another subject, did you drop all the users from blacknova.net? My user (tolket) is gone....
its kind of a smart way to do things cuz they could have a small lab for their physicists (sic?) and a small office for theyr[sic] ceo's. they have almost no overhead.
Sadly untrue. Rambus has a huge honkin' building a couple blocks east of El Camino. 15-20 stories or so. Lots of room for the physicists, no? They're shoving another one up next to it - then again, maybe they're waiting to see if their business model is sustainable, since those cranes have been quiet for a while now...
In truth, it looks like the archetypical fucked company with a few good researchers in the basement; and pathetic tech execution upstairs. They are not running with minimal overhead. They look like a suit company who don't themselves know what they need to make the company fly on merit alone, and are now suing everyone in a desperate bid to stay afloat.
Considering that Sega is a subsidiary of Matsushita; their developers are primarily Japanese; and their games and tech are released first in Japan, I fail to understand your claim that Sega is a non-Japanese company, or started elsewhere.
The methods are a new DB API function db_dfs (depth-first search); and an older tcl-layer fxn which I am unfamiliar with, but I know of its existence. Ask at the above.
Slashdot Mirror
I'll never understand you ACs.
There a 3 forms of incorrectness which you are failing to discern: failure to match the spec (bugs), failure to match the business requirements (bad spec), and poor performance (which this thread is about). These are 3 totally different things and that you could even possibly confuse them is indicative of, well, I don't want to get personal. But in no way should you think that doing one of those 3 correct is an excuse for failure on the others (eg, "the program doesn't do what you need, but there aren't any bugs!"). It's also worth noting that bad performance, in many cases, can kill a project as well as the other two failure modes - not everything has as many spare cycles as AS/400 report generation or web serving on E10k's...
I think you need more experience.
Have a nice weekend!
Unless you're suggesting that speech with the netherworld is a more common resource in Europe?!? - Man, I gotta go!
Also, Squaresoft is the American subsidiary of Square - there is a distinction you should learn.
Thanks for the tip on 'quiz them first to make them feel bad' - I feel more like a BOFH already.
I don't write byte-level machine/C++/Java code anymore (you poor bastards!!) - I layout DB schema. And in my world, you are extra wrong, b/c if you lay out a naive schema, and then dump 10 million rows in it, you are fucked. No amount of optimization and denormalization will save you, because you didn't think of scaleability first.
Your opinion sickens, but it does not cut. You are, perhaps, the only person free of all such cares; in the meantime, we both are far too anonymous to have such impact.
My "favor" was for neither of them; I told you that already and I wish you could understand that; even if I voted for Bush I would disagree with your statements. Why can't you understand that?
What disgusted me was, as I said, your conviction to judge someone by the rubber stamp of degrees and your assumption that it is "silly" to do otherwise (even while we work in an economy which is breaking that mold). Maybe you don't really think like that; I've never met you and might really like you if I did. But your writing suggested that; and that's what I have to go on.
Utterly silly? Harvard and the other Ivy Leagues have a very strong, very old network of alumni; many, many students' parents went to that or another Ivy League school. Is intelligence found predominantly in wealthy dynastic clans? (Is IQ a vaguely useful measure of that?) Is education found only in schools? It would be foolish to claim such, seeing as both of us are self-taught - yet you claim it's obvious that the establishment-taught person is smarter.
Why the vitrol towards people who leave college? A human spirit grows at different speeds in each person - claiming otherwise is stupid. I would prefer that people leave when they need to; return when they can; ie, people need to be in certain places at differing times - in one case, Gore was thinking about being a priest. How could I ever respect someone who didn't explore their dreams?
I already know your response - "Yes, well, common sense says....". Bullshit. You sound like every beaten, tired, pathetic establishment lackey who parrots existing social convention as permanent wisdom or physical law - "That's just the way it is".
You disgust me more than anyone on slashdot has in a long, long time; and I'm sorry that you do.
The tags you've mentioned are aids to presenting text - they separate images from the text, give some specific boundaries on how to deal with images, and the browser can treat them relatively independently. With the HEIGHT and WIDTH tags, browsers can render text and bring images on later - improving the textual experience, because you don't have to wait for all the images to load. In other words, those tags make text the pre-eminent data form over HTTP.
Honestly you're just being silly. Those had nothing to do with big money - big money mostly slid into the abyss of applets, then myriad plug-ins, now patently ridiculous server tools (which I fight daily). In each, html threw a few tags specifying how to isolate the crap from the text - keeping text supreme.
Okay, I'm not heavy into hardware, I just wanted to point out the numerous problems with the P4 - it seems that the processor itself is not one of them!
Tolu, you always have something insightful to say about chip design, but you have to repeat yourself fairly often across articles - have you thought about bugging the /. crew for some permanent space to soapbox?
Just a thought....
Let me check my notes....
And to reiterate - killing it more than direct comparison to the Athlon is that the associated parts are just out-and-out defunct.
The RDRAM system is hideously expensive; when implemented (correctly) by Intel it didn't meet Rambus's projected specs; anyone who gets in bed with Rambus gets a nasty case of lawsuits.
Entirely new boards, no compatibility, either backwards or forwards.
Chip itself is massively more expensive, perhaps to produce as well.
No SMP - goodbye server market. Remember how long it took to get 4-way Xeons? SMP will not be kludged in easily.
VIA, Intel, Rambus, and others are in a really screwed up relationship ATM.
Intel has some large problems here, more than can be overcome by one chip, even the most important chip, scaling to infinity. But hey, I hope they do - what would AMD do without competition?
I can fault you for stupidity, though.
Nothing to debate? My god, don't you realize that we have to implement these plans? Of course we have voice, and choice, and the ability to debate? What's the matter with you?
Moving on...
Oh, I've never seen this before - "you don't support every hurried implementation of my idea, thus you are an old curmugeon". Right.And just like the guy who posted just before you, you miss my point - I do not like to depend on another daemon, with associated uptime, API, and version conflicts, to load programs; given that you're talking about all the programs I'd be rather concerned. Want XML conf files? Fine - write them, pull some SAX-compliant parser source into your program, compile. Want to add another layer of maintainance to system admins?
Newsflash: SAX is an API, not a parser. Parsers than implement it are not universally tested - you can neither garauntee nor define such a term. Nor 'well established' - XML is rapidly evolving, and 'backwards compatibility will always be maintained' is a common lie.
Newsflash: You ignored my point. Systems will be more stable with their parser code compiled in, so there's never a concern with interfacing with other process or the versions thereof. There's a reason system integrations is a 50 billion $USD business.....Whether that parser code is SAX-compliant, or reads rc files, or reads binaries, I don't care. Avoiding the interface to another daemon makes things possibly more stable - the progger can still fuck up his own stuff, but versioning and api incompatibility is the sisyphean rock of sysadmins. No shit, sherlock. Now who defines 'best'? If you were listening to the kernel people, not the app space people like us, you would note that 'best' is subjective to context - most optimized for common case, whatever the common case might be for your market niche. E.g., Linux doesn't perform well on 64 processors not b/c Linus is lazy but b/c Linux is optimized for less than 16 processors and fewer than 1000s of threads.
I can't tell if you talk that way or if you're karma whoring.
But more to the point - this is not a kernel-level problem!!! Go talk to the GNU crew - you need to slide this stuff into every library concievable - and by doing so you'll have the best chance to have it adopted by the other unices (which is really necessary in the long term - the unices won't stay splintered, history has shown). But as a kernel extension, this discussion is over.
I'm only going to say this once - XML is *a* solution to the trivial problem of syntax; it does not, however, assault the intractable problems of semantics. Your fantasy of trees magically passed between programs with no knowledge of each other falls down when you realize that each program assigns different meanings to each file/tree/whatever.
Other points:
I think it's because XML is not relevant for most of our problems. I use XML for foreign database data exchange. (I also use Java, so I don't understand your reasoning.) Thus far, I don't have any better uses for it, and I'm not hurrying to find any.Programs don't have to check their own config files: After 6 years of adminning systems, I feel more secure with each daemon checking their config files than passing it onto an independent parser daemon. Each program gets to test once with the parser code inside the program; if you move parsing out then you move that work onto the sysadmin (or home user) - the world is filled with minor API changes that screw you over. Feel like running regression tests on every piece of software you install?
Programs avoid bugs in their parsers: Parsing text is a solved problem. When was the last bug where Apache couldn't parse its own files? Compare that to XML, which is an evolving standard - even if you never have a bug in the XML parsers, who's to say that total backwards compatibility will be maintained?
When the daemon changes its config file format: Riiiggghht.. I've seen this happen only a handful of times over the hundreds of software packages I've fucked with. Copying config between applications? Best idea in your post, but most of us will still handcheck it, because of Semantic Complexity. Does postfix's 'address' field mean IPv4, and sendmail's 'address' field allow IP or DNS hostname? When you move to IPv6, does postfix break silently? These are issues that sysadmins everywhere deal with on a daily basis - none of it will go away with a common syntax.
I do like your idea about changing streams to structured streams, though. Most apps these days are moving to shared memory in the absence of any such solution.
I do not think you are incompetent. Let me explain again - if you have bad hardware or a bad driver, and a piece of code hits the trouble spot - bam, the whole system goes down. Not the application, eg, mail servers, but the whole OS.
With your sendmail-on-linux retort - if you are running Linux, and your eth driver misbehaves, then a) kernel panic, or b) kernel decides the hardware is faulty and shuts it down. Probably a; but Linux will take a suprising number of hardware failures before giving up. Sendmail does not crash; the machine does.
If the application crashes, and the OS stays up, the application is probably at fault.
Something I do take issue with - Apologism for poorly-tested applications, with typical excuses like 'oh, bad driver' - sounds like 'Reboot, Re-install, Upgrade' - avoiding both sysadmin and code questions. The original poster said that MS's own people came out - why didn't they say something about his 'unsupported hardware'? They have the largest testing staff of any software company - can't they compile a supported platform list? Or maybe they ok'd his hardware - he did say they found nothing wrong with his setup....
Credibility. Saying things that aren't true (ie., 'exchange is crap', which it isn't)
Oh, I'm sorry. It is. It's also an opinion, formed from my experiences working with it. Want to define a difference between 'fact' of quality and 'opinion' of quality? - there's a Philosophy department out there with your name on it. In the meantime, truth is not yours.
Zealotry - zoom your mind back 6 years. Remember why we were pushing Linux then? Remember how cool it was, even then? Remember the perverse stability; particularly to those raised on MS products? Remember how much more we could do than before?
There are reasons I and others have system preferences. Preferences only reinforced by working with competing tools over the years...the MS2000 stuff is pretty stable, but it's marginally less than the unices (save SCO), far more expensive, and still insanely difficult to administer.
I'm not a zealot - I'm still working with many different systems, and recognize the value of each. I just have opinions. Perhaps you shouldn't assume inexperience because of that.
I don't think the parent poster was incompetent.
There are many existing issues with NT, but they are sort of working out (MS2000 is actually kind of stable).
Leaving {a)} - Exchange is crap. Quell supri'.
Watch it, boy. I only cut my rock with the finest of hallunciatory substances.
But seriously, good rebuttal. I thought, a few years ago, that the point of the internet was that we weren't going to have to listen to the pontification of misinformed losers terrified of tech encroaching on their business models.
On another subject, did you drop all the users from blacknova.net? My user (tolket) is gone....
In truth, it looks like the archetypical fucked company with a few good researchers in the basement; and pathetic tech execution upstairs. They are not running with minimal overhead. They look like a suit company who don't themselves know what they need to make the company fly on merit alone, and are now suing everyone in a desperate bid to stay afloat.
Considering that Sega is a subsidiary of Matsushita; their developers are primarily Japanese; and their games and tech are released first in Japan, I fail to understand your claim that Sega is a non-Japanese company, or started elsewhere.
What type of business are you in?
What region are you in?
What's the average age of your employees?
I think all 3 of those give widely varying results to scheduling - and none of them are ignorable.
The methods are a new DB API function db_dfs (depth-first search); and an older tcl-layer fxn which I am unfamiliar with, but I know of its existence. Ask at the above.