They have a specific ad package that targets only newbies - ads that appear the first time the visitor has the cookie set. Apparently these users click on ads like crazy. They haven't learned yet.
Heh heh. I almost never accept cookies. That probably explains why I keep getting the damn 'if this is flashing, you're a winner!" ad. Every time I think "I can't believe there are still suckers who fall for that." It actually all makes sense now.
The dumbest thing about this whole scheme is that in the end, it doesn't provide decent copy protection! I purchased a copy of the "Fast and Furious" disk to try and see how hard it was to rip. Let's see, I had to put in in my CD-RW drive, and run 'cdparanoia'. A few minutes later, an almost perfect copy. A few errors showed up, but none that were still audible after the automatic correction in the software. The next day I returned the opened album to the store for a full refund! I didn't actually bother to keep the music because, well, I think it's crappy music.
If this system actually provided copy protection, or at least made ripping inconvenient, maybe it would be worth it for Universal. But since it doesn't even provide copy protection, what the hell are they thinking? It only takes one person to populate the MP3's onto the P2P network. Given that common drives (an LG 8080B CD-RW in my case) and common software (EAC, cdparanoia, etc.) don't seem to have any problem reading these CD's. And given that Universal at least has a stated policy letting you return the CD for a full refund if you have 'problems', what the hell are they thinking?
Let's break it down. Folks who don't rip their CD's and have a player which isn't impacted by the protection: no change
Folks who don't rip their CD's but experience problems during playback: pissed off, and lost sales.
Folks who do rip their CD's: they still rip their CD's, only now the pirates can return the CD's for a full refund. This is actually worse for the companies than not selling the CD in the first place! Good lord, are they actually this dumb?
Modems are basically completely maxed out given the contstraints that they operate under. Your math assumes getting 10 bits per hertz (realistic) and getting 56KHz (unrealistic). The phone system is designed to carry voices, not binary data. As a result, it's optimized for the frequency range of the human voice, which only extends up to the 3-4KHz range. In fact, unless you live in the sticks and are calling your neighbor, it is almost for certain that your call is being carried digitally. If so, it's being sampled at 8Hz meaning that due to Nyquist you can't send any frequency higher than 4KHz thru the phone system. Period. You'll notice that if you figure out the bits/hertz that a 56K modem sends, its as good (~8 bits upstream) or better (~13 bits downstream) than what this company is claiming to get.
Basically, they have a system which works as well as a phone modem. Not too suprising really, I suspect that the fundamental limitations on signal and noise are pretty similar for the two different kinds of copper wire run to your house.
Given that they are selling evaluation boards for $3,900 in quantity 1, I think sticking with Apple might be a good idea in the short term. Since the chipset is only $30 in quantity, hopefully somebody else will begin making affordable motherboards based upon the design. But Apple doesn't charge that much for a pimped out G4 tower, even with their steep RAM markup.
What's curious is that their web page seems to indicate that the same chipset works with x86, PPC, and MIPS processors. I'm sure there are 100 reasons why it's impossible, but that kind of chipset flexibility does seem to raise some interesting dual-boot or multiprocessor setups to say the least.
I was going to mod the parent down, but I figured it is better to correct misinformation. You need to go read up on how UWB actually works. It absolutely does not require the transmitter to "switch frequencies". It does not attempt to transmit a little bit of information on lots of different frequencies. Rather, it transmits little bits of information on all frequencies at once. Doing this is not hard. Rather, it is trivial.
You see, in many ways UWB is just like the very first radio tranmissions. The first radios were "spark gap" transmitters, which basically generated RF by creating a little arc of electricity. Doing this creates a little burst of energy which is spread across most of the RF band. You can still hear this effect by trying to listen to AM radio during a lightning storm. Each lightning strike sends out a burst of RF which you can hear on any AM modulated radio. It wipes out all the AM stations, and I guarantee you that the lightning is not using any fancy electronics to "change frequencies". You don't notice the interference as much other radios, such as FM, because they use more advanced modulation techniques. So, the noise from lightning doesn't usually manage to turn into actual audible interference. But if you are listening to a weak signal and the lightning is close, it will still fade out when the noise from the lightning overpowers the signal from the radio station.
Back to UWB, the basic 'unit' of transmission is not unlike the signal generated by a spark gap transmitter or a lightning strike. In order to transmit a bit, the transmitter sends the wide-band pulse either a little bit early or a little bit later than expected. The receiver knowns exactly in time when the next pulse should show up. It has a bit of circuitry which can detect whether the pulse shows up early or late, and spit out a 1 or a 0 accordingly. If the pulse never shows up, nothing gets output. The circuits involved are actually fairly simply. Certainly simpler than a frequency-hopping radio which does work the way you described. Actually, I think you've gotten your wish for "these problems get worked out sooner than later." I say this because I think they have working hardware now. It's not on the market, but it would be if the FCC approval came thru.
Of course, the claims that UWB won't interfere with existing RF users, or with itself, is pretty close to BS. UWB definitely creates interference for other radios, it just a question of whether or not it's enough interference to be noticable. But it will definitely raise the noise level for pretty much every other RF band, so it's safe to assume that the potential of problems exists.
UWB will also interfere with itself. If you are the only user, your fine. But as soon as more than one person is using it, you are going to start finding out that pulses from other transmitters are showing up times which set your receivers correlator off erroniously. If a lot of people are using it in the same area, you are going to get more and more errored bits showing up at the receiver. These can be worked around by using error correcting codes at a higher layer, but it's still interference. Folks who think it can't be jammed are full of it too. One of the papers mentioned that the radios might have a duty cycle as low as 1% or less. If I build a radio that starts spitting pulses out at a 50% duty cycle or some such, I can probably get everyone elses receiver to go nuts trying to deal with all of my extraneous pulses. Maybe I'll need 100 radios running at 50% duty cycles, but it can be done.
As another poster mentioned, eavesdropping will still be quite possible for most applications. It might be hard to detect UWB if you know nothing a priori about the signal. But, anybody who is using it already has a receiver which knows everything it needs to know to pick up signals! It's just like 802.11. It might be hard to pick up a FHSS 802.11 radio if you know nothing about the signal. But if you go out and buy an 802.11 receiver for $100, you can pick up the signal just fine. To some extent this can be worked around by using cryptographically secure PRNG's to generate your timing signals. Then only folks who know the 'key' will be able to pick up the signal. But I can guarantee you that consumer UWB gear will not under any circumstances use secure PRNG's if for no other reason than it would make it a real pain in the ass to set the stuff up to work properly.
So I'm on my way home from work today, and had 10 minutes to kill waiting for the bus at the mall. "What the hell, let's go buy the 'Fast and Furious' soundtrack." So I stop into the local chain store and pick up a copy. $14.92 with tax. Make sure I save my receipt;-)>
So I get home and pop it into my Woody box. I don't bother trying to play it, because I never hooked up the CD analog out anyway. Why bother? I never listen to CD's that way. Fire up Konsole. I'd tell you what I did next, but that might be a DMCA violation. I'm sure you can guess;-)>
Five minutes later, I've got what sure sounds like a perfect copy of the music. Oh, there were a couple of +'s on each track, but I can't hear any errors. Checked the first track. Checked the last track. Checked the middle tracks. Hmmm. Sounds great! Well, as good as can be expected. It's crappy music IMHO. Weird. You would think if they were going to bother with copy protection, they would at least make it work. I'm sure this is the right CD because it includes the sticker on the back of the case saying it's protected against "unauthorized copying". It includes an insert too with the www.musichelponle.com URL. Oh, and a toll free number: 1-877-918-7779. According to the insert, that's only for "Questions and Comments", so don't abuse it;-)>
I think I'll return the CD tommorrow despite the fact that it rips fine on my system. I probably won't even bother encoding it to Vorbis because, well, I think the music sucks. But it's nice to know that there is one less thing to worry about in the world. I can't imagine that this is going to last long when the public finds out that you can buy the CD, rip it to Vorbis or MP3, and return it for a full refund. And they though sales sucked before.:-)> Someone should tell Wall Street and short Universal stock.
As I pointed out last time this was posted, this article is basically 100% FUD. Yes, the amount of traffic goes up. And no, gnutella doesn't scale very well. But the author goes out of his way to make the problem look worse than it actually is. You see, the article only computes the total amount of traffic in the entire network. A number which is both huge and meaningless. You see, by this math, if I send a packet somewhere and it takes 10 hops, well, thats like sending 10 packets!
At the end of the paper, the author coughs up the big scary number of 63GBps of traffic in the Gnutella network when the nodes each have 8 connections and are using a TTL of 8. Wow! That's a lot of traffic. That certainly isn't scaling! Well, what the author never points out is that, by his own math, the network has 7,686,400 users at this point! When we divide up the total traffic among all of those network links, we get a different view. If you do the math you discover that this is a whopping 72Kbps! Oh no! It's the end of the world! Well, no, it's not. True, it's more than a modem can handle. But it's well within the reach of most cable modem connections. Given that your computer is being expected to handle the search requests of over 7 million other people, it's not that much traffic.
Don't get me wrong, I agree that Gnutella doesn't scale all that well. But this paper is just plain FUD. The only number that really matters to users is the total bandwidth load on their pipe. By carefully avoiding that number, which isn't very big and scary at all, the auther is clearly lying by ommision. Given all of the real problems networks like Gnutella encounter, it isn't interesting to read this sort of drivel. Why don't we drag out Mathmatical and model how much bandwidth Napster wastes by transmitting the names of all the files being shared even though most of them will never get searched for. Hmmm. lets assume 7,000,000 users. Let's assume that they each share 1000 files with an average filename length of 32 characters. Why, that's 224 Gigabytes of data, and we haven't even done any searches yet! Cleary, Napster doesn't scale. Ugh. This guy might know how to use Mathematica, but I still suspect he worked in the Marketing department. With the same guys who will tell you about their 200Mbps fast ethernet.
At one of my old jobs, they had a "console" for an old mainframe. An Amdahl IIRC. Anyway, it was basically the size of a desk with a dashboard of lights and switches along the back of the desk. It was easily big enough to use as a normal desk if you wanted to, as it had a ton of flat space on top. But the best part was it had an honest-to-god mechanical odometer in the dash part which counted CPU hours (I think.) Anyway, I always wanted to liberate it and take it home, as it sat there unused for years because no one wanted to move it. But alas, it disappeared before I had the chance. Would've made a great desk. Oh well. At least I have my Sun 3/160 end tables.
"This seems like an attempt to get people to pay if they want to stream the content which they purchased to another location in their own home."
Smart guy. In fact, this is exactly why they want this technology. From the article:
-----quote-----
"we can help content owners create a new business revenue model." Content owners, for example, can start charging consumers every time their digital content is re-distributed within the home, or viewed several times during a certain number of days specified by them.
-----end quote-----
I don't understand why there is such an unreasonable anti-Apple bias around here. First we have the story about the Shuttle where poster feels compelled to compare it to the iMac. "I find these little gems cuter than any iMac I've ever seen!" What kind of crap is that? Do you know what cute means? The shuttle case looks just like any other case, only smaller. It's not cute. It's not cool. It's just a small case that is just as ugly as a regular ATX case. At least the iMac and iMac2 had innovative designs. And they both would qualify as "cute" by most people's definition. The Shuttle is certainly not cute.
Then we have the "iPod killer" from Rio. Eh? The thing looks like it's the size of a brick, and I'm sure just as fun to carry around. And why is the Rio "priced competatively"? They used all cheaper components than the iPod, yet charge the same price? And that's competative? And the iPod is "overpriced" because it uses higer quality components for the same price? What the hell are you people smoking? The iPod uses a brand new high tech hard drive which lets the whole iPod be the size of just the hard drive in the Rio. The Rio is plastic, versus metal for the iPod (can you say more durable?) And what makes the reviewer think the interface is better than Apple's? Has dschuetz actually used either one? I doubt it.
Is it going to show up as a generic USB mass storage device? Or am I going to have to use some half-assed experimental driver to get it to work under Linux? I would say the chance of Linux support is low based upon the support they've given their other products. Sonic Blue might use Linux internally in their products, but have they provided Linux drivers for anything? Ever? Certainly not for their MP3 players. As far as I can tell, any MP3 player which doesn't show up as a generic mass storage device (like the iPod does) is nothing but a Window's centric RIAA-pandering product. I don't know why Slashdot editor would think that was cool. The only reason to not have an MP3 player act as a generic mass storage device is to keep the RIAA happy. And unless the company actually provides Linux drivers (which Sonic Blue does not) you are resigning yourself to half-assed buggy support. Bah.
"The trick is to convert seemingly random/uncommon data into less-random data. Finding equations which do the trick takes much processing power."
Um, OK. Whatever. Are you trying to say that with enough processing power, you can compress all inputs into smaller outputs? It you think that, you miss the whole point. See, you are focused on the "seemingly random" input, and sure, you might be able to compress the ones that only "seem" to be random, but aren't. What you are forgetting is that we are talking about all possible inputs, including the random ones. Just because you think you have some great way of compressing some inputs does not mean you have some way of compressing all inputs.
Yeah, but if we just said "No, it won't work", he wouldn't have believed us. In fact, there is a small but real chance that he still won't believe us;-)>
I'm going try and not sound too snide here, but I'm not sure I can help it. It's a simple fact that you cannot develop a lossless compression algorithm which will compress all inputs to smaller outputs. Period.
People sometimes ask if college is worthwhile for studying CS. One good thing about it is that you learn not to try and design impossible compression algorithms. This isn't like P=NP, or any other hard CS problem which isn't completely answered. Or like the speed of light being absolute, which may or not be true. You simply can't design an algorithm which will make all inputs smaller, and have it be reversable.
For those of you who have not had any 101 level CS classes, here's why. If all outputs from your algorithm are smaller than the inputs, then you have fewer possible outputs than inputs. If this is the case, there have to be multiple inputs which compress to the same output. When it comes time to decompress the output, you will have no way of knowing which input was used to generate the output. Hence your algorithm will not be able to properly decompress the output.
Compression algorithms work because they are designed to make the typical file smaller, while compressing the uncommon inputs into larger outputs. Usually the common files have lots of redundancy in them, which makes it fairly easy to design compression algorithms, especially for readable text.
Actually, most good compression programs cheat a little bit. If they detect that the output is going to be larger than the input, they don't compress the file at all. Which means that all outputs are one bit larger than the output file size, because one bit of information is stored in the fact that the program did or did not compress the file. Logically, that.gz or the lack thereof is included in the output of the program.
Now lossy compression is a whole different story. You can compress as much as you want, based upon how much loss you think is acceptable. I could easily design a lossy image compression scheme that compressed all pictures down to a single bit, but some folks might find that simply calling pictures 'light' and 'dark' is a little too lossy to be useful. But the important fact is that in any lossy compression scheme, there are multiple inputs which map to single outputs. And that's fine because you don't care if you get the exact file back when you decompress the output.
No. Packet loss happens because the link is congested. TCP slows down because the link is congested. Blasting traffic onto a congested link without flowcontrol does not magically make the link less congested. It makes it more congested. Their algorithms don't actually avoid retransmissions. They just rename them. There isn't any fancy math that can help you avoid packets getting dropped.
Let's take an extreme example of 50% packet loss. Let's also say that the data would fit in 100 packets. With TCP, the sender will have to send about 200 packets in order to get the 100 needed packets thru to the receiver. The same is true of the 'fountain' method. Just because the 200 packets are all different doesn't mean that the sender doesnt need to the send packets. Which is what counts.
Now, with their method they might send the 200 packets faster than TCP would. But in the larger picture, that just screws everybody else. Look at the white papers on their site describing their technology. They give the example of somebody who has T3 (45Mbps) links, but the network in between them is suffering from 200ms latency and 2% packet loss (which is a shitload by the way). TCP, of course, runs slowly on such a network. As it should. They talk about using their tech to just firehose UDP packets out at 45Mbps, and hey! Your file will get thru in seconds instead of hourse! Which of course is BS. If you start slamming 45Mbps of un-flow-controlled traffic onto a congested link you will probably take it completely down. If you keep it up, you can expect somebody to eventually start filtering your traffic out because you are DoS'ing the network. At best. At worst, you can expect a visit from the FBI because your behavior is exactly the same as a script-kidding DoS'ing somebody, only you won't be bothering to forge your source address so you'll be easy to find.
Don't get me wrong, their technology has some wonderful applications. But intercontinental traffic is sometimes slow because the links are congested! No fancy math is going to change that. Ignoring the fact that the link is full and blasting traffic into it without flowcontrol will only make it worse! They might think they are on to something really cool, but if it works at all it will only work for one person at everyone elses expense. If everyone stops using flow control and just blasts traffic out as fast as they can, performance will really start sucking.
All of which they realize, which is why they are working on RFC's for flow control. And when those RFC's get approved, you can bet that the congestion backoff will look a lot like TCP because we have a pretty good idea of how TCP behaves on a macro scale. The whole spin of getting super fast network transfers is basically marketing BS, something which I'm sure the developers are aware of. The real advantages, which are the ones they are pursuing in RFC's, are reliable multicast and (almost) stateless data serving.
Yeah, you are right. This protocol would be perfect for multicast! People have been working on developing "reliable" multicast transmissions of data forever. If you try to do it with the usual TCP-style transfer it's an amazingly hard problem. Especially since one of the standard "requirements" of multicast is that senders don't have to know anything about the receivers! This limitation alone makes reliable data transfers almost impossible within the boundaries of standard multicast.
Until this came along. All a sender needs to do is pump out the data continuously on a given group address at some network-friendly rate. Any receiver who wants the data just connects and slurps down data until it has the whole file. Then disconnect from the group and the routers prune the traffic off of your network. It's genius. Each listener only has to receive traffic for exactly as long as they need to get the whole file! Since the overhead is claimed to be only 5% or so, it's hard to imagine any other scheme being more efficient.
On the other hand, I don't see much benefit for unicast connections. If their idea is to use their algorithms to allow them to send data faster than TCP without flowcontrol, they are going to piss off a lot of network managers. Their traffic is going to look an awful lot like a DoS attack. In fact, without flowcontrol in a lot of cases it will be a DoS attack. The article gives the case of somebody with a 32Mbps connection who only gets 0.5Mbps out of TCP. Well, if they decide "hey, I'll use 1/3 of my connection for this traffic" and start dumping 10Mbps into a network that was already bottlenecked, they can expect a call from a very upset network person who wants to know why they are melting down their network.
There are also some lies about TCP in the article. TCP does not require packets to arrive in sequence. Well, a few old brain-dead stacks did. But no OS made in the last few years cares that much about out of order packets. If you have a high bandwidth connection but you can't seem to get much thruput one of two things is happening: you have buffers that are too small on one or both ends of the connections, or the network is really too congested to go much faster. In the first case, there are numerous fixes if you take the time to research them (although I'll admit it's a pain in most cases.) Here's a search for more info. The article even implies that this is the case they are trying to fix. "They had too much turnaround". Hmm. Sounds like latency. 32Mbps * (your round trip time) = suggested buffer size. You don't need to spend 100K on hardware, just tweak your TCP stack! Or run a 2.4 kernel which will do a pretty darn good job of autotuning your buffers on the fly.
Is it possible to hack the firmware to have it play raw audio? Or is the output of the mpeg chip wired directly to the input of the D/A? I ask because it would be infinitely easier to add support for things like Ogg and such by simply decoding on the server and streaming the raw audio to the player. It would also allow us to do normalization, cross-fades, or whatever. It would also be nice to avoid any additional artifacts from re-encoding. Sure, it would take more bandwidth, but with 10bT there's plenty.
Cool? Definitely! This dangerous toy is a hella lot cooler than a lot of the toys I had as a kid. Voice control over a walkie talkie? Man, I might have to put this on the Xmas list. I'll teach that darn cat not to jump on the counter yet!
People probably say that because it's, um, a PC? It does run Windows2000 after all. And it does use the same DirectX API as PC's. And I'd be willing to bet that by moving a few libraries around the XBox would run PC software and visa-versa. It's also using a processor that is identical to a PC processor. Plus the same memory. Plus the same hard drive.
This is nowhere near the same as the GameCube. Does a GC run MacOS? Does it support the QuickTime API? Or QuickDraw? Does it use a standard G3 or G4 processor? Does it use commodity memory? A commodity hard drive? The answer to all of these is no. An XBox is 95% identical to a PC. A Gamecube has as much in common with a Mac as a Mac has in common with an IBM RS/6000.
This isn't judicial idiocy. This is the idiocy of your bosses at DOI. The judge in no way ordered the entire DOI offline, only the servers which are dealing with access to individual trust data. This is a decision your bosses made because they want to play hardball with the judge. The reason Gayle Norton is being sued is because of the continued incompetence shown in dealing with the Indian trust issue. Taking the entire department offline is just more of the same. The folks running DOI don't appear to have any desire to serve the public interest. Quite honestly, I don't know what they think they are accomplishing. They are probably hoping that they can spin this to look like it's another example of an 'activist judiciary' (which seems to have worked on you, since you think it's the judges fault.) In reality, it's another example of their continuing bad faith and incompetence when it comes to dealing with Indian affairs. Actually, their bad faith in dealing with all BOI affairs since they seem more than willing to punish all of their employees and constituents rather than fix the ongoing problems at BIA.
Don't forget to remind everyone that the left hand is going to cost you money in the long run. First there is the upfront expense of paying for the copy protection technologies, lawyers, etc. Second is the lost sales.
Like lots of people, I'm in the process of putting all of my CD's onto a PC jukebox. Right now, everything I have is ripped from my personal CD collection. All of the music is 100% legal music that the artists have been paid for. And I plan on keeping it that way. But what do you think I'm going to do if I find out that the music I want can't be converted into the format I'm using? Do you think I'm going to give up on my digital jukebox? No. Think again. I buy CD's for the express purpose of ripping the music and putting it into my jukebox. If the record companies remove that functionality, I'll just stop buying new CD's. Why would I pay $15-$20 for something that provides me with no value at all!
Rather, I'll buy used CD's for old stuff I want, and just go straight to the P2P for new stuff. That's the real problem with the copy protection: it will actually push people away from CDs even faster! The standard CD is actually a pretty good method for distributing music in a standard, widely available, and lost lasting technology. Making CD's less useful is not a way to increase sales, it's a way to decrease sales!
You should stress to the other people in your company that the sidetrack of copy protection is a self-defeating one. The industry needs to get the celestial jukebox services up and running ASAP, because the P2P services are already just about there. Until the industry has a product that can compete with the P2P, it should be trying to keep existing customers as happy as possible for as long as possible. Drop the copy protection. Hell, drop prices out of respect for the fact that the economy is tanking and people have less disposable income! But don't keep acting like the bad guy and alienating your customers. That is not the path to long term success. The people who think it is need to be "rightsized" as soon as possible.
Good points, but I think they are doable. ACLs: not a problem since they are separate from the forwarding decision. Multicast is not a problem either. You have 64 bytes of state. You could easily keep a pointer to an OIL (as Cisco calls them) for a multicast route. Adding a class A would involve writing 4MB of memory to the table. I don't think the delay there would be show stopper. When you say overlapping routes, you probably mean accepting the same route from two different BGP peers? Well, usually only one would be put in the actual forwarding table. Again, with 64 bytes of state you could easily list two or three interfaces to round-robin if you want to do that. By source routing, you mean when the source supplies the route in the IP header? That doesn't use the routing table anyway so it's a moot point.
You mention latency to the DRAM as a possible problem, but sufficiently sized L1 or L2 SRAM caches should deal with this.
As to multiple routing tables, I assume you are talking about using them for policy based routing. Having multiple distinct tables is only one way of doing it. The access list could also be applied after the forwarding decision had been made. One possibility would be to have the access list choose one of several next hops which are all stored in the 64 bytes of space you set aside per route
I'm not saying that it would be trivial to build such a box, but I think it's entirely doable. The details of making it work well would be the same details you run into with any router design. Memory has become practially free. There isn't any reason not to leverage that fact. It's a standard tradeoff in CS that you can optimize for either memory or CPU and trade off one versus the other. Putting routes in a big array wastes memory, but saves time because lookups are O(1) instead of the O(n) or O(ln n) or whatever your favorite data structure is. There is every reason to believe that such a router should be faster than a traditional one which keeps routes in a more complex data structure.
Well, the lookup part should be doable. It's entirely reasonable to keep a route for every single possible/24 route in an array. Not any fancy CEF lookup table or B-Tree or anything fancy. Just allocate an array for every single/24. There are only 16M of them! Let's say you need 64 bytes per route to keep the state you need (next hop, outbound interface, route source, timeout, etc.) and you are only using 1GB of RAM! 1GB of DDR RAM is worth less than the power cords for a high end router. In fact, I think it will be realistic to store host routes for all 2^32 addresses within a few years. Sure, 512GB or so seems like a lot of RAM today, but 512MB seemed like a lot only a few years ago.
Getting rid of the larger net blocks will make better use of available address space not worse. The addresses are not being 'pissed away'. From an allocation point of view, if I have a/24 it doesn't matter if I got it from ARIN or from my ISP. A/24 is being used either way. Any ISP that's going to last is going to sit a on significant portion of it's allocated addresses for future growth. I would argue that the waste involved in every major ISP keeping it's own 'reserved' pool is greater than the waste involved in having only ARIN keep a 'reserved' pool and allocate/24's out dynamically. Hell, you admit yourself you are sitting on a/16! How much of that is actually being used by cusomers, and how much is being 'pissed away'? It's just like older MacOS where each application had a fixed amount of memory allocated to it. It lead to huge amounts of waste as each app had to have memory allocated for the worst case scenario. This is like today where hugh fixed chunks are handed out to ISPs to manage. They are all going to sit on a bunch of unused space 'just in case'. On the other hand, any decent OS allocates memory out a page at a time on demand leading to better use. The same could be done with address space. Give each organization the/24's it needs. If they are not using them, yank them back.
Now, whether or not BGP can keep up with all the updates is a different story. But with the vast amounts of bandwidth between core routers and GHz processors cheaply available, I think a box could be built to handle it. Especially given that most routing is done by ASICs and the CPUs sit around at 2% utilization most of the time.
Another question about the shower...
on
Listening to Leonids
·
· Score: 3, Interesting
One thing several of my friends and I wondered about is why the meteors didn't all travel in the same direction? The velocity of the Earth during the shower was basically constant. The velocity of all the particles in the cloud of debris that make up the shower should be the same, otherwise the cloud would have dispersed generations ago. If the two velocities are the same, then the path of the meteors should have all been the same. But while most of the meteors clearly traveled from East to West in accordance with the rotation of the Earth, quite a few appeared to come from the North and South! Does anyone know what causes this?
Take a look at Diva. Somewhere on their page it says it's "SDMI capable", but there aren't any handicaps in the current player. I think a lot of companies say they are "SDMI capable" when in reality, SDMI will only matter with SDMIv2. And that has a low chance of ever becoming reality, especially after the watermarking techniques it was to rely on were shown to be nearly worthless.
The Diva has three main advantages: It's cheap. I got a 128MB version for ~$130. It uses CF memory, which IMHO is about the most standard of the various flash formats. Most importanty, it's a generic USB mass storage device. I just plug it into my laptop and mount/dev/sda1. I can copy files in and out to my hearts content. It just ignores any file that doesn't end in.mp3. No drivers to install. No special software. No mess. No fuss.
The downsides are that it's rather cheaply made, and the display/controls are a little lacking. But hey, you get what you pay for. The 32MB version can be had for like $70 after rebate. For me, the security of knowing that I would have no driver issues at all outweighed the disadvantages. Oh, it has a voice recording mode too, for what it's worth. I got the MP3128VP, but it looks like they have a new "Music Pen" version coming out. It should work just as well in Linux. The Specs brag about "No drivers with Windows2000/ME" which means it should work fine in any OS with USB mass store drivers.
Slashdot Mirror
They have a specific ad package that targets only newbies - ads that appear the first time the visitor has the cookie set. Apparently these users click on ads like crazy. They haven't learned yet.
Heh heh. I almost never accept cookies. That probably explains why I keep getting the damn 'if this is flashing, you're a winner!" ad. Every time I think "I can't believe there are still suckers who fall for that." It actually all makes sense now.
The dumbest thing about this whole scheme is that in the end, it doesn't provide decent copy protection! I purchased a copy of the "Fast and Furious" disk to try and see how hard it was to rip. Let's see, I had to put in in my CD-RW drive, and run 'cdparanoia'. A few minutes later, an almost perfect copy. A few errors showed up, but none that were still audible after the automatic correction in the software. The next day I returned the opened album to the store for a full refund! I didn't actually bother to keep the music because, well, I think it's crappy music.
If this system actually provided copy protection, or at least made ripping inconvenient, maybe it would be worth it for Universal. But since it doesn't even provide copy protection, what the hell are they thinking? It only takes one person to populate the MP3's onto the P2P network. Given that common drives (an LG 8080B CD-RW in my case) and common software (EAC, cdparanoia, etc.) don't seem to have any problem reading these CD's. And given that Universal at least has a stated policy letting you return the CD for a full refund if you have 'problems', what the hell are they thinking?
Let's break it down. Folks who don't rip their CD's and have a player which isn't impacted by the protection: no change
Folks who don't rip their CD's but experience problems during playback: pissed off, and lost sales.
Folks who do rip their CD's: they still rip their CD's, only now the pirates can return the CD's for a full refund. This is actually worse for the companies than not selling the CD in the first place! Good lord, are they actually this dumb?
Modems are basically completely maxed out given the contstraints that they operate under. Your math assumes getting 10 bits per hertz (realistic) and getting 56KHz (unrealistic). The phone system is designed to carry voices, not binary data. As a result, it's optimized for the frequency range of the human voice, which only extends up to the 3-4KHz range. In fact, unless you live in the sticks and are calling your neighbor, it is almost for certain that your call is being carried digitally. If so, it's being sampled at 8Hz meaning that due to Nyquist you can't send any frequency higher than 4KHz thru the phone system. Period. You'll notice that if you figure out the bits/hertz that a 56K modem sends, its as good (~8 bits upstream) or better (~13 bits downstream) than what this company is claiming to get.
Basically, they have a system which works as well as a phone modem. Not too suprising really, I suspect that the fundamental limitations on signal and noise are pretty similar for the two different kinds of copper wire run to your house.
Given that they are selling evaluation boards for $3,900 in quantity 1, I think sticking with Apple might be a good idea in the short term. Since the chipset is only $30 in quantity, hopefully somebody else will begin making affordable motherboards based upon the design. But Apple doesn't charge that much for a pimped out G4 tower, even with their steep RAM markup.
What's curious is that their web page seems to indicate that the same chipset works with x86, PPC, and MIPS processors. I'm sure there are 100 reasons why it's impossible, but that kind of chipset flexibility does seem to raise some interesting dual-boot or multiprocessor setups to say the least.
I was going to mod the parent down, but I figured it is better to correct misinformation. You need to go read up on how UWB actually works. It absolutely does not require the transmitter to "switch frequencies". It does not attempt to transmit a little bit of information on lots of different frequencies. Rather, it transmits little bits of information on all frequencies at once. Doing this is not hard. Rather, it is trivial.
You see, in many ways UWB is just like the very first radio tranmissions. The first radios were "spark gap" transmitters, which basically generated RF by creating a little arc of electricity. Doing this creates a little burst of energy which is spread across most of the RF band. You can still hear this effect by trying to listen to AM radio during a lightning storm. Each lightning strike sends out a burst of RF which you can hear on any AM modulated radio. It wipes out all the AM stations, and I guarantee you that the lightning is not using any fancy electronics to "change frequencies". You don't notice the interference as much other radios, such as FM, because they use more advanced modulation techniques. So, the noise from lightning doesn't usually manage to turn into actual audible interference. But if you are listening to a weak signal and the lightning is close, it will still fade out when the noise from the lightning overpowers the signal from the radio station.
Back to UWB, the basic 'unit' of transmission is not unlike the signal generated by a spark gap transmitter or a lightning strike. In order to transmit a bit, the transmitter sends the wide-band pulse either a little bit early or a little bit later than expected. The receiver knowns exactly in time when the next pulse should show up. It has a bit of circuitry which can detect whether the pulse shows up early or late, and spit out a 1 or a 0 accordingly. If the pulse never shows up, nothing gets output. The circuits involved are actually fairly simply. Certainly simpler than a frequency-hopping radio which does work the way you described. Actually, I think you've gotten your wish for "these problems get worked out sooner than later." I say this because I think they have working hardware now. It's not on the market, but it would be if the FCC approval came thru.
Of course, the claims that UWB won't interfere with existing RF users, or with itself, is pretty close to BS. UWB definitely creates interference for other radios, it just a question of whether or not it's enough interference to be noticable. But it will definitely raise the noise level for pretty much every other RF band, so it's safe to assume that the potential of problems exists.
UWB will also interfere with itself. If you are the only user, your fine. But as soon as more than one person is using it, you are going to start finding out that pulses from other transmitters are showing up times which set your receivers correlator off erroniously. If a lot of people are using it in the same area, you are going to get more and more errored bits showing up at the receiver. These can be worked around by using error correcting codes at a higher layer, but it's still interference. Folks who think it can't be jammed are full of it too. One of the papers mentioned that the radios might have a duty cycle as low as 1% or less. If I build a radio that starts spitting pulses out at a 50% duty cycle or some such, I can probably get everyone elses receiver to go nuts trying to deal with all of my extraneous pulses. Maybe I'll need 100 radios running at 50% duty cycles, but it can be done.
As another poster mentioned, eavesdropping will still be quite possible for most applications. It might be hard to detect UWB if you know nothing a priori about the signal. But, anybody who is using it already has a receiver which knows everything it needs to know to pick up signals! It's just like 802.11. It might be hard to pick up a FHSS 802.11 radio if you know nothing about the signal. But if you go out and buy an 802.11 receiver for $100, you can pick up the signal just fine. To some extent this can be worked around by using cryptographically secure PRNG's to generate your timing signals. Then only folks who know the 'key' will be able to pick up the signal. But I can guarantee you that consumer UWB gear will not under any circumstances use secure PRNG's if for no other reason than it would make it a real pain in the ass to set the stuff up to work properly.
So I'm on my way home from work today, and had 10 minutes to kill waiting for the bus at the mall. "What the hell, let's go buy the 'Fast and Furious' soundtrack." So I stop into the local chain store and pick up a copy. $14.92 with tax. Make sure I save my receipt ;-)>
;-)>
;-)>
:-)> Someone should tell Wall Street and short Universal stock.
So I get home and pop it into my Woody box. I don't bother trying to play it, because I never hooked up the CD analog out anyway. Why bother? I never listen to CD's that way. Fire up Konsole. I'd tell you what I did next, but that might be a DMCA violation. I'm sure you can guess
Five minutes later, I've got what sure sounds like a perfect copy of the music. Oh, there were a couple of +'s on each track, but I can't hear any errors. Checked the first track. Checked the last track. Checked the middle tracks. Hmmm. Sounds great! Well, as good as can be expected. It's crappy music IMHO. Weird. You would think if they were going to bother with copy protection, they would at least make it work. I'm sure this is the right CD because it includes the sticker on the back of the case saying it's protected against "unauthorized copying". It includes an insert too with the www.musichelponle.com URL. Oh, and a toll free number: 1-877-918-7779. According to the insert, that's only for "Questions and Comments", so don't abuse it
I think I'll return the CD tommorrow despite the fact that it rips fine on my system. I probably won't even bother encoding it to Vorbis because, well, I think the music sucks. But it's nice to know that there is one less thing to worry about in the world. I can't imagine that this is going to last long when the public finds out that you can buy the CD, rip it to Vorbis or MP3, and return it for a full refund. And they though sales sucked before.
As I pointed out last time this was posted, this article is basically 100% FUD. Yes, the amount of traffic goes up. And no, gnutella doesn't scale very well. But the author goes out of his way to make the problem look worse than it actually is. You see, the article only computes the total amount of traffic in the entire network. A number which is both huge and meaningless. You see, by this math, if I send a packet somewhere and it takes 10 hops, well, thats like sending 10 packets!
At the end of the paper, the author coughs up the big scary number of 63GBps of traffic in the Gnutella network when the nodes each have 8 connections and are using a TTL of 8. Wow! That's a lot of traffic. That certainly isn't scaling! Well, what the author never points out is that, by his own math, the network has 7,686,400 users at this point! When we divide up the total traffic among all of those network links, we get a different view. If you do the math you discover that this is a whopping 72Kbps! Oh no! It's the end of the world! Well, no, it's not. True, it's more than a modem can handle. But it's well within the reach of most cable modem connections. Given that your computer is being expected to handle the search requests of over 7 million other people, it's not that much traffic.
Don't get me wrong, I agree that Gnutella doesn't scale all that well. But this paper is just plain FUD. The only number that really matters to users is the total bandwidth load on their pipe. By carefully avoiding that number, which isn't very big and scary at all, the auther is clearly lying by ommision. Given all of the real problems networks like Gnutella encounter, it isn't interesting to read this sort of drivel. Why don't we drag out Mathmatical and model how much bandwidth Napster wastes by transmitting the names of all the files being shared even though most of them will never get searched for. Hmmm. lets assume 7,000,000 users. Let's assume that they each share 1000 files with an average filename length of 32 characters. Why, that's 224 Gigabytes of data, and we haven't even done any searches yet! Cleary, Napster doesn't scale. Ugh. This guy might know how to use Mathematica, but I still suspect he worked in the Marketing department. With the same guys who will tell you about their 200Mbps fast ethernet.
At one of my old jobs, they had a "console" for an old mainframe. An Amdahl IIRC. Anyway, it was basically the size of a desk with a dashboard of lights and switches along the back of the desk. It was easily big enough to use as a normal desk if you wanted to, as it had a ton of flat space on top. But the best part was it had an honest-to-god mechanical odometer in the dash part which counted CPU hours (I think.) Anyway, I always wanted to liberate it and take it home, as it sat there unused for years because no one wanted to move it. But alas, it disappeared before I had the chance. Would've made a great desk. Oh well. At least I have my Sun 3/160 end tables.
"This seems like an attempt to get people to pay if they want to stream the content which they purchased to another location in their own home."
Smart guy. In fact, this is exactly why they want this technology. From the article:
-----quote-----
"we can help content owners create a new business revenue model." Content owners, for example, can start charging consumers every time their digital content is re-distributed within the home, or viewed several times during a certain number of days specified by them.
-----end quote-----
I don't understand why there is such an unreasonable anti-Apple bias around here. First we have the story about the Shuttle where poster feels compelled to compare it to the iMac. "I find these little gems cuter than any iMac I've ever seen!" What kind of crap is that? Do you know what cute means? The shuttle case looks just like any other case, only smaller. It's not cute. It's not cool. It's just a small case that is just as ugly as a regular ATX case. At least the iMac and iMac2 had innovative designs. And they both would qualify as "cute" by most people's definition. The Shuttle is certainly not cute.
Then we have the "iPod killer" from Rio. Eh? The thing looks like it's the size of a brick, and I'm sure just as fun to carry around. And why is the Rio "priced competatively"? They used all cheaper components than the iPod, yet charge the same price? And that's competative? And the iPod is "overpriced" because it uses higer quality components for the same price? What the hell are you people smoking? The iPod uses a brand new high tech hard drive which lets the whole iPod be the size of just the hard drive in the Rio. The Rio is plastic, versus metal for the iPod (can you say more durable?) And what makes the reviewer think the interface is better than Apple's? Has dschuetz actually used either one? I doubt it.
Is it going to show up as a generic USB mass storage device? Or am I going to have to use some half-assed experimental driver to get it to work under Linux? I would say the chance of Linux support is low based upon the support they've given their other products. Sonic Blue might use Linux internally in their products, but have they provided Linux drivers for anything? Ever? Certainly not for their MP3 players. As far as I can tell, any MP3 player which doesn't show up as a generic mass storage device (like the iPod does) is nothing but a Window's centric RIAA-pandering product. I don't know why Slashdot editor would think that was cool. The only reason to not have an MP3 player act as a generic mass storage device is to keep the RIAA happy. And unless the company actually provides Linux drivers (which Sonic Blue does not) you are resigning yourself to half-assed buggy support. Bah.
"The trick is to convert seemingly random/uncommon data into less-random data. Finding equations which do the trick takes much processing power."
Um, OK. Whatever. Are you trying to say that with enough processing power, you can compress all inputs into smaller outputs? It you think that, you miss the whole point. See, you are focused on the "seemingly random" input, and sure, you might be able to compress the ones that only "seem" to be random, but aren't. What you are forgetting is that we are talking about all possible inputs, including the random ones. Just because you think you have some great way of compressing some inputs does not mean you have some way of compressing all inputs.
Yeah, but if we just said "No, it won't work", he wouldn't have believed us. In fact, there is a small but real chance that he still won't believe us ;-)>
I'm going try and not sound too snide here, but I'm not sure I can help it. It's a simple fact that you cannot develop a lossless compression algorithm which will compress all inputs to smaller outputs. Period.
.gz or the lack thereof is included in the output of the program.
People sometimes ask if college is worthwhile for studying CS. One good thing about it is that you learn not to try and design impossible compression algorithms. This isn't like P=NP, or any other hard CS problem which isn't completely answered. Or like the speed of light being absolute, which may or not be true. You simply can't design an algorithm which will make all inputs smaller, and have it be reversable.
For those of you who have not had any 101 level CS classes, here's why. If all outputs from your algorithm are smaller than the inputs, then you have fewer possible outputs than inputs. If this is the case, there have to be multiple inputs which compress to the same output. When it comes time to decompress the output, you will have no way of knowing which input was used to generate the output. Hence your algorithm will not be able to properly decompress the output.
Compression algorithms work because they are designed to make the typical file smaller, while compressing the uncommon inputs into larger outputs. Usually the common files have lots of redundancy in them, which makes it fairly easy to design compression algorithms, especially for readable text.
Actually, most good compression programs cheat a little bit. If they detect that the output is going to be larger than the input, they don't compress the file at all. Which means that all outputs are one bit larger than the output file size, because one bit of information is stored in the fact that the program did or did not compress the file. Logically, that
Now lossy compression is a whole different story. You can compress as much as you want, based upon how much loss you think is acceptable. I could easily design a lossy image compression scheme that compressed all pictures down to a single bit, but some folks might find that simply calling pictures 'light' and 'dark' is a little too lossy to be useful. But the important fact is that in any lossy compression scheme, there are multiple inputs which map to single outputs. And that's fine because you don't care if you get the exact file back when you decompress the output.
"You have the right to free speech, as long as you're not dumb enough to actually try it!"
From "Know Your Rights" by The Clash
No. Packet loss happens because the link is congested. TCP slows down because the link is congested. Blasting traffic onto a congested link without flowcontrol does not magically make the link less congested. It makes it more congested. Their algorithms don't actually avoid retransmissions. They just rename them. There isn't any fancy math that can help you avoid packets getting dropped.
Let's take an extreme example of 50% packet loss. Let's also say that the data would fit in 100 packets. With TCP, the sender will have to send about 200 packets in order to get the 100 needed packets thru to the receiver. The same is true of the 'fountain' method. Just because the 200 packets are all different doesn't mean that the sender doesnt need to the send packets. Which is what counts.
Now, with their method they might send the 200 packets faster than TCP would. But in the larger picture, that just screws everybody else. Look at the white papers on their site describing their technology. They give the example of somebody who has T3 (45Mbps) links, but the network in between them is suffering from 200ms latency and 2% packet loss (which is a shitload by the way). TCP, of course, runs slowly on such a network. As it should. They talk about using their tech to just firehose UDP packets out at 45Mbps, and hey! Your file will get thru in seconds instead of hourse! Which of course is BS. If you start slamming 45Mbps of un-flow-controlled traffic onto a congested link you will probably take it completely down. If you keep it up, you can expect somebody to eventually start filtering your traffic out because you are DoS'ing the network. At best. At worst, you can expect a visit from the FBI because your behavior is exactly the same as a script-kidding DoS'ing somebody, only you won't be bothering to forge your source address so you'll be easy to find.
Don't get me wrong, their technology has some wonderful applications. But intercontinental traffic is sometimes slow because the links are congested! No fancy math is going to change that. Ignoring the fact that the link is full and blasting traffic into it without flowcontrol will only make it worse! They might think they are on to something really cool, but if it works at all it will only work for one person at everyone elses expense. If everyone stops using flow control and just blasts traffic out as fast as they can, performance will really start sucking.
All of which they realize, which is why they are working on RFC's for flow control. And when those RFC's get approved, you can bet that the congestion backoff will look a lot like TCP because we have a pretty good idea of how TCP behaves on a macro scale. The whole spin of getting super fast network transfers is basically marketing BS, something which I'm sure the developers are aware of. The real advantages, which are the ones they are pursuing in RFC's, are reliable multicast and (almost) stateless data serving.
Yeah, you are right. This protocol would be perfect for multicast! People have been working on developing "reliable" multicast transmissions of data forever. If you try to do it with the usual TCP-style transfer it's an amazingly hard problem. Especially since one of the standard "requirements" of multicast is that senders don't have to know anything about the receivers! This limitation alone makes reliable data transfers almost impossible within the boundaries of standard multicast.
Until this came along. All a sender needs to do is pump out the data continuously on a given group address at some network-friendly rate. Any receiver who wants the data just connects and slurps down data until it has the whole file. Then disconnect from the group and the routers prune the traffic off of your network. It's genius. Each listener only has to receive traffic for exactly as long as they need to get the whole file! Since the overhead is claimed to be only 5% or so, it's hard to imagine any other scheme being more efficient.
On the other hand, I don't see much benefit for unicast connections. If their idea is to use their algorithms to allow them to send data faster than TCP without flowcontrol, they are going to piss off a lot of network managers. Their traffic is going to look an awful lot like a DoS attack. In fact, without flowcontrol in a lot of cases it will be a DoS attack. The article gives the case of somebody with a 32Mbps connection who only gets 0.5Mbps out of TCP. Well, if they decide "hey, I'll use 1/3 of my connection for this traffic" and start dumping 10Mbps into a network that was already bottlenecked, they can expect a call from a very upset network person who wants to know why they are melting down their network.
There are also some lies about TCP in the article. TCP does not require packets to arrive in sequence. Well, a few old brain-dead stacks did. But no OS made in the last few years cares that much about out of order packets. If you have a high bandwidth connection but you can't seem to get much thruput one of two things is happening: you have buffers that are too small on one or both ends of the connections, or the network is really too congested to go much faster. In the first case, there are numerous fixes if you take the time to research them (although I'll admit it's a pain in most cases.) Here's a search for more info. The article even implies that this is the case they are trying to fix. "They had too much turnaround". Hmm. Sounds like latency. 32Mbps * (your round trip time) = suggested buffer size. You don't need to spend 100K on hardware, just tweak your TCP stack! Or run a 2.4 kernel which will do a pretty darn good job of autotuning your buffers on the fly.
Is it possible to hack the firmware to have it play raw audio? Or is the output of the mpeg chip wired directly to the input of the D/A? I ask because it would be infinitely easier to add support for things like Ogg and such by simply decoding on the server and streaming the raw audio to the player. It would also allow us to do normalization, cross-fades, or whatever. It would also be nice to avoid any additional artifacts from re-encoding. Sure, it would take more bandwidth, but with 10bT there's plenty.
Cool? Definitely! This dangerous toy is a hella lot cooler than a lot of the toys I had as a kid. Voice control over a walkie talkie? Man, I might have to put this on the Xmas list. I'll teach that darn cat not to jump on the counter yet!
People probably say that because it's, um, a PC? It does run Windows2000 after all. And it does use the same DirectX API as PC's. And I'd be willing to bet that by moving a few libraries around the XBox would run PC software and visa-versa. It's also using a processor that is identical to a PC processor. Plus the same memory. Plus the same hard drive.
This is nowhere near the same as the GameCube. Does a GC run MacOS? Does it support the QuickTime API? Or QuickDraw? Does it use a standard G3 or G4 processor? Does it use commodity memory? A commodity hard drive? The answer to all of these is no. An XBox is 95% identical to a PC. A Gamecube has as much in common with a Mac as a Mac has in common with an IBM RS/6000.
This isn't judicial idiocy. This is the idiocy of your bosses at DOI. The judge in no way ordered the entire DOI offline, only the servers which are dealing with access to individual trust data. This is a decision your bosses made because they want to play hardball with the judge. The reason Gayle Norton is being sued is because of the continued incompetence shown in dealing with the Indian trust issue. Taking the entire department offline is just more of the same. The folks running DOI don't appear to have any desire to serve the public interest. Quite honestly, I don't know what they think they are accomplishing. They are probably hoping that they can spin this to look like it's another example of an 'activist judiciary' (which seems to have worked on you, since you think it's the judges fault.) In reality, it's another example of their continuing bad faith and incompetence when it comes to dealing with Indian affairs. Actually, their bad faith in dealing with all BOI affairs since they seem more than willing to punish all of their employees and constituents rather than fix the ongoing problems at BIA.
Don't forget to remind everyone that the left hand is going to cost you money in the long run. First there is the upfront expense of paying for the copy protection technologies, lawyers, etc. Second is the lost sales.
Like lots of people, I'm in the process of putting all of my CD's onto a PC jukebox. Right now, everything I have is ripped from my personal CD collection. All of the music is 100% legal music that the artists have been paid for. And I plan on keeping it that way. But what do you think I'm going to do if I find out that the music I want can't be converted into the format I'm using? Do you think I'm going to give up on my digital jukebox? No. Think again. I buy CD's for the express purpose of ripping the music and putting it into my jukebox. If the record companies remove that functionality, I'll just stop buying new CD's. Why would I pay $15-$20 for something that provides me with no value at all!
Rather, I'll buy used CD's for old stuff I want, and just go straight to the P2P for new stuff. That's the real problem with the copy protection: it will actually push people away from CDs even faster! The standard CD is actually a pretty good method for distributing music in a standard, widely available, and lost lasting technology. Making CD's less useful is not a way to increase sales, it's a way to decrease sales!
You should stress to the other people in your company that the sidetrack of copy protection is a self-defeating one. The industry needs to get the celestial jukebox services up and running ASAP, because the P2P services are already just about there. Until the industry has a product that can compete with the P2P, it should be trying to keep existing customers as happy as possible for as long as possible. Drop the copy protection. Hell, drop prices out of respect for the fact that the economy is tanking and people have less disposable income! But don't keep acting like the bad guy and alienating your customers. That is not the path to long term success. The people who think it is need to be "rightsized" as soon as possible.
Good points, but I think they are doable. ACLs: not a problem since they are separate from the forwarding decision. Multicast is not a problem either. You have 64 bytes of state. You could easily keep a pointer to an OIL (as Cisco calls them) for a multicast route. Adding a class A would involve writing 4MB of memory to the table. I don't think the delay there would be show stopper. When you say overlapping routes, you probably mean accepting the same route from two different BGP peers? Well, usually only one would be put in the actual forwarding table. Again, with 64 bytes of state you could easily list two or three interfaces to round-robin if you want to do that. By source routing, you mean when the source supplies the route in the IP header? That doesn't use the routing table anyway so it's a moot point.
You mention latency to the DRAM as a possible problem, but sufficiently sized L1 or L2 SRAM caches should deal with this.
As to multiple routing tables, I assume you are talking about using them for policy based routing. Having multiple distinct tables is only one way of doing it. The access list could also be applied after the forwarding decision had been made. One possibility would be to have the access list choose one of several next hops which are all stored in the 64 bytes of space you set aside per route
I'm not saying that it would be trivial to build such a box, but I think it's entirely doable. The details of making it work well would be the same details you run into with any router design. Memory has become practially free. There isn't any reason not to leverage that fact. It's a standard tradeoff in CS that you can optimize for either memory or CPU and trade off one versus the other. Putting routes in a big array wastes memory, but saves time because lookups are O(1) instead of the O(n) or O(ln n) or whatever your favorite data structure is. There is every reason to believe that such a router should be faster than a traditional one which keeps routes in a more complex data structure.
Well, the lookup part should be doable. It's entirely reasonable to keep a route for every single possible /24 route in an array. Not any fancy CEF lookup table or B-Tree or anything fancy. Just allocate an array for every single /24. There are only 16M of them! Let's say you need 64 bytes per route to keep the state you need (next hop, outbound interface, route source, timeout, etc.) and you are only using 1GB of RAM! 1GB of DDR RAM is worth less than the power cords for a high end router. In fact, I think it will be realistic to store host routes for all 2^32 addresses within a few years. Sure, 512GB or so seems like a lot of RAM today, but 512MB seemed like a lot only a few years ago.
/24 it doesn't matter if I got it from ARIN or from my ISP. A /24 is being used either way. Any ISP that's going to last is going to sit a on significant portion of it's allocated addresses for future growth. I would argue that the waste involved in every major ISP keeping it's own 'reserved' pool is greater than the waste involved in having only ARIN keep a 'reserved' pool and allocate /24's out dynamically. Hell, you admit yourself you are sitting on a /16! How much of that is actually being used by cusomers, and how much is being 'pissed away'? It's just like older MacOS where each application had a fixed amount of memory allocated to it. It lead to huge amounts of waste as each app had to have memory allocated for the worst case scenario. This is like today where hugh fixed chunks are handed out to ISPs to manage. They are all going to sit on a bunch of unused space 'just in case'. On the other hand, any decent OS allocates memory out a page at a time on demand leading to better use. The same could be done with address space. Give each organization the /24's it needs. If they are not using them, yank them back.
Getting rid of the larger net blocks will make better use of available address space not worse. The addresses are not being 'pissed away'. From an allocation point of view, if I have a
Now, whether or not BGP can keep up with all the updates is a different story. But with the vast amounts of bandwidth between core routers and GHz processors cheaply available, I think a box could be built to handle it. Especially given that most routing is done by ASICs and the CPUs sit around at 2% utilization most of the time.
One thing several of my friends and I wondered about is why the meteors didn't all travel in the same direction? The velocity of the Earth during the shower was basically constant. The velocity of all the particles in the cloud of debris that make up the shower should be the same, otherwise the cloud would have dispersed generations ago. If the two velocities are the same, then the path of the meteors should have all been the same. But while most of the meteors clearly traveled from East to West in accordance with the rotation of the Earth, quite a few appeared to come from the North and South! Does anyone know what causes this?
Take a look at Diva. Somewhere on their page it says it's "SDMI capable", but there aren't any handicaps in the current player. I think a lot of companies say they are "SDMI capable" when in reality, SDMI will only matter with SDMIv2. And that has a low chance of ever becoming reality, especially after the watermarking techniques it was to rely on were shown to be nearly worthless.
/dev/sda1. I can copy files in and out to my hearts content. It just ignores any file that doesn't end in .mp3. No drivers to install. No special software. No mess. No fuss.
The Diva has three main advantages: It's cheap. I got a 128MB version for ~$130. It uses CF memory, which IMHO is about the most standard of the various flash formats. Most importanty, it's a generic USB mass storage device. I just plug it into my laptop and mount
The downsides are that it's rather cheaply made, and the display/controls are a little lacking. But hey, you get what you pay for. The 32MB version can be had for like $70 after rebate. For me, the security of knowing that I would have no driver issues at all outweighed the disadvantages. Oh, it has a voice recording mode too, for what it's worth. I got the MP3128VP, but it looks like they have a new "Music Pen" version coming out. It should work just as well in Linux. The Specs brag about "No drivers with Windows2000/ME" which means it should work fine in any OS with USB mass store drivers.