Ah, sorry. Misparsed original post, thought it was talking about bone-induction instead of the stuff in the article when it said "this is interesting because it reads from the nervous system directly".
Bone induction microphones do *not* read from the nervous system. They pick up vibrations in your bones (typically jaw bone, I think, but I could be wrong). Your ears do the same thing, which is why you sound different to how you normally hear yourself when you record your voice and play it back - you're missing the sound conducted by your bones to your ear.
"Embedded" systems typically are small, low power, and run inside of devices you don't think of as computers. Such as washing machines, microwave ovens, cellphones, car assembly robots, PLCs, and so forth.
Calling a Mac Mini or a $89 desktop PC an embedded machine is just silly. And embedded x86 machines don't use Athlons or Pentium 4s; they use 386es and (more recently) 486es.
Also, you don't need to be able to run your embedded system's software natively on your PC. That's what cross-compilers and emulators are for.
For goodness' sake, guys! +5 Funny, not +4 Interesting!
You'd think people would get suspicious when they read things like "poison the DNS cyber buffer", but that's probably expecting too much of the typical mod-point wielding slashdotter.
MOD files were used with Amiga computers -- it's no accident that the format (four voices, 8-bit samples) maps directly to what the Amiga's sound hardware was capable of doing.
Later similar file formats like S3M utilised more advanced sound hardware available for the PC, like the Gravis Ultrasound (or the alternative for those of us with less money, a lot of CPU time). Not being stuck with the limitations of the Amiga's sound hardware, these were capable of producing higher quality sound.
What's your source for this information? Is the act of writing a virus illegal? Or is merely causing it to run on systems on which you are unauthorized to do so illegal?
The approach they describe works quite well, and is easy to do incrementally, and easy to use for developers. Of course, you still want reference documentation for individual modules/methods/functions, but that's not going to be much use by itself.
Step 3.5: get the drivers included in the stock kernel.
Getting drivers in the Linux kernel is much better than just "releasing" drivers with your hardware; it ensures that they're likely to remain available, and be upgraded to be compatible when kernel interfaces change. And your users won't have to install seperate drivers most of the time -- things will just work.
Overseas (well, underseas) cables to the US tend to be financed by the non-US end. And people buy bandwidth on them. They're supported by phone service charges inasmuch as running phone service requires purchasing capacity on them, in the same way that running internet service over them requires purchasing capacity on them.
But I don't see what this has to do with flat-fee internet charging at all.
IP is a customary internet service. The rest you list all use IP. Blocking arbitary IP traffic to your customers, when they haven't asked for it and have no way to make you stop, is bad.
I think by "internet" you really mean "interweb", than nebulous thing accessed by newbies with that big e icon.
The problem is then you end up with something like WAP -- built on assumptions that current systems can't do much, and thus requiring workarounds by future systems which *are* much more capable but must still remain backwards-compatible.
I hate to break it to you, but Star Trek and the universe it portrays is fiction. Thus, the future as seen in this work of fiction is quite probably also not going to happen. Which means that we won't end up with a "Prime Directive".
This approach tends to cause problems when for some reason you need to tell someone else the password, and can't (or have forgotten to) change it first. It's particularly bad when the password contains some less than positive comment about a client, and the client needs to be given the password...
On a vaguely related note, is there any similar service for providing small (100 groups) feeds to individuals? Slurp works, but it's a pain if you want to use it to feed other servers:-(
(okay, probably only useful on IBM PCs and their many clones where some pesky operating system hasn't stomped over the BIOSes interrupt vector assignments)
Slashdot Mirror
Ah, sorry. Misparsed original post, thought it was talking about bone-induction instead of the stuff in the article when it said "this is interesting because it reads from the nervous system directly".
Bone induction microphones do *not* read from the nervous system. They pick up vibrations in your bones (typically jaw bone, I think, but I could be wrong). Your ears do the same thing, which is why you sound different to how you normally hear yourself when you record your voice and play it back - you're missing the sound conducted by your bones to your ear.
"Embedded" systems typically are small, low power, and run inside of devices you don't think of as computers. Such as washing machines, microwave ovens, cellphones, car assembly robots, PLCs, and so forth.
Calling a Mac Mini or a $89 desktop PC an embedded machine is just silly. And embedded x86 machines don't use Athlons or Pentium 4s; they use 386es and (more recently) 486es.
Also, you don't need to be able to run your embedded system's software natively on your PC. That's what cross-compilers and emulators are for.
For goodness' sake, guys! +5 Funny, not +4 Interesting!
You'd think people would get suspicious when they read things like "poison the DNS cyber buffer", but that's probably expecting too much of the typical mod-point wielding slashdotter.
MOD files were used with Amiga computers -- it's no accident that the format (four voices, 8-bit samples) maps directly to what the Amiga's sound hardware was capable of doing.
Later similar file formats like S3M utilised more advanced sound hardware available for the PC, like the Gravis Ultrasound (or the alternative for those of us with less money, a lot of CPU time). Not being stuck with the limitations of the Amiga's sound hardware, these were capable of producing higher quality sound.
...for each time you saw this scenario:
Let's be generous, and assume you've seen this scenario four times per day: that's USD0.20/day.
Assuming you don't work on weekends, that's USD1.00/week.
If you don't take holidays, that's USD52/year.
I'd always assumed the cost of living in the US was a bit higher than that.
Makes you glad US politics doesn't affect those of us outside the US, doesn't it?
:-)
Oh, wait...
Damn superpowers. At least we're not affected by their domestic policy
What's your source for this information? Is the act of writing a virus illegal? Or is merely causing it to run on systems on which you are unauthorized to do so illegal?
Assuming that by SDK you really mean "some sort of framework", you should read the Documenting Frameworks Using Patterns paper.
The approach they describe works quite well, and is easy to do incrementally, and easy to use for developers. Of course, you still want reference documentation for individual modules/methods/functions, but that's not going to be much use by itself.
Step 3.5: get the drivers included in the stock kernel.
Getting drivers in the Linux kernel is much better than just "releasing" drivers with your hardware; it ensures that they're likely to remain available, and be upgraded to be compatible when kernel interfaces change. And your users won't have to install seperate drivers most of the time -- things will just work.
Silly question, perhaps, but which jurisdictions does this apply in? Or is it US- (or some other country) specific?
Yes, because no one ever makes legitimate calls from overseas.
You must work for Verizon.
Why not a photoblog of grass growing?
Overseas (well, underseas) cables to the US tend to be financed by the non-US end. And people buy bandwidth on them. They're supported by phone service charges inasmuch as running phone service requires purchasing capacity on them, in the same way that running internet service over them requires purchasing capacity on them.
But I don't see what this has to do with flat-fee internet charging at all.
IP is a customary internet service. The rest you list all use IP. Blocking arbitary IP traffic to your customers, when they haven't asked for it and have no way to make you stop, is bad.
I think by "internet" you really mean "interweb", than nebulous thing accessed by newbies with that big e icon.
Two quibbles:
(a) How can software look at data it's passing around and work out if it's copyrighted or not?
(b) What does any of this have to do with hating professors?
The problem is then you end up with something like WAP -- built on assumptions that current systems can't do much, and thus requiring workarounds by future systems which *are* much more capable but must still remain backwards-compatible.
This assumes you use the *first* phone line...
:-)
I currently have no phone line at home. But I do have broadband
I hate to break it to you, but Star Trek and the universe it portrays is fiction. Thus, the future as seen in this work of fiction is quite probably also not going to happen. Which means that we won't end up with a "Prime Directive".
Well, actually:
Nokia is one of many manufacturers of phones
T-Mobile owns a GSM cellular network in the US (and presumably more elsewhere)
This approach tends to cause problems when for some reason you need to tell someone else the password, and can't (or have forgotten to) change it first. It's particularly bad when the password contains some less than positive comment about a client, and the client needs to be given the password...
It's obvious: Google is going to leap into the area of Sewerage over IP! A market previously dominated by AOL.
On a vaguely related note, is there any similar service for providing small (100 groups) feeds to individuals? Slurp works, but it's a pain if you want to use it to feed other servers :-(
Execute this! CD 18
(okay, probably only useful on IBM PCs and their many clones where some pesky operating system hasn't stomped over the BIOSes interrupt vector assignments)
I've seen that page before. It's always looked like that. Nothing special about being slashdotted.