Why would I want to carry around a device which would allow anyone in the world to call and bug me at any time?
In my case, it's because my employer pays me to.
Would I do so otherwise? Unlikely. Nobody I know needs to get in touch with me that badly. I've got an answering machine.
I did carry an unactivated cell phone in my glove compartment before I got this job, though. (You can still use an unactivated phone to make emergency calls).
I'm not too worried about the radiation but with the amount of heat this thing is giving off I think I have just fried a few gazillion sperm.
No joke -- the ideal temperature for sperm is actually several degrees cooler then the 98.6 F that most of the body runs at. That's why the testicles are swinging in the breeze, instead of tucked inside the body for protection.
I've heard it told of a primitive tribe in Africa that employed a method of birth control where the males would soak their testicles in hot water for several minutes before engaging in sexual intercourse. No word on how well it worked.
I wonder if the heat effects on balls are more than just temporary.
As long as you're not actually burning yourself (and if you keep something that hot on your balls, you don't deserve to reproduce;), it should be. The testicles nominally keep producing sperm for as long as you're sexually capable. Only the female of the species has a limited number of genetic carriers. Fortunately, ovaries are better protected.
... wouldn't it be nice if opening a harddrive and by breaking the vacuum seal...
It is a common misconception that hard drives are vacuum sealed. In fact, Winchester-style disk drives use an air cushion to "float" the heads above the disk platters. They won't work in a vacuum. Furthermore, hard disk drives have filtered "breather holes" which connect the inside of the drive to the outside. They need to do this because as the spindle motor heats up, the air inside the chamber expands, and it needs a place to go.
... but you must realize that by opening a harddrive, you are ruining it anyway.
Not true. The danger is contamination -- i.e., dust. If even a tiny dust particle gets between the read/write head and the platter while it is spinning at 3600 RPM or faster, Bad Things Happen. If you use a clean-room environment, you can open up a hard drive -- and even run it with the cover off. Data recovery companies sometimes do this sort of thing.
Since this incident we have gone back to the traditional method of: 1) Place drive on bare concrete floor 2) Hit repeatedly with a 50# sledge (this is a BIG mofo) 3) Put your new extreme slimline drive in the trash.
Note that physical deformation may still leave recoverable magnetic signatures on the recording medium. There are companies who specialize in this sort of data recovery. I know of at least one case where a laptop (with hard drive) was run over by a truck, completely crushing it. The company was able to recover all most all of the data.
Yes, most any hard drive made past 1990 or so will have "spare sectors", which are used to replace sectors the drive detects are going bad. This is considered a problem for the DoD, which is why you are required to either (1) use drives certified not to do that or (2) physically destroy the drive before you can call it "clean".
The military actually uses these things. One of the neater James Bond devices I've seen is what appears (at first glance) to be two thick hanging file folders. One at the front of the drawer, one at the back. Then you notice the wires attached to them. They're shaped explosive charges, designed to completely destroy the contents of a file cabinate or safe quicky. For use in the event of "imminent compromise" of security by enemy forces.
Sun has been saying they'll Open Source Solaris, Java, StarOffice, the Human Genome, and the Secret to Life, the Universe, and Everything for years now. We've seen little to no actual materialization of these promises.
Forgive me for sounding skeptical, but I'm not going to believe this until I've got the source code on my hard drive, complete with GNU "COPYING" file, and had it compile successfully.
Personally (and here I'm in Armchair-Professor mode, so don't take this too seriously), I see two (related) reasons why imperative languages get more use then functional ones:
1. Imperative languages more closely model the way the computer works.
2. Imperative languages more closely model the way most people think about doing things.
When people write instructions for something, they generally use an imperative, procedural format. "To build a car, follow these steps." They break things down into subroutines, and call them as needed. "For step #105, you need a door. To build a door, follow these steps."
Perhaps this is cultural, perhaps it is biological, perhaps it just depends on the person. But it does seem to be the way it is. Thinking in the imperative style is just easier for most people, and like water, people follow the path of least resistance. After that starts, network effects only reinforce things.
But the courts may not see it that way. The First Amendment doesn't apply terribly much these days.
Oh, get a grip. To quote: "Congress shall make no law... abridging the freedom of speech..."
No where in there does it say "Everyone has the right to say whatever they want, whenever they want, about whatever they want."
People seem to think that the First Amendment to the Constitution of the USA grants protection to all forms of speech. In reality, all it does is keep Congress from passing laws restricting speech. There's a world of difference there.
(Note: I happen to think YesMail's case doesn't have a leg to stand on, but that isn't because of the First Amendment.)
No, RedHat (the 'R' in RPM) 'invented' RPMs to close the gap until InstallShield Corporation or someone else came up with a solution that worked in the *nix kernels of various flavors.
Where did you get THAT from?
RPM was created to install, remove, upgrade, verify, and build software packages. Even RPP (Red Hat's first attempt at a package manager) could track what was installed.
InstallShield(TM) isn't anything like RPM. It doesn't use a standard package format, it doesn't keep track of what has been installed, it requires a executable be built for each package, and that executable and its user interface is intimately part of the package.
You're so far off base people are wondering why you left the ballpark.
Thereafter, it was assumed the user would use 'gzip,' 'bz2,' or 'tar.(gz),' to uncompress the package/product and 'make' to install it.
Huh? If that was the case, they'd just dump it in using tarballs, like Slackware does (used to?).
RPMs... -seriously- mess up the target OS (unless it is _precisely_ the OS the RPM binary was compiled on)...
The only time I've seen this is when the packages in question were distribution-specific things, like the initscripts package, for example. If you have something else you're talking about, I would like to here about it...?
... strew ungodly amounts of crap throughout the file system.
First of all, it is the packager who decides where to put things, regardless of package format. Everything down to "make install" works the same way. If you don't like where the packager put things, edit the source to install where you want. Don't blame RPM.
Second, I've found most of Red Hat's RPMs adhere to the Linux File System Hierarchy Standard rather strictly.
So, again, just what is your basis for this assertion?
The _best_ thing about the Open Source movement is the ability for _everyone_ to become a developer...
I really think there is no single "best" thing about Open Source. But, either way, 99% of the people in the world have absolutely zero interest in becoming a developer.
Now there is a non-free compiler/tool/libs that threatens to take that essential paradigm away.
Um, hello? Most software already is closed-source, non-free, locked-up-tighter-then-a-drum code. It hasn't threatened Linux yet, and I don't think it will start now. Nobody's forcing you to use anyone else's commercial compiler. If someone produces a product using a commercial compiler, and you don't like -- don't use it. This isn't that hard to figure out.
... the practical use of Kylix could be limited to in-house projects in shops that need the cross-platform compatibility or the utility of Borland's otherwise excellent optimizing compilers and customer service/community.
I think the practical use of Kylix will be to whoever wants to code in it. Be it big corporations, small businesses, or Joe Hacker. Be it custom middleware, general applications, or system code. If someone wants to use it, they will. Otherwise, they won't.
Again: Nobody is holding a gun to your head, forcing you to use Borland's (or anyone else's) products.
At the very least, sysadmins, techs, and managers of Linux and *BSD shops should _carefully_ examine the products they install for GPL-flavored libraries and modules...
You should always carefully examine the products you install, period. Be they commercial or free, closed or open. Interestingly enough, many people in the BSD camp consider "GPL-flavored" code something to avoid, because they don't like the restrictions on closed-source use. Likewise, there are those who think the BSDL's more lax attitude gives up too many protections.
Open Source doesn't make the need for software evaluation go away.
... and watch out for the inclusion of proprietary code such as what Borland will offer, lest they get too far down a one-way highway.
This, at least, is good advice.
I really wish Borland/Inpise had donated a tool the whole community could use.
And I wish there was World Peace. But I don't think either is going to happen. Borland's in the business to make money selling their software; that is their right. They have to make their business sink or swim using their chosen strategy. If their choices aren't compatible with the Linux community, they'll either change them or leave the market.
SKU = Stock Keeping Unit, I think. It's that barcoded number you see on everything.
SKU does stand for Stock Keeping Unit, but the barcode you see on "everything", i.e., most consumer products, are encoded UPCs, or Universal Product Codes. UPCs are "standard", where as SKUs are usually specific to the manufacturer or retailer you're talking to.
'Tis also worth pointing out that both UPCs and SKUs are the numbers themselves, not the barcodes used to encode them.
Totally off-topic at this point, but I just wanted to take the time (and bandwidth) to commend rodgerd for his apology. Most people, it seems, these days, when caught in the wrong, either ignore it or deny it outright. It takes guts to admit a mistake.
It makes the problem look like AMD's fault, aside from a very few quotes from the Gateway reps.
Now you've moved off Slashdot completely. I suppose C|Net's editiorial content is Slashdot's fault, too, right?
FWIW, I really don't see the C|Net article as biased, either. You might get that impression if you didn't read the whole article, but then, you said you did do that. The only distinguishing factor known at this point is that all the systems use AMD's Thunderbird chipset. That's reasonable information to put near the top of the story. And C|Net does state, early on, that "the chip itself is not the likely cause". Perhaps their one-line teaser under the headline should have stated this explicitly, but I wouldn't rake them over the coals for what, in the end, is the reader's fault for making assumptions.
Anyone simply browsing for news would come away with impression that AMD's 1Ghz processors sucks.
You cannot blame the journalists for the fact that people who aren't looking for the whole story don't get the whole story.
Since you're so smart, how would you phrase the headline? Remember, the new chip is the distinguishing characteristic, so you have to include that fact. And I'm not going to read anything but the headline, as that would apparently be too much to ask.
Man, comments from people who read too much into headlines being moderated up to 4, and then this crap.
Topic, anyone?
Yes, IP banning isn't perfect because some people can change IPs easily (e.g., dialup modem pools) while others may get stuck with a bad rap (proxy servers, anyone who happens to dial-in and get someone's previous IP, etc.).
Life's not perfect, either. Get over it.
ObTopic: I am planning on buying a new motherboard+CPU soon, and am strongly considering an AMD Athlon- or Thunderbird-based system. Anyone have any comments on how well such systems work with VMware? I know VMware dislikes my current 400 MHz AMD K6-2.
No, I just read the headline. It says "Gateway Says Bug Affects 1GHz Thunderbird Systems".
Which is completely, one-hundred percent correct and true.
This is like saying "Ford says Bug Affects 350 HP Engines".
No, because unlike Gateway, Ford makes all the engines that go in their cars. Or at least, brands them that way.
But, just for the sake of argument, say Ford didn't make their own engines. And say Ford had a problem with one trim line using the new Acme ICE350 engine, that did not effect other brands of engine. The headling "Ford Discovers Problem With ICE350 Mustangs" seems pretty reasonable to me.
Its misleading.
Headlines, by definition, are short, one-line descriptions of a larger story. They will never hold the whole story. If you depend on them for such, you will be burned. And it looks like you were. Again, not Slashdot's fault.
What the headlines is implying is that Thunderbirds have a fundamental bug...
I certainly didn't see that implication. Again, no one else is responsible if you read meaning where there isn't any. Next time, read the story before you start adding meaning to the headline.
The commentary by timothy reads like an astroturf advertisment for Intel.
*exasperated sigh*
Doesn't anyone know the difference between quoted and unquoted text?
timothy:According to the article, the "chip itself is not the likely cause. Instead, the flaw probably results from the overall design of the system or other components." Sounds more like a kink like a showstopper, but a disappointment for anyone in line for a Thunderbird.
timothy states three things: 1. Article says the problem is not with the chip. 2. Problem is minor, not a show-stopper. 3. Disappointment for anyone waiting for systems with the chip.
#1 and #2 seem pretty much in favor of AMD. Number three seems pretty neutral to me, too. This would be a disappointment to anyone waiting for one of the systems, as they would now have to wait longer.
Now, yes, krautt's comment seems rather biased, or at least jumps to conclusions, but everyone's entitled to their opinions.
The accompanying software is guaranteed to operate in exact accordance with the source code provided, under condition that it is compiled using an error-free compiler and executed on error-free hardware.
Because multiple TCP connections do not share congestion information, it is possible for a greedy user to get more than his "fair share" of a pipe by using many parallel connections.
And any number of additional protocols, be they layered on top of IP (like TCP is) or TCP (like BXXP is) will not solve this problem.
Each TCP socket takes up system (kernel) resources on the server.
One way or the other, multiple connections are going to use more resources. 'Tis inescapable.
Where those resources are allocated is entirely implementation dependent, and indeed, only makes sense in terms of specific implementations. Look at an MS-DOS system, where there is no kernel, or something like khttpd, which implements HTTP inside the Linux kernel.
Layering additional protocols on top of existing protocols which do the same thing because some number of existing implementations don't handle resource allocation well is highly bogus.
... a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself...
The thing is, any time you flood a system with more connections then it can support (whether those connections are at the TCP level or something higher), it is going to suck mud. BXXP isn't going to change that fact; it is simply going to relocate it. See above about bogus.
Personally, BXXP looks to me to be redundant and needlessly repetitive. The core is basically TCP running on TCP, and then there is some higher level stuff that doesn't belong in channel-level code to begin with. It would be better to design some standard wrapper protocol to layer on a TCP connection to describe arbitrary data, thus providing something new without reinventing the wheel while we're at it.
Geez, your answer to practically everything is "That's just syntactic sugar; it doesn't really add anything".
Hey, buddy, here's a news flash -- any above the level of raw machine code is syntactic sugar. After all, all you're doing is making things require more symbols then they really do.
The point is, human beings like sugar, both syntactic and otherwise, and generally do better if they have some in their diet.
Slashdot Mirror
Why would I want to carry around a device which would allow anyone in the world to call and bug me at any time?
In my case, it's because my employer pays me to.
Would I do so otherwise? Unlikely. Nobody I know needs to get in touch with me that badly. I've got an answering machine.
I did carry an unactivated cell phone in my glove compartment before I got this job, though. (You can still use an unactivated phone to make emergency calls).
I'm not too worried about the radiation but with the amount of heat this thing is giving off I think I have just fried a few gazillion sperm.
;), it should be. The testicles nominally keep producing sperm for as long as you're sexually capable. Only the female of the species has a limited number of genetic carriers. Fortunately, ovaries are better protected.
No joke -- the ideal temperature for sperm is actually several degrees cooler then the 98.6 F that most of the body runs at. That's why the testicles are swinging in the breeze, instead of tucked inside the body for protection.
I've heard it told of a primitive tribe in Africa that employed a method of birth control where the males would soak their testicles in hot water for several minutes before engaging in sexual intercourse. No word on how well it worked.
I wonder if the heat effects on balls are more than just temporary.
As long as you're not actually burning yourself (and if you keep something that hot on your balls, you don't deserve to reproduce
... wouldn't it be nice if opening a harddrive and by breaking the vacuum seal ...
... but you must realize that by opening a harddrive, you are ruining it anyway.
It is a common misconception that hard drives are vacuum sealed. In fact, Winchester-style disk drives use an air cushion to "float" the heads above the disk platters. They won't work in a vacuum. Furthermore, hard disk drives have filtered "breather holes" which connect the inside of the drive to the outside. They need to do this because as the spindle motor heats up, the air inside the chamber expands, and it needs a place to go.
Not true. The danger is contamination -- i.e., dust. If even a tiny dust particle gets between the read/write head and the platter while it is spinning at 3600 RPM or faster, Bad Things Happen. If you use a clean-room environment, you can open up a hard drive -- and even run it with the cover off. Data recovery companies sometimes do this sort of thing.
Since this incident we have gone back to the traditional method of: 1) Place drive on bare concrete floor 2) Hit repeatedly with a 50# sledge (this is a BIG mofo) 3) Put your new extreme slimline drive in the trash.
Note that physical deformation may still leave recoverable magnetic signatures on the recording medium. There are companies who specialize in this sort of data recovery. I know of at least one case where a laptop (with hard drive) was run over by a truck, completely crushing it. The company was able to recover all most all of the data.
Anyone know any more about this?
Yes, most any hard drive made past 1990 or so will have "spare sectors", which are used to replace sectors the drive detects are going bad. This is considered a problem for the DoD, which is why you are required to either (1) use drives certified not to do that or (2) physically destroy the drive before you can call it "clean".
The military actually uses these things. One of the neater James Bond devices I've seen is what appears (at first glance) to be two thick hanging file folders. One at the front of the drawer, one at the back. Then you notice the wires attached to them. They're shaped explosive charges, designed to completely destroy the contents of a file cabinate or safe quicky. For use in the event of "imminent compromise" of security by enemy forces.
Sun has been saying they'll Open Source Solaris, Java, StarOffice, the Human Genome, and the Secret to Life, the Universe, and Everything for years now. We've seen little to no actual materialization of these promises.
Forgive me for sounding skeptical, but I'm not going to believe this until I've got the source code on my hard drive, complete with GNU "COPYING" file, and had it compile successfully.
Personally (and here I'm in Armchair-Professor mode, so don't take this too seriously), I see two (related) reasons why imperative languages get more use then functional ones:
1. Imperative languages more closely model the way the computer works.
2. Imperative languages more closely model the way most people think about doing things.
When people write instructions for something, they generally use an imperative, procedural format. "To build a car, follow these steps." They break things down into subroutines, and call them as needed. "For step #105, you need a door. To build a door, follow these steps."
Perhaps this is cultural, perhaps it is biological, perhaps it just depends on the person. But it does seem to be the way it is. Thinking in the imperative style is just easier for most people, and like water, people follow the path of least resistance. After that starts, network effects only reinforce things.
But the courts may not see it that way. The First Amendment doesn't apply terribly much these days.
... abridging the freedom of speech ..."
Oh, get a grip. To quote: "Congress shall make no law
No where in there does it say "Everyone has the right to say whatever they want, whenever they want, about whatever they want."
People seem to think that the First Amendment to the Constitution of the USA grants protection to all forms of speech. In reality, all it does is keep Congress from passing laws restricting speech. There's a world of difference there.
(Note: I happen to think YesMail's case doesn't have a leg to stand on, but that isn't because of the First Amendment.)
No, RedHat (the 'R' in RPM) 'invented' RPMs to close the gap until InstallShield Corporation or someone else came up with a solution that worked in the *nix kernels of various flavors.
... -seriously- mess up the target OS (unless it is _precisely_ the OS the RPM binary was compiled on) ...
... strew ungodly amounts of crap throughout the file system.
...
... the practical use of Kylix could be limited to in-house projects in shops that need the cross-platform compatibility or the utility of Borland's otherwise excellent optimizing compilers and customer service/community.
...
... and watch out for the inclusion of proprietary code such as what Borland will offer, lest they get too far down a one-way highway.
Where did you get THAT from?
RPM was created to install, remove, upgrade, verify, and build software packages. Even RPP (Red Hat's first attempt at a package manager) could track what was installed.
InstallShield(TM) isn't anything like RPM. It doesn't use a standard package format, it doesn't keep track of what has been installed, it requires a executable be built for each package, and that executable and its user interface is intimately part of the package.
You're so far off base people are wondering why you left the ballpark.
Thereafter, it was assumed the user would use 'gzip,' 'bz2,' or 'tar.(gz),' to uncompress the package/product and 'make' to install it.
Huh? If that was the case, they'd just dump it in using tarballs, like Slackware does (used to?).
RPMs
The only time I've seen this is when the packages in question were distribution-specific things,
like the initscripts package, for example. If you have something else you're talking about, I would like to here about it...?
First of all, it is the packager who decides where to put things, regardless of package format. Everything down to "make install" works the same way. If you don't like where the packager put things, edit the source to install where you want. Don't blame RPM.
Second, I've found most of Red Hat's RPMs adhere to the Linux File System Hierarchy Standard rather strictly.
So, again, just what is your basis for this assertion?
The _best_ thing about the Open Source movement is the ability for _everyone_ to become a developer
I really think there is no single "best" thing about Open Source. But, either way, 99% of the people in the world have absolutely zero interest in becoming a developer.
Now there is a non-free compiler/tool/libs that threatens to take that essential paradigm away.
Um, hello? Most software already is closed-source, non-free, locked-up-tighter-then-a-drum code. It hasn't threatened Linux yet, and I don't think it will start now. Nobody's forcing you to use anyone else's commercial compiler. If someone produces a product using a commercial compiler, and you don't like -- don't use it. This isn't that hard to figure out.
I think the practical use of Kylix will be to whoever wants to code in it. Be it big corporations, small businesses, or Joe Hacker. Be it custom middleware, general applications, or system code. If someone wants to use it, they will. Otherwise, they won't.
Again: Nobody is holding a gun to your head, forcing you to use Borland's (or anyone else's) products.
At the very least, sysadmins, techs, and managers of Linux and *BSD shops should _carefully_ examine the products they install for GPL-flavored libraries and modules
You should always carefully examine the products you install, period. Be they commercial or free, closed or open. Interestingly enough, many people in the BSD camp consider "GPL-flavored" code something to avoid, because they don't like the restrictions on closed-source use. Likewise, there are those who think the BSDL's more lax attitude gives up too many protections.
Open Source doesn't make the need for software evaluation go away.
This, at least, is good advice.
I really wish Borland/Inpise had donated a tool the whole community could use.
And I wish there was World Peace. But I don't think either is going to happen. Borland's in the business to make money selling their software; that is their right. They have to make their business sink or swim using their chosen strategy. If their choices aren't compatible with the Linux community, they'll either change them or leave the market.
I seen no problem with that.
SKU = Stock Keeping Unit, I think. It's that barcoded number you see on everything.
SKU does stand for Stock Keeping Unit, but the barcode you see on "everything", i.e., most consumer products, are encoded UPCs, or Universal Product Codes. UPCs are "standard", where as SKUs are usually specific to the manufacturer or retailer you're talking to.
'Tis also worth pointing out that both UPCs and SKUs are the numbers themselves, not the barcodes used to encode them.
My bad - sorry timothy.
Totally off-topic at this point, but I just wanted to take the time (and bandwidth) to commend rodgerd for his apology. Most people, it seems, these days, when caught in the wrong, either ignore it or deny it outright. It takes guts to admit a mistake.
My hat comes off for you, Sir.
[T]he slashdot headline implies that amd is guilty of faulty quality assurance testing, thus saying that the problem is with the cpu.
I see no such statement in the Slashdot headline.
True, the reader's comment out-right says AMD is guilty of that problem, but again: Everyone's entitled to their opinions.
It makes the problem look like AMD's fault, aside from a very few quotes from the Gateway reps.
Now you've moved off Slashdot completely. I suppose C|Net's editiorial content is Slashdot's fault, too, right?
FWIW, I really don't see the C|Net article as biased, either. You might get that impression if you didn't read the whole article, but then, you said you did do that. The only distinguishing factor known at this point is that all the systems use AMD's Thunderbird chipset. That's reasonable information to put near the top of the story. And C|Net does state, early on, that "the chip itself is not the likely cause". Perhaps their one-line teaser under the headline should have stated this explicitly, but I wouldn't rake them over the coals for what, in the end, is the reader's fault for making assumptions.
Anyone simply browsing for news would come away with impression that AMD's 1Ghz processors sucks.
You cannot blame the journalists for the fact that people who aren't looking for the whole story don't get the whole story.
Since you're so smart, how would you phrase the headline? Remember, the new chip is the distinguishing characteristic, so you have to include that fact. And I'm not going to read anything but the headline, as that would apparently be too much to ask.
Man, comments from people who read too much into headlines being moderated up to 4, and then this crap.
Topic, anyone?
Yes, IP banning isn't perfect because some people can change IPs easily (e.g., dialup modem pools) while others may get stuck with a bad rap (proxy servers, anyone who happens to dial-in and get someone's previous IP, etc.).
Life's not perfect, either. Get over it.
ObTopic: I am planning on buying a new motherboard+CPU soon, and am strongly considering an AMD Athlon- or Thunderbird-based system. Anyone have any comments on how well such systems work with VMware? I know VMware dislikes my current 400 MHz AMD K6-2.
No, I just read the headline. It says "Gateway Says Bug Affects 1GHz Thunderbird Systems".
...
Which is completely, one-hundred percent correct and true.
This is like saying "Ford says Bug Affects 350 HP Engines".
No, because unlike Gateway, Ford makes all the engines that go in their cars. Or at least, brands them that way.
But, just for the sake of argument, say Ford didn't make their own engines. And say Ford had a problem with one trim line using the new Acme ICE350 engine, that did not effect other brands of engine. The headling "Ford Discovers Problem With ICE350 Mustangs" seems pretty reasonable to me.
Its misleading.
Headlines, by definition, are short, one-line descriptions of a larger story. They will never hold the whole story. If you depend on them for such, you will be burned. And it looks like you were. Again, not Slashdot's fault.
What the headlines is implying is that Thunderbirds have a fundamental bug
I certainly didn't see that implication. Again, no one else is responsible if you read meaning where there isn't any. Next time, read the story before you start adding meaning to the headline.
It'll be a scary day if CPU manufacturers start taking a 'release early, release often' approach.
;-)
On the other hand, such approaches generally go hand-in-hand with putting the new releases in the end-user's hands cheaply or for free.
AMD can release a new CPU every day, if they also send me one for free to replace yesterday's! I'll even send them the old one back!
If you want to get technical....
[Variations on the headline deleted]
So, what you're saying is, you read too much into the headline and assumed it was a problem with AMD's chip?
It's not Slashdot's fault you jump to conclusions.
The commentary by timothy reads like an astroturf advertisment for Intel.
*exasperated sigh*
Doesn't anyone know the difference between quoted and unquoted text?
timothy: According to the article, the "chip itself is not the likely cause. Instead, the flaw probably results from the overall design of the system or other components." Sounds more like a kink like a showstopper, but a disappointment for anyone in line for a Thunderbird.
timothy states three things:
1. Article says the problem is not with the chip.
2. Problem is minor, not a show-stopper.
3. Disappointment for anyone waiting for systems with the chip.
#1 and #2 seem pretty much in favor of AMD. Number three seems pretty neutral to me, too. This would be a disappointment to anyone waiting for one of the systems, as they would now have to wait longer.
Now, yes, krautt's comment seems rather biased, or at least jumps to conclusions, but everyone's entitled to their opinions.
Read the headline - oh no! Athlons have a bug! I knew it!
Read it again:
Gateway Says Bug Affects 1GHz Thunderbird Systems
Read the story, and Gateway has discovered a problem in their 1GHz Thunderbird systems.
Let's see.
Gateway Says. Yup.
Bug Affects. Yup.
1GHz Thunderbird Systems. Yup.
Perhaps hype, like beauty, is in the eye of the beholder.
The accompanying software is guaranteed to operate in exact accordance with the source code provided, under condition that it is compiled using an error-free compiler and executed on error-free hardware.
What about undefined constructs in the language?
;-)
Why multiple connections are a bad idea ...
... a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself ...
Because multiple TCP connections do not share congestion information, it is possible for a greedy user to get more than his "fair share" of a pipe by using many parallel connections.
And any number of additional protocols, be they layered on top of IP (like TCP is) or TCP (like BXXP is) will not solve this problem.
Each TCP socket takes up system (kernel) resources on the server.
One way or the other, multiple connections are going to use more resources. 'Tis inescapable.
Where those resources are allocated is entirely implementation dependent, and indeed, only makes sense in terms of specific implementations. Look at an MS-DOS system, where there is no kernel, or something like khttpd, which implements HTTP inside the Linux kernel.
Layering additional protocols on top of existing protocols which do the same thing because some number of existing implementations don't handle resource allocation well is highly bogus.
The thing is, any time you flood a system with more connections then it can support (whether those connections are at the TCP level or something higher), it is going to suck mud. BXXP isn't going to change that fact; it is simply going to relocate it. See above about bogus.
Personally, BXXP looks to me to be redundant and needlessly repetitive. The core is basically TCP running on TCP, and then there is some higher level stuff that doesn't belong in channel-level code to begin with. It would be better to design some standard wrapper protocol to layer on a TCP connection to describe arbitrary data, thus providing something new without reinventing the wheel while we're at it.
Geez, your answer to practically everything is "That's just syntactic sugar; it doesn't really add anything".
Hey, buddy, here's a news flash -- any above the level of raw machine code is syntactic sugar. After all, all you're doing is making things require more symbols then they really do.
The point is, human beings like sugar, both syntactic and otherwise, and generally do better if they have some in their diet.
Isn't that supposed to be the "Human Gnome Project"?
So what's KDE? The "Klingon Decoding Endeavor"?
;-)
They say a man doesn't know true happiness until he is married...
... and then it's too late!
;-)
Congrats to the happy couple!