The trick here looks to be finding out which things can be done parallel without causing an exception.
IMHO it's rather about making the common case (i.e. no exceptions via memory fault, etc) go fast, and have a hardware glue to find the non-fast quickly. Basically, the idea of cacheing followed to the end of it.:)
And another guess.. Maybe these "exceptions" can mean that other "instruction streams" has modified/could use the exact same in-memory data another instruction sequence is doing... On another CPU?
I can smell it... Can they build a system into which you can simply add a few more transmeta cpu's, and seamlessly increase the performance of existing code? Maybe even in a network? You buy another few transmeta box, and your suddenly can encode MPEG2 in real time? Maybe this partly depends on the compiler's smartness to let the processor avoid conflicting stores a bit longer, but they control that too:)
(It would also explain why Linus is so sure we will have more appliances, simply because it will make the meta-box (meta-transputer?) go faster...)
So you want two Net-TV devices instead of a heap of networked appliances? Maybe your paradigm is still locked onto the Intel/Microsoft "we will build what you need; next time for sure" mentality.. Only (near) monopolies, and in very mass production can afford to build general purpose devices, appropriate for many use.. It seems to me, PC's really good for Linux are still cheaper than a TV I really would love:)
Maybe the "multimedia convergence" finally really turns into divergence later on, and we will have specific devices much better suited to the task as a PC with a limited output (monitor, stereo speakers), and even more limited input (mouse, 10x key keyboard). Maybe the geeks of the future still will have a central remote control, which could well be more powerful than a current server, but still have his house populated by many more devices. After all, you can't have a single device for two people, it simply isn't fun to watch a PDA style device with another people in the same room. Why not have videowalls, remote controls, status displays, toys all around in the place?
IMHO it will be much easier to replace a faulty videowall, or control handset of all the wirelessly interconnected future room than to call a technician to fix the net-tv-holophone-security system, and find out that you can't open the fron door without the central unit:)
Remember, you can't predict paradigm shifts when you abhor change. But change will come:).
(transmeta revelation mode on) Did anyone notice how they talk about embedded stuff, customization, and many devices per home (appliances in buzzspeak, which he avoided of course:) He also criticized the Nokia 9000 as not a convenient PDA and not a convenient cell-phone either.. That might help us close on what the heck transmeta is working on:)
Now, the only thing to hope that the three years he is talking about is not the announcement of their product (remember, on Comdex we will know, what it is or we will know when we will know:), but the final takeover worldwide, where there's not anything traditional left, but customized Linux devices running transmeta parts:) (transmeta reveleation mode off)
Oh, but then why did he (attempted to) cancel that article?:) BTW, another "sign" for something may be that another Transmeta employee just contributed support for the picojava architecture to the Cygnus binutils stuff (assembler, linker, you know).
The "can emulate a few processors and more" theory stands on strong base, IMHO:)
Well, I think the only "reasonable" (ehrm) incentive to "fake" results is having a large keys/sec value, and if you have multiple id's, you won't have that:)
I think by carefully looking at log results they would be able to get most of the bad guys anyway. IP address, submitter id, submitter team; some of them must repeat frequently if you use a fake client...
But having just sending a few bits of result (i.e. 32 bits for each keyblocks, each meaning the xor of the last bits of the particular cleartexts from the 1/32 of the keyblock) is basically what you and I am saying too, I like "my" way because by storing less bits you can store more proofs to check later if someone looks suspicious, whereas for a random check it's more wise to send more bits (the more to chose from, the more sure you can be faster by checking it).
Now would you honestly prefer that D.net progress be *halved* as a result of them turning to the Good Side of the Force? C'mon..
Who said halved??? I just devised a method which provides a way to prove that a given block is incorrectly submitted as done. Inexpensive even in the storage point of view (just a few more bits for each block to store, where the submitter ID is already stored); and there's no need to check all of the results, just the suspicious ones. Done correctly, just slows the progress down possibly even microscopically. The "cryptographic" method to compute these bits is actually very fast too, MD5 doesn't take too long for a few bits per N blocks at the clients. And might be even unneeded as the final bits of computations are probably hard to get anyway...
Oh, and let me ignore your opensource bashing.. Why do you think people can't abuse the closed source version too? This simply seems to be a way where you can be safer than that, even with open source clients...
By opening the source, people like those Russian guys can fiddle with it and
Not necessarily. It should work this way: when the client checks all the keys in a block, it saves the results of the intermediate calculations, and hashes all of them via a semi-secure hash function (md5, sha1). You just have to be careful that these intermediate values are hard or impossible to get without the real computations; for example let them be the last bit of the supposedly decrypted text (which then looks invalid).
Then, occasionally, you check some of these values by hand (or, the horror, by sending the same task to another individual:) and if there's a mismatch, you know one of them is lying about his performance.
You need to check only a small percent (i.e. probably less than 0.1%) of these values anyway, since anyone trying to fake his keyblocks will want to do crank out much more false keyblocks like those pranks before.
The only question is where to store these additional values, as it might take a significant amount of storage to administrate the keyspace anyway, but I think it even sufficient to store a few bits (at most 32) of this hash to be able to catch the bad guys.
Now I can only hope the distributed.net guys read this:)
Worrisome, yes, but mainly because Baratz' attack is so FUD'dy. It seems now that they partly own the "tree", "they" want to lock out the small guys from profiting from the code. And I'm not speaking about financial profits! Sun's idea of a community is nothing else as slaves working quietly for them; just as with Java, they want to control everything related to it. And now with Mozilla? Please, get your hands off that, manager-head. It's a sad thing how few people could change licensing of a magnificent project, I hope it turns out impossible if even someone else takes it seriously.
These cries about Mozilla's failing are really only disgusting; the development model works. As others said too, their progress is perceived slowly, but only because it's not an evolutionary progress from the last Netscape code base, but instead the "redo everything correctly" way; opening up to the public might not be fully successful, but I think it improved the developer's communication enormously. Just think of the development tools they had published, tinderbox, bonsai, bugzilla are still mightily useful and they really help the developers work.
Now contrast this with the "Community" licensing, and development model for Jini/Java. Do they help communication? No, they just help making sure you know their rules. It's still basically a large cathedral, surrounded by small shops connected to the cathedral, and rarely communicating with eachother. Sounds perfect for the control freak, but it's the kind of development that's being shown to not scale with other commercial software. If you are not free to restructure the communication, and you can't take the code for your purposes (i.e. fairly, abiding to share it), it won't scale.
And yes, Mozilla is really needed as a real, hardcore, full-featured, top-notch browser, fully opened up to cope with the future. Thinking about a future where core technologies are controlled, and licensed (financially) from central organizations controlling the given stuff makes me vomit. And that's just because Baratz and a few thinks it will pay them better? The conspiracy theorist in me says when "they" get this done, a few months later they become managers/presidents at another Big Company to further work on their own wealth. There's nothing more bitter than news like that, rumours about closing a good, important, open project. Make it not happen, please.
Well, it just popped into my mind, when there will be finally so real large displays, we could probably have a powerful controller each cubic foot (probably boasting more pixels out than current 3D "accelerators"). At least, that sounds the most logical for me:) An easy way to get around refresh rates for 3d (or whatever popular control metaphor there will be at that time), and then connecting small number of powerful devices will be even more advanced than today's SMP technology.
Running today's games would be a piece of cake on that kind of display, of course, just as a side effect:)
Yep, funny; it looks like Linus plans to have more time around the fall, that may mean the hard, secret work is over by then:) Also, while he says nothing "big" about the release, he's sure of it; that could also mean support for the Transmeta chip, whatever it does, will be big news, but he doesn't want to say just now.
OTOH, I don't think telephony is a "big thing", it should be a fading business; the Neon (?) chip will IMHO be just a cheap one, which is way more efficient for special tasks (DSP, 3d accelator) than the current general CPU's. Hopefully able to run everything efficiently, but many doubt that:)
However, if you want UUCP, BITNET relaying, or FIDO-NET support (which is CRITICAL in many third world countries) sendmail is your only option.
Bzzt. Wrong conclusion, although it's a common misconception. I've done UUCP via ssh, and even fidonet mail routing with qmail when I had an 2400 baud modem link. BITNET? Well, no, but that's just because it was disappeared for years when I began working with computers. But I don't think it would be that hard to use it. There's nothing spectacular about it, it's all straightforward. Actually, that's how I see qmail vs. sendmail; with you don't need to know what you do, just ask for help, or buy the book, and look up the answer, with qmail, you spend a few hours looking through the documentation, and you understand it all.
And in a surprise twist, when you understand it, you also can do anything with it, if you are good with general programming/scripting otherwise; no need to grab that bat book again..
Yes, free software can be forked; but that's *good*. It won't be forked like crapola just for the forking; only for *very* good reasons, maybe for different *targets*, and it either won't matter for the users, or it will be unified again. A few examples: the Linux ports (m68k/alpha/mips/etc), and the egcs/gcc split. Yes, both is a real fork, but the pressure is there to unify the forces. When there isn't a big bad entity out there preventing the forks, the fork will happen, but there will be also a deeper pressure to fix the situation, and the end result will be better. This pressure is really more urging than the official enforcement to comply to standards.
Sure, anyone could "fix" the byte codes all they want, but that would be a worthless effort; I wouldn't use an incompatible JVM either. But the development must be kept open, central control is not a good solution. What do you have now? We can't fork the code, but anyone can license, and build all their enhancements, and market it. Tons of different JVM's, different optimizations, all (most) in binary modules. There are different "brands" of java, different levels of implementations, different native libraries, etc. If Java were open source, you still wouldn't download JoeBlowJava v3.81, but the real enhancements would be better, and integrated faster into the common code, while causing less work for Sun to do the dirty work to support N+1 architectures/features. In the end, much *less* fragmentation than now.
The source is really my pet peeve (although not really relevant to Java now, but there was the difficulty to cooperate with other developers, and proprietary license agreements "poison" even more than the GPL, IMHO) without source, you are effectively locked into the vendors' imagination of the market; you can't port it to the newest toy you built, and over time, the PIII-500 will also be an overheated, noisy, slow, and overall undesirable platform...
You missed the "but Java is not open source!" crowd; among them me:) Stereotypical, I know, but it's really irking some of us. Of course Sun just want to retain full control of Java, but IMHO, strict control is no good for the public/developers/users. The main advantage of Linux is that there is no real control kicking it into the "right" directions; by giving up a bit control on Java, they could get the impulse of the whole river, instead of a few feet.
Java, for many people is still looking like being forced down their throat, and this handheld Java invasion (while obviously better than the WinCE army) is still a Microsofty solution: "get the people see it everywhere, buy the developers, make contracts, whatever, and then we can reap". The good solution from the open-source advocate's viewpoint would be: "spread it, and let them pick the good parts, improve it, and it will be ubiquitious, and really cool technology". Obviously, Sun's exploit-the-community license (Alan's words, AFAIR) is going too slow for their Marketing dept. They just don't seem to want to give (wrt. Java, I know about NFS, RPC), that will always cut some shades on them; it just doesn't help that you are welcome to work on their stuff... well...
It's all ok, but I see two mistakes: first, you might have more "chips" (whose transistor count doubled) for a given node; that might give a few years to bump into limits.
Second, I don't think system "processing" speed (highly variable anyway, depending on the task), system memory/link bandwidth, and transistor count of a single chip are all so really closely coupled. And of course, to be repetitive, you don't know the future:) BTW, This article is a nice friendly place, I guess that NPR think turns off most of the "interested" people:)
Yea, funny. "Microsoft and its server hardware partners are taking a different tack." -- They let the marketing dept. do the hard work. News indeed. Two PC's with "COM+ failover" is indeed much more reliable than a hardware cluster designed for high availability.
And of course the "wills" sprinkled around, prefixed with Windows 2000.. Oh, man, this is just boooooring.
SCSI? ATA? 100 Mbps Ethernet? $30 dialups? Slashdot effect? Remember, we are talking about the future, not the present. 100 years ago anyone would regard as outright silliness to sell the horses which basically live on the fields, by the river for something that costs a few bucks at each refill to go a few miles...
The future of the computing is just began forming; MS and all the big dinosaurs want to take part of it, but this time, with global cooperation, there's a chance to get everything right. Really everything, don't think the current drawbacks are bothering only you.
I'm, for example pretty surprised by how much joshv thinks the same way as me; and chances are I'm about 8-10 hours away in a different time zone, and 8-10 thousand miles away. With helpers finding each other in this distance, turning the whole world around to the better is a snap. I mean it.
2) Accessibility: I want to be able to get at my data even when the network (say, to my ISP) goes down.
(This was the first one I want to comment on). Sure; but you are locked into thinking in the present. The majority of the people, even computing people depend really hard on the power grid functioning (although someone said in the US, this situation is worse than in Europe, where I am). The network could really get so reliable (erhm.. available), that you won't think about its downtime; of course, there will be people who will have backup "connections" (not necessarily physical lines) to different providers, and have local storage farms, just as some people have UPS, and/or generators.
Privacy: it's just the protocols, if the ISP can store thousand times more data than my disks for the subscription that I'll need also; there will also be protocols to do this storage the way that really only you can access your data (not even the ISP).
Autonomy: in this case, however, I also think you are right; everyone needs to notice that the only *good*, reliable parts of the internet are the ones that are *not* centralized. Slashdot is great, but freshmeat's mirroring system is much more reliable:) And ultimately, the domain registration should also change to a seemingly anarchic one (compared to the current one), and you know what? It will be better for *us*.
Yep, frankly; it's pretty in the style of MS; preannouncing that something will happen sometimes:) It's also basically "oh, how we missed getting big money by not researching how TV changed our lives. Now we will watch, and will tell you when we see it changed..."
After all, when a report is out, every one of us will know all about it, only the people not "on the net" will wonder what this net thing is, just like now:) And, in a weird way, I guess they already missed this change. A generation is too long, if no market participant, including Bill Gates could guess there will be an internet, no "research" will reveal anything. It will be a real tough change.
Has anyone ever wondered what's at the edge of the universe?
It's weird:) In a way, it's obvious, the edge is where the universe still can influence anything (e.g. us). What's even more out, you can't sense via any device, it could be anything, but in no way could you determine. Until it's "inside" of the universe, then we can already know what it is.
The question is like what's after "now"? Noone can know for sure, although we can guess it quite correctly, at least for short ranges. How will your watch look 2 seconds from now?
34 to 32 people decide what must be done for millions of net users? From just one narrow point of view? If just one people votes otherwise... But the shortsights are still shining through. Blocking web sites? What for? Can't anyone simply provide the same information via FTP servers? FSP servers? Future file transfer protocol servers? Distributed file sharing servers when no specific machine (and thus IP address) holds any significant amount from the "unwanted" data?
I'll be checking how the people of Oz could be helped with this issue, but I hope something will be done.
I for one am getting quite fed up with the current MS-y trend of announcements that "we will have it soon". Here's my advice: when it is source, even open-source, just wait quietly until it IS available. If we could wait for it, you also could wait with the announcement.
It sounds like a good marketing stunt to get press attention two times, once for announcement, and once for release, but refuse the temptation, it's having the possibility that the announced product will be much inferior than waited for. It's also getting the style "people, get off my way, I'm coming", and stopping perfectly acceptable, and well working other projects with a similar goal.
I knew this was comming, but I though they were going to delay it for one or two months.
Well, they are:
While SGI's announcement will come tomorrow, the software itself won't be available for download until the summer. SGI still is deciding how to structure the open source license...
At least there will be a "hacker" reason to wait for the summer:) If they won't hurry however, we will be getting the next ext2fs with journaling and B-tree code (faster directory/file data access) by then from Ted T'tso and Stephen Tweedie, and XFS will be useful only for IRIX compatibility:)
Licensing is still an issue, GPL would be nice IMHO for them, because of the protection they would be getting to not commercialize it without them getting the improvements back, and also perfect for kernel code. If it's not GPL, it can't be used by directly linking into the kernel (minor issue, but still inconvenient.) Let's hope for the best.
It's also not the "full" XFS, according to the report, it's got only the features the kernel hackers are planning to build into ext2.. really weird.
A few more point to the crypto-crippled exportable "secure" browser topic: the export versions are the most easily available for most of the world, I guess even mostly in the U.S too because of the awkward registrations to get it. You can however make Netscape at least talk stronger crypto with the help of Fortify.
Second: all these inconveniences to get a secure browser to hide your communications are mostly useless considering the fact that only sites of very commercial nature let you use https (secure http via SSL/TLS). Of course, the point is not that "they" can see what we are talking about something on slashdot. They can see what we are talking about anything on anywhere.
U.S. is still pretty much driving the internet communications, protocols, applications and implementations, and when at every point we are limited to non-encrypted traffic, the bad guys still can get the whole picture (see, the bad guys even have the habit of defining the bad guys..). It's important do anything to get the U.S. lift those crypto controls, the regulations are not there for you! We would be in a much safer world where encryption would be ubiquitious, including even protocols like DNS, SMTP, POP3, HTTP. Maybe they would be a bit slower, but there would finally be another reason to get faster CPU's other than to run Bloatware version N+1 from MS.:)
Making "my" DIY Linux box speak IPv6 is easy; converting some real applications to let it use it fully is workable too, but there are so many places out there that I'm simply scared:) Lot of cable modems, lot of printers, lot of routers, leaf hosts with Win 3.1, MacOS, Amiga, and the uncountable rest with hard to upgrade software/firmware. Agreed, it's only the core what's really need to be upgraded, for example, LAN printers, and most end hosts will do fine with IPv4. I also know the measures taken to have IPv4-IPv6 networks to talk together; but it sometimes sounds hopelessly tedious to me.
Although, the biggest mental obstacle was that getting IPv6 networks was quite of limited to experimental educational usage, I'm glad it's just a few days and it's more available.
The proxy system: sounds much funkier than I imagine, but I just didn't have the time to even mentally design it correctly; I still think it could be easy, but let's drop it:)
Slashdot Mirror
IMHO it's rather about making the common case (i.e. no exceptions via memory fault, etc) go fast, and have a hardware glue to find the non-fast quickly. Basically, the idea of cacheing followed to the end of it. :)
And another guess.. Maybe these "exceptions" can mean that other "instruction streams" has modified/could use the exact same in-memory data another instruction sequence is doing... On another CPU?
I can smell it... Can they build a system into which you can simply add a few more transmeta cpu's, and seamlessly increase the performance of existing code? Maybe even in a network? You buy another few transmeta box, and your suddenly can encode MPEG2 in real time? Maybe this partly depends on the compiler's smartness to let the processor avoid conflicting stores a bit longer, but they control that too :)
(It would also explain why Linus is so sure we will have more appliances, simply because it will make the meta-box (meta-transputer?) go faster...)
So you want two Net-TV devices instead of a heap of networked appliances? Maybe your paradigm is still locked onto the Intel/Microsoft "we will build what you need; next time for sure" mentality.. Only (near) monopolies, and in very mass production can afford to build general purpose devices, appropriate for many use.. It seems to me, PC's really good for Linux are still cheaper than a TV I really would love :)
Maybe the "multimedia convergence" finally really turns into divergence later on, and we will have specific devices much better suited to the task as a PC with a limited output (monitor, stereo speakers), and even more limited input (mouse, 10x key keyboard). Maybe the geeks of the future still will have a central remote control, which could well be more powerful than a current server, but still have his house populated by many more devices. After all, you can't have a single device for two people, it simply isn't fun to watch a PDA style device with another people in the same room. Why not have videowalls, remote controls, status displays, toys all around in the place?
IMHO it will be much easier to replace a faulty videowall, or control handset of all the wirelessly interconnected future room than to call a technician to fix the net-tv-holophone-security system, and find out that you can't open the fron door without the central unit :)
Remember, you can't predict paradigm shifts when you abhor change. But change will come :).
Did anyone notice how they talk about embedded stuff, customization, and many devices per home (appliances in buzzspeak, which he avoided of course
Now, the only thing to hope that the three years he is talking about is not the announcement of their product (remember, on Comdex we will know, what it is or we will know when we will know :), but the final takeover worldwide, where there's not anything traditional left, but customized Linux devices running transmeta parts :)
(transmeta reveleation mode off)
Oh, but then why did he (attempted to) cancel that article? :) BTW, another "sign" for something may be that another Transmeta employee just contributed support for the picojava architecture to the Cygnus binutils stuff (assembler, linker, you know).
The "can emulate a few processors and more" theory stands on strong base, IMHO :)
BTW, I think few people saw this: http://www.deja.com/getdoc.xp?AN=4614616 79
Well, I think the only "reasonable" (ehrm) incentive to "fake" results is having a large keys/sec value, and if you have multiple id's, you won't have that :)
I think by carefully looking at log results they would be able to get most of the bad guys anyway. IP address, submitter id, submitter team; some of them must repeat frequently if you use a fake client...
But having just sending a few bits of result (i.e. 32 bits for each keyblocks, each meaning the xor of the last bits of the particular cleartexts from the 1/32 of the keyblock) is basically what you and I am saying too, I like "my" way because by storing less bits you can store more proofs to check later if someone looks suspicious, whereas for a random check it's more wise to send more bits (the more to chose from, the more sure you can be faster by checking it).
Who said halved??? I just devised a method which provides a way to prove that a given block is incorrectly submitted as done. Inexpensive even in the storage point of view (just a few more bits for each block to store, where the submitter ID is already stored); and there's no need to check all of the results, just the suspicious ones. Done correctly, just slows the progress down possibly even microscopically. The "cryptographic" method to compute these bits is actually very fast too, MD5 doesn't take too long for a few bits per N blocks at the clients. And might be even unneeded as the final bits of computations are probably hard to get anyway...
Oh, and let me ignore your opensource bashing.. Why do you think people can't abuse the closed source version too? This simply seems to be a way where you can be safer than that, even with open source clients...
Not necessarily. It should work this way: when the client checks all the keys in a block, it saves the results of the intermediate calculations, and hashes all of them via a semi-secure hash function (md5, sha1). You just have to be careful that these intermediate values are hard or impossible to get without the real computations; for example let them be the last bit of the supposedly decrypted text (which then looks invalid).
Then, occasionally, you check some of these values by hand (or, the horror, by sending the same task to another individual :) and if there's a mismatch, you know one of them is lying about his performance.
You need to check only a small percent (i.e. probably less than 0.1%) of these values anyway, since anyone trying to fake his keyblocks will want to do crank out much more false keyblocks like those pranks before.
The only question is where to store these additional values, as it might take a significant amount of storage to administrate the keyspace anyway, but I think it even sufficient to store a few bits (at most 32) of this hash to be able to catch the bad guys.
Now I can only hope the distributed.net guys read this :)
These cries about Mozilla's failing are really only disgusting; the development model works. As others said too, their progress is perceived slowly, but only because it's not an evolutionary progress from the last Netscape code base, but instead the "redo everything correctly" way; opening up to the public might not be fully successful, but I think it improved the developer's communication enormously. Just think of the development tools they had published, tinderbox, bonsai, bugzilla are still mightily useful and they really help the developers work.
Now contrast this with the "Community" licensing, and development model for Jini/Java. Do they help communication? No, they just help making sure you know their rules. It's still basically a large cathedral, surrounded by small shops connected to the cathedral, and rarely communicating with eachother. Sounds perfect for the control freak, but it's the kind of development that's being shown to not scale with other commercial software. If you are not free to restructure the communication, and you can't take the code for your purposes (i.e. fairly, abiding to share it), it won't scale.
And yes, Mozilla is really needed as a real, hardcore, full-featured, top-notch browser, fully opened up to cope with the future. Thinking about a future where core technologies are controlled, and licensed (financially) from central organizations controlling the given stuff makes me vomit. And that's just because Baratz and a few thinks it will pay them better? The conspiracy theorist in me says when "they" get this done, a few months later they become managers/presidents at another Big Company to further work on their own wealth. There's nothing more bitter than news like that, rumours about closing a good, important, open project. Make it not happen, please.
Running today's games would be a piece of cake on that kind of display, of course, just as a side effect :)
OTOH, I don't think telephony is a "big thing", it should be a fading business; the Neon (?) chip will IMHO be just a cheap one, which is way more efficient for special tasks (DSP, 3d accelator) than the current general CPU's. Hopefully able to run everything efficiently, but many doubt that :)
Another lesser know transmeta leak is here.
Bzzt. Wrong conclusion, although it's a common misconception. I've done UUCP via ssh, and even fidonet mail routing with qmail when I had an 2400 baud modem link. BITNET? Well, no, but that's just because it was disappeared for years when I began working with computers. But I don't think it would be that hard to use it. There's nothing spectacular about it, it's all straightforward. Actually, that's how I see qmail vs. sendmail; with you don't need to know what you do, just ask for help, or buy the book, and look up the answer, with qmail, you spend a few hours looking through the documentation, and you understand it all.
And in a surprise twist, when you understand it, you also can do anything with it, if you are good with general programming/scripting otherwise; no need to grab that bat book again..
Sure, anyone could "fix" the byte codes all they want, but that would be a worthless effort; I wouldn't use an incompatible JVM either. But the development must be kept open, central control is not a good solution. What do you have now? We can't fork the code, but anyone can license, and build all their enhancements, and market it. Tons of different JVM's, different optimizations, all (most) in binary modules. There are different "brands" of java, different levels of implementations, different native libraries, etc. If Java were open source, you still wouldn't download JoeBlowJava v3.81, but the real enhancements would be better, and integrated faster into the common code, while causing less work for Sun to do the dirty work to support N+1 architectures/features. In the end, much *less* fragmentation than now.
The source is really my pet peeve (although not really relevant to Java now, but there was the difficulty to cooperate with other developers, and proprietary license agreements "poison" even more than the GPL, IMHO) without source, you are effectively locked into the vendors' imagination of the market; you can't port it to the newest toy you built, and over time, the PIII-500 will also be an overheated, noisy, slow, and overall undesirable platform...
Java, for many people is still looking like being forced down their throat, and this handheld Java invasion (while obviously better than the WinCE army) is still a Microsofty solution: "get the people see it everywhere, buy the developers, make contracts, whatever, and then we can reap". The good solution from the open-source advocate's viewpoint would be: "spread it, and let them pick the good parts, improve it, and it will be ubiquitious, and really cool technology". Obviously, Sun's exploit-the-community license (Alan's words, AFAIR) is going too slow for their Marketing dept. They just don't seem to want to give (wrt. Java, I know about NFS, RPC), that will always cut some shades on them; it just doesn't help that you are welcome to work on their stuff... well...
Second, I don't think system "processing" speed (highly variable anyway, depending on the task), system memory/link bandwidth, and transistor count of a single chip are all so really closely coupled. And of course, to be repetitive, you don't know the future :) BTW, This article is a nice friendly place, I guess that NPR think turns off most of the "interested" people :)
And of course the "wills" sprinkled around, prefixed with Windows 2000.. Oh, man, this is just boooooring.
The future of the computing is just began forming; MS and all the big dinosaurs want to take part of it, but this time, with global cooperation, there's a chance to get everything right. Really everything, don't think the current drawbacks are bothering only you.
I'm, for example pretty surprised by how much joshv thinks the same way as me; and chances are I'm about 8-10 hours away in a different time zone, and 8-10 thousand miles away. With helpers finding each other in this distance, turning the whole world around to the better is a snap. I mean it.
(Well, assuming my English makes sense :)
(This was the first one I want to comment on). Sure; but you are locked into thinking in the present. The majority of the people, even computing people depend really hard on the power grid functioning (although someone said in the US, this situation is worse than in Europe, where I am). The network could really get so reliable (erhm.. available), that you won't think about its downtime; of course, there will be people who will have backup "connections" (not necessarily physical lines) to different providers, and have local storage farms, just as some people have UPS, and/or generators.
Privacy: it's just the protocols, if the ISP can store thousand times more data than my disks for the subscription that I'll need also; there will also be protocols to do this storage the way that really only you can access your data (not even the ISP).
Autonomy: in this case, however, I also think you are right; everyone needs to notice that the only *good*, reliable parts of the internet are the ones that are *not* centralized. Slashdot is great, but freshmeat's mirroring system is much more reliable :) And ultimately, the domain registration should also change to a seemingly anarchic one (compared to the current one), and you know what? It will be better for *us*.
After all, when a report is out, every one of us will know all about it, only the people not "on the net" will wonder what this net thing is, just like now :) And, in a weird way, I guess they already missed this change. A generation is too long, if no market participant, including Bill Gates could guess there will be an internet, no "research" will reveal anything. It will be a real tough change.
It's weird :) In a way, it's obvious, the edge is where the universe still can influence anything (e.g. us). What's even more out, you can't sense via any device, it could be anything, but in no way could you determine. Until it's "inside" of the universe, then we can already know what it is.
The question is like what's after "now"? Noone can know for sure, although we can guess it quite correctly, at least for short ranges. How will your watch look 2 seconds from now?
I'll be checking how the people of Oz could be helped with this issue, but I hope something will be done.
It sounds like a good marketing stunt to get press attention two times, once for announcement, and once for release, but refuse the temptation, it's having the possibility that the announced product will be much inferior than waited for. It's also getting the style "people, get off my way, I'm coming", and stopping perfectly acceptable, and well working other projects with a similar goal.
Well, they are:
At least there will be a "hacker" reason to wait for the summer :) If they won't hurry however, we will be getting the next ext2fs with journaling and B-tree code (faster directory/file data access) by then from Ted T'tso and Stephen Tweedie, and XFS will be useful only for IRIX compatibility :)
Licensing is still an issue, GPL would be nice IMHO for them, because of the protection they would be getting to not commercialize it without them getting the improvements back, and also perfect for kernel code. If it's not GPL, it can't be used by directly linking into the kernel (minor issue, but still inconvenient.) Let's hope for the best.
It's also not the "full" XFS, according to the report, it's got only the features the kernel hackers are planning to build into ext2.. really weird.
Second: all these inconveniences to get a secure browser to hide your communications are mostly useless considering the fact that only sites of very commercial nature let you use https (secure http via SSL/TLS). Of course, the point is not that "they" can see what we are talking about something on slashdot. They can see what we are talking about anything on anywhere.
U.S. is still pretty much driving the internet communications, protocols, applications and implementations, and when at every point we are limited to non-encrypted traffic, the bad guys still can get the whole picture (see, the bad guys even have the habit of defining the bad guys..). It's important do anything to get the U.S. lift those crypto controls, the regulations are not there for you! We would be in a much safer world where encryption would be ubiquitious, including even protocols like DNS, SMTP, POP3, HTTP. Maybe they would be a bit slower, but there would finally be another reason to get faster CPU's other than to run Bloatware version N+1 from MS. :)
Making "my" DIY Linux box speak IPv6 is easy; converting some real applications to let it use it fully is workable too, but there are so many places out there that I'm simply scared :) Lot of cable modems, lot of printers, lot of routers, leaf hosts with Win 3.1, MacOS, Amiga, and the uncountable rest with hard to upgrade software/firmware. Agreed, it's only the core what's really need to be upgraded, for example, LAN printers, and most end hosts will do fine with IPv4. I also know the measures taken to have IPv4-IPv6 networks to talk together; but it sometimes sounds hopelessly tedious to me.
Although, the biggest mental obstacle was that getting IPv6 networks was quite of limited to experimental educational usage, I'm glad it's just a few days and it's more available.
The proxy system: sounds much funkier than I imagine, but I just didn't have the time to even mentally design it correctly; I still think it could be easy, but let's drop it :)