I think it's getting to be evident that the traditional UNIX RISC workstation vendors are having a hard time keeping their CPUs not only on the price/performance curve, but on the performance curve itself.
The MIPS chip is battling uphill, just like the UltraSPARC III against competitive offerings like the 2.2 GHz Northwood P4 and the AMD Athlon XP 2000.
I respect SGI for it's history of graphics expertise and devotion to producing quality hardware, but like many others I have to ask the hard question:
Is what I'm getting in this desktop workstation worth the difference in price with, say, an HP x4000 running Linux with a Wildcat 5110?
For some people, it probably is worth the extra money. But I think that target market is constantly shrinking.
SGI has hemorrhaged some good people, money, and their 3D patent portfolio (to MS recently). They can ill afford to come up with any product less than a perfect bullseye at this stage of the game. I fear this is not it.
Yes, it could be good, since Hans Reiser makes the point of just how much the overall utility of information is in making that information more widely accessible to the fringes of access.
That's a key insight, one that deserves to be addressed.
The immediate practical issue with this is that
many owners of information don't want their information accessible by a wide audience!
which, admittedly, represents more of a psychological and personality problem than it does a problem in information technlogy. All the great file system ideas in the world won't work if people are fundamentally against the premise of more information sharing being a Good Thing.
Indeed, one could argue that more research is probably being funded into ways of restricting information access than devising filesystems to make widespread information access more efficient. Why? Well, because restricting the free flow of information is a policy that is more closely aligned with the current revenue models of important content copyright holders.
You watch. Longhorn will have some improved technology in the filesystem to make information queries more efficient, but everyone on the corporate LAN will clamp down access controls that render it effectively of no value.
So why would anyone expect the state AGs to do much about something they know very little about (no disrepect, but the majority of lawyers do not have the specialized knowledge of technology as they do with law)?
Note that they haven't too much about something comparably restrictive of commercial activity that affects their citizens and about which they know much more - to wit, VISA.
Have you given much thought to how much merchants get charged for the privilage of accepting VISA cards? Of how much your ability to conduct transactions in the real world is affected by the need for you to have a VISA card?
As with the price of Windows and Office, the price of VISA service is kept just barely under the pain threshhold, where the host is not willing to make the effort to squash the parasite.
If nothing's been done about VISA, I hardly expect a snappy acknowledgement from the state AGs recognizing the similar capacity of MS Passport to obtain a stranglehold on electronic trade.
But, what, pray tell does the general public know about the best places to explore?
Politically, I know this is a good way to engage the public in this exciting area of science, and I know that many people want a say in how their tax dollars are spent.
For the record, this particular citizen would prefer that the decisions be made on a purely technical basis, including input from the most respected and knowledgable astronomers in the world.
That, to me, would make me feel a lot more comfortable about where my dollars are going than if the decision were made on the basis of what 2000 third grade students thought was the "most cool" thing to do in space, which is almost as likely to be off the mark as what 550 Congressman thought was "the most cool" thing to do in space.
source management isn't the problem. Making sure useless crap doesn't make it into the tree is the problem. CVS doesn't have any sort of means to make sure that what goes in is quality code.
Well, source management is a problem that CVS or the new Subversion might help with.
But your point is a good one. Source code management of patches, diffs, etc. is only part of the problem.
For userland application codes, it's been possbile to set up cron jobs to do automated feature, coverage, and performance testing so that if anyone checks in crappy code, it is shortly revealed to the world.
I'm thinking that some big outfit like OSDL could corral a whole stable of motley hardware that could be used to automate kernel testing. Volunteers are great, but the testing gets done on an ad hoc basis. Thus you can guarantee that whatever hardware is owned by Alan Cox or some other kernel guru will probably work great, the bozo box I've got will not be similarly tuned up because I wouldn't feel safe tweaking the kernel source, despite some years of C programmiong experience.
The big problem I see in automated testing is that I'm not sure kernel's can be tested as easily as other applications can be. I can just see the BIOS hanging there with no means to talk over the network to tell the master tester just exactly how it has hung. Perhaps running User Mode Linux?
I have to say, I'd like to find a really good approach for dealing with mailers with built-in prejudicial statements in them.
You know the kind, where you get to see disparaging comments like
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
as if you are using a deficient MUA when you see such text.
I'd really like a 2-3 sentence autoreply text that could bounce some of those MS Word attachments with similar pronouncements about
Unfortunately, the.doc attachment you sent me is coded in a special MS proprietary format. Please resend it in an open standard format that is fully described by IETF, ISO, W3C or other international standards body. Also, please request your software vendor to submit their widely-used format for standards approval.
Most people simply have no idea what standards are, nor the ways or the degree to which they pay for the IT infrastructure that they currently use.
Their responses are usually quizzical and predictable, "Uhh, so what does it look like to you when Word launches?" Answer: Word doesn't launch. It requires money to launch. It requires that you buy the whole banana to get Word. (There used to be Ted Rall cartoon years ago that parodied the whole issue during the browser war years "Works best with MS House!"
People so much consider these things like.doc to be standards, that they ought to be made into bona fide standards that are publicly documented, including all the quirks of proper display, instead of just glossing over that they cannot be displayed without paying money to see them, even if its bundled into the cost of your new PC or the Microsoft Enterprise License Agreement for Office, which is probably priced more inelastically than gasoline.
...but why are peer reviewers accepting half-baked papers?
Peer review relies on the same fount of goodwill that fuels information sharing in the scientific community.
If you've reviewed papers thoroughly, you know that it takes an investment of time on your part to get up to speed in the specific subject that the authors are writing about.
I'm finding that it is becoming increasingly difficult to justify that kind of time investment on any regular basis.
I think peer reviewed papers are a great idea, but the current system has some structural defects, in that the peers are not directly renumerated for their efforts and expertise.
If high quality displays can be made inexpensively, of flexible material, and incorporate light sensors (presumably not overwhelmed with photons emanating from the display), would it not be possible to use them as wall paper on the inside and out and thereby achieve the illusion of transparency?
Taking a cue from all those advertisements that have been chopping the bottoms off the screen and overwriting part of the action with a semi-transparent channel logo I hereby predict:
When HDTV arrives with its wide aspect ratio, old style TV programs that do not expand to such a wide panorama will be buttressed with sideways letterbox format, which will rapidly be filled with advertisements.
Don't forget the fact that some years ago the Alpha was able to run some version of Windows NT. There would certainly have to be some cobweb dusting to get Win2K or WinXP to run on the new Alphas, but I bet it really wouldn't take too much effort.
Also, DEC had developed something called FX!32 in order to run the 32 bit IA32 apps on their new 64 bit chip, when emulation was necessary. (Sounds a lot like the strategy in Hammer, actually).
So, you see, Intel really is in a good position to dust off the EV7 as if it were their own chip and be able to make it succeed.
Not only that, IIRC, some of the bus technology for the K7 came out from the Alpha project. That would seem to mean that some of the motherboard makers could more easily interchange between AMD and Alpha than they could, say, between the Hammer and what is currently called IA64.
But I agree with you. The NIH syndrome is very powerful.
Long ago and far away (about 15 years ago) I recall that TeX was frequently built in a fashion that required running the binary on some "initialization" information. That process took some nontrivial amount of time back in those days (I'm sure now it would be an eyeblink), and the program could be made to \dump its state in some way.
Then, when you ran TeX in everyday circumstances, the digested initialization file was read in by the application as part of the usual startup process.
I'm probably botching the explanation of how this really worked, but I guess my point is that the "resume" function had to be coded into the specific application.
Hmmm...this resume dumping looks like a great way to...ah...unload some of those prickly co-workers or PHBs in my workplace!
I can think of several people right now that I'd rather not have here. I could polish up a resume for them and post it to every Usenet group I could find. Mebbe even a few of the alt.sex sites just for the entertainment value!
The filters have extremely little to do with the problem.
I beg to differ. From the perspective of someone who uses Word, Excel and Powerpoint day in and day out, one of the biggest stumbling blocks to a migration to Linux is being able to communicate effectively in these formats, which are a de facto standard. If there's a difference, however small, in how those formats are interpreted under StarOffice compared to how they are interpreted under MS Office, then that is one glitch too many for users that are transitioning.
I agree, MS has no reason to adopt a single, open file format. From a business perspective, they have everything to gain by keeping such standards under their control and making all access to such standards require a payment to Redmond. MS will continue to follow the same strategy of "upgrading into incompatiblity", as Office XP Word attachments arrive on the desks of Office 97 users, ever so gently goading them into an upgrade merely to be able to read and write attachments that their friends are sending from WinXP machines (which are pretty much all you can find at the stores) Funny how that works.
As far as I can tell, the biggest costs of switching are in user retraining. The software cost savings of desktop Linux are a given; the added benefit of not being put on a forced upgrade treadmill is an additional savings; finally, the need of keeping track of MS licenses is eliminated. Those are all significant real benefits that anyone in IT decision-making should weight, but it is not the entire equation as far as costs are concerned.
It's all the secretaries that learn the quirks of Word for a period of years that represent an investment in user training that can only be partially recouped by switching to StarOffice, and that only to the degree that the user interface and behavior of SO mimics MS Word.
I'll agree that Win2K is reasonable as far as MS operating systems are concerned. It's quite usable. But there's the rub!
Why on earth should anyone need to upgrade to XP?
Win2K is fine if you need a operating system with a stable win32 API for office productivity applications.
But if your Win2K Enterprise Licensing costs will be forced through the roof unless you buy XP real soon (reminds me of some car-buying experiences), MS is forcing you to make a choice of upgrading, even though Win2K will work just fine for many years to come, if you had any say in the matter.
Very well, you must consider an upgrade, because of MS business tactics. In that case, I submit that you have an opportunity to at least consider Linux on the desktop as an alternative. If you're serious about your IT costs, then you really are obligated to consider the alternatives at every step of the game.
I guess I can see where power, cooling and perhaps space requirements could be less for the equivalent mainframe solution.
I gather, then, that software solutions to make racks of PCs more manageable haven't made enough difference - that too much of the system administrator's tasks require "saving state" in his head, which can't scale beyond O(dozens) to O(100s)?
I like the way that they describe the practical side of the transition - i.e., moving new users over instead of people comfortable to sit on the top of the learning curve that they've already scaled.
My outfit is looking at Linux desktops in a more scientific and engineering environment.
But we share a similar need to deal with the ubiquitous.doc,.xls and.ppt files that are endemic in the corporate world.
I like their setup with KDE, but I've thought that using Evolution would be a nicer MUA.
It's great they can do so well with StarOffice 5.2 that has its share of glitches and user interface problems.
If only StarOffice 6 would finally come out!
I believe that single product, SO 6, with updated filters for the aforementioned "standard" file formats and non-monolithic user interface, will do more to unleash a flood of Linux desktop migration than any other single product (unless AOL 9.0 includes Linux).
...they mention that one of the $400,000 servers can replace 'hundreds of servers'
Well, it better replace hundreds of servers, because you could theoretcially purchase hundreds of cheap rack-mounted boxes for a similar amount of money.
It's got to pay off in a different way than providing equivalent computing horsepower to hundreds of PC servers.
Is it in reduced hardware maintenance headaches, easier to manage than a crowd of servers?
Is someone out there with experience in managing racks of PCs and mainframes for a while able to tell us how much of an incentive there is to use the mainframes instead of racks `o PCs?
How, pray tell, do they propose to determine whether a user has NAT?
Well, probably nothing is a perfectly reliable diagnostic.
But, [not an expert, here] I had thought that one symptom of NAT was a plethora of high numbered ports being used.
But this practice really irks me.
As far as I'm concerned, just let the user pay for [bandwith + 1/latency]*connect_time.
If clients don't want to subscribe to your extra services, then don't try to browbeat them into it by saying that home-brewed services are "not allowed".
The first network service provider with a business model specifically designed to cater to the commoditization of the network will eventually make mincemeat of those providers that rely on heavy-handed tactics to force their customers into needless higher cost products.
It's like having to buy rust-proofing as part of your new car or an extended warranty on a piece of solid-state electronics - a complete rip-off.
No one would by it because they could never guarentee that your PC is going to act the same as everyone else's.
A valid concern, and certainly one that I would have.
Upon further reflection, though, I thought of this analogy:
The brains and nervous systems of any two human beings are absolutely different. Yet, you can program them (education) so that they can perform the same function (eg, produce consistently spelled words of a language.
Of course, programming humans is more involved than programming silicon, but at least it suggests to me that different underlying physical architecture does not preclude having consistent functionality. [Yes, you can argue that the yield of properly functioning humans is not all that great, but, hey, there's hope.]
Well, AFAICT, the real bug is in the communication of relevent knowledge.
These kinds of bugs would have significantly shorter duration if the specifications for all four possible culprits in (A)-(D) were openly published, completely, for all to see.
My large organization is probably a lot like many others.
We have a fairly extensive policy for managing records that has been developed over decades in a world dominated by paper.
There has been some effort to extend those policies into the electronic arena as well.
But I think the sheer volume of electronic records is making the certain impracticalities of those policies show.
Things like having people periodically review material and decide what to keep and what to archive and what to destroy - this requires more human time than any reasonable person is willing to commit. And, if the corporation thinks about the real costs of having a live human review those e-documents, they'll probably come to the same conclusion.
And I won't even mention the complications of moss-covered media that has stuff on it that no one has really inventoried carefully.
I have 8mm tapes from 7-8 years ago that I haven't looked at. There's several GB of stuff on it, but even I couldn't tell you what it all is.
It's probably includes the 12 page document that Oliver North faxed to me about the impending Enron collapse that was initiated by the Whitewater deal. 8)
No, there's nothing that prevents one from "running" those KDE apps under Gnome (and vice versa), but I'm wondering whether you might find that Kchart, Kfile, etc. work "better" under KDE because of the KParts object model connecting them underneath everything.
Maybe even the mutual interactions between K* applications works pretty good under Gnome, but the ideal would be if those applications interacted in a full way with Gnome applications (that use Bonobo).
So that you could perhaps embed a Kchart inside of a document you are writing with OpenOffice under GTK and have it be just as useful as if it were embedded inside a KOffice document.
That's kind of what I'm thinking. (If I sound vague, it's because I'm no expert on this matter, in case you haven't guessed by now.)
Slashdot Mirror
I think it's getting to be evident that the traditional UNIX RISC workstation vendors are having a hard time keeping their CPUs not only on the price/performance curve, but on the performance curve itself.
The MIPS chip is battling uphill, just like the UltraSPARC III against competitive offerings like the 2.2 GHz Northwood P4 and the AMD Athlon XP 2000.
I respect SGI for it's history of graphics expertise and devotion to producing quality hardware, but like many others I have to ask the hard question:
For some people, it probably is worth the extra money. But I think that target market is constantly shrinking.SGI has hemorrhaged some good people, money, and their 3D patent portfolio (to MS recently). They can ill afford to come up with any product less than a perfect bullseye at this stage of the game. I fear this is not it.
Yes, it could be good, since Hans Reiser makes the point of just how much the overall utility of information is in making that information more widely accessible to the fringes of access.
That's a key insight, one that deserves to be addressed.
The immediate practical issue with this is that
which, admittedly, represents more of a psychological and personality problem than it does a problem in information technlogy. All the great file system ideas in the world won't work if people are fundamentally against the premise of more information sharing being a Good Thing.Indeed, one could argue that more research is probably being funded into ways of restricting information access than devising filesystems to make widespread information access more efficient. Why? Well, because restricting the free flow of information is a policy that is more closely aligned with the current revenue models of important content copyright holders.
You watch. Longhorn will have some improved technology in the filesystem to make information queries more efficient, but everyone on the corporate LAN will clamp down access controls that render it effectively of no value.
So why would anyone expect the state AGs to do much about something they know very little about (no disrepect, but the majority of lawyers do not have the specialized knowledge of technology as they do with law)?
Note that they haven't too much about something comparably restrictive of commercial activity that affects their citizens and about which they know much more - to wit, VISA.
Have you given much thought to how much merchants get charged for the privilage of accepting VISA cards? Of how much your ability to conduct transactions in the real world is affected by the need for you to have a VISA card?
As with the price of Windows and Office, the price of VISA service is kept just barely under the pain threshhold, where the host is not willing to make the effort to squash the parasite.
If nothing's been done about VISA, I hardly expect a snappy acknowledgement from the state AGs recognizing the similar capacity of MS Passport to obtain a stranglehold on electronic trade.
But, what, pray tell does the general public know about the best places to explore?
Politically, I know this is a good way to engage the public in this exciting area of science, and I know that many people want a say in how their tax dollars are spent.
For the record, this particular citizen would prefer that the decisions be made on a purely technical basis, including input from the most respected and knowledgable astronomers in the world.
That, to me, would make me feel a lot more comfortable about where my dollars are going than if the decision were made on the basis of what 2000 third grade students thought was the "most cool" thing to do in space, which is almost as likely to be off the mark as what 550 Congressman thought was "the most cool" thing to do in space.
source management isn't the problem. Making sure useless crap doesn't make it into the tree is the problem. CVS doesn't have any sort of means to make sure that what goes in is quality code.
Well, source management is a problem that CVS or the new Subversion might help with.
But your point is a good one. Source code management of patches, diffs, etc. is only part of the problem.
For userland application codes, it's been possbile to set up cron jobs to do automated feature, coverage, and performance testing so that if anyone checks in crappy code, it is shortly revealed to the world.
I'm thinking that some big outfit like OSDL could corral a whole stable of motley hardware that could be used to automate kernel testing. Volunteers are great, but the testing gets done on an ad hoc basis. Thus you can guarantee that whatever hardware is owned by Alan Cox or some other kernel guru will probably work great, the bozo box I've got will not be similarly tuned up because I wouldn't feel safe tweaking the kernel source, despite some years of C programmiong experience.
The big problem I see in automated testing is that I'm not sure kernel's can be tested as easily as other applications can be. I can just see the BIOS hanging there with no means to talk over the network to tell the master tester just exactly how it has hung. Perhaps running User Mode Linux?
I have to say, I'd like to find a really good approach for dealing with mailers with built-in prejudicial statements in them.
You know the kind, where you get to see disparaging comments like
as if you are using a deficient MUA when you see such text.I'd really like a 2-3 sentence autoreply text that could bounce some of those MS Word attachments with similar pronouncements about
Most people simply have no idea what standards are, nor the ways or the degree to which they pay for the IT infrastructure that they currently use.Their responses are usually quizzical and predictable, "Uhh, so what does it look like to you when Word launches?" Answer: Word doesn't launch. It requires money to launch. It requires that you buy the whole banana to get Word. (There used to be Ted Rall cartoon years ago that parodied the whole issue during the browser war years "Works best with MS House!"
People so much consider these things like .doc to be standards, that they ought to be made into bona fide standards that are publicly documented, including all the quirks of proper display, instead of just glossing over that they cannot be displayed without paying money to see them, even if its bundled into the cost of your new PC or the Microsoft Enterprise License Agreement for Office, which is probably priced more inelastically than gasoline.
Peer review relies on the same fount of goodwill that fuels information sharing in the scientific community.
If you've reviewed papers thoroughly, you know that it takes an investment of time on your part to get up to speed in the specific subject that the authors are writing about.
I'm finding that it is becoming increasingly difficult to justify that kind of time investment on any regular basis.
I think peer reviewed papers are a great idea, but the current system has some structural defects, in that the peers are not directly renumerated for their efforts and expertise.
No, really!
If high quality displays can be made inexpensively, of flexible material, and incorporate light sensors (presumably not overwhelmed with photons emanating from the display), would it not be possible to use them as wall paper on the inside and out and thereby achieve the illusion of transparency?
Taking a cue from all those advertisements that have been chopping the bottoms off the screen and overwriting part of the action with a semi-transparent channel logo I hereby predict:
Remember, you read it on Slashdot first!
Don't forget the fact that some years ago the Alpha was able to run some version of Windows NT. There would certainly have to be some cobweb dusting to get Win2K or WinXP to run on the new Alphas, but I bet it really wouldn't take too much effort.
Also, DEC had developed something called FX!32 in order to run the 32 bit IA32 apps on their new 64 bit chip, when emulation was necessary. (Sounds a lot like the strategy in Hammer, actually).
So, you see, Intel really is in a good position to dust off the EV7 as if it were their own chip and be able to make it succeed.
Not only that, IIRC, some of the bus technology for the K7 came out from the Alpha project. That would seem to mean that some of the motherboard makers could more easily interchange between AMD and Alpha than they could, say, between the Hammer and what is currently called IA64.
But I agree with you. The NIH syndrome is very powerful.
Looks cool.
How do you compare your effort that uses PHP to IMP Horde?
This has been the focus of some stories at the Inquirer as well.
Personally, I thought that Intel would have been in a good position to just relabel the Alpha 21364 as IA64 and be done with it.
Cerenkov radiation, that's been known for decades?
I think you misspelled "epidemic".
You're right! Wait a minute, let me try again to get it right here...
Long ago and far away (about 15 years ago) I recall that TeX was frequently built in a fashion that required running the binary on some "initialization" information. That process took some nontrivial amount of time back in those days (I'm sure now it would be an eyeblink), and the program could be made to \dump its state in some way.
Then, when you ran TeX in everyday circumstances, the digested initialization file was read in by the application as part of the usual startup process.
I'm probably botching the explanation of how this really worked, but I guess my point is that the "resume" function had to be coded into the specific application.
Hmmm...this resume dumping looks like a great way to...ah...unload some of those prickly co-workers or PHBs in my workplace!
I can think of several people right now that I'd rather not have here. I could polish up a resume for them and post it to every Usenet group I could find. Mebbe even a few of the alt.sex sites just for the entertainment value!
The filters have extremely little to do with the problem.
I beg to differ. From the perspective of someone who uses Word, Excel and Powerpoint day in and day out, one of the biggest stumbling blocks to a migration to Linux is being able to communicate effectively in these formats, which are a de facto standard. If there's a difference, however small, in how those formats are interpreted under StarOffice compared to how they are interpreted under MS Office, then that is one glitch too many for users that are transitioning.
I agree, MS has no reason to adopt a single, open file format. From a business perspective, they have everything to gain by keeping such standards under their control and making all access to such standards require a payment to Redmond. MS will continue to follow the same strategy of "upgrading into incompatiblity", as Office XP Word attachments arrive on the desks of Office 97 users, ever so gently goading them into an upgrade merely to be able to read and write attachments that their friends are sending from WinXP machines (which are pretty much all you can find at the stores) Funny how that works.
As far as I can tell, the biggest costs of switching are in user retraining. The software cost savings of desktop Linux are a given; the added benefit of not being put on a forced upgrade treadmill is an additional savings; finally, the need of keeping track of MS licenses is eliminated. Those are all significant real benefits that anyone in IT decision-making should weight, but it is not the entire equation as far as costs are concerned.
It's all the secretaries that learn the quirks of Word for a period of years that represent an investment in user training that can only be partially recouped by switching to StarOffice, and that only to the degree that the user interface and behavior of SO mimics MS Word.
I'll agree that Win2K is reasonable as far as MS operating systems are concerned. It's quite usable. But there's the rub!
Win2K is fine if you need a operating system with a stable win32 API for office productivity applications.But if your Win2K Enterprise Licensing costs will be forced through the roof unless you buy XP real soon (reminds me of some car-buying experiences), MS is forcing you to make a choice of upgrading, even though Win2K will work just fine for many years to come, if you had any say in the matter.
Very well, you must consider an upgrade, because of MS business tactics. In that case, I submit that you have an opportunity to at least consider Linux on the desktop as an alternative. If you're serious about your IT costs, then you really are obligated to consider the alternatives at every step of the game.
Thanks for your insight!
I guess I can see where power, cooling and perhaps space requirements could be less for the equivalent mainframe solution.
I gather, then, that software solutions to make racks of PCs more manageable haven't made enough difference - that too much of the system administrator's tasks require "saving state" in his head, which can't scale beyond O(dozens) to O(100s)?
I like the way that they describe the practical side of the transition - i.e., moving new users over instead of people comfortable to sit on the top of the learning curve that they've already scaled.
My outfit is looking at Linux desktops in a more scientific and engineering environment.
But we share a similar need to deal with the ubiquitous .doc, .xls and .ppt files that are endemic in the corporate world.
I like their setup with KDE, but I've thought that using Evolution would be a nicer MUA.
It's great they can do so well with StarOffice 5.2 that has its share of glitches and user interface problems.
If only StarOffice 6 would finally come out!
I believe that single product, SO 6, with updated filters for the aforementioned "standard" file formats and non-monolithic user interface, will do more to unleash a flood of Linux desktop migration than any other single product (unless AOL 9.0 includes Linux).
Well, it better replace hundreds of servers, because you could theoretcially purchase hundreds of cheap rack-mounted boxes for a similar amount of money.
It's got to pay off in a different way than providing equivalent computing horsepower to hundreds of PC servers.
Is it in reduced hardware maintenance headaches, easier to manage than a crowd of servers?
Is someone out there with experience in managing racks of PCs and mainframes for a while able to tell us how much of an incentive there is to use the mainframes instead of racks `o PCs?
How, pray tell, do they propose to determine whether a user has NAT?
Well, probably nothing is a perfectly reliable diagnostic.
But, [not an expert, here] I had thought that one symptom of NAT was a plethora of high numbered ports being used.
But this practice really irks me.
As far as I'm concerned, just let the user pay for [bandwith + 1/latency]*connect_time.
If clients don't want to subscribe to your extra services, then don't try to browbeat them into it by saying that home-brewed services are "not allowed".
The first network service provider with a business model specifically designed to cater to the commoditization of the network will eventually make mincemeat of those providers that rely on heavy-handed tactics to force their customers into needless higher cost products.
It's like having to buy rust-proofing as part of your new car or an extended warranty on a piece of solid-state electronics - a complete rip-off.
No one would by it because they could never guarentee that your PC is going to act the same as everyone else's.
A valid concern, and certainly one that I would have.
Upon further reflection, though, I thought of this analogy:
The brains and nervous systems of any two human beings are absolutely different. Yet, you can program them (education) so that they can perform the same function (eg, produce consistently spelled words of a language.
Of course, programming humans is more involved than programming silicon, but at least it suggests to me that different underlying physical architecture does not preclude having consistent functionality. [Yes, you can argue that the yield of properly functioning humans is not all that great, but, hey, there's hope.]
Hmmmm.
Is the Bug...
- (A) In the Athlon cache?
- (B) In the chipset?
- (C) In the AGP-using devices misusing memory?
- (D) In the Linux kernel?
Well, AFAICT, the real bug is in the communication of relevent knowledge.These kinds of bugs would have significantly shorter duration if the specifications for all four possible culprits in (A)-(D) were openly published, completely, for all to see.
My large organization is probably a lot like many others.
We have a fairly extensive policy for managing records that has been developed over decades in a world dominated by paper.
There has been some effort to extend those policies into the electronic arena as well.
But I think the sheer volume of electronic records is making the certain impracticalities of those policies show.
Things like having people periodically review material and decide what to keep and what to archive and what to destroy - this requires more human time than any reasonable person is willing to commit. And, if the corporation thinks about the real costs of having a live human review those e-documents, they'll probably come to the same conclusion.
And I won't even mention the complications of moss-covered media that has stuff on it that no one has really inventoried carefully.
I have 8mm tapes from 7-8 years ago that I haven't looked at. There's several GB of stuff on it, but even I couldn't tell you what it all is.
It's probably includes the 12 page document that Oliver North faxed to me about the impending Enron collapse that was initiated by the Whitewater deal. 8)
No, there's nothing that prevents one from "running" those KDE apps under Gnome (and vice versa), but I'm wondering whether you might find that Kchart, Kfile, etc. work "better" under KDE because of the KParts object model connecting them underneath everything.
Maybe even the mutual interactions between K* applications works pretty good under Gnome, but the ideal would be if those applications interacted in a full way with Gnome applications (that use Bonobo).
So that you could perhaps embed a Kchart inside of a document you are writing with OpenOffice under GTK and have it be just as useful as if it were embedded inside a KOffice document.
That's kind of what I'm thinking. (If I sound vague, it's because I'm no expert on this matter, in case you haven't guessed by now.)