Flash media will typically have about 100,000 read/write cycles before failing. It's sometimes advertised as millions, but practically, no one makes media that goes over 300k, and no one makes media that goes under maybe 10k. Used naively (e.g. CompactFlash in an IDE-to-CF adapter as your / partition), the time to failure is on the order of days. Log files, file access times, and bits like that get written over and over and over, with some files being touched every few seconds. You've got 86,400 seconds in a day, which is in the same ballpark as flash endurance. I've seen drives fail this way.
Used properly, however, a SSD will last forever. Typically, the drive will include load spreading somewhere in the chain. The algorithms are a bit more clever than what I'm about to describe, but naively, if you've written the same location more than a few times, you move that data to a different location. This are often implemented in the drive's firmware, but may also be implemented in the file system (Linux comes with a few flash file systems that do this -- indeed, OLPC uses one of them). Used this way, the solid state drive will last for many decades of continuous use before failing, and will eventually fail for the same mechanisms as any other old IC. A 40GB drive, written at 100Mbps, will take about an hour to overwrite completely. With an endurance of 100,000 cycles, you get a bit over 10 years of continuous write at that speed before you run into endurance limits. With normal write frequencies, that means it'll last essentially forever.
Data is stored as charge on a conductor surrounded by insulator, but the insulator isn't perfect, and eventually, electrons do drift on and off. As a result, data stored in flash has a lifetime on the order of 10 years if it doesn't get refreshed. Of course, refreshing it is trivial (read out data, write it back).
Of course, with a Sony laptop, the major question isn't drive lifetime, but how long until the hinges or latches break. Sony laptops typically frequently have mechanical failures within a few months of purchase. Sony skims on quality quite a bit, these days, and is mostly running on reputation for quality acquired many years ago. That, combined with shooting for the lowest possible weight (and skimming on construction quality to save weight too) makes for pretty flimsy laptops.
The problem is that Nokia considers GNU/Linux tablets to be unsupported abandonware only 1.5 years after introduction. The tablets are loaded with proprietary and binary-only drivers and software, which means once official support goes away, you're left with a very expensive paperweight. Linux Weekly News reported on this just this week.
Sony Electronics has gone down the tubes in the past decade or so (it started a while before that -- old school Sony TVs and CRTs had a full metal Faraday cage around the tube, and touches like that went sometime before then). Nowadays, Sony electronics is mostly living off of the reputation it developed up through the 80s or 90s, when it delivered truly exceptional quality products at a high premium. Sony still charges a premium (albeit a smaller one), while delivering mostly sub-par products.
The Sony laptops are light and attractive, but almost universally have mechanical problems (hinges and latches break). The MP3 players are a disaster. A relative bought one, and it wouldn't play MP3s -- he had to convert music into Sony's proprietary atrak format before it worked. He returned it and bought an iRiver. The headphones give reasonable (but not exceptional) audio quality for the price, but generally break after about 3 months of use. Cameras have nice imagers, mechanically filmy (but not horrible), but as with most Sony, try to force you into a proprietary, incompatible, overpriced technology stack with MemoryStick. PS3 was an unqualified disaster. Home audio equipment is okay, but suboptimal on the price/performance curve (e.g. Kenwood generally has better-sounding, better-quality equipment for the same price in my price range).
I also really, really, really hate the attempted "synergy." If you want the PS3, you need to pay for Blu-ray. Everything you buy will use MemoryStick, and where possible, use proprietary cables, plugs, and formats to try to lock you in to buy other Sony products, and not work well with non-Sony products.
It's actually a problem. I had a bad experience with Travel Document Systems. I wrote a page on it. Because of SEO type crap, and companies like reputation defender, it is not even showing up. I wish there was some way of dealing with SEO and search engine spam. I'd love to be able to search for reviews, criticisms, and things like that, without having to go through 50 commercial pages advertising products first. Maybe if we could tag pages "noncommercial" and search noncommercial pages, or something?
Sounds like dumping. Offer a product for free to destroy competition, so you can later charge for it. If I were VMWare, I'd get the DOJ and its international friends involved. They'd probably win in at least one country.
Having an EULA pop up during the first run is idiotic for a free software project. There is no reason why the user must accept a license to run this program. EULA acceptance screens are needed for programs that add restrictions beyond regular copyright law (e.g. no reverse engineering). For programs with a free software license, which add additional rights (e.g. modify, but only if you distribute source to changes), it is not. The user either accepts or does not. If she does not, she has the rights granted by plain old copyright law, which means she can run it, but no copies or modifications. If she does, she has the additional rights under the EULA. The GPL has a nice clause and explanation about this.
As is, this is nust an unneccessary additional user hassle. Why do we copy stupid things from commercial software when it doesn't apply? If the trend continues, by FX3, we'll have to type in a 20 digit product code to make sure it's a valid copy...
What we need now is one of those government black-ops biolabs to mutate H5N1 (and other potential flus) into a human-contagious but not very aggressive strain. Whatever the state of technology, we ought to be able to do better than the random mutation mother nature will give us. If H5N1 mutates into a form that starts killing massive numbers of people in the wild, the black ops would release their strain into all the major airports in the US (or in the world). Whereas the natural mutation might have 5-50% fatality rate, the human-engineered would ideally be below 1%, and would immunize everyone before the natural version came over from wherever it first mutated (probably China).
This is similar to the vaccine theory, with two twists:
In contrast to a legally-approved vaccine, this would be allowed to have a significant mortality rate. As a result, it would be fairly easy to engineer (normal vaccines are very hard, since they must be very, very safe)
Unlike modern vaccines, it would spread between people. As a result, we wouldn't have the manufacturing problems of making vaccine for the whole world and distributing it.
My guess is that this would be illegal, or at the very least, would outrage large numbers of people. As a result, I'm suggesting the black ops approach. I was contemplating mailing the CDC and the White House with the suggestion, but I appear to be too lazy.
Note that this would only work for flus. Most other diseases are not nearly contagious enough -- a flu, in contrast, hits basically 100% of the population (usually, not very severly).
The recommendations don't follow from the user experience. Several don't necessarily follow, but I'll present the dominant problem here:
Maintain the Abstraction from the Underlying System
This is almost universally the wrong approach -- this is what Windows tries to do, and MacOS avoids. The key is to make the underlying system simple, and make the UI reflect that.
The problem with abstracting the two is that it leads to bit rot. At some point, the Windows registry will think a file is in one location, whereas the file is actually in another. Or the UI will misunderstand the way that the 5 options in the configuration file should be presented as 2 options in the UI. Or there will be some underlying binary configuration file, with some option that's not available in the GUI, that somehow gets flipped, breaking the whole system.
You very strongly don't want an abstraction. On the Mac, installing an application (I haven't use OSX, so my knowledge is based on the older versions) is as easy as dragging the folder onto the hard drive. To erase, you wipe it. On Windows, if you wipe an app like that, it'll leave bits and pieces of itself scattered throughout the registry, links in menus, DLLs in system folders, and dozens of other places. Worse, the uninstaller will often no longer work. Most clueless users, if they try to erase an application the wrong way, will end up with a semibroken system, since there are different levels of abstraction that do not maintain consistency.
The whole Windows (and increasingly, GNU/Linux) approach of abstracting out underlying complexity is flawed. The trick is to eliminate the underlying complexity, and have a single set of simple structures that the GUI tools (or the users manually) operate on.
When I first used Red Hat in '96, the types of issues that threw me were: I wanted to change the login text. I grepped for the old login text, found/etc/issues, and I edited it. It worked. I rebooted. It went away. It took me the longest time to figure out that an fucking script in/etc/rc.something/ was overwriting it. The information was stored in two places. I overwrote the wrong one, and boom. I was fucked. I stopped using Red Hat precisely because of the complex configuration scripts, which made the system fragile and ultimately, easy to break and difficult to use.
This shows up a huge number of places -- especially in a heterogenous environment like GNU/Linux, you often have multiple configuration tools. I can download a half dozen Apache configuration tools. Very often, if you run one, then switch to another, the thing no longer works, since they edit different options in different ways.
One way to implement this (presented in an oversimplified fashion) is to first design what you want the UI to look like. Once you know, you design the underlying structure to match. This is the opposite of what most GNU/Linux and Windows developers do, where they try to engineer the most flexible underlying structure possible, and then develop a UI on top of that. This doesn't necessarily lead to less flexible underlying structures -- it's just that to have a good UI, you want to give some thought to the user experience when designing the engine, and especially, the configuration files.
What Engim is doing is actually a good bit more sophisticated than any of the Slashdot posts imply. When you transmit, you usually have two types of bandwidth: how much bandwidth you are using, and how much you are interfering with. For instance, a simple AM broadcast will require maybe 8KHz of the spectrum on which it actually transmits data. Since transmitters are imperfect, however, it may actually interfer with transmitters on, say, 20KHz of spectrum.
As a result, if you're in a big company, and set up 3 off-the-shelf 802.11b access points, on 3 different theoretically non-overlapping bands, you'll still get something on the order of, maybe, 1.6x the bandwidth you'd get with one.
What Engim does is it has an insanely fast ADC/DAC front-end, that grabs the entire 802.11b/g spectrum, including all the bands. Then, they have a fancy DSP that looks at the bands together, figures out how they interfere with each other, and sorts them out. As a result, in a theoretical world, where only notebooks were transmitting to the access point, they would have 3x the bandwidth. They do fancy transmitting techniques, so that notebooks on all 3 bands can hear at the same time. So if the wireless access point was transmitting, and all the notebooks receiving, they would, again, have 3x the bandwidth.
The problem is that notebooks don't have this sort of technology, so when they transmit, they cause interference for other notebooks. If the Engim WAP transmits on band 1 to notebook A, and notebook B transmits on band 2 at the same time, the transmission from notebook B may interfere with that from the WAP. As a result, in practice, it's a little less than 3x the bandwidth, but not a heck of a lot less. They try to juggle notebooks between bands, based on location, so this doesn't happen, but it doesn't really work too well.
The technology they have is wicked cool, actually. For those worrying about interference -- it's really not a problem. First of all, this isn't for personal WAPs, but for $1000 access points you'd see on an IBM or Microsoft campus. They won't be going in apartments any time soon. You need a minimum of 3 very expensive chips for a single WAP (RF front-end, ADC/DAC, and DSP). Those places don't tolorate employees setting up their own WAPs anyways.
Second, you still have the remaining bands. The way 802.11 works, with the interference issues described above, if I set up a WAP, and my neighbor sets up a WAP, we will be interfering. We'll both have wireless networks, but both with reduced bandwidth. You can still set up your own WAP on any of the remaining bands, and it'll work -- it's just that if you try to send a packet at the same moment as the Engim network, you'll get a collision and retransmit. This is what happens anyways. 802.11 was never designed to have many, non-interfering bands. It was designed to have many, interfering, overlapping networks, with packet collisions. By design, the total bandwidth of 5 overlapping networks, in the same area, is the same as if there was only one. Each network gets 1/5 of the bandwidth then. This is the exact issue Engim technology is meant to address.
In terms of cell phones, etc. my impression is that the Engim technology was actually smart enough to look for "interference sources" and try to pick bands around them. This last bit is from an Engim PowerPoint slide, so I'm not sure if it's actually implemented or vaporware.
I would like to see whether this is, indeed, trusted computing. The article was somewhat vague in some ways. If it is the full-fledged hardware portion of the Pallidium initiative, as part of the article implies, it's very, very bad. If, instead, it's a way to save money on a system restore disk by having the hardware hide a portion of the hard drive from normal software, it's annoying, but probably fine, depending on how it is done (if there's a PKI, that's bad, but if it's just read-only, that's fine).
If trusted computers do appear in your area, I would suggest the following strategy for making them go away:
Order a trusted computer from one of the trusted computer makers
Return it
Go back to step 1
This assumes the companies have a 30-day no-questions-ask return policy (which is usually the case). You can even say that the "trusted" computing was the reason you returned it. Once they start losing tons of money, it'll go the way of DiVX (not the codec -- the old DVD standard which needed to call home to get authorization). It was pushed by Circuit City, which had a ton of people do this to them, so they introduced restocking fees, and lost a lot of customers who knew nothing about DiVX. Eventually, Circuit City backed off the DiVX thing.
If you want to be illegal (which I don't recommend), some people have a modified scheme:
Order a trusted computer from one of the trusted computer makers
Take out the batteries (which are potentially explosive), and connect the battery plugs or some port in back to 120VAC, thereby frying the motherboard
Return it as defective
Go back to step 1
This costs them a heck of a lot more, and gets around the place of returns without restocking fee. If you need to buy a DRMed product, you can also use this to make sure the company pays the manufacturing costs for 2 of 'em instead of one, and loses money on the sale. It is, however, illegal, and probably unethical.
I've done government work. In general, government people are lazy. When you apply for grants, you have two choices:
Use LaTeX and xv for text and presentations
Use Word and Presentations, and give the guy a copy
After you do the presentation, if the guy likes you, he'll do a presentation to his boss, who will pick out his favorite projects from the first filtering from his underlings. The underling you presented to is usually lazy, so in all likelyhood, this presentation will consist of cut-and-pasting from your Word and Presentations documents. If you give him the documents in.tex/.dvi/etc. formats, unless your grant proposal is absolutely, completely brillian, he'll probably be too lazy to redo your presentation, so he will just not bother presenting you to his boss, and you lose the grant.
If I were a lazy administrator drone in the attorney general's office, I would have documents on my desk from MPAA, P2P United, EFF, FSF, RIAA, etc., all in.doc format. I would then read all of the documents, discuss with the attorney general what our stance should be, and cut-and-paste sections presenting that stance from all of the documents on my desk. It saves me time, and avoids duplication of work. It's how the government works.
I don't doubt many politicians are corrupted by the RIAA/MPAA. The fact that they have MPAA-authored text, however, is not direct evidence of this. The best ways to find corruption is to follow the money, as well as to look for unreasonable actions. This may be an unreasonable action, but the fact that the document went through or from the MPAA/RIAA says nothing.
There is a difference between ethics and legality. You cannot legally use MP3s in your country. You've been conditioned to think of copyright as "intellectual property," rather than a social contract between creator of content and the consumer, which associates concepts like stealing and piracy with what is, in the end, not theft but copyright violation. This brings with it the feeling of guilt. You've also been conditioned, probably by the German society, that laws were meant to be followed and that ethical people follow laws.
The reality is quite different. Laws are, at best, an attempt to codify and enforce ethics by committee. The committee is usually right, but does, on occasion, make errors. In those cases, there is sometimes no compelling reason to follow the laws. Worse, as in the case of Eastern Europe under Communism, the committee maybe corrupt, in which case, the ethical thing to do is often civil disobedience, and intentionally breaking laws. To me, this feels like one of those cases.
You should strive to follow ethics, not laws. I would argue that there is a compelling ethical argument not to give money to record companies, so they can better buy off governments to pass acts like the DMCA mandating DRM, and destroy your right to write free software capable of interacting with the mainstream world (you cannot, right now, write free legal DVD players, or players for DRMed CDs, even if they have zero uses for copying content). If this is allowed to continue, in short time, GNU/Linux computers will no longer be able to legally access music and video, followed by books and electronic texts, and eventually, mainstream documents. Once this happens, GNU/Linux and free software will have been effectively legally banned from any sort of desktop use (and quite possibly, eventually, server use).
I would sidestep the issue of benefiting personally from illegal action by making sure you do not benefit. Donate the money you would have spent on CDs to either the artists, or organizations like the FSF, the EFF and similar. Make sure you donate at least as much as you have in illegal content. Then, gather the content illegally, and use it as you see fit. I believe this is the second most ethical course of action (the most ethical being that you only boycott all mainstream music, and listen only to independent labels uninvolved in the push for DRM).
It's good that SEC is investigating them, although it is not clear whether they will find anything. This is really as much or more FTC's arena. Specifically, it would be beneficial if a large number of people filled out FTC's complaint form to maybe get some action about false advertising, slander, unfair competition, and so on. It is comparatively easy to show that SCO has directly lied on a large number of occasions. There is probably enough for SCO to convict it of false advertising on the Linux license front.
Cringly somehow equates difficulty of reverse-engineering with security (in the sense of buffer overflows, etc.). Other than weak arguments about security-by-obscurity, it holds no water. The NSA has automated analysis tools that look for buffer overflows and the like. Plenty of attacks come about with people just throwing random packets at a machine, and seeing what crashes it. In addition, in spite of the well publicized NT source release, Microsoft licenses Windows source to universities and other organizations, and it is fairly wide-spread. Anyone who really cares can get it.
Very few people will reverse-engineer source code to make a competing product. With the exception of file formats and the like (Word format, DeCSS, etc.), it is generally much faster to reinvent than it is to reverse engineer -- this is often true even when you have the original source code, with comments. I guess the only other place I can think of where reverse-engineering might make sense is highly-optimized algorithm (3d rendering, video compression, etc.), but even there, it's sketchy as to whether there is any real benefit.
He goes on to talk about how source code watermarks are impossible to remove. Quite frankly, I've never seen a watermark in a non-lossy data format that's impossible to remove. They just take different amounts of time and effort.
I used to think this guy had a clue, or some insight once in a while. This article is just so confused, and wrong in so many ways, that we Cringeley has no grasp of basic technology. Damn. it sucks.
I would like to point out that the FSF is also not a bunch of zealots. RMS is the founder, but it is run by a lot of people. Even if you don't like RMS (although a lot of the reason he's been marginalized stems from ESR badmouthing him/exaggarating his problems, rather than RMS himself), they are a big organization. Most of the other head honchos over the FSF are quite amazing.
Eben Moglen (the chief counsel of the FSF, law professor at Columbia) is extremely reasonable, competent and friendly. He is a brilliant lawyer and an excellent public speaker. You should go to one of his talks at some point -- I cannot overemphasize how good he is. A large number of the FSF charity events are headed by him for precisely that reason. Heck, try reading some of his writings.
Gerry Sussman is President of the FSF. He is one of MIT's top professors. He is the creator of the Scheme programming language, the guy who proved the motion of the solar system is chaotic, and is responsible for dozens of other similar breakthroughs in computer science, math, physics, and electronics. He is brilliant, but also one of the nicest, most reasonable guys I know.
I've met both. I can assure you neither of these guys could be described as a zealot, or anything close to a zealot.
It is very unfair to characterize the FSF simply by one man, even if he is the founder. The FSF is very good at what it does. RMS is one piece of the equation, and acts as a sort of moral compass for the organization as a whole (and his morals are indisputable, although you may argue with his tactics or interpersonal skills). However, people like Eben and Gerry handle many of the FSF's operations, and they do their jobs competently, and exceedingly well.
A package is a file that contains information needed to install and uninstall a program. They are similar to MSI files, but have a number of advantages, mostly stemming from the fact that free software is, well, free, and so you can get it without buying it. Proprietary software comes on CDs, whereas free comes over the Internet. Upgrading free software is very "light weight" whereas upgrading proprietary software is usually very "heavy weight." This gives a different distribution model.
This has several effects. If I distribute a nonfree 10MB program UberTool, that requires the nonfree 20MB MegaLib, I'd better distribute MegaLib with UberTool. If both are free, I can distribute them seperately -- if the user already has MegaLib, he'll just install UberTool.deb. If he doesn't, the package management system will know where to grab MegaLib from, will download MegaLib.deb, and install it.
Furthermore, if I'm going from Office 97 to Office 2000, it's because I bought money on a CD, and I'm running an installer. In the free software world, upgrades are no-brainers, since they cost no money, and most free software programs are a smooth evolution, rather than major versions every several years. As a result, I'll generally be running the latest version of my office suite (as well as every other little utility on my system), and it is convenient to be able to do the upgrades all in one step (apt-get upgrade; apt-get update will grab all packages with newer versions, and install them, cleanly removing the previous ones). Most people never reinstall Debian -- I know installs from '96 that are still running today, at the latest versions, and there are almost certainly ones from before. I don't know of anyone who went from DOS/Windows 3.1 through Windows XP with just upgrades, and without a reinstall.
The next thing is Windows has a problem of bit rot. If you leave a Windows system without reinstalling the whole thing, adding and removing programs, etc. crap builds up. You get all sorts of registry keys you don't need,.dll files you don't need, weird interdependencies, and the system gets slower, more bloated, etc. This doesn't happen on Debian -- I installed my box maybe 3 or 4 years ago, and it's identical in functionality to if I installed it yesterday. Package management, well implemented, buys you that. You never reinstall the overall system, and upgrades are well-managed and don't break things.
The other place package management helps is in centrally-maintained networks. You can install the same package, with the same configuration settings, very easily from a centralized location.
So package management is, in effect, a fancy way to install and uninstall files. However, the fanciness buys you a lot. The new Windows installer is a form of package management, and gives some of the same advantages, although it's not yet as mature as the GNU/Linux ones (.deb has been around since at least '95, and.rpm even longer).
The theory is fine. The problem is that package managers are, in many ways, incompatible. Debian packages, for instance, track dependencies based on the names of other Debian packages (libfoobaz-dev requires libfoobaz). I've seen package management systems that have dependencies based on files (libfoobaz-dev requires/usr/lib/libfoobaz.so). The former system won't recognize dependencies from packages installed in the latter format. Worse, the packages don't overlap. One distribution will have libgnome, whereas another will have 50 different packages, one for each of the Gnome libraries. The problem of dependencies there breaks almost completely.
There's also a matter of versions and security updates. On Debian, I run 'apt-get update; apt-get upgrade' and have a new version. Since the packages are all maintained by the Debian project (and a few smaller projects that target Debian), this works. Versions aren't linear -- Debian back-ports security fixes. The package manager has no way of knowing whether kernel-2.4.24 is newer than kernel-2.4.19-with-patches.
Basically, there is no clean way to install.rpm packages on a.deb system, or vica-versa, without breaking something. It is possible to install packages of one sort on the other system, but eventually, things will break. Each package management system relies on some set of information about packages to work, and each system has a different set of information it provides and needs.
There is room for improvement in package management -- a really good GUI for finding and installing packages would be nice. I wouldn't mind having more information about the packages I'm about to install -- links to project web pages, ability to browse installed files (the packages.debian.org/freshmeat.net/etc. databases either installed locally or quickly accessable from the system), the ability to view screenshots of GUI programs, etc. There's a lot of metainformation that could be added, and better search functionality that could be implemented.
At the same time, on the package build side, it'd be pretty simple to have a system where you make a configuration file of information about the package, and it builds.deb,.rpm,.tgz, etc. packages, and give easy-to-read information about what systems it'll work on. I've heard of tools similar to this, but I haven't seen them used. Adding something like this to the standard autoconf/automake/... process would certainly be nice.
The last solution is to have the groups work together to make sure all packages have the same set of metainformation (more than is needed for any given package system), so that cross-platform package installs become possible. In practice, I don't see this scaling across versions, as package management systems evolve.
One more thing to bear in mind is the perspective of the author of the article -- he says he runs Slackware, and builds most packages from source (something I've stopped doing maybe 3-5 years ago). Slackware's package management tools are very basic, manual, and crude. That gives a very different attitude towards package management than someone running a distribution like Red Hat, which has a much heavier-weight, more technologically-advanced, but somewhat fragile, somewhat inflexible package management system, or a user of Debian, which has a state-of-the-art ubermaintainable, uberupgradeable package management system, but that primarily relies on grabbing packages from one (or a small number) of sources. I apologize about the stereotypes in this paragraph -- they're not entirely true, but the package management systems differ a lot (more than most people realize, if you've ever tried to build the packages), and I'm just trying to make people aware that users of each of them will have a very different world view, and it's important to keep that in mind when reading these articles.
For those not following the broadband-over-power-lines debate, the basic problem is lack of shielding. Cable modems use coax cable, where the outside of the coax acts as a shield, and so very little RF gets out. The wires carry broadband internet, but don't interfere with anything. In the case of DSL/telephone, you have twisted pair (or at the very least, two wires running very close to each other). They effectively shield each other (meaning that each generates a field in the opposite direction, and the fields cancel out if you're not too close to the wire). More RF gets out than coax, but it's still negligable compared to desirable transmissions. In the case of power lines, they are, depending on power line configuration and frequency, either a significant fraction of a wavelength apart, or several wavelengths apart. In some directions, you get destructive interference, but in others, you get constructive interfence. In the directions of constructive interference, you have a lot of signal being broadcast. As a result, they act as a directional antenna, which interferes with anything on the same wavelengths as power-over-power-lines.
Signal strength goes a square of distance. That means that if I have an antenna running 10 meters from my house, and I'm trying to tune into a station 10 kilometers aways, that station needs to be putting out a million times more power than the segment of powerline running next to me. Ouch.
This probably won't interfere with typical consumer applications (television, FM radio), because if it did, there would be significant political reprecussions, and it would be banned (in other words, it's probably engineered to operate outside of those frequencies). On the other hand, according to the ARRL, it very likely will interfere with amateur radio and therefore emergency communications services.
My view is that it may be a good idea in some third world countries, with no telephone service, where there are no alternatives for Internet. However, in modernized countries, we're better off spending the few extra dollars to put in DSL on top of all phone lines or sticking with modems for a while longer, than in the short term, sacrificing emergency communications infrastructure, and in the long term, entrenching a system of broadband that takes away a significant chunk of the spectrum, and prevents all sorts of innovative uses of that spectrum we haven't thought of yet. Spectrum is a scarce resource, and it's gonna get scarcer. The population growing, but amount of spectrum stays constant, sans a few one-time improvements from better utilization (there are fundamental limits on signal strength vs. noise vs. bandwidth vs. bitrate -- with antenna arrays/directional transmissions, there are limits on directionality vs. frequency vs. transmitter size -- we cannot improve utilization forever). In contrast, all the benefits of power-over-power-lines are short-term -- we only gain the one-time cost of not having to modernize our infrastructure (maintanance costs of the two possible infrastructures aren't significantly different).
I don't know how this initiative works, but my impression is that it sends broadband over powerlines, and then the last gap is sent via wireless. If this is the case, it has all of the standard problems associated above. If not, I need more information than is in the article to evalute it:)
The new form factor is probably not strictly necessary, but is useful, given the move to much smaller connectors (PCI Express, USB, SATA, etc.). Serial connections are primarily institute because they use fewer pins, and so save money. The costs of packaging on modern chips, with hundreds of pins and BBGAs, is enormous. You can save more money if you engineer the form factor to go with it.
PCI Express also allows low-profile cards, so with BTX, you can make much smaller machines if you go legacy-free (no PCI, AGP, MCA, VESA, EISA, or ISA slots). Generally, boards are much more integrated now, use solely SMT components, small connectors, and are cheaper, but the overall system also requires less room. Observe the number of PCI cards that consist of a 1" sliver of PCB, right up to the back of the computer, and then extend to full PCI height. That's expensive, and wastes space. The height of PCI comes from the days of ISA, with through-hole parts and 25 pin connectors going to printers. The only big cards I've seen in the past many years are custom boards and graphics cards. Graphics cards have a funky horizontal option in BTX.
To relieve the slashdotted server, a similar review: http://www.anandtech.com/showdoc.html?i=1 876 The actual spec: http://web.newsguy.com/nstrom/BTX_Spec_1_0. pdf Intel's info about it: http://www.intel.com/update/contents/dt10031. htm
This post has no point. It just provides some general (hopefully interesting) background info.
As many people pointed out, Bochs is an x86 emulator, rather than a virtualization system like VMWare. Emulation means that you have a representation of an x86 machine in memory, look at each instruction, and change the representation appropriately. Virtualization means the code runs on the actual CPU natively, and uses 386 ninja powers to intercept all I/O calls and reroute them to the base OS.
As a result, Bochs will run on any platform. VMWare will only run on x86. Bochs is slow enough to be useless for most common uses (a bit over a 100x hit in speed). VMWare has almost no hit in speed.
However, the free software community did have a project that attempted to reimplement VMWare. That project was called Plex86 (http://plex86.sourceforge.net/). For reasons that I do not know, Plex86 recently reinvented itself not to do full hardware virtualization -- rather, it does not implement the I/O layer, and instead provides special drivers for Linux to talk to its I/O layer. As a result, it can only run Linux (although it claims to run it reasonably well). They may implement drivers for other platforms, but I would be fairly sceptical of any real Windows support anytime soon. That seems a lot less useful now...
The Plex86 project, however, claims the possibility of using their virtualization technology in conjunction with Bochs to make a useable system: "There is the potential to use plex86 as an accelerator for bochs, as was demonstrated some time ago." (source: Plex86 FAQ). Likewise, it seems that if Bochs was more intelligently implemented, they could use just-in-time recompliation, a la Java or Transmeta, since they are effectively treating the x86 ISA as bytecode. That would be in the very, very distant future, but if either of these is implemented, the Bochs project is not as hopeless for end-user use as it may at first seem... Either or both of these technologies ought to give reasonable performance.
One problem is that VMWare is creating a patent minefield in front of Plex86 and Bochs. I am not familiar with all of the patents, but from what I've heard, they've got a pretty wide field of IP cut out. I'm not sure how hard they'll exploit it, since the people working there seem like nice guys, and understand the whole open/Linux/GNU/free/etc. thing. On the other hand, so did Caldera a few years back, and VMWare is definitely getting those patents for a reason....
One final point -- properly used, emulators like Bochs can provide amazingly powerful debugging tools. You can run a full x86 machine (admittedly at very slow speeds), but grab snapshots of the system memory at different points. You can then roll back, use a capture of all inputs to roll forward, etc.
There is no evidence the MacOS is fundamentally significantly more secure than Windows. I understand that people will now post some anacdotal evidence about it coming from a BSD base, and so on and so forth, but it has been developed seperately long enough that, without an audit, it doesn't matter much anymore. It also branched in the days of NeXT, at which time, security was not much of an issue yet. The early versions of Unix and BSD were horrendously insecure (remember all the ping-of-death type attacks in the Windows 95 era that came from the BSD-derived TCP/IP stack?). The only way to demonstrate security is to have a significant number of competent people try to break it and fail (which is what an audit consists of). That hasn't happened to MacOS-X, and until it does, we know nothing about its security (except for default settings, which while very important for normal end-users, if you're a security-conscious power user, you will reconfigure under Windows and GNU/Linux anyways).
It is, however, more obscure, so less people look for and find security holes. Of the people who exploit holes, fewer target Macs, since it's a smaller market. Criminals generally go after the lowest-hanging fruit/easiest target, and if you run a Mac, you're not it.
Security through obscurity has been completely debunked from an acadamic perspective, but from a practical/risk-management perspective, it still often makes good sense. You don't want obscurity on encryption, but on software, it is not a bad way to go. If you run BeOS, or OS/2, VMS, or Plan9, the odds of anyone knowing how to attack you are miniscule. Better yet, if you use a variety of OSes, the odds of compromises being found in all of them simultaniously go down astronomically. If your goal is to not lose data (as opposed to maintaining privacy), a very heterogenous computing environment is the way to go. Protecting privacy? Set up multiple firewalls, each running a different OS. Use custom software to communicate through the firewalls.
If you want to avoid data forensics, combination of obscure OS and encryption is the way to go. Mainstream OSes have presumably been analyzed to death by foresnics companies. They can pull your data out of the Linux swap partition or Windows swap file, if it sat around in memory decrypted, and wasn't wiped yet. BeOS swap file? You'd have to spend hundreds of thousands of dollars reverse-engineering something new.
Last time I posted a negative article (admittedly somewhat provocative/aggressive) on the Mac, I was not only marked troll, but someone went through my past articles, and modded one or two of those down. Gotta love the Mac community. Wonder what'll happen this time:)
Is it just me, or has this reeked of bad engineering since the beginning? Most everything I've heard from them came from what sounded like Mac/G5 zealotry, rather than actual engineering. If you look at their slide show, they discounted a whole bunch of platforms because they would be 1.5 months later than Apple (to me the "Build and Benchmark" lines sounded like this hasn't been done. There was also no price/performance-type curve, etc.). Their justification for running OS-X also sounds like the sort of propaganda you hear from Mac bigots.
I'm not arguing the G5 is the wrong platform -- I'm just arguing the G5 wasn't chosen because it's the right platform, but because the guy in charge of the project is an Apple zealot. The G5 was quite possibly the right platform. MacOS-X is less clear; it's fundamentally an end-user OS. Linux has a huge amount of active development in high performance computing/clustering, and the kernel reflects that. The Linux kernel is also much more readable, and known by more people, so custom modifications (for low-latency communications with specific hardware, etc.) are a lot easier to do. This is not atypical -- when I was working on a little 18-way cluster of then-state-of-the-art dual PIIIs, I recall needing to tweak one or two things in the kernel (for reasons I won't go into, we had a large number of things on the PCI bus, and/proc/pci would overflow).
It's not clear how well the G5 version of Linux is optimized (although it should be trivial to reoptimize it for the G5 if it's not -- probably a couple months kernel hacker time), but my impression is the VaTech guys didn't bother to investigate this, and instead said "We've got a full-fledged FreeBSD under MacOS!" and ran with it. Nothing I can find on their web site indicates any sort of competitive comparison.
The "minimal cost" of upgrading compared to the 5 million budget is bogus. That's over a thousand high-end Apple boxes. Those things cost considerably more than a grand each to produce (raw manufacturing costs), so that's easily over a fifth of their budget. They'll probably do some funky accounting to make it look minimal (give G5s to profs, who don't really want them, or place them in computer labs, or similar, and discount the cost it would have taken to do this in the first place). To be doing this change this late means they f-ed up big on some design parameter early on (didn't realize space/power/thermal limitations, didn't investigate other G5 platforms, or similar). I know university funding doesn't work like normal funding (money comes from sponsors, and some expensive things are "free", while some cheap things are unaffordable), but that doesn't make up for the huge cost.
I know people will be screaming that Apple or IBM probably footed much of the bill, but I think had VaTech talked to Intel or AMD, they could have gotten a similar offer (although the other chip houses probably couldn't have matched it).
Anyways, I won't rant and rave more. Everything I said is based on minimal information -- looking at the VaTech site, there just isn't that much. As a result, some of what I said might be wrong. Anyone from VaTech with actual facts care to provide some insight? By facts, I mean "The PIII-3.2GHz costs x dollars per box, while the G5 costs y dollars. We benchmarked them with z scientific computing test, and found the G5 has w advantage," rather than "we downloaded some benchmarks from a Macintosh web site." More importantly, provide insight on why you chose MacOS-X (got any benchmarks?)
You should look into getting ham radio licenses for all your techs, and getting amateur radios. For non-commercial use (high school theater certainly qualifies), those would be perfect. The lowest level license is very easy to get -- simple exam, no morse code. You can buy a book ("Now You're Talking"), and if you read it, you'll ace the test. All the possible questions on the exam are also on-line (www.arrl.org). I cannot overemphasize how easy it is -- I learned what I needed for it in elementary school (higher-level exams are hard).
That gives you access to HF frequencies, which don't go very far, which for use in theatre is very good (no interference). To clarify, "not very far" means your town, as opposed to hitting stations in Australia and Japan. You may also be able to talk to the local ham community, and get a block of bandwidth for yourselves (there are protocols for doing this in the ham community, and it shouldn't be difficult). The FCC has laws about non-interference, and everyone on the waves is licensed, so you can expect people to respect this.
Using 802.11 would be both very expensive, unreliable, and cumbursome in comparison. Ham equipment will also last forever -- 802.11 already has a, b, and g, and will presumably have new standards coming out every so often. Every several years, all your equipment will become obsolete. There also aren't very well established standards for sending audio over TCP/IP. What you use now may not exist in a couple years.
SSB and FM, in contrast, have been here for close to a century, and aren't going away anytime soon.
You'll also have large numbers of potential suppliers for your equipment, open standards, and all that good stuff. This gives you access to amazing resources if you want to do anything more fancy (repeaters, etc.). You have access to a big block of bandiwidth, so you can switch channels if you want to have an individual conversation with someone. In addition, the equipment is general-purpose. You can use it for anything you'd use an amateur radio for, and other people's amateur radios can interface to you. You also have a very large community of technically inclined people on the waves who would be willing to support you (kinda like GNU/Linux, back in '94 or '95, before there was a mass of people). Hams are (a) friendly (b) helpful (c) constantly complaining about the lack of new blood. They also generally know a heck of a lot (the highest-level license basically requires you to know how to design a radio from scratch).
I cannot think of many other communications standards that offer all of this. To some extent, CB, but then you're vulnerable to pricks interfering on purpose (if your school is at all like mine was). Then again, if you're school is more civilized, or the dumb people are even dumber, this might not be a problem....
The only annoyance is that, when you transmit, you need to broadcast your callsign every so often (a series of up to 7 characters; for instance KB7DQQ).
I definitely wouldn't go for anything digital -- until the standards are better established, you'd find yourself with obsolete equipment very soon.
For those of you who like stupid science tricks/supercheap climate control, here's a trick for how to heat and cool a house without using any energy (outside of what's free from the Sun):
First, some background on black body radiation. All matter radiates some light, based on its temperature. By basic thermodynamics, the amount of radiation that a color of matter absorbs in a given frequency range (as opposed to reflects) is directly proportional to how much it radiates (as compared to a perfect black body of the same temperature).
The sun only radiates on a fairly small set of frequencies, and that set is very different from the frequencies at which a black body at room temperature radiates. If you build a panel of a material that is perfectly absorbent in the frequencies on which the Sun radiates (perfect black body), but reflects in the remaining frequencies (perfectly white on the blackbody frequencies of room temperature), it will lose very little heat to radiation, but absorb a lot from the sun, and it'll get very hot. If you take a body that reflects radiation in the colors the sun emits (white), but absorbs/radiates elsewhere (black), it'll get very, very cool, even in bright sunlight. You can get pretty close to the full 1000W/m^2 of heating (level of Sun's radiation hitting the earth). In cooling, you get pretty close to the ideal from Stefan's Law (http://www.egglescliffe.org.uk/physics/astronomy/ blackbody/bbody.html), which gives 300-500W/m^2 at typical Earth temperatures (over 400W/m^2 heat loss at typical room temperature).
This means that you can theoretically heat or cool a house with just a painted square on the roof a few square meters in area, if you could just create a material of the right color.
Problem is the guy who came up with this (and showed it to me) was a physicist and not a chemist, and had no idea how one would go about creating a material whose color was that well controlled.
Still a nifty concept, eh? If you could make this, it would save a ton of energy, since you'd no longer need to burn gas to heat and use electricity to cool -- just flip a panel on your roof, and the temperature changes (although for heating, the house would need to be well enough insulated to last the night).
I'd give it a while to see if it's a real research lab. I've seen a large number of tech companies form "research labs" that are basically engineering products for a year or two down the line. I've interacted with one.com where the entire software development team was called a research lab.
A traditional research lab focuses on basic research, with occasional industry applications coming out. Examples of this include IBM TJ Watson Research Center, Xerox PARC, Bell Labs, (surprisingly) Microsoft Research, as well as most acadamic labs. These have the property that many projects have no applications for as much as 20+ years, but they are critical to long-term economic growth, and most importantly, they are fun to work at. As a result, they have a very easy time recruiting good people, and for all the economic loss on "basic research projects," generate some very cool stuff otherwise.
Right now, although I'm not sure how much fundamental research Google does, it does require employees to spend 20% of their time on personal pet projects, which encourages a lot of creativity. They are a very fun employer, and at least looking at MIT AI Lab and Stanford, Google seems to pick of the cream-of-the-crop from PhDs not going into acadamia. Yahoo, on the other hand, has the army-of-moron-developers models.
If Yahoo, on the other hand, starts a search engine development team, and calls it "Yahoo Labs," I will be unimpressed. However, from the press release, it is entirely unclear what form the lab will take, but from the phrases in the press release ("strategic projects," "short-term projects," "work collaboratively with Yahoo! business"), I am inclined to think it'll be the software development team called a research lab, rather a real research lab.
Slashdot Mirror
Flash media will typically have about 100,000 read/write cycles before failing. It's sometimes advertised as millions, but practically, no one makes media that goes over 300k, and no one makes media that goes under maybe 10k. Used naively (e.g. CompactFlash in an IDE-to-CF adapter as your / partition), the time to failure is on the order of days. Log files, file access times, and bits like that get written over and over and over, with some files being touched every few seconds. You've got 86,400 seconds in a day, which is in the same ballpark as flash endurance. I've seen drives fail this way.
Used properly, however, a SSD will last forever. Typically, the drive will include load spreading somewhere in the chain. The algorithms are a bit more clever than what I'm about to describe, but naively, if you've written the same location more than a few times, you move that data to a different location. This are often implemented in the drive's firmware, but may also be implemented in the file system (Linux comes with a few flash file systems that do this -- indeed, OLPC uses one of them). Used this way, the solid state drive will last for many decades of continuous use before failing, and will eventually fail for the same mechanisms as any other old IC. A 40GB drive, written at 100Mbps, will take about an hour to overwrite completely. With an endurance of 100,000 cycles, you get a bit over 10 years of continuous write at that speed before you run into endurance limits. With normal write frequencies, that means it'll last essentially forever.
Data is stored as charge on a conductor surrounded by insulator, but the insulator isn't perfect, and eventually, electrons do drift on and off. As a result, data stored in flash has a lifetime on the order of 10 years if it doesn't get refreshed. Of course, refreshing it is trivial (read out data, write it back).
Of course, with a Sony laptop, the major question isn't drive lifetime, but how long until the hinges or latches break. Sony laptops typically frequently have mechanical failures within a few months of purchase. Sony skims on quality quite a bit, these days, and is mostly running on reputation for quality acquired many years ago. That, combined with shooting for the lowest possible weight (and skimming on construction quality to save weight too) makes for pretty flimsy laptops.
The problem is that Nokia considers GNU/Linux tablets to be unsupported abandonware only 1.5 years after introduction. The tablets are loaded with proprietary and binary-only drivers and software, which means once official support goes away, you're left with a very expensive paperweight. Linux Weekly News reported on this just this week.
Sony Electronics has gone down the tubes in the past decade or so (it started a while before that -- old school Sony TVs and CRTs had a full metal Faraday cage around the tube, and touches like that went sometime before then). Nowadays, Sony electronics is mostly living off of the reputation it developed up through the 80s or 90s, when it delivered truly exceptional quality products at a high premium. Sony still charges a premium (albeit a smaller one), while delivering mostly sub-par products.
The Sony laptops are light and attractive, but almost universally have mechanical problems (hinges and latches break). The MP3 players are a disaster. A relative bought one, and it wouldn't play MP3s -- he had to convert music into Sony's proprietary atrak format before it worked. He returned it and bought an iRiver. The headphones give reasonable (but not exceptional) audio quality for the price, but generally break after about 3 months of use. Cameras have nice imagers, mechanically filmy (but not horrible), but as with most Sony, try to force you into a proprietary, incompatible, overpriced technology stack with MemoryStick. PS3 was an unqualified disaster. Home audio equipment is okay, but suboptimal on the price/performance curve (e.g. Kenwood generally has better-sounding, better-quality equipment for the same price in my price range).
I also really, really, really hate the attempted "synergy." If you want the PS3, you need to pay for Blu-ray. Everything you buy will use MemoryStick, and where possible, use proprietary cables, plugs, and formats to try to lock you in to buy other Sony products, and not work well with non-Sony products.
It's actually a problem. I had a bad experience with Travel Document Systems. I wrote a page on it. Because of SEO type crap, and companies like reputation defender, it is not even showing up. I wish there was some way of dealing with SEO and search engine spam. I'd love to be able to search for reviews, criticisms, and things like that, without having to go through 50 commercial pages advertising products first. Maybe if we could tag pages "noncommercial" and search noncommercial pages, or something?
Sounds like dumping. Offer a product for free to destroy competition, so you can later charge for it. If I were VMWare, I'd get the DOJ and its international friends involved. They'd probably win in at least one country.
Having an EULA pop up during the first run is idiotic for a free software project. There is no reason why the user must accept a license to run this program. EULA acceptance screens are needed for programs that add restrictions beyond regular copyright law (e.g. no reverse engineering). For programs with a free software license, which add additional rights (e.g. modify, but only if you distribute source to changes), it is not. The user either accepts or does not. If she does not, she has the rights granted by plain old copyright law, which means she can run it, but no copies or modifications. If she does, she has the additional rights under the EULA. The GPL has a nice clause and explanation about this.
As is, this is nust an unneccessary additional user hassle. Why do we copy stupid things from commercial software when it doesn't apply? If the trend continues, by FX3, we'll have to type in a 20 digit product code to make sure it's a valid copy...
This is similar to the vaccine theory, with two twists:
My guess is that this would be illegal, or at the very least, would outrage large numbers of people. As a result, I'm suggesting the black ops approach. I was contemplating mailing the CDC and the White House with the suggestion, but I appear to be too lazy.
Note that this would only work for flus. Most other diseases are not nearly contagious enough -- a flu, in contrast, hits basically 100% of the population (usually, not very severly).
The recommendations don't follow from the user experience. Several don't necessarily follow, but I'll present the dominant problem here:
/etc/issues, and I edited it. It worked. I rebooted. It went away. It took me the longest time to figure out that an fucking script in /etc/rc.something/ was overwriting it. The information was stored in two places. I overwrote the wrong one, and boom. I was fucked. I stopped using Red Hat precisely because of the complex configuration scripts, which made the system fragile and ultimately, easy to break and difficult to use.
Maintain the Abstraction from the Underlying System
This is almost universally the wrong approach -- this is what Windows tries to do, and MacOS avoids. The key is to make the underlying system simple, and make the UI reflect that.
The problem with abstracting the two is that it leads to bit rot. At some point, the Windows registry will think a file is in one location, whereas the file is actually in another. Or the UI will misunderstand the way that the 5 options in the configuration file should be presented as 2 options in the UI. Or there will be some underlying binary configuration file, with some option that's not available in the GUI, that somehow gets flipped, breaking the whole system.
You very strongly don't want an abstraction. On the Mac, installing an application (I haven't use OSX, so my knowledge is based on the older versions) is as easy as dragging the folder onto the hard drive. To erase, you wipe it. On Windows, if you wipe an app like that, it'll leave bits and pieces of itself scattered throughout the registry, links in menus, DLLs in system folders, and dozens of other places. Worse, the uninstaller will often no longer work. Most clueless users, if they try to erase an application the wrong way, will end up with a semibroken system, since there are different levels of abstraction that do not maintain consistency.
The whole Windows (and increasingly, GNU/Linux) approach of abstracting out underlying complexity is flawed. The trick is to eliminate the underlying complexity, and have a single set of simple structures that the GUI tools (or the users manually) operate on.
When I first used Red Hat in '96, the types of issues that threw me were: I wanted to change the login text. I grepped for the old login text, found
This shows up a huge number of places -- especially in a heterogenous environment like GNU/Linux, you often have multiple configuration tools. I can download a half dozen Apache configuration tools. Very often, if you run one, then switch to another, the thing no longer works, since they edit different options in different ways.
One way to implement this (presented in an oversimplified fashion) is to first design what you want the UI to look like. Once you know, you design the underlying structure to match. This is the opposite of what most GNU/Linux and Windows developers do, where they try to engineer the most flexible underlying structure possible, and then develop a UI on top of that. This doesn't necessarily lead to less flexible underlying structures -- it's just that to have a good UI, you want to give some thought to the user experience when designing the engine, and especially, the configuration files.
What Engim is doing is actually a good bit more sophisticated than any of the Slashdot posts imply. When you transmit, you usually have two types of bandwidth: how much bandwidth you are using, and how much you are interfering with. For instance, a simple AM broadcast will require maybe 8KHz of the spectrum on which it actually transmits data. Since transmitters are imperfect, however, it may actually interfer with transmitters on, say, 20KHz of spectrum.
As a result, if you're in a big company, and set up 3 off-the-shelf 802.11b access points, on 3 different theoretically non-overlapping bands, you'll still get something on the order of, maybe, 1.6x the bandwidth you'd get with one.
What Engim does is it has an insanely fast ADC/DAC front-end, that grabs the entire 802.11b/g spectrum, including all the bands. Then, they have a fancy DSP that looks at the bands together, figures out how they interfere with each other, and sorts them out. As a result, in a theoretical world, where only notebooks were transmitting to the access point, they would have 3x the bandwidth. They do fancy transmitting techniques, so that notebooks on all 3 bands can hear at the same time. So if the wireless access point was transmitting, and all the notebooks receiving, they would, again, have 3x the bandwidth.
The problem is that notebooks don't have this sort of technology, so when they transmit, they cause interference for other notebooks. If the Engim WAP transmits on band 1 to notebook A, and notebook B transmits on band 2 at the same time, the transmission from notebook B may interfere with that from the WAP. As a result, in practice, it's a little less than 3x the bandwidth, but not a heck of a lot less. They try to juggle notebooks between bands, based on location, so this doesn't happen, but it doesn't really work too well.
The technology they have is wicked cool, actually. For those worrying about interference -- it's really not a problem. First of all, this isn't for personal WAPs, but for $1000 access points you'd see on an IBM or Microsoft campus. They won't be going in apartments any time soon. You need a minimum of 3 very expensive chips for a single WAP (RF front-end, ADC/DAC, and DSP). Those places don't tolorate employees setting up their own WAPs anyways.
Second, you still have the remaining bands. The way 802.11 works, with the interference issues described above, if I set up a WAP, and my neighbor sets up a WAP, we will be interfering. We'll both have wireless networks, but both with reduced bandwidth. You can still set up your own WAP on any of the remaining bands, and it'll work -- it's just that if you try to send a packet at the same moment as the Engim network, you'll get a collision and retransmit. This is what happens anyways. 802.11 was never designed to have many, non-interfering bands. It was designed to have many, interfering, overlapping networks, with packet collisions. By design, the total bandwidth of 5 overlapping networks, in the same area, is the same as if there was only one. Each network gets 1/5 of the bandwidth then. This is the exact issue Engim technology is meant to address.
In terms of cell phones, etc. my impression is that the Engim technology was actually smart enough to look for "interference sources" and try to pick bands around them. This last bit is from an Engim PowerPoint slide, so I'm not sure if it's actually implemented or vaporware.
I would like to see whether this is, indeed, trusted computing. The article was somewhat vague in some ways. If it is the full-fledged hardware portion of the Pallidium initiative, as part of the article implies, it's very, very bad. If, instead, it's a way to save money on a system restore disk by having the hardware hide a portion of the hard drive from normal software, it's annoying, but probably fine, depending on how it is done (if there's a PKI, that's bad, but if it's just read-only, that's fine).
If trusted computers do appear in your area, I would suggest the following strategy for making them go away:
This assumes the companies have a 30-day no-questions-ask return policy (which is usually the case). You can even say that the "trusted" computing was the reason you returned it. Once they start losing tons of money, it'll go the way of DiVX (not the codec -- the old DVD standard which needed to call home to get authorization). It was pushed by Circuit City, which had a ton of people do this to them, so they introduced restocking fees, and lost a lot of customers who knew nothing about DiVX. Eventually, Circuit City backed off the DiVX thing.
If you want to be illegal (which I don't recommend), some people have a modified scheme:
This costs them a heck of a lot more, and gets around the place of returns without restocking fee. If you need to buy a DRMed product, you can also use this to make sure the company pays the manufacturing costs for 2 of 'em instead of one, and loses money on the sale. It is, however, illegal, and probably unethical.
- Use LaTeX and xv for text and presentations
- Use Word and Presentations, and give the guy a copy
After you do the presentation, if the guy likes you, he'll do a presentation to his boss, who will pick out his favorite projects from the first filtering from his underlings. The underling you presented to is usually lazy, so in all likelyhood, this presentation will consist of cut-and-pasting from your Word and Presentations documents. If you give him the documents inIf I were a lazy administrator drone in the attorney general's office, I would have documents on my desk from MPAA, P2P United, EFF, FSF, RIAA, etc., all in .doc format. I would then read all of the documents, discuss with the attorney general what our stance should be, and cut-and-paste sections presenting that stance from all of the documents on my desk. It saves me time, and avoids duplication of work. It's how the government works.
I don't doubt many politicians are corrupted by the RIAA/MPAA. The fact that they have MPAA-authored text, however, is not direct evidence of this. The best ways to find corruption is to follow the money, as well as to look for unreasonable actions. This may be an unreasonable action, but the fact that the document went through or from the MPAA/RIAA says nothing.
There is a difference between ethics and legality. You cannot legally use MP3s in your country. You've been conditioned to think of copyright as "intellectual property," rather than a social contract between creator of content and the consumer, which associates concepts like stealing and piracy with what is, in the end, not theft but copyright violation. This brings with it the feeling of guilt. You've also been conditioned, probably by the German society, that laws were meant to be followed and that ethical people follow laws.
The reality is quite different. Laws are, at best, an attempt to codify and enforce ethics by committee. The committee is usually right, but does, on occasion, make errors. In those cases, there is sometimes no compelling reason to follow the laws. Worse, as in the case of Eastern Europe under Communism, the committee maybe corrupt, in which case, the ethical thing to do is often civil disobedience, and intentionally breaking laws. To me, this feels like one of those cases.
You should strive to follow ethics, not laws. I would argue that there is a compelling ethical argument not to give money to record companies, so they can better buy off governments to pass acts like the DMCA mandating DRM, and destroy your right to write free software capable of interacting with the mainstream world (you cannot, right now, write free legal DVD players, or players for DRMed CDs, even if they have zero uses for copying content). If this is allowed to continue, in short time, GNU/Linux computers will no longer be able to legally access music and video, followed by books and electronic texts, and eventually, mainstream documents. Once this happens, GNU/Linux and free software will have been effectively legally banned from any sort of desktop use (and quite possibly, eventually, server use).
I would sidestep the issue of benefiting personally from illegal action by making sure you do not benefit. Donate the money you would have spent on CDs to either the artists, or organizations like the FSF, the EFF and similar. Make sure you donate at least as much as you have in illegal content. Then, gather the content illegally, and use it as you see fit. I believe this is the second most ethical course of action (the most ethical being that you only boycott all mainstream music, and listen only to independent labels uninvolved in the push for DRM).
It's good that SEC is investigating them, although it is not clear whether they will find anything. This is really as much or more FTC's arena. Specifically, it would be beneficial if a large number of people filled out FTC's complaint form to maybe get some action about false advertising, slander, unfair competition, and so on. It is comparatively easy to show that SCO has directly lied on a large number of occasions. There is probably enough for SCO to convict it of false advertising on the Linux license front.
Cringly somehow equates difficulty of reverse-engineering with security (in the sense of buffer overflows, etc.). Other than weak arguments about security-by-obscurity, it holds no water. The NSA has automated analysis tools that look for buffer overflows and the like. Plenty of attacks come about with people just throwing random packets at a machine, and seeing what crashes it. In addition, in spite of the well publicized NT source release, Microsoft licenses Windows source to universities and other organizations, and it is fairly wide-spread. Anyone who really cares can get it.
Very few people will reverse-engineer source code to make a competing product. With the exception of file formats and the like (Word format, DeCSS, etc.), it is generally much faster to reinvent than it is to reverse engineer -- this is often true even when you have the original source code, with comments. I guess the only other place I can think of where reverse-engineering might make sense is highly-optimized algorithm (3d rendering, video compression, etc.), but even there, it's sketchy as to whether there is any real benefit.
He goes on to talk about how source code watermarks are impossible to remove. Quite frankly, I've never seen a watermark in a non-lossy data format that's impossible to remove. They just take different amounts of time and effort.
I used to think this guy had a clue, or some insight once in a while. This article is just so confused, and wrong in so many ways, that we Cringeley has no grasp of basic technology. Damn. it sucks.
I would like to point out that the FSF is also not a bunch of zealots. RMS is the founder, but it is run by a lot of people. Even if you don't like RMS (although a lot of the reason he's been marginalized stems from ESR badmouthing him/exaggarating his problems, rather than RMS himself), they are a big organization. Most of the other head honchos over the FSF are quite amazing.
Eben Moglen (the chief counsel of the FSF, law professor at Columbia) is extremely reasonable, competent and friendly. He is a brilliant lawyer and an excellent public speaker. You should go to one of his talks at some point -- I cannot overemphasize how good he is. A large number of the FSF charity events are headed by him for precisely that reason. Heck, try reading some of his writings.
Gerry Sussman is President of the FSF. He is one of MIT's top professors. He is the creator of the Scheme programming language, the guy who proved the motion of the solar system is chaotic, and is responsible for dozens of other similar breakthroughs in computer science, math, physics, and electronics. He is brilliant, but also one of the nicest, most reasonable guys I know.
I've met both. I can assure you neither of these guys could be described as a zealot, or anything close to a zealot.
It is very unfair to characterize the FSF simply by one man, even if he is the founder. The FSF is very good at what it does. RMS is one piece of the equation, and acts as a sort of moral compass for the organization as a whole (and his morals are indisputable, although you may argue with his tactics or interpersonal skills). However, people like Eben and Gerry handle many of the FSF's operations, and they do their jobs competently, and exceedingly well.
A package is a file that contains information needed to install and uninstall a program. They are similar to MSI files, but have a number of advantages, mostly stemming from the fact that free software is, well, free, and so you can get it without buying it. Proprietary software comes on CDs, whereas free comes over the Internet. Upgrading free software is very "light weight" whereas upgrading proprietary software is usually very "heavy weight." This gives a different distribution model.
.dll files you don't need, weird interdependencies, and the system gets slower, more bloated, etc. This doesn't happen on Debian -- I installed my box maybe 3 or 4 years ago, and it's identical in functionality to if I installed it yesterday. Package management, well implemented, buys you that. You never reinstall the overall system, and upgrades are well-managed and don't break things.
.rpm even longer).
This has several effects. If I distribute a nonfree 10MB program UberTool, that requires the nonfree 20MB MegaLib, I'd better distribute MegaLib with UberTool. If both are free, I can distribute them seperately -- if the user already has MegaLib, he'll just install UberTool.deb. If he doesn't, the package management system will know where to grab MegaLib from, will download MegaLib.deb, and install it.
Furthermore, if I'm going from Office 97 to Office 2000, it's because I bought money on a CD, and I'm running an installer. In the free software world, upgrades are no-brainers, since they cost no money, and most free software programs are a smooth evolution, rather than major versions every several years. As a result, I'll generally be running the latest version of my office suite (as well as every other little utility on my system), and it is convenient to be able to do the upgrades all in one step (apt-get upgrade; apt-get update will grab all packages with newer versions, and install them, cleanly removing the previous ones). Most people never reinstall Debian -- I know installs from '96 that are still running today, at the latest versions, and there are almost certainly ones from before. I don't know of anyone who went from DOS/Windows 3.1 through Windows XP with just upgrades, and without a reinstall.
The next thing is Windows has a problem of bit rot. If you leave a Windows system without reinstalling the whole thing, adding and removing programs, etc. crap builds up. You get all sorts of registry keys you don't need,
The other place package management helps is in centrally-maintained networks. You can install the same package, with the same configuration settings, very easily from a centralized location.
So package management is, in effect, a fancy way to install and uninstall files. However, the fanciness buys you a lot. The new Windows installer is a form of package management, and gives some of the same advantages, although it's not yet as mature as the GNU/Linux ones (.deb has been around since at least '95, and
The theory is fine. The problem is that package managers are, in many ways, incompatible. Debian packages, for instance, track dependencies based on the names of other Debian packages (libfoobaz-dev requires libfoobaz). I've seen package management systems that have dependencies based on files (libfoobaz-dev requires /usr/lib/libfoobaz.so). The former system won't recognize dependencies from packages installed in the latter format. Worse, the packages don't overlap. One distribution will have libgnome, whereas another will have 50 different packages, one for each of the Gnome libraries. The problem of dependencies there breaks almost completely.
.rpm packages on a .deb system, or vica-versa, without breaking something. It is possible to install packages of one sort on the other system, but eventually, things will break. Each package management system relies on some set of information about packages to work, and each system has a different set of information it provides and needs.
.deb, .rpm, .tgz, etc. packages, and give easy-to-read information about what systems it'll work on. I've heard of tools similar to this, but I haven't seen them used. Adding something like this to the standard autoconf/automake/... process would certainly be nice.
There's also a matter of versions and security updates. On Debian, I run 'apt-get update; apt-get upgrade' and have a new version. Since the packages are all maintained by the Debian project (and a few smaller projects that target Debian), this works. Versions aren't linear -- Debian back-ports security fixes. The package manager has no way of knowing whether kernel-2.4.24 is newer than kernel-2.4.19-with-patches.
Basically, there is no clean way to install
There is room for improvement in package management -- a really good GUI for finding and installing packages would be nice. I wouldn't mind having more information about the packages I'm about to install -- links to project web pages, ability to browse installed files (the packages.debian.org/freshmeat.net/etc. databases either installed locally or quickly accessable from the system), the ability to view screenshots of GUI programs, etc. There's a lot of metainformation that could be added, and better search functionality that could be implemented.
At the same time, on the package build side, it'd be pretty simple to have a system where you make a configuration file of information about the package, and it builds
The last solution is to have the groups work together to make sure all packages have the same set of metainformation (more than is needed for any given package system), so that cross-platform package installs become possible. In practice, I don't see this scaling across versions, as package management systems evolve.
One more thing to bear in mind is the perspective of the author of the article -- he says he runs Slackware, and builds most packages from source (something I've stopped doing maybe 3-5 years ago). Slackware's package management tools are very basic, manual, and crude. That gives a very different attitude towards package management than someone running a distribution like Red Hat, which has a much heavier-weight, more technologically-advanced, but somewhat fragile, somewhat inflexible package management system, or a user of Debian, which has a state-of-the-art ubermaintainable, uberupgradeable package management system, but that primarily relies on grabbing packages from one (or a small number) of sources. I apologize about the stereotypes in this paragraph -- they're not entirely true, but the package management systems differ a lot (more than most people realize, if you've ever tried to build the packages), and I'm just trying to make people aware that users of each of them will have a very different world view, and it's important to keep that in mind when reading these articles.
For those not following the broadband-over-power-lines debate, the basic problem is lack of shielding. Cable modems use coax cable, where the outside of the coax acts as a shield, and so very little RF gets out. The wires carry broadband internet, but don't interfere with anything. In the case of DSL/telephone, you have twisted pair (or at the very least, two wires running very close to each other). They effectively shield each other (meaning that each generates a field in the opposite direction, and the fields cancel out if you're not too close to the wire). More RF gets out than coax, but it's still negligable compared to desirable transmissions. In the case of power lines, they are, depending on power line configuration and frequency, either a significant fraction of a wavelength apart, or several wavelengths apart. In some directions, you get destructive interference, but in others, you get constructive interfence. In the directions of constructive interference, you have a lot of signal being broadcast. As a result, they act as a directional antenna, which interferes with anything on the same wavelengths as power-over-power-lines.
:)
Signal strength goes a square of distance. That means that if I have an antenna running 10 meters from my house, and I'm trying to tune into a station 10 kilometers aways, that station needs to be putting out a million times more power than the segment of powerline running next to me. Ouch.
This probably won't interfere with typical consumer applications (television, FM radio), because if it did, there would be significant political reprecussions, and it would be banned (in other words, it's probably engineered to operate outside of those frequencies). On the other hand, according to the ARRL, it very likely will interfere with amateur radio and therefore emergency communications services.
My view is that it may be a good idea in some third world countries, with no telephone service, where there are no alternatives for Internet. However, in modernized countries, we're better off spending the few extra dollars to put in DSL on top of all phone lines or sticking with modems for a while longer, than in the short term, sacrificing emergency communications infrastructure, and in the long term, entrenching a system of broadband that takes away a significant chunk of the spectrum, and prevents all sorts of innovative uses of that spectrum we haven't thought of yet. Spectrum is a scarce resource, and it's gonna get scarcer. The population growing, but amount of spectrum stays constant, sans a few one-time improvements from better utilization (there are fundamental limits on signal strength vs. noise vs. bandwidth vs. bitrate -- with antenna arrays/directional transmissions, there are limits on directionality vs. frequency vs. transmitter size -- we cannot improve utilization forever). In contrast, all the benefits of power-over-power-lines are short-term -- we only gain the one-time cost of not having to modernize our infrastructure (maintanance costs of the two possible infrastructures aren't significantly different).
I don't know how this initiative works, but my impression is that it sends broadband over powerlines, and then the last gap is sent via wireless. If this is the case, it has all of the standard problems associated above. If not, I need more information than is in the article to evalute it
The new form factor is probably not strictly necessary, but is useful, given the move to much smaller connectors (PCI Express, USB, SATA, etc.). Serial connections are primarily institute because they use fewer pins, and so save money. The costs of packaging on modern chips, with hundreds of pins and BBGAs, is enormous. You can save more money if you engineer the form factor to go with it.
1 876. pdf. htm
PCI Express also allows low-profile cards, so with BTX, you can make much smaller machines if you go legacy-free (no PCI, AGP, MCA, VESA, EISA, or ISA slots). Generally, boards are much more integrated now, use solely SMT components, small connectors, and are cheaper, but the overall system also requires less room. Observe the number of PCI cards that consist of a 1" sliver of PCB, right up to the back of the computer, and then extend to full PCI height. That's expensive, and wastes space. The height of PCI comes from the days of ISA, with through-hole parts and 25 pin connectors going to printers. The only big cards I've seen in the past many years are custom boards and graphics cards. Graphics cards have a funky horizontal option in BTX.
To relieve the slashdotted server, a similar review:
http://www.anandtech.com/showdoc.html?i=
The actual spec:
http://web.newsguy.com/nstrom/BTX_Spec_1_0
Intel's info about it:
http://www.intel.com/update/contents/dt10031
This post has no point. It just provides some general (hopefully interesting) background info.
As many people pointed out, Bochs is an x86 emulator, rather than a virtualization system like VMWare. Emulation means that you have a representation of an x86 machine in memory, look at each instruction, and change the representation appropriately. Virtualization means the code runs on the actual CPU natively, and uses 386 ninja powers to intercept all I/O calls and reroute them to the base OS.
As a result, Bochs will run on any platform. VMWare will only run on x86. Bochs is slow enough to be useless for most common uses (a bit over a 100x hit in speed). VMWare has almost no hit in speed.
However, the free software community did have a project that attempted to reimplement VMWare. That project was called Plex86 (http://plex86.sourceforge.net/). For reasons that I do not know, Plex86 recently reinvented itself not to do full hardware virtualization -- rather, it does not implement the I/O layer, and instead provides special drivers for Linux to talk to its I/O layer. As a result, it can only run Linux (although it claims to run it reasonably well). They may implement drivers for other platforms, but I would be fairly sceptical of any real Windows support anytime soon. That seems a lot less useful now...
The Plex86 project, however, claims the possibility of using their virtualization technology in conjunction with Bochs to make a useable system: "There is the potential to use plex86 as an accelerator for bochs, as was demonstrated some time ago." (source: Plex86 FAQ). Likewise, it seems that if Bochs was more intelligently implemented, they could use just-in-time recompliation, a la Java or Transmeta, since they are effectively treating the x86 ISA as bytecode. That would be in the very, very distant future, but if either of these is implemented, the Bochs project is not as hopeless for end-user use as it may at first seem... Either or both of these technologies ought to give reasonable performance.
One problem is that VMWare is creating a patent minefield in front of Plex86 and Bochs. I am not familiar with all of the patents, but from what I've heard, they've got a pretty wide field of IP cut out. I'm not sure how hard they'll exploit it, since the people working there seem like nice guys, and understand the whole open/Linux/GNU/free/etc. thing. On the other hand, so did Caldera a few years back, and VMWare is definitely getting those patents for a reason....
One final point -- properly used, emulators like Bochs can provide amazingly powerful debugging tools. You can run a full x86 machine (admittedly at very slow speeds), but grab snapshots of the system memory at different points. You can then roll back, use a capture of all inputs to roll forward, etc.
There is no evidence the MacOS is fundamentally significantly more secure than Windows. I understand that people will now post some anacdotal evidence about it coming from a BSD base, and so on and so forth, but it has been developed seperately long enough that, without an audit, it doesn't matter much anymore. It also branched in the days of NeXT, at which time, security was not much of an issue yet. The early versions of Unix and BSD were horrendously insecure (remember all the ping-of-death type attacks in the Windows 95 era that came from the BSD-derived TCP/IP stack?). The only way to demonstrate security is to have a significant number of competent people try to break it and fail (which is what an audit consists of). That hasn't happened to MacOS-X, and until it does, we know nothing about its security (except for default settings, which while very important for normal end-users, if you're a security-conscious power user, you will reconfigure under Windows and GNU/Linux anyways).
:)
It is, however, more obscure, so less people look for and find security holes. Of the people who exploit holes, fewer target Macs, since it's a smaller market. Criminals generally go after the lowest-hanging fruit/easiest target, and if you run a Mac, you're not it.
Security through obscurity has been completely debunked from an acadamic perspective, but from a practical/risk-management perspective, it still often makes good sense. You don't want obscurity on encryption, but on software, it is not a bad way to go. If you run BeOS, or OS/2, VMS, or Plan9, the odds of anyone knowing how to attack you are miniscule. Better yet, if you use a variety of OSes, the odds of compromises being found in all of them simultaniously go down astronomically. If your goal is to not lose data (as opposed to maintaining privacy), a very heterogenous computing environment is the way to go. Protecting privacy? Set up multiple firewalls, each running a different OS. Use custom software to communicate through the firewalls.
If you want to avoid data forensics, combination of obscure OS and encryption is the way to go. Mainstream OSes have presumably been analyzed to death by foresnics companies. They can pull your data out of the Linux swap partition or Windows swap file, if it sat around in memory decrypted, and wasn't wiped yet. BeOS swap file? You'd have to spend hundreds of thousands of dollars reverse-engineering something new.
Last time I posted a negative article (admittedly somewhat provocative/aggressive) on the Mac, I was not only marked troll, but someone went through my past articles, and modded one or two of those down. Gotta love the Mac community. Wonder what'll happen this time
Is it just me, or has this reeked of bad engineering since the beginning? Most everything I've heard from them came from what sounded like Mac/G5 zealotry, rather than actual engineering. If you look at their slide show, they discounted a whole bunch of platforms because they would be 1.5 months later than Apple (to me the "Build and Benchmark" lines sounded like this hasn't been done. There was also no price/performance-type curve, etc.). Their justification for running OS-X also sounds like the sort of propaganda you hear from Mac bigots.
/proc/pci would overflow).
I'm not arguing the G5 is the wrong platform -- I'm just arguing the G5 wasn't chosen because it's the right platform, but because the guy in charge of the project is an Apple zealot. The G5 was quite possibly the right platform. MacOS-X is less clear; it's fundamentally an end-user OS. Linux has a huge amount of active development in high performance computing/clustering, and the kernel reflects that. The Linux kernel is also much more readable, and known by more people, so custom modifications (for low-latency communications with specific hardware, etc.) are a lot easier to do. This is not atypical -- when I was working on a little 18-way cluster of then-state-of-the-art dual PIIIs, I recall needing to tweak one or two things in the kernel (for reasons I won't go into, we had a large number of things on the PCI bus, and
It's not clear how well the G5 version of Linux is optimized (although it should be trivial to reoptimize it for the G5 if it's not -- probably a couple months kernel hacker time), but my impression is the VaTech guys didn't bother to investigate this, and instead said "We've got a full-fledged FreeBSD under MacOS!" and ran with it. Nothing I can find on their web site indicates any sort of competitive comparison.
The "minimal cost" of upgrading compared to the 5 million budget is bogus. That's over a thousand high-end Apple boxes. Those things cost considerably more than a grand each to produce (raw manufacturing costs), so that's easily over a fifth of their budget. They'll probably do some funky accounting to make it look minimal (give G5s to profs, who don't really want them, or place them in computer labs, or similar, and discount the cost it would have taken to do this in the first place). To be doing this change this late means they f-ed up big on some design parameter early on (didn't realize space/power/thermal limitations, didn't investigate other G5 platforms, or similar). I know university funding doesn't work like normal funding (money comes from sponsors, and some expensive things are "free", while some cheap things are unaffordable), but that doesn't make up for the huge cost.
I know people will be screaming that Apple or IBM probably footed much of the bill, but I think had VaTech talked to Intel or AMD, they could have gotten a similar offer (although the other chip houses probably couldn't have matched it).
Anyways, I won't rant and rave more. Everything I said is based on minimal information -- looking at the VaTech site, there just isn't that much. As a result, some of what I said might be wrong. Anyone from VaTech with actual facts care to provide some insight? By facts, I mean "The PIII-3.2GHz costs x dollars per box, while the G5 costs y dollars. We benchmarked them with z scientific computing test, and found the G5 has w advantage," rather than "we downloaded some benchmarks from a Macintosh web site." More importantly, provide insight on why you chose MacOS-X (got any benchmarks?)
You should look into getting ham radio licenses for all your techs, and getting amateur radios. For non-commercial use (high school theater certainly qualifies), those would be perfect. The lowest level license is very easy to get -- simple exam, no morse code. You can buy a book ("Now You're Talking"), and if you read it, you'll ace the test. All the possible questions on the exam are also on-line (www.arrl.org). I cannot overemphasize how easy it is -- I learned what I needed for it in elementary school (higher-level exams are hard).
That gives you access to HF frequencies, which don't go very far, which for use in theatre is very good (no interference). To clarify, "not very far" means your town, as opposed to hitting stations in Australia and Japan. You may also be able to talk to the local ham community, and get a block of bandwidth for yourselves (there are protocols for doing this in the ham community, and it shouldn't be difficult). The FCC has laws about non-interference, and everyone on the waves is licensed, so you can expect people to respect this.
Using 802.11 would be both very expensive, unreliable, and cumbursome in comparison. Ham equipment will also last forever -- 802.11 already has a, b, and g, and will presumably have new standards coming out every so often. Every several years, all your equipment will become obsolete. There also aren't very well established standards for sending audio over TCP/IP. What you use now may not exist in a couple years.
SSB and FM, in contrast, have been here for close to a century, and aren't going away anytime soon.
You'll also have large numbers of potential suppliers for your equipment, open standards, and all that good stuff. This gives you access to amazing resources if you want to do anything more fancy (repeaters, etc.). You have access to a big block of bandiwidth, so you can switch channels if you want to have an individual conversation with someone. In addition, the equipment is general-purpose. You can use it for anything you'd use an amateur radio for, and other people's amateur radios can interface to you. You also have a very large community of technically inclined people on the waves who would be willing to support you (kinda like GNU/Linux, back in '94 or '95, before there was a mass of people). Hams are (a) friendly (b) helpful (c) constantly complaining about the lack of new blood. They also generally know a heck of a lot (the highest-level license basically requires you to know how to design a radio from scratch).
I cannot think of many other communications standards that offer all of this. To some extent, CB, but then you're vulnerable to pricks interfering on purpose (if your school is at all like mine was). Then again, if you're school is more civilized, or the dumb people are even dumber, this might not be a problem....
The only annoyance is that, when you transmit, you need to broadcast your callsign every so often (a series of up to 7 characters; for instance KB7DQQ).
I definitely wouldn't go for anything digital -- until the standards are better established, you'd find yourself with obsolete equipment very soon.
For those of you who like stupid science tricks/supercheap climate control, here's a trick for how to heat and cool a house without using any energy (outside of what's free from the Sun):
/ blackbody/bbody.html), which gives 300-500W/m^2 at typical Earth temperatures (over 400W/m^2 heat loss at typical room temperature).
First, some background on black body radiation. All matter radiates some light, based on its temperature. By basic thermodynamics, the amount of radiation that a color of matter absorbs in a given frequency range (as opposed to reflects) is directly proportional to how much it radiates (as compared to a perfect black body of the same temperature).
The sun only radiates on a fairly small set of frequencies, and that set is very different from the frequencies at which a black body at room temperature radiates. If you build a panel of a material that is perfectly absorbent in the frequencies on which the Sun radiates (perfect black body), but reflects in the remaining frequencies (perfectly white on the blackbody frequencies of room temperature), it will lose very little heat to radiation, but absorb a lot from the sun, and it'll get very hot. If you take a body that reflects radiation in the colors the sun emits (white), but absorbs/radiates elsewhere (black), it'll get very, very cool, even in bright sunlight. You can get pretty close to the full 1000W/m^2 of heating (level of Sun's radiation hitting the earth). In cooling, you get pretty close to the ideal from Stefan's Law (http://www.egglescliffe.org.uk/physics/astronomy
This means that you can theoretically heat or cool a house with just a painted square on the roof a few square meters in area, if you could just create a material of the right color.
Problem is the guy who came up with this (and showed it to me) was a physicist and not a chemist, and had no idea how one would go about creating a material whose color was that well controlled.
Still a nifty concept, eh? If you could make this, it would save a ton of energy, since you'd no longer need to burn gas to heat and use electricity to cool -- just flip a panel on your roof, and the temperature changes (although for heating, the house would need to be well enough insulated to last the night).
I'd give it a while to see if it's a real research lab. I've seen a large number of tech companies form "research labs" that are basically engineering products for a year or two down the line. I've interacted with one .com where the entire software development team was called a research lab.
A traditional research lab focuses on basic research, with occasional industry applications coming out. Examples of this include IBM TJ Watson Research Center, Xerox PARC, Bell Labs, (surprisingly) Microsoft Research, as well as most acadamic labs. These have the property that many projects have no applications for as much as 20+ years, but they are critical to long-term economic growth, and most importantly, they are fun to work at. As a result, they have a very easy time recruiting good people, and for all the economic loss on "basic research projects," generate some very cool stuff otherwise.
Right now, although I'm not sure how much fundamental research Google does, it does require employees to spend 20% of their time on personal pet projects, which encourages a lot of creativity. They are a very fun employer, and at least looking at MIT AI Lab and Stanford, Google seems to pick of the cream-of-the-crop from PhDs not going into acadamia. Yahoo, on the other hand, has the army-of-moron-developers models.
If Yahoo, on the other hand, starts a search engine development team, and calls it "Yahoo Labs," I will be unimpressed. However, from the press release, it is entirely unclear what form the lab will take, but from the phrases in the press release ("strategic projects," "short-term projects," "work collaboratively with Yahoo! business"), I am inclined to think it'll be the software development team called a research lab, rather a real research lab.