Need to do some quick multiplication? Instead of searching google for a bloody online calculator, press F12 and out of nowhere pops up a calculator instantly.
In class and listening to a boring lecture? Press F12 and quickly play a few games like Pacman, chess, and Snake, right in the dashboard - no internet connection required!
In short, for you to say that base64 encoding does not occur on HTTP connections, is wrong. Period.
Well, I'm just getting this directly from RFC 2616.
19.4 Differences Between HTTP Entities and RFC 2045 Entities
19.4.5 No Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
remove any non-identity CTE ("quoted-printable" or "base64") encoding
prior to delivering the response message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe
transport" is defined by the limitations of the protocol being used.
Such a proxy or gateway SHOULD label the data with an appropriate
Content-Transfer-Encoding if doing so will improve the likelihood of
safe transport over the destination protocol.
As I said, I've seen base64 used in HTTP before, but not in the transfer itself. I've seen it encoded into cookies and form elements (and maybe view-source on webmail messages). The only way HTTP is supposed to deliver something base64 encoded is if the source material was base64 encoded. HTTP uses the MIME types just the same as Linux desktop environments do -- to identify the file type, nothing more.
Sure it's possible some wacky configuration may create this situation, but I'd be willing to pull a number out of my tailpipe that says a badly confiugred web server which does bad things is many order of magnitude more probable than is a ftp server which has been misconfigured to use IDENT.
Well, the reason I choose IDENT is the fact that it's still on by default in most FTP daemons (it's not their fault, really, it was a "different time" when they were designed). I'm sure everyone has experienced the MIME type misconfigurations which result in the webbrowser trying to display a file when it's not text/plain. Or the character set encoding problems where the server reports that it's UCS-2, but it's just iso8859-1, or vice-versa. On the other hand, FTP clients sometimes get the wonderful task of trying to deal with the [broken] "DOS" directory format of IIS FTP.
If you enjoy falied downloads, unknowns as to what you're actually downloading (up to 200% (unicode/local conversion) overhead + 33% (base64) of the 200%), inability to resume downloads (with costs up to 199% of the total bandwidth), by all means, continue to believe that HTTP is great for downloads.
I will admit that it is possible for the server to convert the format into Unicode since nothing in the RFC disallows that. The standard gives implementers three choices for the Accept-Charset header, deliver the document in the requested charset, give a 406 error, or deliver an unacceptable charset anyway. It would be a little unusual to see a conversion, however, since most HTTP servers only use it as a suggestion, not a hardline rule, and happily deliver a non-requested format if that's all they have available. Besides, when we're talking about downloads, they're usually a binary file, and converting those would generally corrupt them.
As for the reliability angle, I guess it's been so long that I've had a stable connection that I've forgotten about the frustration of downloading something 4 or 5 times. Not to mention that when I want to download an ISO, I usually look for a bittorrent link instead of an FTP or HTTP site (since resumability is built-in, and it generally uses all of my bandwidth to download). I do vaguely remember using software like GetRight to resume broken HTTP downloads, and I believe I did hate it.
There are a lot of possible downsides to HTTP. The biggest o
Given that the highly populous countries also tend to be the poorest, I don't think that conclusion follows the data. What would a starving farmer in Africa or China do with something he invented? He's not going to get a patent or anything else measurable. No one in industrialized countries is likely to be interested in this poor man's invention, and there's no one around to buy his invention because everyone else is trying to survive.
Encoding = "header overhead", plus the potential for base64/language encoding, depending on the mine type.
Base64 encoding does not happen on HTTP transfers. The only time I've seen base64 encoding used on webservers is when encoding binary data into cookies. There's obviously nothing in the HTTP spec that prevents base64 content encoding, but it would be an extension, and non-standard (not to mention almost completely useless because HTTP has no reason to be 8bit-clean).
As a measure of oddity potential, it's also possible to actually HTTP-gzip encode a download which is already compressed, which can actually make the download larger.
Gzip (or deflate) is designed to only add 5 bytes per 32KiB (0.015%). Phil Katz designed the format extremely well in this regard. It's a pity that he's no longer with us. Besides, on a properly configured server, you'd specifically exclude already compressed files.
This means with HTTP, it's not unreasonable to expect an exchange of very large headers for each and every file downloaded with HTTP. Sure, you can argue a minimum HTTP header size, but even the smallest is larger than what is required for FTP; including anonymous login.
That is true if you consider the minimum required for both protocols, however, I've noticed many FTPs with very verbose MOTD banners. The one Debian FTP mirror I connected to had a 983 byte MOTD in addition to all the usual protocol parts (this pales in comparison to ftp.kernel.org, which weighs in at a hefty 2208 bytes). With that same request size, I could send a reasonably complex request to any webserver, including cookie, and referrer.
I'll concede that it's easier to resume transfers done via FTP, if for no other reason than the software for FTP access is typically designed to have that feature, and HTTP clients (webbrowsers) do not. Anyone who has ever used IE knows that there's no way to tell IE to resume -- if it wants to resume it will, and it it doesn't want it, it won't. Firefox does the same.
Even if the webbrowsers had well designed resume features, there'd still be obnoxious web applications that pipe the file through the webapp to prevent off-site linking to the download (and these webapps are typically not well designed enough to sent a meaningful Content-Length or Last-Modified header, let alone accept the Range header). So for large files, especially on unreliable connections, FTP has some clear benefits.
One could argue that FTP has a slightly higher latency for download startup but actually has a much lower startup bandwidth demand.
Assuming a meager 30ms roundtrip time, and 1 Mbps connection, you could download 3.7KB for each extra roundtrip an FTP connection would add (at least three). A 42kbps modem user with 150ms latency could get 787bytes per command. This has a large effect on the perception of speed (it gets even worse if the FTP server is [mis]configured to wait for an IDENT response before it finishes establishing the connection).
Generally speaking, if speed is what you want, FTP is what you want.
I still believe that there's no meaningful overhead difference between FTP and HTTP (at least for real-life situations and single file transfers). We're talking about differences of one to two kilobytes for an HTTP request versus 100 bytes to two kilobytes for an FTP connection, with the normal difference probably being around one kilobyte. When talking about files in the hundreds of kilobytes, that's not a high overhead. When I see people say that HTTP has a high overhead, I'm left wondering if they believe that HTTP servers base64 encode binary files like MUAs must (HTTP uses MIME types and some look-alike headers, but not MIME encoding - see RFC 2616 19.4).
Microwaving, instead of heating the surface of the food, heats all of the water molecules within the food. This is exactly the same as if you had a knob and could change the temperature of the water without changing the rest of the food in any way.
This isn't completely true. Microwaves can heat fat and sugars quite effectively, as well.
That means, roughly, that they don't knock atoms into pieces, and thus don't break atomic bonds. They just heat up matter, especially water, since water absorbs microwaves so well.
True, however, the rapid, high heat that microwaving can cause can cause chemical reactions in the food (conventional cooking does, as well). This effect is made worse by the fact that most microwaves can not provide evenly dispersed "heat" to the chamber. All cooking is about breaking down certain chemicals via heat, and creating new ones. Because of the different way microwaves do it, it produces different results than conventional cooking (and different tastes).
That's because it is. There's no valid scientific observation, and no logical scientific model, to suggest that microwave radiation directly affects the nutrition in food.
I'd agree that the sites he posted are pseudoscience, however I'd disagree with you on the second part. The difference between microwave heating and conductive heating is significant, and could quite easily affect the nutrition of the food (for good, or bad). It deserves study, but from people without an agenda they want to further (such as the "modern food processing is poison" agenda of that study).
Then would you kindly point me to where the HTTP spec specifies this encoding overhead? I've only found some special purpose encoding methods (chunked, and byte-ranges), but they aren't typically used for normal transfers.
I can handle being wrong, but the "ha-ha, you're stupid" attitude doesn't help.
I'm going to make a guess here and assume you mean HTTP, not TCP.
Yes, my error. Not the only one, either.
A notable part of the difference is the encoding; FTP can transfer data straight binary - no MIME types or special encoding to send the data over the channel.
The only encoding I can find on that RFC is the chunked transfer coding, which I only ever seen used in streaming applications. It could bloat a transfer somewhat, however. Content coding, on the other hand, is all compression or straight data according to the RFC. HTTP doesn't use Content-Tranfer-Encoding, which is the primary source of bloat in MIME messages. HTTP connections are not base64 encoded, and don't need to be 8bit-clean. I don't see any data overhead in the HTTP spec that would affect anyone in the normal cases. If you can point to the exact section, I'd appreciate it.
All of this is is likely done in less then 100 bytes of data transferred. [...]The amount of data necessary to open a raw TCP connection is so miniscule that it's almost not worth mentioning.
My appologies, I missed some important words when I posted. In the case of FTP, I was thinking of the latency involved. Each roundtrip for each command that needs to be sent, and establishing the data connection increases the time needed to start the transfer. On high latency connections such as dial-up or satellite, the negotation phase can take longer than the entire transfer.
The point I was trying to make was that HTTP uses TCP just the same as FTP does, and that FTP has some downsides to it. However, I'm still not convinced that HTTP has any more data overhead than FTP does. If you have more information on what overhead HTTP has that FTP doesn't, I'd appreciate it.
Microsoft has already tried this tactic with Windows Server 2003, Web Edition. It seems just lowering the pricetag isn't enough to get any meaningful amount of people to switch. The fact of the matter is, it's easier to deploy websites in bulk on Apache, especially a large number of sites sharing a single system (machine, cluster, or whatever). There's also things like authentication (IIS can only do authentication against a Windows username/password, Apache does it against a file by default and can be extended by modules to authenticate against just about anything else without any real programming) which makes it hard to offer users password-protected sections of their own website on IIS versus Apache. To make matters worse, IIS has had problems with hosting a large number of sites on a single machine in the past (I'm told this is fixed in 2003).
To steal Microsoft's marketing, Windows Server's TCO is higher than Apache on Unix when doing webhosting. It requires less administration to host more websites per server using Apache.
Note that Netcraft's numbers are per domainname. I seem to recall them mentioning a long time back that despite the fact that IIS only accounted for something like 20% of the domain names surveyed, it accounted for 50% of the distinct IPs (and therefore, probably machines).
FTP does not send ACK's, rather, it uses TCP. At the protocol level, where the data is already queued up, the TCP stack sends ACKs as part of the TCP protocol. FTP smartly so, relies on TCP to do it's part. Thusly, FTP has very low overhead. Most people don't realize that HTTP is fairly high overhead compared to the lean/mean FTP protocol. If bandwidth matters, FTP is still king.
That's a rather funny thing to say. FTP and HTTP both use TCP. The only time FTP has less overhead than TCP is when you're retrieving several files. Otherwise, the overhead of FTP can be significantly higher than HTTP (logon banners). In addition, there is more bi-directional communication required to start an FTP transfer. For HTTP, you send the request and sit back and wait for the data. With FTP, you have to login (USER, PASS), which both require you to wait for confirmation before you can PORT and RETR. Not to mention the overhead of establishing another TCP socket to pass the data over.
If you need to retrieve a tree structure of files, download several files from a single server, or need to upload files, FTP is the way to do it. If you need to download only one file, or several files in parallel (typical webbrowsing), then HTTP is your friend.
How many of those sites are just link farms used to pollute search engines like Google? I'm noticing more and more of these linkfarms getting high placement when searching for things. It's making searching frustrating.
And he's supposed to retroactively watch his mouth how, exactly? This was an old article, which he had removed from his site (to which naysayers will likely say that he's trying to "cover his tracks!"). Ironically, I find your sig quote to be quite applicable in this case ("Good judgement comes from experience, and experience comes from bad judgement."). Maybe his views changed somewhat, or maybe he grew up a bit, or maybe he's just covering his ass. Naysayers will always think he's up to no good, and the fans will always think he's righteous. Regardless, the technology is extremelyuseful.
Brahm (from TFA) says that "manifesto" was written as a parody, and it's up to you to decide if you want to believe that or not. The sad thing isn't that his words can be used against him, but the fact that his words can be used as the only evidence required to distinguish between a lawful technology invention, and an unlawful one.
Sun has a large number of wonderful and intelligent people working for them, but unfortunately, they have this one annoying aspect: They have a strong "us vs. them" mentality. For a long time it was "us vs. Microsoft", but recently they seem to have changed their tune to "us vs. GPL/Red Hat". Their ranting about Microsoft when they were in the first stage is just as much nonsense as it is today when they rant against the GPL.
Frankly, this part of their corporate culture is hurting them. People read things like this, and get the idea that Sun doesn't work well with others. They get the idea that Sun wants you to either run entirely their stuff, or run nothing of theirs. Microsoft learned this the hard way during their fight with Novell. As they resisted Novell, their products didn't go anywhere because no one wanted to rip out all their stuff to switch. As they added interoperable services and toned down the anti-Novell rhetoric, they gained traction in the entireprise because there was less risk of putting in the server.
Frankly, if they'd just focus on the business end of things -- why their product is better than the competition, and leave the religious "Holy Wars" such as licensing out of it, they'd be much further ahead. You can read a feature or product comparison and get valuable information, and believe the information you read. You read one of these rants from a Sun CxO, and you wonder why they're so scared.
No, he was insinuating that someone with "serious perl skills" employed by a shady company must be partaking in that shady behaviour. It's still defective logic, but it's a bit more reasonable than what you posted.
Besides, even very, very smart people can delude themselves into thinking their work, which could use used to harm others is only being used for helpful purposes.
Have you seen Intel's made up number system? Is a Intel Pentium 4 571 faster or slower than the Intel pentium 4 630? And how does it compare to the Intel Pentium M processor 705? Even if you did have the Mhz numbers in those cases, does it really tell you anything useful? The P4 630 has 2MB cache, but is much slower than the 571, so which is faster? And the 705 has a much lower clock speed than any of them, but might outperform them all because of it's higher efficiency.
To be fair, AMD had some problems during the K5/K6 era. The processors were somewhat flaky, and didn't always run properly at their labeled speed.
Now, it's entirely possible we were getting rebadged K6-2s and that's why we were having so many problems with them not running at their labelled clockspeed. Regardless of if we were or not, it has soured a lot of people's opinions on AMD because of that. The end result is, we don't sell AMD chips anymore.
Myself, I have an Athlon XP system, and it works fine.
If it's a big enough investment to get worried about it being stolen, insure it! It's usually fairly cheap to add it as a rider to your contents insurance on your house or apartment. I doubt it'll cost more than $30-$50/yr in most places, and if the thing is important to her school work why don't you have it now? Besides, at an average life of 5 to 6 years for a laptop, that's only $300. You can't even buy a new laptop for $300.
I'm not an insurance salesman, but I have had my laptop stolen before (at work, no less!). Having insured it, it let me get a new laptop, and put in extra money out of my own pocket to get a much nicer one than I had before (along with correcting mistakes I had made about the importance of screen size).
How do the thieves know about the passwords in advance?
They don't know about it, but that means they stand a greater chance of being caught with the machine when they either take it into a repair shop to get the password removed, or try to sell it somewhere. There is a better chance of recovering the machine, and having the person responsible for stealing it being caught. If the person who stole it is smart enough to try and start up the machine before getting rid of it, then there's a good chance it'll end up in the nearest dumpster.
Until you take the hard drive off to another machine, of course.
Most recent laptops make use of the ATA locking feature when you set a start-up password to make the hard drive inaccessable until your password is given. According the the hard drive vendors, the only way to clear the password is to send it the command to wipe the drive. Data recovery places say they know how to get around the passwords, though [and they're not saying how they do it, either:-( ].
Most boot-up passwords on notebook computers can not be cleared except by the manufacturer (or by highly motivated thieves who know an awful lot about electronics). There's no CMOS battery to pull to wipe out the password, and even if you could, there's still the password on the hard drive. This simple measure means getting the laptop into good enough shape to sell is more effort than it's worth.
My other suggestion is insurance. It shouldn't cost too much ($50/yr) and it'll cover theft. I had my laptop stolen once, and it was insured, so I replaced it easily. Not only that, it was quite easy to deal with the insurance folks (no horror stories here!).
Besides, even if you know what IP it's coming from, what goes does that do you? Are you going to go vigilante on them? The police aren't likely to care much -- they don't usually give such thefts very high priority.
Households would probably be a better measure than population. I assume the US is similar to Canada which has 2.6 persons per household, so that puts US's numbers at 32%. No idea about China, though. I would assume population per dwelling is higher there, but I don't know how much higher.
I believe it. Here in Manitoba, it's generally cheaper to get broadband connectivity than dial-up. 128/128kbit DSL or cable at $27/mo is cheaper than $15-$20/mo plus tying up your phone line all the time. Even rurally, high speed internet is available to most average sized towns.
Also, if the population:dwellings ratio holds, the number of dwellings should've increased to over 12M since the 1996 census is 9 years old. Stats Canada has estimated the population of Canada to be over 32 million at this point (versus almost 29M in 1996). This would put the ratio at closer to 40%.
Now, rename your true admin account (via a group policy).
Okay, I really hate this advise. Renaming your administrator account gets you no additional security, only a false sense of one. If you want to secure that account, disable it. The Administrator user has a well-known SID, which makes it fairly trivial to convert back to a username. Getting locked out is not really much of a problem either because this offline password changer can re-enable and change the password of any user on the system.
I have never seen a reputable source ever suggest renaming the root account on any UNIX platform, so I'm not sure why that advise is so popular on Windows. Personally, I like the method Ubuntu Linux has come up with for securing the administrative user -- root is disabled, and all administration should be done via sudo.
It gets in my way, especially when using a program that uses different icons for different windows. For example, in Outlook, you might be looking for a window that has an envelope icon, but can't find it because it got collapsed into the outlook icon group. I also find it moderately disorientating when the state of the taskbar changes drastically because a new systray icon appeared, or window opened.
Frankly, the default implementation is broken in Windows. Either the feature should be always enabled, or always disabled, not suddenly turn on when certain arbitrary conditions are fulfilled. I realize the behaviour of the grouping can be controlled via registry hacks or via tweak programs, but it's still poor UI design to have these "modes", especially when the computer decides to switch modes on you.
bizarro network settings (ever wonder why seemingly every computer in a home network gets configured with bridging?)
I've NEVER seen that as a default. I have, however, seen a large number of PCs with ICS (NAT) enabled for no reason, mainly because people misunderstood the question about "sharing" their internet connection during the home networking setup wizard.
It's an incomplete standard covered by a patent awarded to Microsoft who is only providing it under non-OSI compatible terms (it's non-transferrable, so each party needs to get a license directly from Microsoft). This is Microsoft trying to bully everyone else into adopting their patented standard. However, I believe they have overestimated their strength in this matter.
Slashdot Mirror
Well, I'm just getting this directly from RFC 2616.
19.4 Differences Between HTTP Entities and RFC 2045 Entities
19.4.5 No Content-Transfer-Encoding
As I said, I've seen base64 used in HTTP before, but not in the transfer itself. I've seen it encoded into cookies and form elements (and maybe view-source on webmail messages). The only way HTTP is supposed to deliver something base64 encoded is if the source material was base64 encoded. HTTP uses the MIME types just the same as Linux desktop environments do -- to identify the file type, nothing more.
Well, the reason I choose IDENT is the fact that it's still on by default in most FTP daemons (it's not their fault, really, it was a "different time" when they were designed). I'm sure everyone has experienced the MIME type misconfigurations which result in the webbrowser trying to display a file when it's not text/plain. Or the character set encoding problems where the server reports that it's UCS-2, but it's just iso8859-1, or vice-versa. On the other hand, FTP clients sometimes get the wonderful task of trying to deal with the [broken] "DOS" directory format of IIS FTP.
I will admit that it is possible for the server to convert the format into Unicode since nothing in the RFC disallows that. The standard gives implementers three choices for the Accept-Charset header, deliver the document in the requested charset, give a 406 error, or deliver an unacceptable charset anyway. It would be a little unusual to see a conversion, however, since most HTTP servers only use it as a suggestion, not a hardline rule, and happily deliver a non-requested format if that's all they have available. Besides, when we're talking about downloads, they're usually a binary file, and converting those would generally corrupt them.
As for the reliability angle, I guess it's been so long that I've had a stable connection that I've forgotten about the frustration of downloading something 4 or 5 times. Not to mention that when I want to download an ISO, I usually look for a bittorrent link instead of an FTP or HTTP site (since resumability is built-in, and it generally uses all of my bandwidth to download). I do vaguely remember using software like GetRight to resume broken HTTP downloads, and I believe I did hate it.
There are a lot of possible downsides to HTTP. The biggest o
Given that the highly populous countries also tend to be the poorest, I don't think that conclusion follows the data. What would a starving farmer in Africa or China do with something he invented? He's not going to get a patent or anything else measurable. No one in industrialized countries is likely to be interested in this poor man's invention, and there's no one around to buy his invention because everyone else is trying to survive.
Base64 encoding does not happen on HTTP transfers. The only time I've seen base64 encoding used on webservers is when encoding binary data into cookies. There's obviously nothing in the HTTP spec that prevents base64 content encoding, but it would be an extension, and non-standard (not to mention almost completely useless because HTTP has no reason to be 8bit-clean).
Gzip (or deflate) is designed to only add 5 bytes per 32KiB (0.015%). Phil Katz designed the format extremely well in this regard. It's a pity that he's no longer with us. Besides, on a properly configured server, you'd specifically exclude already compressed files.
That is true if you consider the minimum required for both protocols, however, I've noticed many FTPs with very verbose MOTD banners. The one Debian FTP mirror I connected to had a 983 byte MOTD in addition to all the usual protocol parts (this pales in comparison to ftp.kernel.org, which weighs in at a hefty 2208 bytes). With that same request size, I could send a reasonably complex request to any webserver, including cookie, and referrer.
I'll concede that it's easier to resume transfers done via FTP, if for no other reason than the software for FTP access is typically designed to have that feature, and HTTP clients (webbrowsers) do not. Anyone who has ever used IE knows that there's no way to tell IE to resume -- if it wants to resume it will, and it it doesn't want it, it won't. Firefox does the same.
Even if the webbrowsers had well designed resume features, there'd still be obnoxious web applications that pipe the file through the webapp to prevent off-site linking to the download (and these webapps are typically not well designed enough to sent a meaningful Content-Length or Last-Modified header, let alone accept the Range header). So for large files, especially on unreliable connections, FTP has some clear benefits.
Assuming a meager 30ms roundtrip time, and 1 Mbps connection, you could download 3.7KB for each extra roundtrip an FTP connection would add (at least three). A 42kbps modem user with 150ms latency could get 787bytes per command. This has a large effect on the perception of speed (it gets even worse if the FTP server is [mis]configured to wait for an IDENT response before it finishes establishing the connection).
I still believe that there's no meaningful overhead difference between FTP and HTTP (at least for real-life situations and single file transfers). We're talking about differences of one to two kilobytes for an HTTP request versus 100 bytes to two kilobytes for an FTP connection, with the normal difference probably being around one kilobyte. When talking about files in the hundreds of kilobytes, that's not a high overhead. When I see people say that HTTP has a high overhead, I'm left wondering if they believe that HTTP servers base64 encode binary files like MUAs must (HTTP uses MIME types and some look-alike headers, but not MIME encoding - see RFC 2616 19.4).
There are obvious uses for FT
I can handle being wrong, but the "ha-ha, you're stupid" attitude doesn't help.
The point I was trying to make was that HTTP uses TCP just the same as FTP does, and that FTP has some downsides to it. However, I'm still not convinced that HTTP has any more data overhead than FTP does. If you have more information on what overhead HTTP has that FTP doesn't, I'd appreciate it.
To steal Microsoft's marketing, Windows Server's TCO is higher than Apache on Unix when doing webhosting. It requires less administration to host more websites per server using Apache.
Note that Netcraft's numbers are per domainname. I seem to recall them mentioning a long time back that despite the fact that IIS only accounted for something like 20% of the domain names surveyed, it accounted for 50% of the distinct IPs (and therefore, probably machines).
If you need to retrieve a tree structure of files, download several files from a single server, or need to upload files, FTP is the way to do it. If you need to download only one file, or several files in parallel (typical webbrowsing), then HTTP is your friend.
How many of those sites are just link farms used to pollute search engines like Google? I'm noticing more and more of these linkfarms getting high placement when searching for things. It's making searching frustrating.
Brahm (from TFA) says that "manifesto" was written as a parody, and it's up to you to decide if you want to believe that or not. The sad thing isn't that his words can be used against him, but the fact that his words can be used as the only evidence required to distinguish between a lawful technology invention, and an unlawful one.
Frankly, this part of their corporate culture is hurting them. People read things like this, and get the idea that Sun doesn't work well with others. They get the idea that Sun wants you to either run entirely their stuff, or run nothing of theirs. Microsoft learned this the hard way during their fight with Novell. As they resisted Novell, their products didn't go anywhere because no one wanted to rip out all their stuff to switch. As they added interoperable services and toned down the anti-Novell rhetoric, they gained traction in the entireprise because there was less risk of putting in the server.
Frankly, if they'd just focus on the business end of things -- why their product is better than the competition, and leave the religious "Holy Wars" such as licensing out of it, they'd be much further ahead. You can read a feature or product comparison and get valuable information, and believe the information you read. You read one of these rants from a Sun CxO, and you wonder why they're so scared.
Besides, even very, very smart people can delude themselves into thinking their work, which could use used to harm others is only being used for helpful purposes.
Have you seen Intel's made up number system? Is a Intel Pentium 4 571 faster or slower than the Intel pentium 4 630? And how does it compare to the Intel Pentium M processor 705? Even if you did have the Mhz numbers in those cases, does it really tell you anything useful? The P4 630 has 2MB cache, but is much slower than the 571, so which is faster? And the 705 has a much lower clock speed than any of them, but might outperform them all because of it's higher efficiency.
Now, it's entirely possible we were getting rebadged K6-2s and that's why we were having so many problems with them not running at their labelled clockspeed. Regardless of if we were or not, it has soured a lot of people's opinions on AMD because of that. The end result is, we don't sell AMD chips anymore.
Myself, I have an Athlon XP system, and it works fine.
If it's a big enough investment to get worried about it being stolen, insure it! It's usually fairly cheap to add it as a rider to your contents insurance on your house or apartment. I doubt it'll cost more than $30-$50/yr in most places, and if the thing is important to her school work why don't you have it now? Besides, at an average life of 5 to 6 years for a laptop, that's only $300. You can't even buy a new laptop for $300.
I'm not an insurance salesman, but I have had my laptop stolen before (at work, no less!). Having insured it, it let me get a new laptop, and put in extra money out of my own pocket to get a much nicer one than I had before (along with correcting mistakes I had made about the importance of screen size).
My other suggestion is insurance. It shouldn't cost too much ($50/yr) and it'll cover theft. I had my laptop stolen once, and it was insured, so I replaced it easily. Not only that, it was quite easy to deal with the insurance folks (no horror stories here!).
Besides, even if you know what IP it's coming from, what goes does that do you? Are you going to go vigilante on them? The police aren't likely to care much -- they don't usually give such thefts very high priority.
That wasn't TCPA, that was SDMI. TCPA is an encryption based technology. SDMI was a watermark based technology. SDMI is all but dead at this point.
Households would probably be a better measure than population. I assume the US is similar to Canada which has 2.6 persons per household, so that puts US's numbers at 32%. No idea about China, though. I would assume population per dwelling is higher there, but I don't know how much higher.
Also, if the population:dwellings ratio holds, the number of dwellings should've increased to over 12M since the 1996 census is 9 years old. Stats Canada has estimated the population of Canada to be over 32 million at this point (versus almost 29M in 1996). This would put the ratio at closer to 40%.
I have never seen a reputable source ever suggest renaming the root account on any UNIX platform, so I'm not sure why that advise is so popular on Windows. Personally, I like the method Ubuntu Linux has come up with for securing the administrative user -- root is disabled, and all administration should be done via sudo.
Frankly, the default implementation is broken in Windows. Either the feature should be always enabled, or always disabled, not suddenly turn on when certain arbitrary conditions are fulfilled. I realize the behaviour of the grouping can be controlled via registry hacks or via tweak programs, but it's still poor UI design to have these "modes", especially when the computer decides to switch modes on you.
It's an incomplete standard covered by a patent awarded to Microsoft who is only providing it under non-OSI compatible terms (it's non-transferrable, so each party needs to get a license directly from Microsoft). This is Microsoft trying to bully everyone else into adopting their patented standard. However, I believe they have overestimated their strength in this matter.