If you do decide to go with dry ice, make suree to have a good supply of fresh air to wash over the ice instead of letting the dryice evaporate in the data-center. What happens is dryice melts and turns into carbon gas, which makes humans passout from a lack of oxygen. It is even possible to die as this would be comparable to running the exhaust of the car with the garage door down. It would fill the room full of noxious gas. So the trick is to use the dryice in conjunction with a heat/cold exchanger to cool the air in the room. Then again, punching holes for the generators doesn't sound like such a bad idea any more huh?
First off, we dislike having gpl code in the base system, but we do have gpl stuff (but always a bsd fall back) for things like tar, gcc, dialog, rcs, sort, gzip, and just a few others. We keep our/bin and/sbin clean of the gpl. We typically think that awk or perl is capable of this sort of thing, and to get a program like this into the base system requires at the very least a commit bit in the cvs tree, or approval form the core team, or membership to the core team (yeah right). Since a text-processing, or rather a number processing, program is considered to be strictly useless to a base system's functionality, it would most certainly be religated to the ports tree. Don't kid yourself, you might think your software is the best thing under the sun since sliced bread, but to be so bold as to think it needs to be included in the base of any Unix-like-system is a pipe dream.
When President Bush made the stament that one bullet could solve the problem in the midle east, I suspect its ok for me to say that one fire-bomb at the SCO's world headquarters would solve this issue. At any rate, its only a matter of time before the SCO sources are compared to the Linux sources by Computer Science prfessors, and other qualified persons. At that time it will be a matter of court record (public or sealled), and ultimatly the areas of sources will be altered with fresh code, or proved to be of the type that is algorythmically common to code design. Comments in code are not normally admisable, as they were not in the Berkley case in 94. anyways, once the code is clean, as was the way in the berkley case, SCO will have nothing to license, and their UnixWare will still suck.
I followed the FAQ link to d-link's website and found a link to a binary driver. So the claim that no driver exists is a wash. Granted, no source code... but its a non-trival task to decompile the drivers, and definatly inside the realm of possibilities. Am I missing something, or was the original poster, or did d-link sneak in the linkage in responce to a slashdot effect?
The answer is neither. The solution is to run FreeBSD instead of SCO or Finux. It's not about a high signal, or noise that both Finux, and SCO generate.. its about stability that matters at teh end of the day. =)
I see that you still have not worked on the reasoning skills. Or perhaps it is the reading comprehension that is causing you difficulty. In reality you opened your mouth and promptly inserted your foot and now resort to boring and childish diversionary tactics in the sad hope that will somehow distract from your untenable claims.
I already knew you were an idiot, but each time you write something you seem to remove any doubt. As I pointed out before, I do not want to devolve this thread by wasting it on you. To answer you somewhat off-thread question: it not about the *freedom* to choose a license, it's about the rights to use the licensed code, and the freedoms therein. Again, your missing the conversation about a crappy license and turning it into something about you, and your right to choose a license. I hardly think I'm creating a diversion or inserting my foot into mouth. If anything I think I just proved that you have! Please go back and re-read the thread to understand the point is about linksys would have avoided the so called "community pressure" involved in releasing the code back for the GPL'ed code they used in the 802.11 router. The point is the "GPL strikes again", and you missed it utterly, and completly. Thanks.
In your narrow view of the world, I'm sure your make perfect sense, but not here. BTW - I wouldn`t devolve this thread to be *about you*, as you suggest. You can solve for yourself any issues you have in choosing a license. This never was about you choosing a license, so bug off. In regards to my reasoning skills, I still think your a moron. =)
The GPL is free as in "hey look, its free code at no cost", and nothing more. Free Speech is part of it, but there isa restriction. Yoy have to provide any modifications to the authors, as I'm surw you know.
The BSD license has no restriction except the one about attributing the original copyright holder. It free as in "free stuff", and free as in "Freedom of use".
The GPL is not free as in freedom, it is restricted so that you are trapped by it if you modify code and use it in a project. That is not freedom, or free speech. There is nothign free about a license that forces somebody to do something, in this case release modifications to gpl code.
That simply doesn't compute. Yes, the GPL can asymilate any code that is more free than itself. In regards to BSD developers supporting the gpl, even by theory of indirect contribution by simply existing, is utter naivety. Thats like saying I support getting the flu because I'm human and am therfor suseptible to viral disease. And in the thought experiment you suggest, then Linksys (for example) would have two parallel options to choose ofthe same thing, and you you belive they would take the not so free version for their modification? I hardly think they would in that situation.
This type of license strong-arming is the reason embeded market should choose BSD. We FreeBSD folk shun the idea of a not-so-free license like the GPL where you have free as in beer, not free as in freedom. Free, Net, and OpenBSD are free as in beer, and freedom. Linksys could have had equal if not better performance with a BSD based kernel, and there is certainly an established BSD embeded computing community. Certainly NetBSD is the most supperior embeded Open Source OS on Earth which runs on over 35 architectures.
Well, the GPL might be good if Linksys wanted to write code that was Open source, but didn't want a competitor to takeover. Sorta like how IBM did with their JFS filesystem. SUN could take JFS, put it on Solaris, but they would have to show IBM the code that glued it together. So in this way the GPL is great for companies who want to share code, but bad for companies who want to borrow code for their own products. It appears Linksys needs to ignore a bit of the linux hype and get more practical, or continue to "cave under pressure" as the slashdot post implies.
The reason this movie sucks-ass is the fact that James Cameron isn't involved. Sure there was plenty of explosions, a sexy protagonist, and a plot suitable for the attention-deficient. The movie is short, and certain parts have plot holes so big I can drive a space shutle thru. There is a part where a missle is shot thru a window at our hero, John Conor, that only does damage to a chalk board. The star of the show, if any, had to be Arnold Swartzenegger as the Terminator. Actually, the whole movie seems nothing more than an excuse to stand Arnold in front of a camera and tell one-liners about "I'll be back", or "I'm back", or whatever. In my opinion, they would have done well to get another huge muscle actor to play the part of the antique terminator. After all, would the humans of the future really have to fight an army of Arnolds, heck no! Terminators would all look slightly different on the outside, but be metal on the inside. Another big hole in the story is the fact that if the progression of terminators is getting more leathal per sequal, then the folks of the future probably didn't have a chance.
That really sad to see! It was a simple fact that Microsoft actually made *good* game controllers, and is one of the reasons I decided to go with an Xbox for my consol. One of the reasons sales might be in decline is that all the people that would get a game controller for their PC might already have them? New sales being young first timers to the controler market. Most games are designed for a mouse and keyboard, that is true. However, I point to the Xbox/Playstation and see a large number of titles ported over from the PC. All those ported games use a typical game contrller like the kind microsoft sells. Microsoft should sell that biz unit to somebody else, it might even look good in their anti-trust disposition.
We have had 802.11g gear on the market for nearly a year, if not longer? TAlk about the tail wagging the dog! Now if only we can get the vendors to release the specs for the registers for these 802.11g cards we can start to have OSS drivers made. Apparently the gear is all capable of being tuned with control for power, and frequency adjustments, so the FCC doens't want home users using 802.11g gears as the next-generation of HAM radio. Not to mention the ability to interfear with existing radio licenses granted.
Because DEC had a major marketing champain to promote the alpha as a desktop, but that didn't pan out at the time. At the time cyrix was Intel's other competitor, and AMD wasn't even on most folks radar yet.
Back in 96' or 97' I can recall a bunch of hype in the public markets for the infamous DEC ALpha. I can recall banner adds here on slashdot for "64bit power" and other advertisments basically to the effect of "my processor is bigger than yours" type stuff. The difference now is that the market seems slightly more ready for 64 bit computing as more than 2 vendors are selling 64 bit systems. Intel (ia 64), IBM (ppc 970), Transmeta (128bit/2 core), MIPS, AMD, and I think you can still buy a new Alpha from HP still. I suspect the market still isnt' ready for 64 bit computing, but the saturation of vendors trying to be the one wwho actually makes penetration, like sperm on the egg of the consumer market. Apple is probably the most end-user'ish vendor on the market with very little server penetration, and this is promising news. Most of the other 64 platforms go the way of awsome servers. Apple has the chance to sell systems to mac-heads who would do anything to recapture their former elitness geek glory of years gone by. The onyl way 64 bit system will work ijs if they are compatible with the 32 bit software, and yes I mean the OS + user apps. This is why Apple, and AMD have an advantage. Intell seems to have the notion that since it is the market leader that it can simply force a new architecture down our necks, and the market has decided otherwise, and Intel hasn't lived up to its own expectations either. Time will tell is the IBM incarnation of the PPC is going to make it, and Apple has a history of over pricing their gear. If they could get their systems down to the average price of $1200 usd, then they would have a chance.
The speed, er... rather the window size is changed according to a rigid design, and ideas like this in the past have failed because once everyone is doing them, they stability of the network decreases. Mind you this is distinctly different that "removing error checking" because it is basically taking two steps forward instead of one step at a time. If you leap ahead two steps, and fail you simply step back one (which is still one step forward). The packets are still resent on the TCP leaving the application to not worry about data quality. Looking at packet captures of ftp traffic show that ftp is an aggressive consumer of bandwidth, and that ramping up or down near the beginning or end of the TCP session is were the greatest amount of *inefficiency* is found. So the idea is to make tcp more aggressive near the ramp-up/down stages of the connection. The idea also being to remove some of the agonizingly redundant error checking in favor of self-throttling optimistic educated guessing. Fast TCP simply wants to do the dirty work ahead of time instead of gradually discovering the safe speed limit. Fast TCP will bump into glass bandwith ceiling at mach 10, instead of 10 Mph, quicly recovering by resending the big chucks at a fraction of the window size previously sent. So it could also be described as willig to find the threashold quickly in echange for knowing the boundrys instead of wasting precious time ramping up. Traditional TCP hates data loss to the point that is "drives slow in a parking lot" attempting to never have a colision, whne the protocal itself is well designed to recover from such an event already.
If SCO sues Linus, then that would mean the offending code is kernel code. Linux only holds control over the kernel, and the central source repository. That at least narrows down the scope from anywhere in a Linux based distro, to some place insidce a Linux kernel, or kernel module. You can never unilaterally blaim all off linux for beign in violation. In reality it's only just a few lines of code from the source file(s). The industry would simply splice out the offending code with a replacment. So what SCO is apparently wantign to do is tell everyone to stop using linux , or be sued later, and not telling what part of linux is the offendign part. Revelinng the part of the offending code would remove the ability to sue everyone under the sun aspect of the law suit, which seems to be very lulkrative for SCO.
It doesn't matter if SMTP is "intrinsically flawed" (which it isn't)
I duno what planet your from, and I doubt you've read the RFC's regarding SMTP on Earth... cuz the above statements clearly shows your ignorance in the SPAM issue. SMTP can be abused because it is flawed despite what you desire, or perceive, to be true. SMTP is wide open to Spam from an era of wide open, non-security minded protocol design.
In regards to your silly statement about SMTP not being flawed, security wise... I believe Mark Twain classifies you best: The whole world knows you're a fool, but when you open your mouth, you remove all doubt. Why do you think that the architects want to add extra headers to the standard, its not because they think SMTP is complete as is. Gosh dude... think about it! Maybe if you keep telling yourself that SMTP is not flawed, it will fix itself? Perhaps you think that if you wish to the tooth fairy, that spam will go away?
Slashdot Mirror
If you do decide to go with dry ice, make suree to have a good supply of fresh air to wash over the ice instead of letting the dryice evaporate in the data-center. What happens is dryice melts and turns into carbon gas, which makes humans passout from a lack of oxygen. It is even possible to die as this would be comparable to running the exhaust of the car with the garage door down. It would fill the room full of noxious gas. So the trick is to use the dryice in conjunction with a heat/cold exchanger to cool the air in the room. Then again, punching holes for the generators doesn't sound like such a bad idea any more huh?
First off, we dislike having gpl code in the base system, but we do have gpl stuff (but always a bsd fall back) for things like tar, gcc, dialog, rcs, sort, gzip, and just a few others. We keep our /bin and /sbin clean of the gpl. We typically think that awk or perl is capable of this sort of thing, and to get a program like this into the base system requires at the very least a commit bit in the cvs tree, or approval form the core team, or membership to the core team (yeah right). Since a text-processing, or rather a number processing, program is considered to be strictly useless to a base system's functionality, it would most certainly be religated to the ports tree. Don't kid yourself, you might think your software is the best thing under the sun since sliced bread, but to be so bold as to think it needs to be included in the base of any Unix-like-system is a pipe dream.
When President Bush made the stament that one bullet could solve the problem in the midle east, I suspect its ok for me to say that one fire-bomb at the SCO's world headquarters would solve this issue. At any rate, its only a matter of time before the SCO sources are compared to the Linux sources by Computer Science prfessors, and other qualified persons. At that time it will be a matter of court record (public or sealled), and ultimatly the areas of sources will be altered with fresh code, or proved to be of the type that is algorythmically common to code design. Comments in code are not normally admisable, as they were not in the Berkley case in 94. anyways, once the code is clean, as was the way in the berkley case, SCO will have nothing to license, and their UnixWare will still suck.
I followed the FAQ link to d-link's website and found a link to a binary driver. So the claim that no driver exists is a wash. Granted, no source code... but its a non-trival task to decompile the drivers, and definatly inside the realm of possibilities. Am I missing something, or was the original poster, or did d-link sneak in the linkage in responce to a slashdot effect?
The answer is neither.
The solution is to run FreeBSD instead of SCO or Finux. It's not about a high signal, or noise that both Finux, and SCO generate.. its about stability that matters at teh end of the day. =)
I see that you still have not worked on the reasoning skills. Or perhaps it is the reading comprehension that is causing you difficulty. In reality you opened your mouth and promptly inserted your foot and now resort to boring and childish diversionary tactics in the sad hope that will somehow distract from your untenable claims.
I already knew you were an idiot, but each time you write something you seem to remove any doubt. As I pointed out before, I do not want to devolve this thread by wasting it on you. To answer you somewhat off-thread question: it not about the *freedom* to choose a license, it's about the rights to use the licensed code, and the freedoms therein. Again, your missing the conversation about a crappy license and turning it into something about you, and your right to choose a license. I hardly think I'm creating a diversion or inserting my foot into mouth. If anything I think I just proved that you have! Please go back and re-read the thread to understand the point is about linksys would have avoided the so called "community pressure" involved in releasing the code back for the GPL'ed code they used in the 802.11 router. The point is the "GPL strikes again", and you missed it utterly, and completly. Thanks.
Yes, you have all my prior threads, and journals to read, have fun!
In your narrow view of the world, I'm sure your make perfect sense, but not here. BTW - I wouldn`t devolve this thread to be *about you*, as you suggest. You can solve for yourself any issues you have in choosing a license. This never was about you choosing a license, so bug off. In regards to my reasoning skills, I still think your a moron. =)
Ok, I think your wrong, and here is why:
The GPL is free as in "hey look, its free code at no cost", and nothing more. Free Speech is part of it, but there isa restriction. Yoy have to provide any modifications to the authors, as I'm surw you know.
The BSD license has no restriction except the one about attributing the original copyright holder. It free as in "free stuff", and free as in "Freedom of use".
The GPL is not free as in freedom, it is restricted so that you are trapped by it if you modify code and use it in a project. That is not freedom, or free speech. There is nothign free about a license that forces somebody to do something, in this case release modifications to gpl code.
That simply doesn't compute. Yes, the GPL can asymilate any code that is more free than itself. In regards to BSD developers supporting the gpl, even by theory of indirect contribution by simply existing, is utter naivety. Thats like saying I support getting the flu because I'm human and am therfor suseptible to viral disease. And in the thought experiment you suggest, then Linksys (for example) would have two parallel options to choose ofthe same thing, and you you belive they would take the not so free version for their modification? I hardly think they would in that situation.
Spoken like a true moron. The first thing a moron does is try to over simplify the issue to their level, as you have. Thanks =)
This type of license strong-arming is the reason embeded market should choose BSD. We FreeBSD folk shun the idea of a not-so-free license like the GPL where you have free as in beer, not free as in freedom. Free, Net, and OpenBSD are free as in beer, and freedom. Linksys could have had equal if not better performance with a BSD based kernel, and there is certainly an established BSD embeded computing community. Certainly NetBSD is the most supperior embeded Open Source OS on Earth which runs on over 35 architectures.
Well, the GPL might be good if Linksys wanted to write code that was Open source, but didn't want a competitor to takeover. Sorta like how IBM did with their JFS filesystem. SUN could take JFS, put it on Solaris, but they would have to show IBM the code that glued it together. So in this way the GPL is great for companies who want to share code, but bad for companies who want to borrow code for their own products. It appears Linksys needs to ignore a bit of the linux hype and get more practical, or continue to "cave under pressure" as the slashdot post implies.
The reason this movie sucks-ass is the fact that James Cameron isn't involved. Sure there was plenty of explosions, a sexy protagonist, and a plot suitable for the attention-deficient. The movie is short, and certain parts have plot holes so big I can drive a space shutle thru. There is a part where a missle is shot thru a window at our hero, John Conor, that only does damage to a chalk board. The star of the show, if any, had to be Arnold Swartzenegger as the Terminator. Actually, the whole movie seems nothing more than an excuse to stand Arnold in front of a camera and tell one-liners about "I'll be back", or "I'm back", or whatever. In my opinion, they would have done well to get another huge muscle actor to play the part of the antique terminator. After all, would the humans of the future really have to fight an army of Arnolds, heck no! Terminators would all look slightly different on the outside, but be metal on the inside. Another big hole in the story is the fact that if the progression of terminators is getting more leathal per sequal, then the folks of the future probably didn't have a chance.
That really sad to see! It was a simple fact that Microsoft actually made *good* game controllers, and is one of the reasons I decided to go with an Xbox for my consol. One of the reasons sales might be in decline is that all the people that would get a game controller for their PC might already have them? New sales being young first timers to the controler market. Most games are designed for a mouse and keyboard, that is true. However, I point to the Xbox/Playstation and see a large number of titles ported over from the PC. All those ported games use a typical game contrller like the kind microsoft sells. Microsoft should sell that biz unit to somebody else, it might even look good in their anti-trust disposition.
does my uid indicate that I'm new here?
this same news was also on yesterdays slashdot. The editors needs to check their stories prior to publishing this type of repeate.
We have had 802.11g gear on the market for nearly a year, if not longer? TAlk about the tail wagging the dog! Now if only we can get the vendors to release the specs for the registers for these 802.11g cards we can start to have OSS drivers made. Apparently the gear is all capable of being tuned with control for power, and frequency adjustments, so the FCC doens't want home users using 802.11g gears as the next-generation of HAM radio. Not to mention the ability to interfear with existing radio licenses granted.
The Brooklyn Bridge, the New York Sewer system.
Send me a check for $500 and they will be yours!
What was so infamous about the DEC Alpha?
Because DEC had a major marketing champain to promote the alpha as a desktop, but that didn't pan out at the time. At the time cyrix was Intel's other competitor, and AMD wasn't even on most folks radar yet.
Back in 96' or 97' I can recall a bunch of hype in the public markets for the infamous DEC ALpha. I can recall banner adds here on slashdot for "64bit power" and other advertisments basically to the effect of "my processor is bigger than yours" type stuff. The difference now is that the market seems slightly more ready for 64 bit computing as more than 2 vendors are selling 64 bit systems. Intel (ia 64), IBM (ppc 970), Transmeta (128bit/2 core), MIPS, AMD, and I think you can still buy a new Alpha from HP still. I suspect the market still isnt' ready for 64 bit computing, but the saturation of vendors trying to be the one wwho actually makes penetration, like sperm on the egg of the consumer market. Apple is probably the most end-user'ish vendor on the market with very little server penetration, and this is promising news. Most of the other 64 platforms go the way of awsome servers. Apple has the chance to sell systems to mac-heads who would do anything to recapture their former elitness geek glory of years gone by. The onyl way 64 bit system will work ijs if they are compatible with the 32 bit software, and yes I mean the OS + user apps. This is why Apple, and AMD have an advantage. Intell seems to have the notion that since it is the market leader that it can simply force a new architecture down our necks, and the market has decided otherwise, and Intel hasn't lived up to its own expectations either. Time will tell is the IBM incarnation of the PPC is going to make it, and Apple has a history of over pricing their gear. If they could get their systems down to the average price of $1200 usd, then they would have a chance.
The speed, er... rather the window size is changed according to a rigid design, and ideas like this in the past have failed because once everyone is doing them, they stability of the network decreases. Mind you this is distinctly different that "removing error checking" because it is basically taking two steps forward instead of one step at a time. If you leap ahead two steps, and fail you simply step back one (which is still one step forward). The packets are still resent on the TCP leaving the application to not worry about data quality. Looking at packet captures of ftp traffic show that ftp is an aggressive consumer of bandwidth, and that ramping up or down near the beginning or end of the TCP session is were the greatest amount of *inefficiency* is found. So the idea is to make tcp more aggressive near the ramp-up/down stages of the connection. The idea also being to remove some of the agonizingly redundant error checking in favor of self-throttling optimistic educated guessing. Fast TCP simply wants to do the dirty work ahead of time instead of gradually discovering the safe speed limit. Fast TCP will bump into glass bandwith ceiling at mach 10, instead of 10 Mph, quicly recovering by resending the big chucks at a fraction of the window size previously sent. So it could also be described as willig to find the threashold quickly in echange for knowing the boundrys instead of wasting precious time ramping up. Traditional TCP hates data loss to the point that is "drives slow in a parking lot" attempting to never have a colision, whne the protocal itself is well designed to recover from such an event already.
If SCO sues Linus, then that would mean the offending code is kernel code. Linux only holds control over the kernel, and the central source repository. That at least narrows down the scope from anywhere in a Linux based distro, to some place insidce a Linux kernel, or kernel module. You can never unilaterally blaim all off linux for beign in violation. In reality it's only just a few lines of code from the source file(s). The industry would simply splice out the offending code with a replacment. So what SCO is apparently wantign to do is tell everyone to stop using linux , or be sued later, and not telling what part of linux is the offendign part. Revelinng the part of the offending code would remove the ability to sue everyone under the sun aspect of the law suit, which seems to be very lulkrative for SCO.
I just pulled down all the stuff for my apache2, and 2 days later it time to start all over again. yee-haw!
not a typo, and I pointed that out at the end with the amd64 comment.
It doesn't matter if SMTP is "intrinsically flawed" (which it isn't)
I duno what planet your from, and I doubt you've read the RFC's regarding SMTP on Earth... cuz the above statements clearly shows your ignorance in the SPAM issue. SMTP can be abused because it is flawed despite what you desire, or perceive, to be true. SMTP is wide open to Spam from an era of wide open, non-security minded protocol design.
In regards to your silly statement about SMTP not being flawed, security wise... I believe Mark Twain classifies you best: The whole world knows you're a fool, but when you open your mouth, you remove all doubt. Why do you think that the architects want to add extra headers to the standard, its not because they think SMTP is complete as is. Gosh dude... think about it! Maybe if you keep telling yourself that SMTP is not flawed, it will fix itself? Perhaps you think that if you wish to the tooth fairy, that spam will go away?