This guy's actually not as on-crack as a lot of folks may think. Squeak has no real opportunity to become a pleasant desktop environment or applications framework right now, since it looks and feels very different from everything else and can't (to my knowledge) run rootless.
HOWEVER - these are things that could be remedied.
The people who get twitchy at the prospect of a virtual machine should try Smalltalk on a 16mhz Palm. One of the main reasons for the slowness in Swing, for example, is that they're taking the MVC paradigm -- which was easy and lightweight in the Smalltalk paradigm -- and cruft it onto Java's statically-typed, heavier model.
I'm hoping that systems like Smalltalk and Self get more attention for desktop development in coming years, now that they're finally seeing a degree of revival for web apps.
You're probably trolling, but my radar is off today.
Considering that, to date, the BSD license is the only one of the two that has been tested in a court of law, I don't really understand your point.
(I'm referring to the AT&T/USL code settlement of the 90s.)
I suspect this guy's entire problem is that he's using the old advertising-clause BSD license, and Codease probably assumed when he said 'BSD' he meant 'modern BSD.' Were it a modern BSD license, they could use his code without attribution.
Since they've since started to acquiesce to his demands, I suspect they may have finally read his license and realized their mistake.
I'm only replying lest the parent might be modded up.
As a professional Java developer who works primarily in Eclipse, Java is not your problem here.
Are you using a legacy app based around AWT? Then your GUI will most likely be annoyingly limited (with a couple of exceptions on MacOS X).
Are you using a GUI app using the Swing toolkit? Okay, yes, that's going to be slow -- I'll give you that. But that's similar to saying "Linux is ugly! Just look at (GTK|Qt|Tk|whatever)!"
Seriously, I'm tired of reading this drech on Slashdot. A properly-implemented Swing is reasonably fast (see MacOS X for an example), but unfortunately the Windows implementation isn't one. Before slamming the language, however, try changing toolkits -- I recommend SWT, as used in Eclipse.
3dNow!, while possibly one of the silliest names for an instruction set extension, is not just a rip of MMX.
3dNow! was the first x86 floating-point vector extension. In that respect, it's far more similar to Altivec. 3dNow! DSP (of Athlon fame) is also not a rip of Intel.
Intel later decided to add their own floating-point VMX, namely SSE, on (iirc) the PIII.
SSE only became available in AMD-land on the AthlonXP, and SSE2 is only available (to my knowledge) on the Opteron-class chips. Those of us doing vector optimization on x86 would love it if these four instruction sets were compatible, but they're not.
From my reading of the article, this sounds like it's just a new spin on the per-page eXec flag on the AMD64 architecture.
Granted, yes, this is a good thing, but "buffer-overflow protection when used with a new version of Windows XP?" We now have to rely on Microsoft to set the X flag properly...
This has been talked about on Slashdot a lot in the past; the OpenBSD guys in particular are hot on the Opteron because it, like SPARC, provides this protection. Fortunately, this isn't some Windows-specific voodoo; we all stand to benefit from this fundamental fix to the broken Intel VM architecture.:-)
You might want to take a gander at FreeBSD 5's RCng (also available in NetBSD, and possibly OpenBSD).
It combines, in my opinion, the best of both worlds: 1. Full control over each service through scripts in/etc/rc.d. Want to restart your sshd?/etc/rc.d/sshd restart. Very similar to init.d. 2. Dependency-graphs determine service start order. Each file contains a special header declaring its dependencies and what it provides; the system analyzes these on boot, or when you request that a specific service be started, and handles the dependencies for you.
Mmm, tasty.
(And yes, this is quite similar to Gentoo's system, except that Gentoo translates the scripts into actual runlevels behind the scenes, whereas the BSDs do not. That, and this doesn't use python.)
"Why are you using Firewire for networking? Buy a hub!"
A couple of points. 1. A lot of us have Firewire cables lying around but not hubs. Therefore, Firewire: $0. Switch: $25. 2. Firewire has the potential to be really fast. I know some of the third-party Firewire networking solutions for Mac used to sell well simply because they were 4x the speed of Ethernet -- which makes a big difference if you're transferring, say, massive TIFF proofs. (I personally have not gotten this working, see below.)
However: 1. It's a Mac. If you've got a free Ethernet port on another machine, you don't need a hub/switch. Macs detect crossover-vs.-normal UTP cables automatically. 2. Last I checked, the Firewire IP implementation in Panther wasn't terribly standard -- or, at least, I couldn't get any of my Linux or BSD boxes to recognize it. Might work with XP; should work with another Mac.
I already have a bulky device that can record audio, play all sorts of media files, and listen to the radio. I call it a "computer."
Seriously; I really like that the Neuros people roped some of the Vorbis developers into doing their Vorbis support, for one. I also really like the backpack idea. However, I currently carry my Rio Karma and an FM transmitter in a tiny fake-velvet bag that, even with cords and headphones, is smaller than a Neuros. (I'm judging based on the CompUSA display model with backpack; maybe there's a smaller one out there somewhere, but this thing's quite hefty.)
Granted, with that setup, I can't record manufactured trash from the radio.:-)
Anyway, end radio rant...my point here is similar to something the Palm people figured out years ago. If something's small enough, you'll unconsciously integrate it into your life. I've quit using my laptop for music when I go places; the Karma's simply easier. I wouldn't be able to do that with a player that can't fit in my shirt pocket, I don't think.
Chances are pretty good that you interact with 31-bit machines every day -- namely, older (pre-64-bit) IBM mainframes. Even the new zSeries machines frequently run apps in 31-bit mode for compatibility with older systems.
Using a couple of bits in an integer for data type is usually (in my experience) called 'tagged data.' I use it in Smalltalk VMs as an optimization -- the "objects" representing Integers are really just 31-bit integers with an extra zero-bit stuck on the LSB. (Object pointers have an LSB of 1, so you mask that to zero before using them and keep everything 16-bit aligned.)
Essentially what you wind up with there is a tradeoff: you can perform simple arithmetic and logic on the Integer "references" without actually having to allocate an object to hold an Integer, but you lose a bit of dynamic range. In my experience, it's an acceptable tradeoff, and it lets you have all the advantages of a true OO system without the performance penalty of having to use an object for, say, every loop variable.
So there's an example of why you do that. The aforementioned Smalltalk systems wouldn't be vulnerable to this date issue, however, as their integers will automatically convert themselves to arbitrary-precision numeric types as needed.
The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.
Not for me. Works just great. Actually works a bit too well, since a few of my mailboxes have 6000+ messages in them and the server is an old mbox UW-IMAP machine. The sysadmin has actually asked that I set the automatic check interval higher. Apparently I'm responsible for their load peaks.
Anyway. Here's me: --UW-IMAP of some unknown but archaic and annoying version. --10.3.1 (now.2) running Mail.app
I haven't seen data on the mass of the reactor vs. the mass of the ship, but if it's a reasonable proportion of the overall mass...
If those thruster pods have side-facing thrusters (which they must, though on first glance they look rear-facing) they might simply be using leverage to turn the craft around a point on the mast, toward the reactor.
> IBM is on the side of the GPL because they don't have much of a choice : they don't really have an OS of their own
Wow.:-) Your second reason, about IBM having already invested millions, is valid. But this is pure lunacy. I guess the zSeries was developed with....Linux in mind?
> Computers can't be creative, > at least not in the way humans _can_ be.
Oh, poppycock.
We humans have a very nice, cushy, arrogant view of human creativity. I see it in movies, where the humans win over the 'calculating machines' by creativity or love or some hogwash like that. Scifi's traditionally very bad about this as well.
My degree is in psychology with a tendency toward physiology. The brain is a deterministic machine -- or at least, as deterministic as anything else. This hypothesis is as strong as nearly anything else in science: it fits the data well, and has yet to be proven false.
A statement like "computers can't be creative" has the assumption (correct me if I'm wrong) that a deterministic, calculating, "pure-logic" machine like a computer isn't capable of producing the same level of creative work as a human. I would argue that a human is just as deterministic as a computer, though the calculation and logic functions in a very different fashion.
I say the problem is in the algorithms. I've seen properly trained computers draw brand new Picassos and compose fugues as good as anything from Bach. "Oh," the critics would say, "they're just taking the input data and modifying it and reproducing it."
Yes. Yes they are. And so are you. That's why we have a concept of 'inspiration.' Of 'derivative works.' That's why each song that's written, each house that's designed, isn't a completely new, off-the-wall creation. That's why we can categorize things into 'styles' and 'genres.'
A properly trained (read: programmed) computer could generate levels for your-game-of-choice that would be on par with a human designer. And chances are good the computer would take some directions that the human wouldn't have thought of.
By contrast, I doubt Bob off the street would design a very interesting level for Counterstrike. It's all in the input and training.
Yes, he probably -did- watch the Matrix, and that may be why he's concerned.
The science in the Matrix is, well, not there. From 'humans combined with a form of fusion' to people who should by all means be horribly atrophied running around and learning kung fu, it's just not a believable work of science.
It -is-, however, a good movie -- but it's a fantasy movie.
If you use same-size subnets in both cases, there's no difference between the 10-net and the 192-net.
If you're using 10/8 vs. 192/24, and have enough computers to justify that, you'll want to break it up into subnets to limit the size of your broadcast domains.
Well, without providing too much information (it's less than seven years ago and IANAL), I've done this, and it works.
During my stay at [MAJOR UNIVERSITY] the computer labs were being swept by the Concept virus. This, for those who missed it, was one of the first Word Macro viruses; this particular variant would open an IRC server and allow access to local files. The virus was getting out of the labs and onto dorm machines, which were given routable public addresses. I notified the IT department to no avail -- they insisted they didn't have any viruses because [ANTIVIRUS SOFTWARE] was kept up to date.
Concept and friends were stupid. They would check a machine for infection before attempting to infect, by searching for a particular string among the system macro sources. I was working through school as a VB programmer (yeah, yeah, I know) and knocked out a concept-derived macro that: 1. Infected a machine. 2. Removed all Concept source code. 3. Left a signature in place that prevented Concept from re-infecting. 4. After a few weeks, erased itself, leaving the signature in place.
The labs were poorly-configured Windows workstations, and both Concept and my antibody could jump between users if they logged in successively. Within a few days I couldn't find any sign of either virus, except the signature.
So this process can work, but is still probably illegal. One also has to be very careful that their 'benign' virus/worm doesn't get out of hand -- people forget that resources like network bandwidth and CPU time are frequently as important as any data that might be lost.
The center frequencies to which our green and blue cones are sensitive are rather far apart, spectrally -- at least, compared to the G/R cones. Looks like the E sensor on this CCD is between the G/B cones.
(RGB sensors and emitters are generally calibrated to the center frequencies of our cones.)
This is a good idea that I'd never considered. More color information is always good, and we can always just define a transform to reduce it to human optics. If nothing else, this makes more data available for image correction and whatnot. I wonder if you can actually get the RGBE data out of the camera, or if it stores three-channel JPEGs like everyone else?
> I'm assuming that sound cards use a decent amount of > bandwidth...
You're actually assuming more than that.
A channel of CD audio takes ~1.4Mbps. (44100 samples per second, two channels per sample, 16 bits per channel.) So full duplex stereo CD-quality audio takes 2.8Mbps. Let's say we're hardcore audiophiles and want full-duplex 96kHz stereo audio: 6.1Mbps.
And yes, the bandwidth of the PCI bus is 133MBps or ~1064Mbps. So if you really need 98 channels of CD-quality audio, PCI's clearly the only way to go.
Now, there are of course issues with USB devices. The main one that comes to mind to me are lack of DMA and bus-mastering. A good PCI sound card can handle its own transfers in and out of RAM, preventing it from being buffer-starved (or at least making it more difficult). This isn't possible with USB (but -is- possible with Firewire, sort of).
You'll also wish to consider latency, but I suspect it'll be lower than your average high-quality software synth if they're using the USB isochronous channel.
I play both regularly on my iPaq (200mhz ARM). Using the libmad decoder for MP3 and Nicholas Pitre's integerized Ogg library (NOT tremor), I see about 10% utilization for MP3, and 8-10% for Ogg. (I say 8-10 as conservative padding. In practice, believe it or no, Vorbis always hangs lower.)
Keep in mind that the libvorbis libraries most folks use are a reference implementation. Once Vorbis is properly optimized, it's really quite light on the resources. These guys are probably using tremor, which I personally haven't tried, but I've heard people say it's even lighter than the Pitre decoder.
Wow, what sites have you written? Please send me a list, because I'd love to break into them.
If you're really storing all that information -- username, password, etc. -- in a cookie, you do realize that you're handing it to the user and saying "I trust you not to modify this."?
A more elegant mechanism in PHP is to hand the user a large session identifer and use either PHP's session mechanism or a database table to store the real information. This doesn't even require cookies -- though, as other posters have noted, avoiding cookies requires URL-rewriting, which can be a performance hit.
However, the availability of URL-rewriting demonstrates that cookies are primarily a convenience item for both the user and the programmer. If we get away from PHP for a moment (and please do), there are really nice facilities for this sort of thing in Servlets and J2EE.
Slashdot Mirror
Why leading companies (eg. Creative, Apple, etc.) consistently fail to support, or even downright ignore the Ogg format
Is Rio no longer a leading company?
Apologies, I've been out of the game for a while, but I've been really happy with my little Karma.
This guy's actually not as on-crack as a lot of folks may think. Squeak has no real opportunity to become a pleasant desktop environment or applications framework right now, since it looks and feels very different from everything else and can't (to my knowledge) run rootless.
HOWEVER - these are things that could be remedied.
The people who get twitchy at the prospect of a virtual machine should try Smalltalk on a 16mhz Palm. One of the main reasons for the slowness in Swing, for example, is that they're taking the MVC paradigm -- which was easy and lightweight in the Smalltalk paradigm -- and cruft it onto Java's statically-typed, heavier model.
I'm hoping that systems like Smalltalk and Self get more attention for desktop development in coming years, now that they're finally seeing a degree of revival for web apps.
Technically speaking, nothing's preventing you from doing that today.
You're probably trolling, but my radar is off today.
Considering that, to date, the BSD license is the only one of the two that has been tested in a court of law, I don't really understand your point.
(I'm referring to the AT&T/USL code settlement of the 90s.)
I suspect this guy's entire problem is that he's using the old advertising-clause BSD license, and Codease probably assumed when he said 'BSD' he meant 'modern BSD.' Were it a modern BSD license, they could use his code without attribution.
Since they've since started to acquiesce to his demands, I suspect they may have finally read his license and realized their mistake.
I'm only replying lest the parent might be modded up.
As a professional Java developer who works primarily in Eclipse, Java is not your problem here.
Are you using a legacy app based around AWT? Then your GUI will most likely be annoyingly limited (with a couple of exceptions on MacOS X).
Are you using a GUI app using the Swing toolkit? Okay, yes, that's going to be slow -- I'll give you that. But that's similar to saying "Linux is ugly! Just look at (GTK|Qt|Tk|whatever)!"
Seriously, I'm tired of reading this drech on Slashdot. A properly-implemented Swing is reasonably fast (see MacOS X for an example), but unfortunately the Windows implementation isn't one. Before slamming the language, however, try changing toolkits -- I recommend SWT, as used in Eclipse.
Alright, alright, alright.
3dNow!, while possibly one of the silliest names for an instruction set extension, is not just a rip of MMX.
3dNow! was the first x86 floating-point vector extension. In that respect, it's far more similar to Altivec. 3dNow! DSP (of Athlon fame) is also not a rip of Intel.
Intel later decided to add their own floating-point VMX, namely SSE, on (iirc) the PIII.
SSE only became available in AMD-land on the AthlonXP, and SSE2 is only available (to my knowledge) on the Opteron-class chips. Those of us doing vector optimization on x86 would love it if these four instruction sets were compatible, but they're not.
From my reading of the article, this sounds like it's just a new spin on the per-page eXec flag on the AMD64 architecture.
:-)
Granted, yes, this is a good thing, but "buffer-overflow protection when used with a new version of Windows XP?" We now have to rely on Microsoft to set the X flag properly...
This has been talked about on Slashdot a lot in the past; the OpenBSD guys in particular are hot on the Opteron because it, like SPARC, provides this protection. Fortunately, this isn't some Windows-specific voodoo; we all stand to benefit from this fundamental fix to the broken Intel VM architecture.
You might want to take a gander at FreeBSD 5's RCng (also available in NetBSD, and possibly OpenBSD).
/etc/rc.d. Want to restart your sshd? /etc/rc.d/sshd restart. Very similar to init.d.
It combines, in my opinion, the best of both worlds:
1. Full control over each service through scripts in
2. Dependency-graphs determine service start order. Each file contains a special header declaring its dependencies and what it provides; the system analyzes these on boot, or when you request that a specific service be started, and handles the dependencies for you.
Mmm, tasty.
(And yes, this is quite similar to Gentoo's system, except that Gentoo translates the scripts into actual runlevels behind the scenes, whereas the BSDs do not. That, and this doesn't use python.)
A lot of posts have been of the form:
"Why are you using Firewire for networking? Buy a hub!"
A couple of points.
1. A lot of us have Firewire cables lying around but not hubs. Therefore, Firewire: $0. Switch: $25.
2. Firewire has the potential to be really fast. I know some of the third-party Firewire networking solutions for Mac used to sell well simply because they were 4x the speed of Ethernet -- which makes a big difference if you're transferring, say, massive TIFF proofs. (I personally have not gotten this working, see below.)
However:
1. It's a Mac. If you've got a free Ethernet port on another machine, you don't need a hub/switch. Macs detect crossover-vs.-normal UTP cables automatically.
2. Last I checked, the Firewire IP implementation in Panther wasn't terribly standard -- or, at least, I couldn't get any of my Linux or BSD boxes to recognize it. Might work with XP; should work with another Mac.
I already have a bulky device that can record audio, play all sorts of media files, and listen to the radio. I call it a "computer."
Seriously; I really like that the Neuros people roped some of the Vorbis developers into doing their Vorbis support, for one. I also really like the backpack idea. However, I currently carry my Rio Karma and an FM transmitter in a tiny fake-velvet bag that, even with cords and headphones, is smaller than a Neuros. (I'm judging based on the CompUSA display model with backpack; maybe there's a smaller one out there somewhere, but this thing's quite hefty.)
Granted, with that setup, I can't record manufactured trash from the radio.
Anyway, end radio rant...my point here is similar to something the Palm people figured out years ago. If something's small enough, you'll unconsciously integrate it into your life. I've quit using my laptop for music when I go places; the Karma's simply easier. I wouldn't be able to do that with a player that can't fit in my shirt pocket, I don't think.
Chances are pretty good that you interact with 31-bit machines every day -- namely, older (pre-64-bit) IBM mainframes. Even the new zSeries machines frequently run apps in 31-bit mode for compatibility with older systems.
Using a couple of bits in an integer for data type is usually (in my experience) called 'tagged data.' I use it in Smalltalk VMs as an optimization -- the "objects" representing Integers are really just 31-bit integers with an extra zero-bit stuck on the LSB. (Object pointers have an LSB of 1, so you mask that to zero before using them and keep everything 16-bit aligned.)
Essentially what you wind up with there is a tradeoff: you can perform simple arithmetic and logic on the Integer "references" without actually having to allocate an object to hold an Integer, but you lose a bit of dynamic range. In my experience, it's an acceptable tradeoff, and it lets you have all the advantages of a true OO system without the performance penalty of having to use an object for, say, every loop variable.
So there's an example of why you do that. The aforementioned Smalltalk systems wouldn't be vulnerable to this date issue, however, as their integers will automatically convert themselves to arbitrary-precision numeric types as needed.
Okay, I read TFA. Wrong.
The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.
It's fun to bash SCO and all, but come on.
Uhrm...
.2) running Mail.app
Not for me. Works just great. Actually works a bit too well, since a few of my mailboxes have 6000+ messages in them and the server is an old mbox UW-IMAP machine. The sysadmin has actually asked that I set the automatic check interval higher. Apparently I'm responsible for their load peaks.
Anyway. Here's me:
--UW-IMAP of some unknown but archaic and annoying version.
--10.3.1 (now
I haven't seen data on the mass of the reactor vs. the mass of the ship, but if it's a reasonable proportion of the overall mass...
If those thruster pods have side-facing thrusters (which they must, though on first glance they look rear-facing) they might simply be using leverage to turn the craft around a point on the mast, toward the reactor.
This is, of course, completely out of my ass.
In the states, that'd be the Amateur Radio 2-meter band.
Wait. Can't Emacs do all of that yet? :-)
> IBM is on the side of the GPL because they don't have much of a choice : they don't really have an OS of their own
:-) Your second reason, about IBM having already invested millions, is valid. But this is pure lunacy. I guess the zSeries was developed with....Linux in mind?
Wow.
> Computers can't be creative,
> at least not in the way humans _can_ be.
Oh, poppycock.
We humans have a very nice, cushy, arrogant view of human creativity. I see it in movies, where the humans win over the 'calculating machines' by creativity or love or some hogwash like that. Scifi's traditionally very bad about this as well.
My degree is in psychology with a tendency toward physiology. The brain is a deterministic machine -- or at least, as deterministic as anything else. This hypothesis is as strong as nearly anything else in science: it fits the data well, and has yet to be proven false.
A statement like "computers can't be creative" has the assumption (correct me if I'm wrong) that a deterministic, calculating, "pure-logic" machine like a computer isn't capable of producing the same level of creative work as a human. I would argue that a human is just as deterministic as a computer, though the calculation and logic functions in a very different fashion.
I say the problem is in the algorithms. I've seen properly trained computers draw brand new Picassos and compose fugues as good as anything from Bach. "Oh," the critics would say, "they're just taking the input data and modifying it and reproducing it."
Yes. Yes they are. And so are you. That's why we have a concept of 'inspiration.' Of 'derivative works.' That's why each song that's written, each house that's designed, isn't a completely new, off-the-wall creation. That's why we can categorize things into 'styles' and 'genres.'
A properly trained (read: programmed) computer could generate levels for your-game-of-choice that would be on par with a human designer. And chances are good the computer would take some directions that the human wouldn't have thought of.
By contrast, I doubt Bob off the street would design a very interesting level for Counterstrike. It's all in the input and training.
Yes, he probably -did- watch the Matrix, and that may be why he's concerned.
The science in the Matrix is, well, not there. From 'humans combined with a form of fusion' to people who should by all means be horribly atrophied running around and learning kung fu, it's just not a believable work of science.
It -is-, however, a good movie -- but it's a fantasy movie.
If you use same-size subnets in both cases, there's no difference between the 10-net and the 192-net.
If you're using 10/8 vs. 192/24, and have enough computers to justify that, you'll want to break it up into subnets to limit the size of your broadcast domains.
Well, without providing too much information (it's less than seven years ago and IANAL), I've done this, and it works.
During my stay at [MAJOR UNIVERSITY] the computer labs were being swept by the Concept virus. This, for those who missed it, was one of the first Word Macro viruses; this particular variant would open an IRC server and allow access to local files. The virus was getting out of the labs and onto dorm machines, which were given routable public addresses. I notified the IT department to no avail -- they insisted they didn't have any viruses because [ANTIVIRUS SOFTWARE] was kept up to date.
Concept and friends were stupid. They would check a machine for infection before attempting to infect, by searching for a particular string among the system macro sources. I was working through school as a VB programmer (yeah, yeah, I know) and knocked out a concept-derived macro that:
1. Infected a machine.
2. Removed all Concept source code.
3. Left a signature in place that prevented Concept from re-infecting.
4. After a few weeks, erased itself, leaving the signature in place.
The labs were poorly-configured Windows workstations, and both Concept and my antibody could jump between users if they logged in successively. Within a few days I couldn't find any sign of either virus, except the signature.
So this process can work, but is still probably illegal. One also has to be very careful that their 'benign' virus/worm doesn't get out of hand -- people forget that resources like network bandwidth and CPU time are frequently as important as any data that might be lost.
The center frequencies to which our green and blue cones are sensitive are rather far apart, spectrally -- at least, compared to the G/R cones. Looks like the E sensor on this CCD is between the G/B cones.
(RGB sensors and emitters are generally calibrated to the center frequencies of our cones.)
This is a good idea that I'd never considered. More color information is always good, and we can always just define a transform to reduce it to human optics. If nothing else, this makes more data available for image correction and whatnot. I wonder if you can actually get the RGBE data out of the camera, or if it stores three-channel JPEGs like everyone else?
Well, in any case, tetrachromats rejoice.
> I'm assuming that sound cards use a decent amount of
> bandwidth...
You're actually assuming more than that.
A channel of CD audio takes ~1.4Mbps. (44100 samples per second, two channels per sample, 16 bits per channel.) So full duplex stereo CD-quality audio takes 2.8Mbps. Let's say we're hardcore audiophiles and want full-duplex 96kHz stereo audio: 6.1Mbps.
And yes, the bandwidth of the PCI bus is 133MBps or ~1064Mbps. So if you really need 98 channels of CD-quality audio, PCI's clearly the only way to go.
Now, there are of course issues with USB devices. The main one that comes to mind to me are lack of DMA and bus-mastering. A good PCI sound card can handle its own transfers in and out of RAM, preventing it from being buffer-starved (or at least making it more difficult). This isn't possible with USB (but -is- possible with Firewire, sort of).
You'll also wish to consider latency, but I suspect it'll be lower than your average high-quality software synth if they're using the USB isochronous channel.
In a word, no.
I play both regularly on my iPaq (200mhz ARM). Using the libmad decoder for MP3 and Nicholas Pitre's integerized Ogg library (NOT tremor), I see about 10% utilization for MP3, and 8-10% for Ogg. (I say 8-10 as conservative padding. In practice, believe it or no, Vorbis always hangs lower.)
Keep in mind that the libvorbis libraries most folks use are a reference implementation. Once Vorbis is properly optimized, it's really quite light on the resources. These guys are probably using tremor, which I personally haven't tried, but I've heard people say it's even lighter than the Pitre decoder.
Wow, what sites have you written? Please send me a list, because I'd love to break into them.
If you're really storing all that information -- username, password, etc. -- in a cookie, you do realize that you're handing it to the user and saying "I trust you not to modify this."?
A more elegant mechanism in PHP is to hand the user a large session identifer and use either PHP's session mechanism or a database table to store the real information. This doesn't even require cookies -- though, as other posters have noted, avoiding cookies requires URL-rewriting, which can be a performance hit.
However, the availability of URL-rewriting demonstrates that cookies are primarily a convenience item for both the user and the programmer. If we get away from PHP for a moment (and please do), there are really nice facilities for this sort of thing in Servlets and J2EE.