You raise the question, and suggest a pessimistic answer. Yes, there are a lot of important measures of success for a VM (good match to real machines, good match for language set, managability, etc.). I agree that standardizing on "One True Language" is a bad idea, and probably so is "One True VM", but I think this is less obvious.
I think the problem is that there are so many issues involved. First, there is the desire to distribute machine independent code, then there are the runtime environments which is where things get really complex. Stripping away all the libraries of the environment, there are still a lot of issues relating to calling conventions (these are critical to maintaining the integrity of the user code "sandbox" (e.g. Java)), and data types (i.e. raw data structures of basic types vs. objects and strings, and the implications of this for memory management).
What may be possible is to settle on a small number of optional aspects of the VMs, but still have a single framework so that code from language systems that require different option sets can all be accomidated. The single unified VM that supports everything would probably be pretty big and complex, but at least it would be possible and practical, and the VM could manage the interfacing requirements to enable integration of sub-systems from radically different languages. Many choices in VM implemetation won't change the VM, but make a big difference in how well it runs. JIT technology, and other speed/space or even run/startup speed tradeoffs are part of it. Management interfaces is another area for variation that may also be visible in the environments (i.e. library APIs).
Seems possible, but it doesn't make sense from a single vendor with a single vision. I have always taken it to be axiomatic that no vendor should "own" a language. Writing code for a language system that can't be freely implemented by other vendors puts you and your organization at the mercy of a 3rd party. In most cases, this is folly bordoring on incompetence. I claim the same is true for VMs; don't give the vendor power to contol your future path/options.
One of the big problems cited in the past was that Sun would not certify OS JVMs, without a big fee. In most cases, this is impractical for OS projects that need to spend limited resources on development and infrastructure. I know some have suggested a certification "scholarship" idea, but I don't know if that has gone anywhere. I'm more willing to trust Sun and their long history of promoting open systems, if not open source, but others remain very skeptical.
The unstated implication of runaway nano-tech is that they are at the very least self-replicating, which is essential for any type of "escape" scenario, as in Prey. It's a little different, cell-division vs. an assembler factory that can make more assemblers. There is no reason to assume that the factories only make one type of nanite, or even that they are all the same size. The only requirement is that the factory can at least build all the nanite types needed to build another factory. The factory itself could be nano-scale, or it could involve millions of billions of individual assemblers of a variety of types. You could even think of biological cells as a factory where the sub-cellular organells corespond to nanites, then cell division looks like a better analogy. But I digress.
Biological cells generally can't change their function unless they are of a special class of stem cells, but highly differentiated cells cannot. They can generally still divide to make more differentiated cells of the same type.
Maybe I will hunt for the math stuff for the scale factors, but none of this is really an argument that the SF scenarios cannot happen, just that the author got the "how" part wrong. Personally, I like SF where the plausibility factor is really high and nothing stands out as improbable for logical reasons.
Think of it in terms of the worries over creating the first atomic fission reactor. Probably, most of the scientists involved had a pretty good idea that fission couldn't be sustained in the more stable matter outside the core of the experiment, but were they able to do a mathematical analysis that proved it was "safe"? At the time, it took whole rooms full of human computers to do even the most basic calculations about the expirements. I'm sure they did some calculations related to stability and extent of any possible chain reaction, but they didn't know enough or have enough computing power to answer all the critical questions with certainty.
My gut feeling from what I know about systems tells me not to worry too much about the grey goo scenarios and other run-away nano-tech predictions. In reality, the questions raised by nano-tech are not that different than the ones we can already see on the horizon. Fundamentally, we need to advance our social and ethical frameworks much more quickly to handle the rapid changes in science and technology. Bottom line is that we all share this world, and if some or a lot of people are left out the odds for something bad happening increases. It is much more likely that technology will go badly wrong because a group of disenfranchised malcontents will intentionally start something than that a herd of wild nanites will escape the lab and unintentionally trash the world. I guess I'm basically saying that the really important and difficult questions are social, not technical. Tech just makes it more critical that we solve the problems, and hopefully gives us some good tools if we use them for good.
I get your point about applying Reynolds numbers to the details of how "multicellular's" move and such, but the quoted max of "2mm/sec" or whatever it was doesn't lend itself to the more complex interpretations. It's unclear how this would come down in terms of "speed limits". Would smaller cellular units be good or bad in terms of top speed for the "organism"? I suspect that it isn't that significant, so I would expect that nano-organisms have similar scale limitations for speed and such.
I think the "highly differentiated" distinction is overrated here. Human cells all have the same "information content" as would the nanites, and I would expect that they could be just as differentiated as biological cells.
BTW, I probably come down more on the side of Dyson in all of this, but I think it is important to make the arguments solid as well.
I agree with what you are saying about reasons people would want to edit, but for myself, I would not find much value in the kind of 3rd party edit lists that are put out now (or at least, I don't think I would). If they gave a lot more control as to the type of thing you wanted edited out, I might look a bit more.
I don't think there is much decided law about the status of the edit lists themselves. I know that there is precident for the idea that legal publishers own the "page and section numbering" even for case law books where all the the underlying material is in the public domain. Citing a couple of cases would clearly be under fair use, but what about cross referenced indexes that refer you back via these page and section numbers? It seems to me that a court could easily decide that the edit lists themselves are indeed a derivitive work requiring the agreement of the copyright holder.
IANAL, and even if I was, the law here is probably not decided yet. I would expect that the courts would give a lot of leeway to individuals and non-profits producing and exchanging cue lists, but once you start to sell it the court will probably find for the copyright holder.
It goes without saying that trying to restrict people from doing this is going to be bad for sales, but we already have plenty of example cases where the content industry is being stupid by trying to control everything and extract every last possible drop of revenue.
I haven't read Prey, so I don't know about how this is dealt with, but my first thought with the stuff about Reynolds numbers was only considering the individual nanites, not how they might behave as a unit of many. If this argument were valid, it would mean you could use the numbers for a single cell to predict a human's top speed.
Now, the other objections are probably more reasonable, but this one has problems, and doesn't really seem like a valid criticism to me.
Sorry, but your analogy is just plain wrong. The trees are the hardware vendors, and all I was saying is that some of them might not survive. Sun and IBM will be around for a long time; HP and SGI are more doubtful, but actually, unification of the OS side makes it a lot more likely that they all will. Well, I have my doubts about HP; they are likely to kill of their PA line in favor of commodity PC hardware and getting in bed with MS.
Exactly what are the trees that MS has? They are completely parasitic, and they are likely to fall quickly. The scale of hardware businesses completely dwarfs even MS in their present bloated state, so I wouldn't put all my eggs in that basket.
As a unified, Open Source operating system that will run on anybody's hardware, Linux is here to stay. The UNIX heritage gives it the kind of deep roots that will ensure its long term survival. Think about it, MS has already abandoned the original DOS and Windows product lines in favor of NT derived products, and it can be argued that these code lines are already gone forever. When the inevitable happens, and the current product line is no longer viable, that will be lost as well. OS guarantees that Linux and all the other OS code that runs on it will be with us as long as anyone finds them useful.
The real effect will be to unmask the people pushing this craziness, and show everyone what control freaks they really are. When I first heard about the way Hollywood, and in particular directors were up in arms about the companies that were producing "safe" versions of various movies, I was simpathetic. In fact, what they were doing was producing a derivative work without permission, and Hollywood really had a good case. When you start thinking about providing the consumer with the information necessary to enable their player to do these edits in real time from the original media, I think the jig is up.
You've got to ask where this would stop. If I want to play pieces of my DVDs cut-up and in whatever sequence I want, that is my right as an owner of the media. My wife often doesn't want to watch anything with extremely violent scenes, and these scenes are rarely important to my enjoyment either (often I'd just as soon have them gone, but not so strongly that I wouldn't watch). There still might be a legal issue WRT the "skip data" because a court may decide this is derived from the original work, but this still shouldn't stop the individual from cutting a work in any way they please.
Also, if they appose "special" players that can do this, I suppose they want to outlaw any playback through a computer. Even with MS style DRM, computer playback will be likely to give you a lot more flexibility than with any purpose built player. This may, in fact, be the origin of the fact the MS is supporting the electronics industry against the content providers. Ultimately, Hollywood wants to prevent any playback flexibility, which is the whole point of having PC playback anyway.
Finally, does anyone really think these "special" devices would even work? You're going to have to have some security controls related to loading the "censor" data, and how old do you think the kids have to get before their hacking skills out-distance their parents ability to control these devices. I'm sure that some with some devices all it will take is a power cycle, and you'll be able to play the raw disks again.
When Linux wins, UNIX does not lose out; it wins. In case you didn't notice, Linux is a UNIX variant, and this from IBM is a major acknowledgement that Linux is uniting UNIX, something that the industry attempted but failed miserably with in the '80s. In part, this is why Windows won (it is more complex, but the UNIX splintering was very good for MS).
No, you can't charge as much for the system, but it doesn't cost you as much to produce either. It means all of the former UNIX, soon to be Linux vendors have to get a lot more competetive. They will now have to compete head-to-head with quality, service and support. Some will lose out and disappear, but the customers will win. It's all about value.
I doubt that Microsoft sees this UNIX unification as good for them because it means their competition is a lot more unified. No, this process isn't a done deal yet, but the handwriting is on the wall. Keep in mind that each hardware vendor that survives will probably have their own Linux distro that is pre-loaded and fully configured for their hardware. This makes a fully functional Linux desktop a lot more likely, and it also means that the ISVs will start targetting Linux a lot more often. In the days of a splinterred UNIX, it was just too costly to target all of the flavors because each was a unique port. With Linux you can probably just do a build for each platform, and in many cases produce a single CD release with all the versions. This makes it a lot more practical because one Linux port gets you a large market. In the end, this will also drive the Non-Linux UNIXes out of the market (Solaris probably being the last hold-out).
What are you talking about? Linux already runs on the same hardware they sell AIX for (primarily PPC based systems, I'm not aware of others). The IBM "customizations" won't be a special kernel, but support for a number of technologies important to current AIX customers. This support may be completely propriatary, but it will run on Linux, and they will continue to give back changes to the Linux community.
Now, they could use Linux to make PPC systems viable on the desktop, but that battle still has to be won in general. This, nor Linux on laptops aren't going to be mainstream next week, but we can still hope. IBM's endorsment means a lot for corporate adoption. Nobody can make noise about lack of support, you can buy IBM hardware and they will support it.
I expect IBM to take care of these people. If this is for real, they will take care of them with a release of Linux, but it won't come until the existing AIX base is comfortable with it. IBM has always bet their business on catering to the needs of serious customers with real work to do, and I don't expect this to change.
What is really good about this is that IBM is now competing on the merits with hardware performance and service. This is why we all pushed for "Open Systems" even before Linux was even a dream. They always had good support and service, so there is no reason they won't compete successfully on the merits. No "vendor motel" marketing techniques anymore to lock-in customers.
IBM was not about to help out its competitors by endorsing one of their UNIX flavors, but Linux is free for anyone to use, and GPL guarantees that it stays that way.
At this point, this is probably just a statement about likely future direction, and as such it doesn't mean much, but in the long run I would expect that many of the AIX engineering and support people can be retargeted for Linux. AIX has a lot of support for things their customers really need, and it will take a while to move the important bits of this over to Linux. Probably, they will not OS all of this, but it may become available for purchase for other platforms. All of this is good for the industry.
Yes, the analog wireless devices are common now, but obviously, that's not what this would be. No doubt they went with wired ethernet is that it best met the latency and bandwidth they needed. These requirements can probably be met with a wireless system, but probably not with many (if even one) current 802.11* gear.
I have no idea whether anyone is already working on the technology for "realtime" digital wireless, but I'm sure any breakthrough would be prime/. material. Yeah, why not an Open * project.... It would be cool technology.
One really good reason for not having ballast -
if you lose all electrical power, you float to
the surface. Think about it.
Not only that, but they mention that they can drop ballast in an emergency, so obviously there are ballast systems and components, just that in normal operation, it has a slightly positive boyancy, and need to keep moving to go down.
With the positive boyancy, you could shut down the motors and concerve power with a sort of inverted gliding. I remember seeing a story (maybe/.) about an underwater drone that could operate for long periods gliding both up and down by shifting the boyancy back and forth between negative and positive.
Or any useful one, anyway. If you're talking about just making it work for all formats, that seems to be more or less handled. The UI stuff, well, that's a matter of taste. First, let's make everything work, then bitch about UI. The part about mplayer being stuck at the bottom of the layering, just doesn't seem right; wouldn't this more likely be a window manager issue (or compatibility with)?
The real issue is that this should work with all formats out of the box without a lot of messing around or special configuration. It is much more of an integration issue for the distribution vendors than anything else. Ok, the hardware vendors have a role here too.
I read the LWCE stuff from Roblimo about his talk with the Dell reps. If they want to cred from us, they would do a better job of supporting their old hardware, then I might be more likely to actually buy a Dell if I ever get to buy a new computer. I had to open my box and guess which was the audio chip and read the numbers off it to figure out how to correctly configure my audio. I should be able to just get that information by just going to their support area and typing in my model number. I tried this and their site was remarkable unhelpful.
I managed to get some of the video functions to work, but mplayer seems to be a loss (my video hardware appears to be too old, and the system too slow to emulate everything). My browser plugin configuration just sucks, though. Plugger is installed and somewhat configured, and some media types will cause xine to fire up, but it just dies with no simple information about why. Maybe someday I will load a newer distribution (I'm RH7.3) on new hardware and everything will just work.
Oh, that brings up another stupidity in the JWZ review. His complaints about stuff dumped to the console. If you don't want it, how hard is it to direct to/dev/null? Sometimes, the only indication that you get of why things aren't functioning is a message dumped to the console. Often, I start up galeon from a console (because if you start if from a menu, the messages go to/dev/null, yet another way to easily ignore them) when something is breaking to see if the browser spits out some indication of what is wrong.
My biggest complaint is that there is no place to go for definitive information about all of this. People seem to imply that Xine will handle all formats, but it failed miserably when I tried in on an avi file (maybe I have to tell it the format? I thought it should figure it out...). That's why I was installing mplaying in the first place, I thought I needed it for windows formats. If I really cared, I'm sure I could find the information, but who has time to root around for this kind of information all the time.
I finally got around to getting sound to work on this ancient Dell I'm using, and initially I was pretty pissed off about how small everything was. I searched for some way to deal with this, looking for a function to zoom, or something, but I couldn't find it. Finally the option to double the display size popped out at me, and I find it to be much more usable. Only now I need a better output device than the built in speaker on my 17" KDS LCD monitor.
I agree that the skins thing is at best a distraction. The default skin just needs to be clear and usable. Some are at least usable once I double the size.
Re:I couldn't put it down
on
Tuxedo Park
·
· Score: 1
I realize you are making a joke here, but if the information is accurate, he was a genius and a particularly gregarious one at that. He obviously could keep many lines of thought going at once and quickly engage in any of them and produce deep insights. All of this would seem very self-promotional if he wasn't also intensly private about much of it. Seems like a lot to accept, but genius can be truely remarkable.
RADAR controlled anti-aircraft guns
on
Tuxedo Park
·
· Score: 1
I assume you are talking about WWII era stuff?
My dad was in the US Army after Korea, and was a service technition on some of the guns they were developing at that time. Recently, he was telling me about some of it. Apparently, the prototypes had an analog computing element that was essentially mechanical. Those never made it into production because they wouldn't work well unless you kept the mechanism moving (probably either or both static friction and followers making little dents and getting stuck). The vaccume tube based stuff worked better. The first models could only track a straight line path.
Ok, so the free speech aspects are more subtle and this article doesn't really cover that. There is another more important aspect of GPL software that is called out in the article, and you don't get this bennefit with BSD licensing.
They do point out that UNIX fragmented in the '80s and '90s because each UNIX vendor went off and created their own additions and variations, and that this is what created the opportunity for Windows to get into the server market. Without the introduction of Linux, we were quickly going to a situation where Sun was the defacto UNIX standard, and in the Sun/Solaris vs PC/Windows competition. This isn't that different from the competition with Apple, where the software development and support is really a drag on the hardware business (keeping costs up), and it is hard to compete with the commodity PC pricing (MS just cleans up, big time).
With Linux, system vendors can cooperate on software without worrying that the competition can just take their contribution and not return anything. IBM will not work on Darwin, but Linux is great precisly because of the limits imposed by the GPL.
Not being familiar with DNSSEC, I can't really comment on the specifics, but having done some serious PKI work for a secure messaging system a few years back I have a pretty good grasp of the issues. The bottom line is that what is important are the physical processes at the roots of the system and the software processes to support it.
What many people commenting on this story fail to realize is that the Certificate Authorities (CAs) are guaranteeing the integrity and security of their process, and not so much the identity of the person or entity applying for the certificates. In our messaging system, we had set up our own CA to issue personal certificates signed by signing certs that we bought from verisign. Since non-repudiation was an important feature of our messaging system, we did not rely on Verisign to verify identities for personal certs. Typically, a company would contract for us to provide personal certs for their people, and they would be responsible for connecting people with certs.
The idea of connecting site certificates with the issuing of domain names is a good one because the organization issuing the domain names already has a relationship with the owner of the name. This seems like the important link for site certs, and since it represents the potential for additional profits for the issuing organization, I would think they would jump on it. Of course, that's probably part of the problem as well, that nobody wants to pass up the potential revenue, so it is hard to set up the necessary relationships.
That said, it should be clear that it wouldn't be that hard to create a 'public' CA, but it couldn't be free either. When this came up before I outlined how it could be done in a comment, but how would you know you could trust this. I could create certs for myself and my friends, but who else would trust it. It isn't that hard to add new root certs to most browsers, so there is no reason you couldn't do this for your company or organization. If more organizations were actually using client certs to authenticate, it probably would be worthwhile to create a cheap, but secure, public facility.
If anyone has the persistance to actually make this happen, I would certainly be open to helping design the processes and maybe write some software. It really is an excellent idea. Ultimately, I would consider it a complete success when the root certs are pre-loaded into most common browsers. It is completely doable, and although there are important details to get right, it isn't really all that complex.
Competent management would already be addressing the problems, so this situation begs the question. The help desk it there to provide an efficient and effective interface between IT and the rest of the company (we are talking about internal help-desk, implied, but not stated). If they aren't fielding the simple calls, then there is no point investing resources. If the 'customers' are keeping the help-desk overworked with questions they should know, then you either have a training or hiring problem (both should be addressed by competent management). If you don't know whether either or both of these conditions are present, you have to measure it. A ticket traking system can do this, but you should have a pretty good idea what is going on without formal measurement.
You also need a range of skills to draw on. Good help-desk people are almost as valuable and rare as good tech people, just a different skill set. Depending on the size of the organization (and therefore the help-desk), there should be a range of experience and processes in place to rotate people to expose them to more situation (i.e to gain experience), and more experienced people always available to help out. A lot of times, there is enough work load to have admins assigned to the help-desk to handle second tier problems directly (help-desk staff takes the call and dispatches to the correct on-desk or on-call person). Admins don't like to do this all the time, so you're going to have to rotate if possible.
If a developer is getting involved, it's called debugging, and it shouldn't be sitting with the help-desk anyway. If your developers are being bothered all the time with help questions, then they aren't doing much developing. Again, this would be a management problem, because good managers will be aware of this sort of thing and take steps to fix it.
The main point here is that IT departments understand that their support costs will always be less if they have fewer distinct environments to support. Mid to large size organizations need some flavor of UNIX to support enterprise applications because reguardless of MS marketting and FUD, there just isn't anything better for infrastructure. The only realy problems are the hoops that MS makes you jump through to support their protocols in another OS. IT managers and engineers know this, and MS has pissed them off repeatedly and at every opportunity. The only people who are really happy with Windows are end users and IT people in MS only shops, and most of them because they don't know any better.
Back when I started my career in the late '70s and early '80s, the prevailing wisdom was that nobody could get fired because they bought IBM systems, but I found their dominance disturbing and felt it held back progress. At that time, I speculated that IBM's days of market dominace were numbered, but I wasn't confident enough to predict their downfall in about ten years. With MicroSoft in a similar position today, I am willing to make predictions. Things are moving faster, so I give MS less time, probably 5-10 years from now. The very thing that propelled them to the current position, the desire of managers to standardise on one OS, will lead to their downfall just as quickly. Linux is much more ready to move into the desktop than Windows is to take over enterprise server apps. While Sun and IBM can say, go ahead and run Linux, but buy our hardware for the performance and support. MS doesn't have this lever, so when the fall, they will fall hard.
Although I actually do think it is likely that Linux will become the new standard, and probably one or two distribution vendors will win big time, I don't think you should worry about commercialization. The commercially oriented vendors and support houses will go this way, but that's already what they do. The core development will remain with the widely dispersed project teams, and GPL (and similar) licensing guarantees that it will remain so. I would worry if one company hired everyone in one of the core teams (kernel, Gnome or KDE for example), but that isn't likely to happen. They don't need to hire the whole team to be influential, just hire people to work on the areas valuable to them.
I realise that this is easier said than done in most organizations, but long term, it is really the only way. Is there really anything that Notes does that wouldn't be better implemented using open standards and/or free/open software tools?
The reason it won't run well under Wine is that the clients just plain don't run that well anywhere. Unless it is way better than the last time I had to use it, this is already an obsolete product that any sane organization would be phasing out, and they certainly would not be creating new applications using this closed technology. Stay with it, and you will be burned, it is just a question of when.
You are correct about what would be required for "Open DRM". I don't really expect the content industry to allow this easily, only if they are taking a really huge market hit, and even then...
I am making the point that in some sense we have a right to view/hear content under Linux and other OSs, and to the extent that what is available is more or less Windows only there is a legal argument. At the very least, there is a new monopoly claim against MS (with the help of the content industries).
You too easily dismiss the efficacy of implementing fair DRM in Linux and other open systems (note that few Solaris admins could work well or happily within the contraints of DRM that doesn't trust them to make system modifications). Most people will not go out of their way to modify the distributions configuration, or recompile some tools in order to break the law. If Linux ever becomes mainstream, we know most people will not change anything from the defaults, and if Linux is ever to become mainstream, it must have the ability to show/play content. Sure, sites could provide ready made tools to make the mods easy, but that would clearly violate the intent and spirit of copy protections. There is little of no reason to do this if fair-use copying is allowed. Yes, the system can't always tell if a copy falls under fair use or not, so the user is still being trusted to follow the rules, but most people want to be fair, so all that is necessary is to clearly state what is permitted before they click the "ok, start the copy" button. What I am proposing is to respect any DRM flags and data, and keep them in the copies. You would have to hack source to create a tool that removed this information, and gnutella should respect this as well. If you are running a public server, you shouldn't have unrestricted downloads of protected content. It is only "easy" in the hacker sense to circumvent these controls.
Slashdot Mirror
I think the problem is that there are so many issues involved. First, there is the desire to distribute machine independent code, then there are the runtime environments which is where things get really complex. Stripping away all the libraries of the environment, there are still a lot of issues relating to calling conventions (these are critical to maintaining the integrity of the user code "sandbox" (e.g. Java)), and data types (i.e. raw data structures of basic types vs. objects and strings, and the implications of this for memory management).
What may be possible is to settle on a small number of optional aspects of the VMs, but still have a single framework so that code from language systems that require different option sets can all be accomidated. The single unified VM that supports everything would probably be pretty big and complex, but at least it would be possible and practical, and the VM could manage the interfacing requirements to enable integration of sub-systems from radically different languages. Many choices in VM implemetation won't change the VM, but make a big difference in how well it runs. JIT technology, and other speed/space or even run/startup speed tradeoffs are part of it. Management interfaces is another area for variation that may also be visible in the environments (i.e. library APIs).
Seems possible, but it doesn't make sense from a single vendor with a single vision. I have always taken it to be axiomatic that no vendor should "own" a language. Writing code for a language system that can't be freely implemented by other vendors puts you and your organization at the mercy of a 3rd party. In most cases, this is folly bordoring on incompetence. I claim the same is true for VMs; don't give the vendor power to contol your future path/options.
One of the big problems cited in the past was that Sun would not certify OS JVMs, without a big fee. In most cases, this is impractical for OS projects that need to spend limited resources on development and infrastructure. I know some have suggested a certification "scholarship" idea, but I don't know if that has gone anywhere. I'm more willing to trust Sun and their long history of promoting open systems, if not open source, but others remain very skeptical.
Biological cells generally can't change their function unless they are of a special class of stem cells, but highly differentiated cells cannot. They can generally still divide to make more differentiated cells of the same type.
Maybe I will hunt for the math stuff for the scale factors, but none of this is really an argument that the SF scenarios cannot happen, just that the author got the "how" part wrong. Personally, I like SF where the plausibility factor is really high and nothing stands out as improbable for logical reasons.
Think of it in terms of the worries over creating the first atomic fission reactor. Probably, most of the scientists involved had a pretty good idea that fission couldn't be sustained in the more stable matter outside the core of the experiment, but were they able to do a mathematical analysis that proved it was "safe"? At the time, it took whole rooms full of human computers to do even the most basic calculations about the expirements. I'm sure they did some calculations related to stability and extent of any possible chain reaction, but they didn't know enough or have enough computing power to answer all the critical questions with certainty.
My gut feeling from what I know about systems tells me not to worry too much about the grey goo scenarios and other run-away nano-tech predictions. In reality, the questions raised by nano-tech are not that different than the ones we can already see on the horizon. Fundamentally, we need to advance our social and ethical frameworks much more quickly to handle the rapid changes in science and technology. Bottom line is that we all share this world, and if some or a lot of people are left out the odds for something bad happening increases. It is much more likely that technology will go badly wrong because a group of disenfranchised malcontents will intentionally start something than that a herd of wild nanites will escape the lab and unintentionally trash the world. I guess I'm basically saying that the really important and difficult questions are social, not technical. Tech just makes it more critical that we solve the problems, and hopefully gives us some good tools if we use them for good.
I think the "highly differentiated" distinction is overrated here. Human cells all have the same "information content" as would the nanites, and I would expect that they could be just as differentiated as biological cells.
BTW, I probably come down more on the side of Dyson in all of this, but I think it is important to make the arguments solid as well.
I don't think there is much decided law about the status of the edit lists themselves. I know that there is precident for the idea that legal publishers own the "page and section numbering" even for case law books where all the the underlying material is in the public domain. Citing a couple of cases would clearly be under fair use, but what about cross referenced indexes that refer you back via these page and section numbers? It seems to me that a court could easily decide that the edit lists themselves are indeed a derivitive work requiring the agreement of the copyright holder.
IANAL, and even if I was, the law here is probably not decided yet. I would expect that the courts would give a lot of leeway to individuals and non-profits producing and exchanging cue lists, but once you start to sell it the court will probably find for the copyright holder.
It goes without saying that trying to restrict people from doing this is going to be bad for sales, but we already have plenty of example cases where the content industry is being stupid by trying to control everything and extract every last possible drop of revenue.
Now, the other objections are probably more reasonable, but this one has problems, and doesn't really seem like a valid criticism to me.
Exactly what are the trees that MS has? They are completely parasitic, and they are likely to fall quickly. The scale of hardware businesses completely dwarfs even MS in their present bloated state, so I wouldn't put all my eggs in that basket.
As a unified, Open Source operating system that will run on anybody's hardware, Linux is here to stay. The UNIX heritage gives it the kind of deep roots that will ensure its long term survival. Think about it, MS has already abandoned the original DOS and Windows product lines in favor of NT derived products, and it can be argued that these code lines are already gone forever. When the inevitable happens, and the current product line is no longer viable, that will be lost as well. OS guarantees that Linux and all the other OS code that runs on it will be with us as long as anyone finds them useful.
You've got to ask where this would stop. If I want to play pieces of my DVDs cut-up and in whatever sequence I want, that is my right as an owner of the media. My wife often doesn't want to watch anything with extremely violent scenes, and these scenes are rarely important to my enjoyment either (often I'd just as soon have them gone, but not so strongly that I wouldn't watch). There still might be a legal issue WRT the "skip data" because a court may decide this is derived from the original work, but this still shouldn't stop the individual from cutting a work in any way they please.
Also, if they appose "special" players that can do this, I suppose they want to outlaw any playback through a computer. Even with MS style DRM, computer playback will be likely to give you a lot more flexibility than with any purpose built player. This may, in fact, be the origin of the fact the MS is supporting the electronics industry against the content providers. Ultimately, Hollywood wants to prevent any playback flexibility, which is the whole point of having PC playback anyway.
Finally, does anyone really think these "special" devices would even work? You're going to have to have some security controls related to loading the "censor" data, and how old do you think the kids have to get before their hacking skills out-distance their parents ability to control these devices. I'm sure that some with some devices all it will take is a power cycle, and you'll be able to play the raw disks again.
No, you can't charge as much for the system, but it doesn't cost you as much to produce either. It means all of the former UNIX, soon to be Linux vendors have to get a lot more competetive. They will now have to compete head-to-head with quality, service and support. Some will lose out and disappear, but the customers will win. It's all about value.
I doubt that Microsoft sees this UNIX unification as good for them because it means their competition is a lot more unified. No, this process isn't a done deal yet, but the handwriting is on the wall. Keep in mind that each hardware vendor that survives will probably have their own Linux distro that is pre-loaded and fully configured for their hardware. This makes a fully functional Linux desktop a lot more likely, and it also means that the ISVs will start targetting Linux a lot more often. In the days of a splinterred UNIX, it was just too costly to target all of the flavors because each was a unique port. With Linux you can probably just do a build for each platform, and in many cases produce a single CD release with all the versions. This makes it a lot more practical because one Linux port gets you a large market. In the end, this will also drive the Non-Linux UNIXes out of the market (Solaris probably being the last hold-out).
Now, they could use Linux to make PPC systems viable on the desktop, but that battle still has to be won in general. This, nor Linux on laptops aren't going to be mainstream next week, but we can still hope. IBM's endorsment means a lot for corporate adoption. Nobody can make noise about lack of support, you can buy IBM hardware and they will support it.
What is really good about this is that IBM is now competing on the merits with hardware performance and service. This is why we all pushed for "Open Systems" even before Linux was even a dream. They always had good support and service, so there is no reason they won't compete successfully on the merits. No "vendor motel" marketing techniques anymore to lock-in customers.
At this point, this is probably just a statement about likely future direction, and as such it doesn't mean much, but in the long run I would expect that many of the AIX engineering and support people can be retargeted for Linux. AIX has a lot of support for things their customers really need, and it will take a while to move the important bits of this over to Linux. Probably, they will not OS all of this, but it may become available for purchase for other platforms. All of this is good for the industry.
I have no idea whether anyone is already working on the technology for "realtime" digital wireless, but I'm sure any breakthrough would be prime /. material. Yeah, why not an Open * project .... It would be cool technology.
Not only that, but they mention that they can drop ballast in an emergency, so obviously there are ballast systems and components, just that in normal operation, it has a slightly positive boyancy, and need to keep moving to go down.
With the positive boyancy, you could shut down the motors and concerve power with a sort of inverted gliding. I remember seeing a story (maybe /.) about an underwater drone that could operate for long periods gliding both up and down by shifting the boyancy back and forth between negative and positive.
The real issue is that this should work with all formats out of the box without a lot of messing around or special configuration. It is much more of an integration issue for the distribution vendors than anything else. Ok, the hardware vendors have a role here too.
I read the LWCE stuff from Roblimo about his talk with the Dell reps. If they want to cred from us, they would do a better job of supporting their old hardware, then I might be more likely to actually buy a Dell if I ever get to buy a new computer. I had to open my box and guess which was the audio chip and read the numbers off it to figure out how to correctly configure my audio. I should be able to just get that information by just going to their support area and typing in my model number. I tried this and their site was remarkable unhelpful.
I managed to get some of the video functions to work, but mplayer seems to be a loss (my video hardware appears to be too old, and the system too slow to emulate everything). My browser plugin configuration just sucks, though. Plugger is installed and somewhat configured, and some media types will cause xine to fire up, but it just dies with no simple information about why. Maybe someday I will load a newer distribution (I'm RH7.3) on new hardware and everything will just work.
Oh, that brings up another stupidity in the JWZ review. His complaints about stuff dumped to the console. If you don't want it, how hard is it to direct to /dev/null? Sometimes, the only indication that you get of why things aren't functioning is a message dumped to the console. Often, I start up galeon from a console (because if you start if from a menu, the messages go to /dev/null, yet another way to easily ignore them) when something is breaking to see if the browser spits out some indication of what is wrong.
My biggest complaint is that there is no place to go for definitive information about all of this. People seem to imply that Xine will handle all formats, but it failed miserably when I tried in on an avi file (maybe I have to tell it the format? I thought it should figure it out ...). That's why I was installing mplaying in the first place, I thought I needed it for windows formats. If I really cared, I'm sure I could find the information, but who has time to root around for this kind of information all the time.
I agree that the skins thing is at best a distraction. The default skin just needs to be clear and usable. Some are at least usable once I double the size.
I realize you are making a joke here, but if the information is accurate, he was a genius and a particularly gregarious one at that. He obviously could keep many lines of thought going at once and quickly engage in any of them and produce deep insights. All of this would seem very self-promotional if he wasn't also intensly private about much of it. Seems like a lot to accept, but genius can be truely remarkable.
My dad was in the US Army after Korea, and was a service technition on some of the guns they were developing at that time. Recently, he was telling me about some of it. Apparently, the prototypes had an analog computing element that was essentially mechanical. Those never made it into production because they wouldn't work well unless you kept the mechanism moving (probably either or both static friction and followers making little dents and getting stuck). The vaccume tube based stuff worked better. The first models could only track a straight line path.
Yeah, I don't get that either. I thought supporting DRM and copy protection was part of their fiendish plans?
They do point out that UNIX fragmented in the '80s and '90s because each UNIX vendor went off and created their own additions and variations, and that this is what created the opportunity for Windows to get into the server market. Without the introduction of Linux, we were quickly going to a situation where Sun was the defacto UNIX standard, and in the Sun/Solaris vs PC/Windows competition. This isn't that different from the competition with Apple, where the software development and support is really a drag on the hardware business (keeping costs up), and it is hard to compete with the commodity PC pricing (MS just cleans up, big time).
With Linux, system vendors can cooperate on software without worrying that the competition can just take their contribution and not return anything. IBM will not work on Darwin, but Linux is great precisly because of the limits imposed by the GPL.
What many people commenting on this story fail to realize is that the Certificate Authorities (CAs) are guaranteeing the integrity and security of their process, and not so much the identity of the person or entity applying for the certificates. In our messaging system, we had set up our own CA to issue personal certificates signed by signing certs that we bought from verisign. Since non-repudiation was an important feature of our messaging system, we did not rely on Verisign to verify identities for personal certs. Typically, a company would contract for us to provide personal certs for their people, and they would be responsible for connecting people with certs.
The idea of connecting site certificates with the issuing of domain names is a good one because the organization issuing the domain names already has a relationship with the owner of the name. This seems like the important link for site certs, and since it represents the potential for additional profits for the issuing organization, I would think they would jump on it. Of course, that's probably part of the problem as well, that nobody wants to pass up the potential revenue, so it is hard to set up the necessary relationships.
That said, it should be clear that it wouldn't be that hard to create a 'public' CA, but it couldn't be free either. When this came up before I outlined how it could be done in a comment, but how would you know you could trust this. I could create certs for myself and my friends, but who else would trust it. It isn't that hard to add new root certs to most browsers, so there is no reason you couldn't do this for your company or organization. If more organizations were actually using client certs to authenticate, it probably would be worthwhile to create a cheap, but secure, public facility.
If anyone has the persistance to actually make this happen, I would certainly be open to helping design the processes and maybe write some software. It really is an excellent idea. Ultimately, I would consider it a complete success when the root certs are pre-loaded into most common browsers. It is completely doable, and although there are important details to get right, it isn't really all that complex.
You also need a range of skills to draw on. Good help-desk people are almost as valuable and rare as good tech people, just a different skill set. Depending on the size of the organization (and therefore the help-desk), there should be a range of experience and processes in place to rotate people to expose them to more situation (i.e to gain experience), and more experienced people always available to help out. A lot of times, there is enough work load to have admins assigned to the help-desk to handle second tier problems directly (help-desk staff takes the call and dispatches to the correct on-desk or on-call person). Admins don't like to do this all the time, so you're going to have to rotate if possible.
If a developer is getting involved, it's called debugging, and it shouldn't be sitting with the help-desk anyway. If your developers are being bothered all the time with help questions, then they aren't doing much developing. Again, this would be a management problem, because good managers will be aware of this sort of thing and take steps to fix it.
Back when I started my career in the late '70s and early '80s, the prevailing wisdom was that nobody could get fired because they bought IBM systems, but I found their dominance disturbing and felt it held back progress. At that time, I speculated that IBM's days of market dominace were numbered, but I wasn't confident enough to predict their downfall in about ten years. With MicroSoft in a similar position today, I am willing to make predictions. Things are moving faster, so I give MS less time, probably 5-10 years from now. The very thing that propelled them to the current position, the desire of managers to standardise on one OS, will lead to their downfall just as quickly. Linux is much more ready to move into the desktop than Windows is to take over enterprise server apps. While Sun and IBM can say, go ahead and run Linux, but buy our hardware for the performance and support. MS doesn't have this lever, so when the fall, they will fall hard.
Although I actually do think it is likely that Linux will become the new standard, and probably one or two distribution vendors will win big time, I don't think you should worry about commercialization. The commercially oriented vendors and support houses will go this way, but that's already what they do. The core development will remain with the widely dispersed project teams, and GPL (and similar) licensing guarantees that it will remain so. I would worry if one company hired everyone in one of the core teams (kernel, Gnome or KDE for example), but that isn't likely to happen. They don't need to hire the whole team to be influential, just hire people to work on the areas valuable to them.
The reason it won't run well under Wine is that the clients just plain don't run that well anywhere. Unless it is way better than the last time I had to use it, this is already an obsolete product that any sane organization would be phasing out, and they certainly would not be creating new applications using this closed technology. Stay with it, and you will be burned, it is just a question of when.
I am making the point that in some sense we have a right to view/hear content under Linux and other OSs, and to the extent that what is available is more or less Windows only there is a legal argument. At the very least, there is a new monopoly claim against MS (with the help of the content industries).
You too easily dismiss the efficacy of implementing fair DRM in Linux and other open systems (note that few Solaris admins could work well or happily within the contraints of DRM that doesn't trust them to make system modifications). Most people will not go out of their way to modify the distributions configuration, or recompile some tools in order to break the law. If Linux ever becomes mainstream, we know most people will not change anything from the defaults, and if Linux is ever to become mainstream, it must have the ability to show/play content. Sure, sites could provide ready made tools to make the mods easy, but that would clearly violate the intent and spirit of copy protections. There is little of no reason to do this if fair-use copying is allowed. Yes, the system can't always tell if a copy falls under fair use or not, so the user is still being trusted to follow the rules, but most people want to be fair, so all that is necessary is to clearly state what is permitted before they click the "ok, start the copy" button. What I am proposing is to respect any DRM flags and data, and keep them in the copies. You would have to hack source to create a tool that removed this information, and gnutella should respect this as well. If you are running a public server, you shouldn't have unrestricted downloads of protected content. It is only "easy" in the hacker sense to circumvent these controls.