The debate against National ID cards still confuses me. It seems to me that if they built a national ID card where everything was contained electronically and there was little to no information on the front, you could do *more* to protect privacy than the current standard of relying on driver's licenses.
The real trick would be developing a method whereby only the information you want to give out is accessible.
My first thought would be to encrypt each peice of information with a different key, but then the government would need to distribute private keys to each business which takes the control out of your hands. On the other hand, if done correctly, they could give access to a liquor store to only be able to decrypt a photograph and if a person is over 21 or not (not even age.)
A better solution of course would be a method of allowing each person to control what information a particular vendor retrieves, but practically speaking, is much more difficult than the above solution.
If the above described card was issued as a national ID card, we'd all be a lot better off. Of course then every club would need a little scanner to read the information instead of being able to just look at the front... but that's not my problem now is it?:)
No. The FCC regulates over-the-air transmissions of television and they have standardized ATSC which is basically unencrypted MPEG-2 at a maximum data rate of 19 Mbps. ATSC also has AC-3 support just in case PBS wants to broadcast surround sound.
Actually they could simply target the one thing people might pay for... ego boosts. By raising the immediate score boost to +3 for paying members with lots of kharma. Granted, comment order would suffer, but what the hell.
Personally... I always thought their perl script should slow down the transfer of the page artificially to allow the ad at the top of the site to be displayed for 3-5 seconds. The table-rendering code in most browsers does this anyway, but not to such a degree.
Of course, the most important thing they could do is simply get advertisers who people actually want to click on. I know it's a groundbreaking [sarcasm] concept, but going out and actively soliciting businesses who your userbase might actually want to visit might actually increase click-through rates. I know I clicked on classmates.com's banner the other day and was pleasently surprised to find a website that was useful.
Of course personally, I think Slashdot is nothing but a giant advertisement system anyway. By posting a store to a site you own, you should probably have to pay at least something.
The physical problems with DVDs are scratches. The more capacity there is on the disc the more problems you get.
Once upon a time, caddies were required for CD-ROM drives. They were bulky peices of junk that didn't typically come with the CD itself.
The thing is... if you scratch your DVD, the average customer is just going to replace it and that's another sale for the movie/record companies.
Sure they are going to argue that the cost was too high, customers didn't like them, etc. In reality, the extra plastic required to make a simple cartriage would be less than the cost of making the DVD itself. A more complex cartriage like those seen on iomega disks would be more expensive however, but if all you want is to have your DVD not get scratched when you drop it, it's not exactly necessary. Dust will be a problem though.
NetInfo exists for the same reason NIS, NYS, YP, etc exist; to centralize system configurations across a network of machines. Things like printer configurations are typically the same in a corporate environment.
NetInfo is actually Open Source. Though I'm not sure how up-to-date it is.
As for/etc... some of those are synchronized from NetInfo, not the other way around. A good number of them are just stub files, but there are a few that do not exist at all in NetInfo at all.
There is quite a big difference between security problems in commercial operating systems such as Solaris and security problems in open source operating systems such as Debian.
The Debian team did not write most of the software that comes with the Debian distribution. Sure they make patches and try to keep things up-to-date, but the software that is in their distribution is included for completeness more than anything else.
Sun on the other hand did write most of the software that comes with Solaris (or at least obfuscated where it came from.) They are directly responsible for security problems with the software they distribute.
When a security problem occurs in Apache, surely it's an Apache security problem that just happens to affect everyone who has Apache installed. If they have Apache installed on Windows, one can't claim it as a Microsoft security bug and blame Microsoft for not auditing every peice of code that happens to compile for their OS.
No one forces the end-administrator to install 99% of the software included with an open source distribution. It is up to the administrator to only install software which they are comfortable with. If the authors of Emacs don't do frequent code audits, don't install it (that's not to say they don't.)
Now... one thing distributions can do to make the end-administrator's job a bit easier is to include statistics along with the application for things like past security vulnerabilities, time since last vulnerability, last code audit, etc. to help them make better decisions about what to install and not to install.
Of course, going the route of only including fully audited code in a distribution just doesn't work. If people need inn, they need inn code review or not. Granted they might take a look at the source while they are compiling it, but the chances of them finding a massive security hole with a curory glance is pretty slim.
That's not to say that distribution vendors are free from blame; especially fully commecial vendors who should at least do some form of audit and mark which packages haven't been audited as 'unsafe,' but come on now... the real blame belongs with the administrator and the developers.
Obviously, distributed resource aggregation isn't a new concept and has been discussed many times before. There have been a couple attempts at a generalized resource aggregation system, but they all seem to have two major problems: no one wants to donate their resources to commercial entities without getting something back in return and the number of problems that can be distributed over high latency, low speed connections is limited.
SETI@home works well because the problem-space can split up and the amount of time it takes for a client to process it far exceeds the time it takes to transfer the data. There are also a good number of users out there who just like the idea of searching for ET.
Distributed.net works well for the same reasons as SETI@home, but instead of users wanting to look for ET... users adopted it originally for chance at cash and later for the ego boost.
If you build a generalized infrastructure to handle arbitrary requests for resources, the end-users loses touch with what they are working with eliminating any type of ego boost. Plus, I can't imagine many people are going to want to donate their space cycles to a pharmacutical company who will then go and patent a drug developed from information you give them, sell it at highly inflated prices in the name of R&D costs while you get nothing in return except a higher power bill and constant noise coming from your computer.
That's not to say there aren't good causes that people would be willing to donate resources to still out there, but these causes are attractive because they give the users a direct connection to them.
Of course, that's just my opinion, I could be wrong.
Microsoft's.Net and Java are going to occupy 70% of the brainspace for programming in the next ten years, and these languages conform to my description above. This is of course not particularly true for anyone who wants to distribute commercial software. Using languages which can be easily decompiled into perfectly readable high-level source isn't terribly good for business.
Any time you need to write software that does what you tell it to do instead of it doing what it wants to do (GC in the background for instance), high-level languages just don't cut it.
The beauty of Mono is that it would allow you to call the Perl module that you really like from Python (and vice versa). You could write an XML parser (for example) in C# (or Python or Perl or C, etc.) and call it from whatever language you like because all of these languages would rely on the CLR (common language runtime).
You do realize that CORBA not only allows you to do the same thing, but is significantly more efficient at doing it?
CORBA ORBs exist for Perl, Python, Smalltalk, LISP, C, C++, Objective-C, etc and they all communicate with eachother.
I am completely dumbfounded by the argument that CORBA, COM/DCOM, RPC and even RMI are somehow less efficient than SOAP when the exact opposite is true. A wonderful article on SOAP vs CORBA is available at the CUJ.
To be a big player in the console industry, you have to have both countries. As a corollary, just because something does well in one country does not automatically spell success in the other country.
One only needs to look at Microsoft's previous business practices to understand why they will fight to the end to ensure the Xbox's success. What they can't embrase and extend, they buy. They have repeatedly done this over the years with everything from compilers to graphics libraries.
Do you really believe that Microsoft won't simply make heavy investments or flat out buy someone like SquareSoft if they think it'll help them gain dominance?
Granted, that doesn't mean they'll succeed right away, but $40 billion dollars in liquid and short-term investments affords them a lot of mistakes.
Of course, that's just my opinion, I could be wrong.
I was in Tokyo in August and London in December and I honestly didn't see anything smaller than what I can buy right down the street. I visited a couple cell phone shops here and there, though they all seemed to offer the same phones.
In Japan, phones tended to be a little bigger than Motorola's flip phones (v.series, startac, etc) (taller more than wide though and less deep) and tended to have more features packed in. They also seemed to make 100 variations of every model for fashion purposes.
In London, phones were basically identical to what is found in the US with the exception of an Ericsson and a couple Samsungs.
Of course, in the Bay Area, we have GSM and PCS available which may not be the case in other parts of the country. Maybe in your area they are still selling brick phones, but around here you can pick up a Motorola v.series, Nokia 8800 series, Samsung A series and Ericcson T series (well the T28 World which is the smallest of the series anyway.)
Just as a quick test I decided to build his Java program with my version of Javac and also write a C version that is basically identical with the exception of the time/print calls and variable ordering and compiled it with both GCC and G++ under MacOS X (PPC.)
Java version: 51250 ms
C version: 6392 ms
C version compiled with G++: 6412 ms
If GCJ can approach even half the performance of G++ in the future it looks like it'll be a complete win over Javac. As I understand it, Apple's version of Java is quite good, but the two just don't compare.
Distribution is a the biggest problem for HDTV right now. People want it but no one will give it to them, except HBO and Showtime off of DirectTV and Dish Network.
In the bay area there are 10 stations broadcasting ATSC. In the US there are 236 stations currently doing DTV broadcasts in 82 markets broadcasting shows from The Young and the Restless to Jay Leno in HDTV.
The problem isn't distribution in major markets, but a general lack of content available.
The audio quality on the iPod is ok. My biggest gripe is the headphone jack appears underpowered and there appears to be some noise introduced in the signal. Granted, it's nowhere near the noise levels of a laptop, but it's there.
Now I do have some problems with the quality of iTunes; the peice of software you use to manage the iPod (yes, you can do it directly, but come on, insert cd, hit import, plug in iPod; it can't get any easier.)
A friend of mine noted that iTunes's MP3 encoder has some problems with introducing artifacts into the audio. I honestly didn't believe him until he took an MP3 he encoded with LAME and directly compared it to one encoded with iTunes and sure enough, at the beginning of the song where there should have been silence was a warping of audio which I now notice during playback.
iTunes also has the interesting problem (though it's probably more of a CDDB fault) of not supporting UTF-8 in ID3 tags, so foreign CDs are either romanized or are in a character set not understood correctly.
In my opinion, the iPod is the best portable MP3 player out there for it's size. It doesn't make a good companion while exercising, but for long train rides, it can't be beat.
I typically use something like the following to counteract my instinctual response to undercut myself. I've found that because seperating work from home life is so difficult, not assuming I'll always have that time for the project makes it hard to make correct estimates.
Let x be the first number in days that pops into your head when you think about how long a project will take.
If the project requires you to work with someone else at any stage (including QA), let x = x*2.
If you usually work on weekends or after hours (or before hours in case of a flipped engineers schedule), let x = x*1.5.
If you are in a bad mood when the number of days pops into your head, you weren't really paying attention to what the project was or you simply aren't in the coding frame of mind, let x = x / 0.9.
If you haven't felt modest in the last 24 hours, let x = x * 1.2.
If the project requires any type of documentation, let x = x*1.2.
Re:The biggest flaw
on
P2P in 2001
·
· Score: 3, Interesting
Actually... Napster's backend can sort by network distance (we have the ability to determine the network distance between two arbitrary IPs in log(N) time), but we only enabled it for Internet2.
So for example, we know Sprint peers with UUnet and so Sprint users would see Sprint users first, UUnet users next. Doing it at the AS level is far easier than actually attempting to map the actual hop distance between every arbitrary point on the Internet.
Honestly... silly mice aren't useful for playing games like Quake. I can't imagine having to constantly pick up and drop down a mouse when I wanted to do circle around someone and given that your hand doesn't cup the large ball of a Kensington (pointer and middle finger are all that's needed), no sweaty hands.
Of course, that's just my opinion, I could be wrong.
Quality. Digital cable picture quality is really really good. bit rates run about 3.5-4.5 Mb/s. this is just about where the average bit rate of a DVD falls (although DVDs peak higher)
Boy I wish that was true all the time. The problem is that any DVD that had real production money thrown at it has bitrates of ~6 Mbps and up. For instance, Gladiator is up at 6.6 Mbps, Cast Away is way up at 7.24 Mbps, Crouching Tiger (Superbit) is up at 7.58 Mbps and that doesn't even count the ~754 Kbps DTS/DD audio tracks.
MPEG-2's bitrates can be tweaked quite a bit if you don't mind choppy video on fast forward/rewind or if you a chroma bit or two, but there is a significant difference between 3.5 Mbps and 7.5 Mbps in terms of quality, especially if that 3.5 Mbps includes audio.
Of course, I don't even want to think about really high bitrate movies for HDTV which unfortunately don't exist as far as I know on DVD due to bitrate requirements exceeding 15 Mbps, but boy would it be nice to watch Star Wars a little closer to the resolution it was shot at.
VOD sounds nice and all, but with ~1 day turnarounds here in San Francisco... Netflix seems to work ok. Not to mention I don't have to deal with advertisements on every menu screen like my damn cable box has (damn you RCN.)
As I understand it, UMTS is a specific application of WCDMA at ~2.1 GHz defined by the ITU with a core network specification based heavily on GSM.
As CDMA operators in the US already exist with their own frequency allocation, 2.5G solutions with most of the 3G benefits will pop up to cut costs.
I blame the FCC for not licensing frequency bands for a praticular protocol that can be shared between companies and instead licensing frequency bands directly to companies and creating this hell. Of course, the FCC pre-dates this type of technology, so it's not all their fault. At least they aren't selling bands yet.
First of all, one should note that IPv6, while supported in newer versions of Cisco IOS, has the slight problem that in BFRs, the hardware accelerated routing hardware has four times more work to do to look up a 128 bit IP address making performance somewhat of a problem. Add to the fact that a lot of the routers out there simply can not be upgraded past 128 MB of RAM and you run into a slight problem when you go to make your $150k router IPv6 capable.
Then there is the little problem of client operating systems and the "migration" to IPv6. As there are only a handful of people on this planet who use IPv6 exclusively, routers will have to support both until all the client software of the world moves over. Now, it is bad enough getting full IPv4 BGP updates, but getting them *AND* IPv6 updates?
Of course, next comes all the little hardware out there. From the terminal servers people dial up to, to the layer 4 load balancers, there is a lot of hardware that doesn't support IPv6.
So, as a large network service provider, one would have to justify the costs associated with IPv6 against the benefits. The benefits are pretty slim right now unfortunately. Ideas like a single roaming IP (pipe dream if you ask me), mandatory multicast/anycast support, fixed sized headers and IP level security are all fine and dandy, but when you are talking about replacing (or at least suplementing) millions of dollars in infrastructure to allow a handful of people to use IPv6 for years until the REST of the world follows, it starts becoming hard to justify.
Don't get me wrong, IPv6 has some lovely attributes, but until Cisco enables IPv6 by default on all the hardware they make, everyone upgrades their copies of Windows and MacOS to support it and all of a sudden the terminal servers of the world (remember dialup still exists) all start learning how to route IPv6 packets, it is an uphill battle.
So the question really becomes, how long will it all take? IPv6 really needs a killer application to the general public aware that they *need* it and ask their providers to provide it. Once enough demand is generated, ISPs will start asking their upstreams for it and the ball will start rolling.
The same problems have plagued multicast for some time and still, very few providers support it and even fewer have customers who use it.
Of course, that's just my opinion, I could be wrong.
Reading this article, I have to start wondering if maybe I'm misunderstanding the problem.
The actual root servers are only queried for the top-level domains and while they have rather massive databases, the types of queries they get is limited.
Now, I'm going to assume that given all the money collected for domains, there somewhere exists a nice pot of money available for running root DNS servers. If there isn't then something is seriously wrong with the administration of DNS.
Segmentation of the actual root servers from the world by utilizing a front-end dns cache that would rewrite the actual DNS queries would solve a lot of problems.
First, rewriting queries would allow an amazing amount of sanity checking to be done on the query itself and should prevent exploiting the back-end root servers directly.
Second, as front-end dns caches can be extremely simple and require almost no configuration, the OS installation can be absolutely minimal excluding even shells. You could go as far as to use an OS that allowed you to revoke system privledges such as certain syscalls (fork, exec, open, etc aren't all that necessary once everything is running) and even make the caching DNS server run as init (though you must have something to bring up networking interfaces.)
Physical segmentation is obviously important as well so a private backbone strung between all core root servers and a seperate interface on each front end cache to access them would help quite a bit.
Of course then comes the issue of DoS attacks which again should be rather easy to solve considering what we are talking about. Just buy a lot of front-end cache systems. You would think given how important root servers are and how much money domain revenues generate, buying a thousand or even ten thousand machines and sticking them in every major network access point wouldn't be all that big of a deal.
Now you still have to deal with the fact that most DNS servers still have a static list of root server IPs. Thankfully, the simple DNS queries that hit root servers can be done with a single UDP packet request and response (until you have to work up the hierarchy) making them prime targets for one of the many clustering solutions out there from simple IP sharing virtual servers to routing protocol tricks.
VM load and system load are two very different things. You can have 250 processes blocked on a floppy disk read and run your load to 250, but try having a bunch of processes and the kernel compete for the last block of memory, especially networked apps where your network card driver all of a sudden needs contiguous blocks of memory in a heavily fragmented system and watch the difference between 2.2 and 2.4.
One more thing to note is the VM != the scheduler. The scheduler is what hands out CPU time slices to programs and ensures your mp3 decoder doesn't skip if it's been using a lot of CPU for some period of time. The VM is what manages memory allocations and decides what to page out and page in to and from disk.
Really, there should be very little difference between VMs unless you are in a low memory condition. Now there is some difference when you consider cached disk pages, but if you are just running a mp3 decoder, I don't think you are constantly re-executing it over and over and even if you were, as long as you aren't in a low memory situation, both VMs should do basically the same thing.
And why has the United States hated Cuba so much? It's not the social policies -- there are far, far worse nations the US has supported. It's because Cuba offered an example of a country going it alone, and to a degree succeding. Even now, despite all that's happened, many people in Latin America look up to Cuba as a model of true independance.
You must be kidding. Cuba is an enemy of the US because in 1962 we discovered they had offensive ballistic missles from the former Soviet Union pointed at us. Since they weren't ICBMs, the amount of damage they could do before we noticed was significantly greater than what the Soviet Union could do directly, so the mutual in mutual assured destruction became a little lopsided.
There is absolutely nothing wrong with an Athlon running at 69 C. AMD Athlon chips are built to withstand on-die temperatures of 95 C (newer generation, older is 90 C) and only require a fan that pushes 16 CFM. Of course, this limit is *ONLY* for socketed CPUs. Slotted CPUs have a much lower tolerance of 70 C.
Unless you are overclocking your CPU (which is rather silly given how frequently new processors come out and how cheap they are), nothing bad will happen with a small CPU fan. The only thing you really have to worry about is the ambient case temperature which should never rise above 42 C.
This is all documented quite clearly in AMD's 'Thermal, mechanical, and chassis cooling design guide.'
So repeat after me: "I do not need to use a turbo prop engine as a CPU cooler. I do not need to worry about my CPU blowing up because it hurts my hand when I touch it. My CPU does not run at a significantly different speed because my CPU is hot."
Of course... what I want to know is if I can buy a dual athlon mp system and underclock the entire thing and use entirely passive cooling. The question is, how low would I have to underclock.
Slashdot Mirror
The debate against National ID cards still confuses me. It seems to me that if they built a national ID card where everything was contained electronically and there was little to no information on the front, you could do *more* to protect privacy than the current standard of relying on driver's licenses.
:)
The real trick would be developing a method whereby only the information you want to give out is accessible.
My first thought would be to encrypt each peice of information with a different key, but then the government would need to distribute private keys to each business which takes the control out of your hands. On the other hand, if done correctly, they could give access to a liquor store to only be able to decrypt a photograph and if a person is over 21 or not (not even age.)
A better solution of course would be a method of allowing each person to control what information a particular vendor retrieves, but practically speaking, is much more difficult than the above solution.
If the above described card was issued as a national ID card, we'd all be a lot better off. Of course then every club would need a little scanner to read the information instead of being able to just look at the front... but that's not my problem now is it?
Of course the ultimate LCD monitor is the IBM T221.
At 22.3" it has a 16x10 aspect ratio and native resolution of 3840x2400. Of course it is also $9000, but that's beside the point now isn't it?
No. The FCC regulates over-the-air transmissions of television and they have standardized ATSC which is basically unencrypted MPEG-2 at a maximum data rate of 19 Mbps. ATSC also has AC-3 support just in case PBS wants to broadcast surround sound.
Actually they could simply target the one thing people might pay for... ego boosts. By raising the immediate score boost to +3 for paying members with lots of kharma. Granted, comment order would suffer, but what the hell.
Personally... I always thought their perl script should slow down the transfer of the page artificially to allow the ad at the top of the site to be displayed for 3-5 seconds. The table-rendering code in most browsers does this anyway, but not to such a degree.
Of course, the most important thing they could do is simply get advertisers who people actually want to click on. I know it's a groundbreaking [sarcasm] concept, but going out and actively soliciting businesses who your userbase might actually want to visit might actually increase click-through rates. I know I clicked on classmates.com's banner the other day and was pleasently surprised to find a website that was useful.
Of course personally, I think Slashdot is nothing but a giant advertisement system anyway. By posting a store to a site you own, you should probably have to pay at least something.
The physical problems with DVDs are scratches. The more capacity there is on the disc the more problems you get.
Once upon a time, caddies were required for CD-ROM drives. They were bulky peices of junk that didn't typically come with the CD itself.
The thing is... if you scratch your DVD, the average customer is just going to replace it and that's another sale for the movie/record companies.
Sure they are going to argue that the cost was too high, customers didn't like them, etc. In reality, the extra plastic required to make a simple cartriage would be less than the cost of making the DVD itself. A more complex cartriage like those seen on iomega disks would be more expensive however, but if all you want is to have your DVD not get scratched when you drop it, it's not exactly necessary. Dust will be a problem though.
NetInfo exists for the same reason NIS, NYS, YP, etc exist; to centralize system configurations across a network of machines. Things like printer configurations are typically the same in a corporate environment.
/etc... some of those are synchronized from NetInfo, not the other way around. A good number of them are just stub files, but there are a few that do not exist at all in NetInfo at all.
NetInfo is actually Open Source. Though I'm not sure how up-to-date it is.
As for
There is quite a big difference between security problems in commercial operating systems such as Solaris and security problems in open source operating systems such as Debian.
The Debian team did not write most of the software that comes with the Debian distribution. Sure they make patches and try to keep things up-to-date, but the software that is in their distribution is included for completeness more than anything else.
Sun on the other hand did write most of the software that comes with Solaris (or at least obfuscated where it came from.) They are directly responsible for security problems with the software they distribute.
When a security problem occurs in Apache, surely it's an Apache security problem that just happens to affect everyone who has Apache installed. If they have Apache installed on Windows, one can't claim it as a Microsoft security bug and blame Microsoft for not auditing every peice of code that happens to compile for their OS.
No one forces the end-administrator to install 99% of the software included with an open source distribution. It is up to the administrator to only install software which they are comfortable with. If the authors of Emacs don't do frequent code audits, don't install it (that's not to say they don't.)
Now... one thing distributions can do to make the end-administrator's job a bit easier is to include statistics along with the application for things like past security vulnerabilities, time since last vulnerability, last code audit, etc. to help them make better decisions about what to install and not to install.
Of course, going the route of only including fully audited code in a distribution just doesn't work. If people need inn, they need inn code review or not. Granted they might take a look at the source while they are compiling it, but the chances of them finding a massive security hole with a curory glance is pretty slim.
That's not to say that distribution vendors are free from blame; especially fully commecial vendors who should at least do some form of audit and mark which packages haven't been audited as 'unsafe,' but come on now... the real blame belongs with the administrator and the developers.
Obviously, distributed resource aggregation isn't a new concept and has been discussed many times before. There have been a couple attempts at a generalized resource aggregation system, but they all seem to have two major problems: no one wants to donate their resources to commercial entities without getting something back in return and the number of problems that can be distributed over high latency, low speed connections is limited.
SETI@home works well because the problem-space can split up and the amount of time it takes for a client to process it far exceeds the time it takes to transfer the data. There are also a good number of users out there who just like the idea of searching for ET.
Distributed.net works well for the same reasons as SETI@home, but instead of users wanting to look for ET... users adopted it originally for chance at cash and later for the ego boost.
If you build a generalized infrastructure to handle arbitrary requests for resources, the end-users loses touch with what they are working with eliminating any type of ego boost. Plus, I can't imagine many people are going to want to donate their space cycles to a pharmacutical company who will then go and patent a drug developed from information you give them, sell it at highly inflated prices in the name of R&D costs while you get nothing in return except a higher power bill and constant noise coming from your computer.
That's not to say there aren't good causes that people would be willing to donate resources to still out there, but these causes are attractive because they give the users a direct connection to them.
Of course, that's just my opinion, I could be wrong.
Microsoft's .Net and Java are going to occupy 70% of the brainspace for programming in the next ten years, and these languages conform to my description above.
This is of course not particularly true for anyone who wants to distribute commercial software. Using languages which can be easily decompiled into perfectly readable high-level source isn't terribly good for business.
Any time you need to write software that does what you tell it to do instead of it doing what it wants to do (GC in the background for instance), high-level languages just don't cut it.
The beauty of Mono is that it would allow you to call the Perl module that you really like from Python (and vice versa). You could write an XML parser (for example) in C# (or Python or Perl or C, etc.) and call it from whatever language you like because all of these languages would rely on the CLR (common language runtime).
You do realize that CORBA not only allows you to do the same thing, but is significantly more efficient at doing it?
CORBA ORBs exist for Perl, Python, Smalltalk, LISP, C, C++, Objective-C, etc and they all communicate with eachother.
I am completely dumbfounded by the argument that CORBA, COM/DCOM, RPC and even RMI are somehow less efficient than SOAP when the exact opposite is true. A wonderful article on SOAP vs CORBA is available at the CUJ.
To be a big player in the console industry, you have to have both countries. As a corollary, just because something does well in one country does not automatically spell success in the other country.
One only needs to look at Microsoft's previous business practices to understand why they will fight to the end to ensure the Xbox's success. What they can't embrase and extend, they buy. They have repeatedly done this over the years with everything from compilers to graphics libraries.
Do you really believe that Microsoft won't simply make heavy investments or flat out buy someone like SquareSoft if they think it'll help them gain dominance?
Granted, that doesn't mean they'll succeed right away, but $40 billion dollars in liquid and short-term investments affords them a lot of mistakes.
Of course, that's just my opinion, I could be wrong.
I was in Tokyo in August and London in December and I honestly didn't see anything smaller than what I can buy right down the street. I visited a couple cell phone shops here and there, though they all seemed to offer the same phones.
In Japan, phones tended to be a little bigger than Motorola's flip phones (v.series, startac, etc) (taller more than wide though and less deep) and tended to have more features packed in. They also seemed to make 100 variations of every model for fashion purposes.
In London, phones were basically identical to what is found in the US with the exception of an Ericsson and a couple Samsungs.
Of course, in the Bay Area, we have GSM and PCS available which may not be the case in other parts of the country. Maybe in your area they are still selling brick phones, but around here you can pick up a Motorola v.series, Nokia 8800 series, Samsung A series and Ericcson T series (well the T28 World which is the smallest of the series anyway.)
Just as a quick test I decided to build his Java program with my version of Javac and also write a C version that is basically identical with the exception of the time/print calls and variable ordering and compiled it with both GCC and G++ under MacOS X (PPC.)
Java version: 51250 ms
C version: 6392 ms
C version compiled with G++: 6412 ms
If GCJ can approach even half the performance of G++ in the future it looks like it'll be a complete win over Javac. As I understand it, Apple's version of Java is quite good, but the two just don't compare.
In the bay area there are 10 stations broadcasting ATSC. In the US there are 236 stations currently doing DTV broadcasts in 82 markets broadcasting shows from The Young and the Restless to Jay Leno in HDTV.
The problem isn't distribution in major markets, but a general lack of content available.
The audio quality on the iPod is ok. My biggest gripe is the headphone jack appears underpowered and there appears to be some noise introduced in the signal. Granted, it's nowhere near the noise levels of a laptop, but it's there.
Now I do have some problems with the quality of iTunes; the peice of software you use to manage the iPod (yes, you can do it directly, but come on, insert cd, hit import, plug in iPod; it can't get any easier.)
A friend of mine noted that iTunes's MP3 encoder has some problems with introducing artifacts into the audio. I honestly didn't believe him until he took an MP3 he encoded with LAME and directly compared it to one encoded with iTunes and sure enough, at the beginning of the song where there should have been silence was a warping of audio which I now notice during playback.
iTunes also has the interesting problem (though it's probably more of a CDDB fault) of not supporting UTF-8 in ID3 tags, so foreign CDs are either romanized or are in a character set not understood correctly.
In my opinion, the iPod is the best portable MP3 player out there for it's size. It doesn't make a good companion while exercising, but for long train rides, it can't be beat.
Actually... Napster's backend can sort by network distance (we have the ability to determine the network distance between two arbitrary IPs in log(N) time), but we only enabled it for Internet2.
So for example, we know Sprint peers with UUnet and so Sprint users would see Sprint users first, UUnet users next. Doing it at the AS level is far easier than actually attempting to map the actual hop distance between every arbitrary point on the Internet.
Honestly... silly mice aren't useful for playing games like Quake. I can't imagine having to constantly pick up and drop down a mouse when I wanted to do circle around someone and given that your hand doesn't cup the large ball of a Kensington (pointer and middle finger are all that's needed), no sweaty hands.
Of course, that's just my opinion, I could be wrong.
Quality. Digital cable picture quality is really really good. bit rates run about 3.5-4.5 Mb/s. this is just about where the average bit rate of a DVD falls (although DVDs peak higher)
Boy I wish that was true all the time. The problem is that any DVD that had real production money thrown at it has bitrates of ~6 Mbps and up. For instance, Gladiator is up at 6.6 Mbps, Cast Away is way up at 7.24 Mbps, Crouching Tiger (Superbit) is up at 7.58 Mbps and that doesn't even count the ~754 Kbps DTS/DD audio tracks.
MPEG-2's bitrates can be tweaked quite a bit if you don't mind choppy video on fast forward/rewind or if you a chroma bit or two, but there is a significant difference between 3.5 Mbps and 7.5 Mbps in terms of quality, especially if that 3.5 Mbps includes audio.
Of course, I don't even want to think about really high bitrate movies for HDTV which unfortunately don't exist as far as I know on DVD due to bitrate requirements exceeding 15 Mbps, but boy would it be nice to watch Star Wars a little closer to the resolution it was shot at.
VOD sounds nice and all, but with ~1 day turnarounds here in San Francisco... Netflix seems to work ok. Not to mention I don't have to deal with advertisements on every menu screen like my damn cable box has (damn you RCN.)
As I understand it, UMTS is a specific application of WCDMA at ~2.1 GHz defined by the ITU with a core network specification based heavily on GSM.
As CDMA operators in the US already exist with their own frequency allocation, 2.5G solutions with most of the 3G benefits will pop up to cut costs.
I blame the FCC for not licensing frequency bands for a praticular protocol that can be shared between companies and instead licensing frequency bands directly to companies and creating this hell. Of course, the FCC pre-dates this type of technology, so it's not all their fault. At least they aren't selling bands yet.
Oh so many answers, so little time.
First of all, one should note that IPv6, while supported in newer versions of Cisco IOS, has the slight problem that in BFRs, the hardware accelerated routing hardware has four times more work to do to look up a 128 bit IP address making performance somewhat of a problem. Add to the fact that a lot of the routers out there simply can not be upgraded past 128 MB of RAM and you run into a slight problem when you go to make your $150k router IPv6 capable.
Then there is the little problem of client operating systems and the "migration" to IPv6. As there are only a handful of people on this planet who use IPv6 exclusively, routers will have to support both until all the client software of the world moves over. Now, it is bad enough getting full IPv4 BGP updates, but getting them *AND* IPv6 updates?
Of course, next comes all the little hardware out there. From the terminal servers people dial up to, to the layer 4 load balancers, there is a lot of hardware that doesn't support IPv6.
So, as a large network service provider, one would have to justify the costs associated with IPv6 against the benefits. The benefits are pretty slim right now unfortunately. Ideas like a single roaming IP (pipe dream if you ask me), mandatory multicast/anycast support, fixed sized headers and IP level security are all fine and dandy, but when you are talking about replacing (or at least suplementing) millions of dollars in infrastructure to allow a handful of people to use IPv6 for years until the REST of the world follows, it starts becoming hard to justify.
Don't get me wrong, IPv6 has some lovely attributes, but until Cisco enables IPv6 by default on all the hardware they make, everyone upgrades their copies of Windows and MacOS to support it and all of a sudden the terminal servers of the world (remember dialup still exists) all start learning how to route IPv6 packets, it is an uphill battle.
So the question really becomes, how long will it all take? IPv6 really needs a killer application to the general public aware that they *need* it and ask their providers to provide it. Once enough demand is generated, ISPs will start asking their upstreams for it and the ball will start rolling.
The same problems have plagued multicast for some time and still, very few providers support it and even fewer have customers who use it.
Of course, that's just my opinion, I could be wrong.
Reading this article, I have to start wondering if maybe I'm misunderstanding the problem.
The actual root servers are only queried for the top-level domains and while they have rather massive databases, the types of queries they get is limited.
Now, I'm going to assume that given all the money collected for domains, there somewhere exists a nice pot of money available for running root DNS servers. If there isn't then something is seriously wrong with the administration of DNS.
Segmentation of the actual root servers from the world by utilizing a front-end dns cache that would rewrite the actual DNS queries would solve a lot of problems.
First, rewriting queries would allow an amazing amount of sanity checking to be done on the query itself and should prevent exploiting the back-end root servers directly.
Second, as front-end dns caches can be extremely simple and require almost no configuration, the OS installation can be absolutely minimal excluding even shells. You could go as far as to use an OS that allowed you to revoke system privledges such as certain syscalls (fork, exec, open, etc aren't all that necessary once everything is running) and even make the caching DNS server run as init (though you must have something to bring up networking interfaces.)
Physical segmentation is obviously important as well so a private backbone strung between all core root servers and a seperate interface on each front end cache to access them would help quite a bit.
Of course then comes the issue of DoS attacks which again should be rather easy to solve considering what we are talking about. Just buy a lot of front-end cache systems. You would think given how important root servers are and how much money domain revenues generate, buying a thousand or even ten thousand machines and sticking them in every major network access point wouldn't be all that big of a deal.
Now you still have to deal with the fact that most DNS servers still have a static list of root server IPs. Thankfully, the simple DNS queries that hit root servers can be done with a single UDP packet request and response (until you have to work up the hierarchy) making them prime targets for one of the many clustering solutions out there from simple IP sharing virtual servers to routing protocol tricks.
Of course, I may be oversimplifying the problem.
VM load and system load are two very different things. You can have 250 processes blocked on a floppy disk read and run your load to 250, but try having a bunch of processes and the kernel compete for the last block of memory, especially networked apps where your network card driver all of a sudden needs contiguous blocks of memory in a heavily fragmented system and watch the difference between 2.2 and 2.4.
One more thing to note is the VM != the scheduler. The scheduler is what hands out CPU time slices to programs and ensures your mp3 decoder doesn't skip if it's been using a lot of CPU for some period of time. The VM is what manages memory allocations and decides what to page out and page in to and from disk.
Really, there should be very little difference between VMs unless you are in a low memory condition. Now there is some difference when you consider cached disk pages, but if you are just running a mp3 decoder, I don't think you are constantly re-executing it over and over and even if you were, as long as you aren't in a low memory situation, both VMs should do basically the same thing.
And why has the United States hated Cuba so much? It's not the social policies -- there are far, far worse nations the US has supported. It's because Cuba offered an example of a country going it alone, and to a degree succeding. Even now, despite all that's happened, many people in Latin America look up to Cuba as a model of true independance.
You must be kidding. Cuba is an enemy of the US because in 1962 we discovered they had offensive ballistic missles from the former Soviet Union pointed at us. Since they weren't ICBMs, the amount of damage they could do before we noticed was significantly greater than what the Soviet Union could do directly, so the mutual in mutual assured destruction became a little lopsided.
There is absolutely nothing wrong with an Athlon running at 69 C. AMD Athlon chips are built to withstand on-die temperatures of 95 C (newer generation, older is 90 C) and only require a fan that pushes 16 CFM. Of course, this limit is *ONLY* for socketed CPUs. Slotted CPUs have a much lower tolerance of 70 C.
Unless you are overclocking your CPU (which is rather silly given how frequently new processors come out and how cheap they are), nothing bad will happen with a small CPU fan. The only thing you really have to worry about is the ambient case temperature which should never rise above 42 C.
This is all documented quite clearly in AMD's 'Thermal, mechanical, and chassis cooling design guide.'
So repeat after me: "I do not need to use a turbo prop engine as a CPU cooler. I do not need to worry about my CPU blowing up because it hurts my hand when I touch it. My CPU does not run at a significantly different speed because my CPU is hot."
Of course... what I want to know is if I can buy a dual athlon mp system and underclock the entire thing and use entirely passive cooling. The question is, how low would I have to underclock.