You've got three resources you need to be carrying with you on the bike: network connectivity, processing (CPU) power and electrical power.
The network connectivity is the easiest: get a cellular phone with CDPD (Cellular Digital Packet Data) or GSM data service. Most cell phones come equipped with an IR port or a serial port attachment so you can connect the phone to an IrDA or serial-capable device and use it as a wireless modem. GSM phones are probably your best bet, since they're most standardized. Check with different cellular service providers to see if any of them cover the entire state of Iowa. I know AT&T does, but they use TDMA which isn't as good as GSM.
Next, you'll need a computer, with webcam, to hook this phone to. Your options here are: buy an iPAQ handheld for $500 (if you can get your hands on one!), or buy a Sony Vaio mini-notebook for $2500 (weighs less than a pound, about the size of a portable CD player)
If you can get hold of an iPAQ, it should suffice nicely. Your challenge will then be to connect a webcam to the iPAQ. The iPAQ has a USB port, so any USB webcam will do; the problem will be finding Windows CE drivers for the webcam. You can install an experimental version of Linux on your iPAQ, courtesy of the Compaq research team. Under Linux it should be a snap to use one of the Linux video APIs to capture frames from the webcam. Your cell phone's data link will also work under Linux, via the iPAQ's IrDA port. To find out how to install Linux on an iPAQ, check out the howto: ftp://ftp.handhelds.org/pub/linux/compaq/ipaq/stab le/install.html. The advantages of an iPAQ are that it's small, very light, and has a comparatively long battery life. If you shut the display off, a single battery charge should last you 24 hours.
The Sony Vaio is an x86 machine AND it has a camera built into the case, so it's a no-brainer to get a webcam working with it, out of the box. The problems with it are its price and its battery life: even with the display off, the battery isn't going to last longer than six hours. If you buy a VAIO, you'll either need to carry along some spare batteries, rig some sort of generator for it, or stop frequently for recharges.
A final note: a continuous cellular data connection can be pretty durned expensive. Expect $0.15 per minute of use; even if you only connect when you're using the service, you'll be spending at least $5 / day on webcam updates.
Rumors of our demise have been greatly exaggerated
on
Rebooting The World?
·
· Score: 1
I think we can all agree that any cataclysm severe enough to obliterate every computer in the world would have the side effect of reducing humanity to the zero function.
However--for argument's sake, let us posit that some disaster has taken out every transistor in the entire world. How long until we're writing our memos in Word again? Not very.
A concerted "bootstrap" effort, with massive infusions of manpower, raw materials and other support from interested parties (and there would be quite a few of those!) could be manufacturing surface-mount transistors inside of six months, assuming all the fabrication machines and other trappings of the electronics industry were at their disposal. Using these, they could build simple logic gates, giving us 1960s-style technology, and the more complicated machinery required to manufacture integrated circuits.
They'd have a bountiful supply of raw materials (silicon wafers, pins, casings and other minutiae) to draw on, since nobody else would be using the stuff!
Starting from ground zero, I'd give it 10 years before we had megaflops machines, and from there a kind of turbo Moore's Law would take effect, artificially accelerated by the fact that we could draw on wealth of completed research into memory architecture, cache design, pipelining, superscalar/speculative/out-of-order execution and a host of other technologies.
Unfortunately, starting over from scratch wouldn't guarantee we do things right this time. Truth is, if you upset humans from equilibrium, they strive to return to exactly where they were, duplicating their successes and failures, advantages and disadvantages.
Certainly, for single users it makes sense to compile your own binaries. You get to choose your optimizations, configure the programs to suit your needs, install everything just where you want--and most important, you gain experience which makes you a better power user and eventually leads you down the road to coding!
It's just not a viable solution for people who need to administer more than one machine, or who lack the time, tenacity or willingness to delve into the mysteries of the tools they use daily.
It's still not a good idea from a security standpoint, but this is not a problem if you're just doing this on your personal system at home.
Lately I've taken a clean-room approach to all my app packaging. I install Linux into a VMWare session running the exact distro and version of the OS I'm packaging software for; I install *only* the tools that are available on the target platform, plus exactly what I need to compile the software. It's been working very well.
By installating a suite of development tools on a production system, you're providing that many more potential security holes to the would-be cracker.
In addition, since most recent applications use dozens of APIs on top of the standard libraries and the Posix API, you're looking at potentially installing hundreds of megabytes of headers, debug libraries, compiler binaries, preprocessors and other development tools, on every single system you own. This is a phenomenal waste of resources, both disk space and time.
If you want portable code, then you should write everything in Java (or Python or any other language which provides for cross-platform binaries and supplies a rich set of universal APIs.)
If you aren't willing to do this, then you must be willing to live with the fact that computers are diverse, and varied.
While it's true that we're advancing the technologies required for really good e-text, I predict that it won't catch on for many years. You can give someone an electronic text in a format that preserves layout perfectly, and you can render it for them at 1600x1200 resolution with antialiased text and all the bells and whistles you could ever wish--but you'll still be displaying it on a monitor or (in the very best case) a plasma display.
Books are versatile. You can read printed text almost anywhere, under any lighting conditions (other than complete darkness.) The sharpness and contrast of the text is limited only by your printing process. At 72dpi, even the cheapest pulp romance is on par, resolution wise, with the most sophisticated computer display available. The paper is absorbing light rather than emitting it; looking at a pattern of emitted light, no matter how small the individual pixels, is something our brains were not evolved to do.
There are also psychological factors unique to "real" texts. People like the smell of ink and paper; they like to turn pages. They love the way the paper feels against their fingers and they enjoy "breaking in" a new book's binding by rifling through the pages.
So, until someone comes up with a display technology that can provide the tactile, audiovisual and even olfactory benefits of paper, it's here to stay.
"We will stalk the infidels with their own hedonistic tools of mindless amusement! We will turn their pig-dog economics against them and kill them in their beds! We will....oooh, pretty pictures. Ibn Abd-el Hakim, give me the controller!"
I think this is a fabulous idea. Why? Because anytime you go to a site in the.health domain you can be confident that you're getting medical information that agrees at least in part with the opinions of the medical establishment. As much as we gripe about doctors and HMOs and other features/bugs of Western medicine, they do a pretty decent job.
So what does this mean for health sites that the WHO won't sanction? Are they out of luck? Certainly not! They can set up a beautiful website under.com or.org or.ws or any other TLD they choose. Perhaps we can even form a new gTLD,.ill, for health-related sites that aren't WHO-sanctioned. =]
Seriously--the fact that a.health site is guaranteed to contain valid medical knowledge, does not imply that a non-.health site is guaranteed not to contain medical knowledge. That's one hell of a fallacy. If WHO were proposing to regulate all health websites, I'd be up in arms. But they're simply proposing to carve out a hunk of the DNS namespace and set it aside in the name of conservative medicine. If I open my own health website under a different TLD (sex-prevents-heart-disease.com?) and it's popular enough and useful enough, then its domain name really won't matter.
The hard drive doesn't suck as much power as you'd think, under the right conditions. If you provide an extremely generous disk cache with tons of read-ahead, and spin down your drive after a minute of disuse, it won't be such a big problem. Why not produce a hard drive that "idles" at low RPM and then kicks into high gear when it receives an I/O request. A variable-speed hard drive would be significantly harder, but probably still doable.
Lithium polymer batteries have started hitting the market--the iPaq uses them, for one, and my new cell phone does as well. With their significantly higher energy density and the Crusoe's power-saving, we'll be seeing laptops with a running time of 6-8 hours--or to put it another way, laptops with a running time of 4 hours that have virtually no battery. This still isn't enough, and definitely isn't worth the 50% performance hit reported on some applications.
In my experience, the biggest power drains on a mobile system are (of course) the display and the CD-ROM/DVD drive. I'm waiting for a new display technology (light-emitting polymer, for example) that will make more difference than the Crusoe or lithium polymer combined.
In the short term, DDR SDRAM is going to be the man of the day. DDR is an improvement on an existing technology (and quite an ingenious one, at that!) It's easy to work with, well-known and since it works in lockstep with the CPU, it's easy to develop for.
In the long term, however, we will see a transaction to bus-based memory, such as RDRAM. (I personally don't think RDRAM will ever fly; some other incarnation of the same idea will likely spring up, a few years down the road.)
Abstracting your core memory behind a memory bus gives the advantages that your chipset can talk to any kind of memory that supports the bus standard--it could be of any speed, implemented with any technology (for instance, holographic memory.) Its disadvantage--and few people seem to realize this!--is that it's quite slow, compared to SDRAM where the chipset (and the CPU) has direct access to the data lines coming from the RAM.
To compensate for this inadequacy, the makers of Rambus RAM pumped the ram bus's clock rate to some absurd speed--I recall hearing 400MHz mentioned. They should have realized that memory technology isn't sufficiently advanced yet, and left well enough alone.
I'm not a rocket scientist, but it occurs to me that they'd need to match orbit with every Iridium satellite they wanted to salvage. And if all the Iridium sats are in the same orbit at different places, that'd make the job even harder! It probably wouldn't be cost-effective if you add in fuel costs and flight time costs.
Here at UCSB, there is a student-taught course called Linux Kernel Hacking, which familiarizes students with the kernel, kernel data structures and the workings of the kernel. The assignments are things like: use advanced features of the OS such as shared memory and IPC, write a device driver for a simple homebrewed device, etc.
The problem is namespace collision. Now, while adding new TLDs can be said to make the namespace larger, riddle me this: when was the last time you saw a startup register just a.com, and not a.net or an.org? Furthermore, how many alternative TLD vendors (such as.to and.cx) stress wordmark-defense in their online promotional material? They all have literature that says "You've got the.com,.net and.org, but do you have the.blah domain under your control? If you don't, you're just asking for it, buddy!"
With that kind of attitude, adding TLDs simply isn't going to help--the same company who registered foo.com is going to register foo.web. And if someone else gets it first, it's still going to do nothing but cause confusion. Do I want to visit newcars.com, newcars.web or newcars.sex? If I can hardly remember the name 'newcars' when I see it on the TV screen, how am I, Joe Q. Consumer, supposed to remember the TLD as well?
I do advocate the addition of a few new TLDs:.web for entities that desire mainly a web presence,.nom for private citizens (perhaps with an arbitration/playing-nice policy to keep smith.nom from being dominated by one person) and.tm for domain names that are registered trademarks--domains to be claimed only by the holder of the trademark, of course!
Aside from that, I would be delighted to see the.us domain opened to general use, with.com.us,.net.us and.org.us available. I would happily switch all my domains to.us in the name of uniform global DNS conventions.
From what I've seen so far in the comments for this item, people aren't claiming that Dilberitos will taste bad; in fact, I think they look rather yummy.
My main beef (no pun intended) with the Dilberito is that most of them are vegan. By catering to the lowest common denominator and leaving the meat and dairy out of these products, they are losing a lot of business from people who enjoy the taste of meat in their meals.
Although from the perspective of my chosen diet the Dilberito seems like a healthful meal, I don't think I'll be buying many of them because:
they are likely to be expensive, and
meat satiates my hunger better than veggies
In response to many peoples' comments about hatred of vegans--every vegan I know, save one, has an unbearable "holier-than-thou" attitude about his or her veganness. When they proudly proclaim "I'm vegan" at restaurants and other places (which they do frequently and with much vigor) the tone of their voices clearly connotes a certain superiority, as if by choosing to be vegan, they are somehow better than I.
You would be bothered by someone who frequently said "I'm gay" or "I'm christian" or "I'm a democrat," wouldn't you? I am a very tolerant individual and whatever lifestyle choice you make is fine with me. Just don't get smug about it, or if you are smug, have the good taste not to do it in such a vocal manner.
In a more frivolous vein, doesn't a vegan food product run contrary to the whole Dilbert ethos? When think of Dilbert, I imagine a pudgy, Coke-guzzling white male, not a health nut. It seems to me that, by flaunting the vegetarianness, they will be further alienating their target market of techies who are well-to-do and health conscious, but are either not obsessed with health or don't know much about nutrition.
Unfortunately, you are being a bit too optimistic. Porting DirectX or Office 2000 would mean porting COM, which as a binary-level specification leaves quite a bit lacking. COM, from the level of calling conventions and method vtables up to the interfaces that are part of "standard" COM were designed with Win32 in mind--for instance, multithreading is pervasive in COM applications, whereas in Unix we are still developing based around the more flexible but less intuitive "many small tools which work together" paradigm.
What all this means is simply that porting COM to Unix (or even x86 Linux) would be a waste of man-hours and the cause of untold amounts of woe due to bugs and security holes.
The only project to benefit directly from the opening of the Windows source would be WINE; everybody else could play cut-and-paste (or glance-and-type if Microsoft's license is unduly strict), and their products may end up the better for it. But the majority of the source would go to waste, while at the same time placating DoJ and allowing Microsoft to proceed with its plans. Whatever they may be.
Not everybody would agree with your claim that the human mind is nondeterministic. Alan Turing was keen on the idea that the mind is a Turing machine. DNA is actually simpler than a Turing machine. So be careful when you pull a holier-than-thou routine on microprocessors...you just may be insulting your little cousins.
When I'm writing time-critical code I use a different approach: first I write it in my high-level language of choice, then I gank the compiler's output and see if I can better it.
But you know what? I find myself doing that less and less, since the amount of code I consider "time critical" gets smaller with every passing day. Furthermore, ever since those funky, dancing bunny-suited good-for-nothings introduced multiple pipelines, superscalar, out-of-order and speculative execution, things have gotten a whole lot harder for the poor assembly programmer.
I use Java frequently at work, and personally I prefer it over almost any other language out there for application and network programming. But I would be remiss if I didn't point out a few potential problems with Java as a language, that make it less desireable for situations where performance is 100% critical.
First off, I agree with the hypothesis about garbage collection being potentially faster than explicit allocation and deallocation (especially on a multiprocessor system!) Second, it might be possible to make memory allocation code aware of repeated allocations and deallocations of the same size, and have it set aside a few chunks of memory to be recycled continuously.
The problem with Java, IMHO, is not garbage collection. It's all the dereferencing that kills you. Consider the case of a line of Java code that refers to the member variable this.myInteger. The Java VM (or the Just In Time compiled code, or whatever) first must convert the object handle to a memory reference to get the object's base address. (Object handles are a necessary evil because they let the garbage collector reorganize memory blocks on the fly.) Next, the VM must add an offset to the base address to obtain the address of the variable. That's a whole lotta dereferencing to get at a simple int.
Running JIT-compiled code on a RISC machine, we've just performed a bare minimum of 3 loads to get to something that would have required only 1 load in C, or 2 loads in C++. The numbers are different on an Intel machine, but everyone knows those are slow by nature.;)
Another area to examine is method calls. In C++, non-virtual method calls cost almost nothing, and virtual calls have a small overhead. In Java, however, all method calls are virtual--not only that, they're called by method name instead of vtable pointer. A JIT could try and optimize this out, but it still must make allowances for introspection and method calls coming from un-JITted code.
I'm sure I've missed a few reasons why Java is slow, but I think I've kicked it around enough for tonight. Until someone can tackle these problems, Java is still slower than an early-binding language like C++. But with judicious use of native code (which has of course been aggressively optimized) we might be able to narrow the performance gap to ~15%. That would be enough to convince most people that Java is not a toy.
Comparing the GPL to licenses for other types of intellectual property is unfair. What almost nobody in the world seems to realize is that software is not in the same class of intellectual property as a painting, photograph or song. Think about it: a compiled executable is (in a loose sense) an implementation of one or more algorithms. An algorithm is a set of very specific instructions for manipulating some data.
Since algorithms are invented by people and require creativity to invent, it seems logical that they should copyrightable. But not programs. Why not? Because a program is an implementation of some algorithms, and not an algorithm in itself!
To draw a simple analogy--a painter copyrights his painting. He does not copyright the canvas it's painted on, nor does he copyright the paints he used to render it upon the canvas. If a software company wants to copyright their software, that's fine with me because I will always find a way to modify, copy and to whatever else I want to the software without even breaking the license agreement or breaking any laws, because the laws are treating the software as if it's an idea! (If you're not convinced of this email me and I will go over it with you in detail.) I'm free to do this because the software publisher has attempted to copyright the medium and not the idea. I never even need to consider piracy.
One would think so, but they seem to be silent on that front. And of course there are millions of Macrovision-weak DVD decoder cards out there by now, so it's impossible to pull a "firmware upgrade" to get rid of the problem. Some versions of the RealMagic Hollywood Plus drivers even allow direct AC-3 output to a special brand of sound card! Someone with the right equipment could play a DVD on Computer #1 and encode it on Computer #2 in real time, in the proper format. (AFAIK, no common video file formats even SUPPORT AC-3 encoded audio streams. And very few sound cards can play it back!)
Nice though the thought is, I don't think they'll be legally able to help out. There are due diligence issues associated with it, and too many people have a slice of the Red Hat pie not to worry about one of them raising a stink.
That's what digital videocasette technology is for. We've come to a technological juncture where there are multiple technologies available for storing our audiovisual media.
It so happens that professionally produced works like movies are better suited to random-access optical media like DVDs, because of the increased quality, interactivity and multiplicity of content afforded by them. (Multiplicity of content is a handy catch-all phrase I'm using to refer to things like subtitles, foreign language tracks, different audio encoding schemes--in other words, any situation where the content is offered in more than one format, in order to increase the usefulness of the content.)
For the home user, we have digital videotapes which are recordable, rewritable and relatively cheap, at the expense of being linearly accessed and fairly inflexible in terms of the different content formats they accept. (You can only interlace so many streams on a strip of tape before it becomes unmanageable.)
Emerging technologies may change the picture somewhat. These new ultra-high-density CDROMs I've been hearing about might be a good candidate to replace DVDs. Likewise, realtime wavelet compression would do wonders for the home digital video market (can you imagine a 90-minute 8mm tape that held 8 hours of video?!?)
Unforunately, however, until someone comes up with a rewritable optical storage technology that's suitable for use in battery-powered devices like camcorders, I'm afraid we're stuck with VHS and its digital cousins. (I'm not an electronics expert, but I'm guessing the laser in your CD burner would drain your camcorder battery pretty darned quickly!)
I wasn't aware of these particular ramifications of the DMCA and I'm sure that I speak for every rights-minded person who read your post and followed the link. A few speculations/observations came to mind while I was skimming it.
"...technology, product, service, device, component, or part thereof..." Does this seem ambiguous to anyone else? If I write an academic paper on the mathematical theory behind cracking CSS, it's certainly not a device, component, service or product, nor is it a part thereof. Is it a technology? Since there is (conveniently) no table of contents in the PDF file, it's rather hard to find the DMCA definition of a technology. If a paper (or a newspaper article or a web page) counts as a technology, then this seems to restrict free speech.
"A technological measure 'effectively controls access to a work' if the measure, in the ordinary course of its operation, requires the application of information, or a process or a treatment, with the authority of the copyright owner, to gain access to the work." The important point to note here is "in the ordinary course of its operation." Who defines the "ordinary course" of a technological measure's operation? Since CCA never published any information about the ordinary course of CSS's operation (and still hasn't to my knowledge) then how can DeCSS be circumventing it? (This is a weaker argument than #1, but still worth looking into.)
You're right. However: within a few months of the debut of the first affordable dual-layer DVD burner will follow the debut of the first DVD player capable of bit-for-bit copy, thus making the entire CSS encryption scheme a moot point.
Hence, it is clear that the purpose of CSS isn't to prevent piracy, which will eventually become possible no matter what, but to maintain control of the technology. The only way for CSS to remain viable in the long run is to prevent any bit-for-bit DVD burners from reaching the market--and if that isn't controlling the market, then I don't know what is!
Slashdot Mirror
You've got three resources you need to be carrying with you on the bike: network connectivity, processing (CPU) power and electrical power.
b le/install.html. The advantages of an iPAQ are that it's small, very light, and has a comparatively long battery life. If you shut the display off, a single battery charge should last you 24 hours.
The network connectivity is the easiest: get a cellular phone with CDPD (Cellular Digital Packet Data) or GSM data service. Most cell phones come equipped with an IR port or a serial port attachment so you can connect the phone to an IrDA or serial-capable device and use it as a wireless modem. GSM phones are probably your best bet, since they're most standardized. Check with different cellular service providers to see if any of them cover the entire state of Iowa. I know AT&T does, but they use TDMA which isn't as good as GSM.
Next, you'll need a computer, with webcam, to hook this phone to. Your options here are: buy an iPAQ handheld for $500 (if you can get your hands on one!), or buy a Sony Vaio mini-notebook for $2500 (weighs less than a pound, about the size of a portable CD player)
If you can get hold of an iPAQ, it should suffice nicely. Your challenge will then be to connect a webcam to the iPAQ. The iPAQ has a USB port, so any USB webcam will do; the problem will be finding Windows CE drivers for the webcam. You can install an experimental version of Linux on your iPAQ, courtesy of the Compaq research team. Under Linux it should be a snap to use one of the Linux video APIs to capture frames from the webcam. Your cell phone's data link will also work under Linux, via the iPAQ's IrDA port. To find out how to install Linux on an iPAQ, check out the howto: ftp://ftp.handhelds.org/pub/linux/compaq/ipaq/sta
The Sony Vaio is an x86 machine AND it has a camera built into the case, so it's a no-brainer to get a webcam working with it, out of the box. The problems with it are its price and its battery life: even with the display off, the battery isn't going to last longer than six hours. If you buy a VAIO, you'll either need to carry along some spare batteries, rig some sort of generator for it, or stop frequently for recharges.
A final note: a continuous cellular data connection can be pretty durned expensive. Expect $0.15 per minute of use; even if you only connect when you're using the service, you'll be spending at least $5 / day on webcam updates.
However--for argument's sake, let us posit that some disaster has taken out every transistor in the entire world. How long until we're writing our memos in Word again? Not very.
A concerted "bootstrap" effort, with massive infusions of manpower, raw materials and other support from interested parties (and there would be quite a few of those!) could be manufacturing surface-mount transistors inside of six months, assuming all the fabrication machines and other trappings of the electronics industry were at their disposal. Using these, they could build simple logic gates, giving us 1960s-style technology, and the more complicated machinery required to manufacture integrated circuits.
They'd have a bountiful supply of raw materials (silicon wafers, pins, casings and other minutiae) to draw on, since nobody else would be using the stuff!
Starting from ground zero, I'd give it 10 years before we had megaflops machines, and from there a kind of turbo Moore's Law would take effect, artificially accelerated by the fact that we could draw on wealth of completed research into memory architecture, cache design, pipelining, superscalar/speculative/out-of-order execution and a host of other technologies.
Unfortunately, starting over from scratch wouldn't guarantee we do things right this time. Truth is, if you upset humans from equilibrium, they strive to return to exactly where they were, duplicating their successes and failures, advantages and disadvantages.
Certainly, for single users it makes sense to compile your own binaries. You get to choose your optimizations, configure the programs to suit your needs, install everything just where you want--and most important, you gain experience which makes you a better power user and eventually leads you down the road to coding!
It's just not a viable solution for people who need to administer more than one machine, or who lack the time, tenacity or willingness to delve into the mysteries of the tools they use daily.
It's still not a good idea from a security standpoint, but this is not a problem if you're just doing this on your personal system at home.
Lately I've taken a clean-room approach to all my app packaging. I install Linux into a VMWare session running the exact distro and version of the OS I'm packaging software for; I install *only* the tools that are available on the target platform, plus exactly what I need to compile the software. It's been working very well.
By installating a suite of development tools on a production system, you're providing that many more potential security holes to the would-be cracker.
In addition, since most recent applications use dozens of APIs on top of the standard libraries and the Posix API, you're looking at potentially installing hundreds of megabytes of headers, debug libraries, compiler binaries, preprocessors and other development tools, on every single system you own. This is a phenomenal waste of resources, both disk space and time.
If you want portable code, then you should write everything in Java (or Python or any other language which provides for cross-platform binaries and supplies a rich set of universal APIs.)
If you aren't willing to do this, then you must be willing to live with the fact that computers are diverse, and varied.
While it's true that we're advancing the technologies required for really good e-text, I predict that it won't catch on for many years. You can give someone an electronic text in a format that preserves layout perfectly, and you can render it for them at 1600x1200 resolution with antialiased text and all the bells and whistles you could ever wish--but you'll still be displaying it on a monitor or (in the very best case) a plasma display.
Books are versatile. You can read printed text almost anywhere, under any lighting conditions (other than complete darkness.) The sharpness and contrast of the text is limited only by your printing process. At 72dpi, even the cheapest pulp romance is on par, resolution wise, with the most sophisticated computer display available. The paper is absorbing light rather than emitting it; looking at a pattern of emitted light, no matter how small the individual pixels, is something our brains were not evolved to do.
There are also psychological factors unique to "real" texts. People like the smell of ink and paper; they like to turn pages. They love the way the paper feels against their fingers and they enjoy "breaking in" a new book's binding by rifling through the pages.
So, until someone comes up with a display technology that can provide the tactile, audiovisual and even olfactory benefits of paper, it's here to stay.
"We will stalk the infidels with their own hedonistic tools of mindless amusement! We will turn their pig-dog economics against them and kill them in their beds! We will....oooh, pretty pictures. Ibn Abd-el Hakim, give me the controller!"
I think this is a fabulous idea. Why? Because anytime you go to a site in the .health domain you can be confident that you're getting medical information that agrees at least in part with the opinions of the medical establishment. As much as we gripe about doctors and HMOs and other features/bugs of Western medicine, they do a pretty decent job.
.com or .org or .ws or any other TLD they choose. Perhaps we can even form a new gTLD, .ill, for health-related sites that aren't WHO-sanctioned. =]
.health site is guaranteed to contain valid medical knowledge, does not imply that a non-.health site is guaranteed not to contain medical knowledge. That's one hell of a fallacy. If WHO were proposing to regulate all health websites, I'd be up in arms. But they're simply proposing to carve out a hunk of the DNS namespace and set it aside in the name of conservative medicine. If I open my own health website under a different TLD (sex-prevents-heart-disease.com?) and it's popular enough and useful enough, then its domain name really won't matter.
So what does this mean for health sites that the WHO won't sanction? Are they out of luck? Certainly not! They can set up a beautiful website under
Seriously--the fact that a
The hard drive doesn't suck as much power as you'd think, under the right conditions. If you provide an extremely generous disk cache with tons of read-ahead, and spin down your drive after a minute of disuse, it won't be such a big problem. Why not produce a hard drive that "idles" at low RPM and then kicks into high gear when it receives an I/O request. A variable-speed hard drive would be significantly harder, but probably still doable.
Lithium polymer batteries have started hitting the market--the iPaq uses them, for one, and my new cell phone does as well. With their significantly higher energy density and the Crusoe's power-saving, we'll be seeing laptops with a running time of 6-8 hours--or to put it another way, laptops with a running time of 4 hours that have virtually no battery. This still isn't enough, and definitely isn't worth the 50% performance hit reported on some applications.
In my experience, the biggest power drains on a mobile system are (of course) the display and the CD-ROM/DVD drive. I'm waiting for a new display technology (light-emitting polymer, for example) that will make more difference than the Crusoe or lithium polymer combined.
In the short term, DDR SDRAM is going to be the man of the day. DDR is an improvement on an existing technology (and quite an ingenious one, at that!) It's easy to work with, well-known and since it works in lockstep with the CPU, it's easy to develop for.
In the long term, however, we will see a transaction to bus-based memory, such as RDRAM. (I personally don't think RDRAM will ever fly; some other incarnation of the same idea will likely spring up, a few years down the road.)
Abstracting your core memory behind a memory bus gives the advantages that your chipset can talk to any kind of memory that supports the bus standard--it could be of any speed, implemented with any technology (for instance, holographic memory.) Its disadvantage--and few people seem to realize this!--is that it's quite slow, compared to SDRAM where the chipset (and the CPU) has direct access to the data lines coming from the RAM.
To compensate for this inadequacy, the makers of Rambus RAM pumped the ram bus's clock rate to some absurd speed--I recall hearing 400MHz mentioned. They should have realized that memory technology isn't sufficiently advanced yet, and left well enough alone.
I'm not a rocket scientist, but it occurs to me that they'd need to match orbit with every Iridium satellite they wanted to salvage. And if all the Iridium sats are in the same orbit at different places, that'd make the job even harder! It probably wouldn't be cost-effective if you add in fuel costs and flight time costs.
Here at UCSB, there is a student-taught course called Linux Kernel Hacking, which familiarizes students with the kernel, kernel data structures and the workings of the kernel. The assignments are things like: use advanced features of the OS such as shared memory and IPC, write a device driver for a simple homebrewed device, etc.
The problem is namespace collision. Now, while adding new TLDs can be said to make the namespace larger, riddle me this: when was the last time you saw a startup register just a .com, and not a .net or an .org? Furthermore, how many alternative TLD vendors (such as .to and .cx) stress wordmark-defense in their online promotional material? They all have literature that says "You've got the .com, .net and .org, but do you have the .blah domain under your control? If you don't, you're just asking for it, buddy!"
.web for entities that desire mainly a web presence, .nom for private citizens (perhaps with an arbitration/playing-nice policy to keep smith.nom from being dominated by one person) and .tm for domain names that are registered trademarks--domains to be claimed only by the holder of the trademark, of course!
.us domain opened to general use, with .com.us, .net.us and .org.us available. I would happily switch all my domains to .us in the name of uniform global DNS conventions.
With that kind of attitude, adding TLDs simply isn't going to help--the same company who registered foo.com is going to register foo.web. And if someone else gets it first, it's still going to do nothing but cause confusion. Do I want to visit newcars.com, newcars.web or newcars.sex? If I can hardly remember the name 'newcars' when I see it on the TV screen, how am I, Joe Q. Consumer, supposed to remember the TLD as well?
I do advocate the addition of a few new TLDs:
Aside from that, I would be delighted to see the
My main beef (no pun intended) with the Dilberito is that most of them are vegan. By catering to the lowest common denominator and leaving the meat and dairy out of these products, they are losing a lot of business from people who enjoy the taste of meat in their meals.
Although from the perspective of my chosen diet the Dilberito seems like a healthful meal, I don't think I'll be buying many of them because:
In response to many peoples' comments about hatred of vegans--every vegan I know, save one, has an unbearable "holier-than-thou" attitude about his or her veganness. When they proudly proclaim "I'm vegan" at restaurants and other places (which they do frequently and with much vigor) the tone of their voices clearly connotes a certain superiority, as if by choosing to be vegan, they are somehow better than I.
You would be bothered by someone who frequently said "I'm gay" or "I'm christian" or "I'm a democrat," wouldn't you? I am a very tolerant individual and whatever lifestyle choice you make is fine with me. Just don't get smug about it, or if you are smug, have the good taste not to do it in such a vocal manner.
In a more frivolous vein, doesn't a vegan food product run contrary to the whole Dilbert ethos? When think of Dilbert, I imagine a pudgy, Coke-guzzling white male, not a health nut. It seems to me that, by flaunting the vegetarianness, they will be further alienating their target market of techies who are well-to-do and health conscious, but are either not obsessed with health or don't know much about nutrition.
Unfortunately, you are being a bit too optimistic. Porting DirectX or Office 2000 would mean porting COM, which as a binary-level specification leaves quite a bit lacking. COM, from the level of calling conventions and method vtables up to the interfaces that are part of "standard" COM were designed with Win32 in mind--for instance, multithreading is pervasive in COM applications, whereas in Unix we are still developing based around the more flexible but less intuitive "many small tools which work together" paradigm.
What all this means is simply that porting COM to Unix (or even x86 Linux) would be a waste of man-hours and the cause of untold amounts of woe due to bugs and security holes.
The only project to benefit directly from the opening of the Windows source would be WINE; everybody else could play cut-and-paste (or glance-and-type if Microsoft's license is unduly strict), and their products may end up the better for it. But the majority of the source would go to waste, while at the same time placating DoJ and allowing Microsoft to proceed with its plans. Whatever they may be.
Not everybody would agree with your claim that the human mind is nondeterministic. Alan Turing was keen on the idea that the mind is a Turing machine. DNA is actually simpler than a Turing machine. So be careful when you pull a holier-than-thou routine on microprocessors...you just may be insulting your little cousins.
Food for thought.
But you know what? I find myself doing that less and less, since the amount of code I consider "time critical" gets smaller with every passing day. Furthermore, ever since those funky, dancing bunny-suited good-for-nothings introduced multiple pipelines, superscalar, out-of-order and speculative execution, things have gotten a whole lot harder for the poor assembly programmer.
First off, I agree with the hypothesis about garbage collection being potentially faster than explicit allocation and deallocation (especially on a multiprocessor system!) Second, it might be possible to make memory allocation code aware of repeated allocations and deallocations of the same size, and have it set aside a few chunks of memory to be recycled continuously.
The problem with Java, IMHO, is not garbage collection. It's all the dereferencing that kills you. Consider the case of a line of Java code that refers to the member variable this.myInteger. The Java VM (or the Just In Time compiled code, or whatever) first must convert the object handle to a memory reference to get the object's base address. (Object handles are a necessary evil because they let the garbage collector reorganize memory blocks on the fly.) Next, the VM must add an offset to the base address to obtain the address of the variable. That's a whole lotta dereferencing to get at a simple int.
Running JIT-compiled code on a RISC machine, we've just performed a bare minimum of 3 loads to get to something that would have required only 1 load in C, or 2 loads in C++. The numbers are different on an Intel machine, but everyone knows those are slow by nature. ;)
Another area to examine is method calls. In C++, non-virtual method calls cost almost nothing, and virtual calls have a small overhead. In Java, however, all method calls are virtual--not only that, they're called by method name instead of vtable pointer. A JIT could try and optimize this out, but it still must make allowances for introspection and method calls coming from un-JITted code.
I'm sure I've missed a few reasons why Java is slow, but I think I've kicked it around enough for tonight. Until someone can tackle these problems, Java is still slower than an early-binding language like C++. But with judicious use of native code (which has of course been aggressively optimized) we might be able to narrow the performance gap to ~15%. That would be enough to convince most people that Java is not a toy.
Since algorithms are invented by people and require creativity to invent, it seems logical that they should copyrightable. But not programs. Why not? Because a program is an implementation of some algorithms, and not an algorithm in itself!
To draw a simple analogy--a painter copyrights his painting. He does not copyright the canvas it's painted on, nor does he copyright the paints he used to render it upon the canvas. If a software company wants to copyright their software, that's fine with me because I will always find a way to modify, copy and to whatever else I want to the software without even breaking the license agreement or breaking any laws, because the laws are treating the software as if it's an idea! (If you're not convinced of this email me and I will go over it with you in detail.) I'm free to do this because the software publisher has attempted to copyright the medium and not the idea. I never even need to consider piracy.
One would think so, but they seem to be silent on that front. And of course there are millions of Macrovision-weak DVD decoder cards out there by now, so it's impossible to pull a "firmware upgrade" to get rid of the problem. Some versions of the RealMagic Hollywood Plus drivers even allow direct AC-3 output to a special brand of sound card! Someone with the right equipment could play a DVD on Computer #1 and encode it on Computer #2 in real time, in the proper format. (AFAIK, no common video file formats even SUPPORT AC-3 encoded audio streams. And very few sound cards can play it back!)
Nice though the thought is, I don't think they'll be legally able to help out. There are due diligence issues associated with it, and too many people have a slice of the Red Hat pie not to worry about one of them raising a stink.
It so happens that professionally produced works like movies are better suited to random-access optical media like DVDs, because of the increased quality, interactivity and multiplicity of content afforded by them. (Multiplicity of content is a handy catch-all phrase I'm using to refer to things like subtitles, foreign language tracks, different audio encoding schemes--in other words, any situation where the content is offered in more than one format, in order to increase the usefulness of the content.)
For the home user, we have digital videotapes which are recordable, rewritable and relatively cheap, at the expense of being linearly accessed and fairly inflexible in terms of the different content formats they accept. (You can only interlace so many streams on a strip of tape before it becomes unmanageable.)
Emerging technologies may change the picture somewhat. These new ultra-high-density CDROMs I've been hearing about might be a good candidate to replace DVDs. Likewise, realtime wavelet compression would do wonders for the home digital video market (can you imagine a 90-minute 8mm tape that held 8 hours of video?!?)
Unforunately, however, until someone comes up with a rewritable optical storage technology that's suitable for use in battery-powered devices like camcorders, I'm afraid we're stuck with VHS and its digital cousins. (I'm not an electronics expert, but I'm guessing the laser in your CD burner would drain your camcorder battery pretty darned quickly!)
Hence, it is clear that the purpose of CSS isn't to prevent piracy, which will eventually become possible no matter what, but to maintain control of the technology. The only way for CSS to remain viable in the long run is to prevent any bit-for-bit DVD burners from reaching the market--and if that isn't controlling the market, then I don't know what is!
I wonder how publishers of Macrovision-encoded VHS tapes account for fair use laws? Or perhaps they don't. If so, then fair use laws will have gone the way of city ordinances prohibiting the detonation of nuclear devices within city limits.