Person-centered devices provide universal personal appliances that are inexpensive and can be carried and used anywhere. They are equipped with
perceptual transducers such as a microphone, speaker, video camera, and display. In response to speech commands, they can reconfigure themselves through software into many useful appliances such as a two-way radios, cell phones, geographical positioning systems, and personal digital assistants, thereby replacing the many dedicated devices we usually carry with us, reducing overall weight, and conserving power.
One important difference is that the design of this devise uses a standard small display instead of the proposed eyepiece. IIRC, the original design for MIT's handheld did yous an viewport-type display, but they must have ditched that idea for some reason. However, we can expect thgat small displays will reach much higher resolutions (wile remaining low power) in the near future, so this may be ok.
Also, the Oxygen project proposes that "environmental" cumputers complement these handhelds by providing wall displays for public use (think the Start Trek Enterprise hallways) and allowing handhelds to offload computing power to the larger, in-wall computers.
I got up and went over to the local YMCA to vote. Then I realized that (1) that's not where I'm supposed to vote, even though it's the closest poll and (2) I forgot to change my registration when I moved last year, so I can't vote anyways. Sigh. And I was psyched to vote this year, too.
I just hope someone implements secure internet registration and voting by 2004.
I think there's also another problem with your example: "int" is a primitive type (not an object), so it is always passed by value. These examples should explain the differences between the three languages C, C++, and Java:
C always passes by value; you get pass-by-reference by passing a pointer to the desired object:
void halve(int va) {
va = va/2;
/* pass by value; call this using halve(a).
'a' does not change outside the function */
}
void halve(int *pa) {
*pa = (*pa)/2;
/* pass by reference; call this using halve(&a).
'a' is halved outside this function */
}
C++ is like C, but also adds language support for pass-by-reference:
void halve(int &ra) {
ra = ra/2;
/* pass by reference; call this using halve(a).
'a' is halved outside this fuction */
}
Java is always pass-by-value: primitive types like 'int' are treated just like the C case. However, you cannot pass a pointer to an 'int' like in C. Instead, you have to use an object reference. The reference to an object argument is copied pass-by-value, so the object is effectively passed-by-reference:
class IntHolder {
public int a;
}
void halve(IntHolder h) {
h.a = h.a/2;
/* 'h' is the reference to the object passed
to this method. We can follow this
reference and change the original object */
h = null;
/* note that the reference itself is passed
by value, so this assignment does NOT
affect the object outside this method. */
}
I agree that 3DES is slow, and I'm by no means saying that I support it. But from what I see (and please correct me if I'm wrong), most e-commerce and online banking systems use 3DES or the RC4 stream cipher for session encryption. Both ciphers have been around for a while and have excellent library support.
So long as the millions of e-commerce and online banking customers are satisfied with the performance, industry has no reason to take a risk on better protocols. In fact, some users like the fact that encrypted connections are slower -- it makes them feel that they're more secure!
As you mentioned, there are applications that need fast crypto, and these may push the industry towards better protocols. But my guess is that unless someone shows that 3DES can be broken quickly and easily AND then steals a bunch of credit card numbers, the average consumer isn't going to care.
Public outcry is the strongest motivater out there; industry demand comes second; academic arguments fall dead last.
Most applications are still using triple-DES (3DES) because it's been around so long and analyzed thouroghly. This doesn't mean it's the most secure or has the best performance, but lots of developers just want a "proven" technology.
Twofish looks like it's done pretty well against the competing ciphers, but my guess is a new cipher will only catch on if it's widely deployed. For example, if Netscape and IE both support Twofish for secure websites and Web Devlopers start using it, then it'll boom. But people need motivation -- right now consumers aren't complaining about the security or performance of 3DES, so it's sticking around...
Most modern GUIs focus on the object->action technique: select an object, then select an action to apply to that object. For example, select an icon on the desktop, then double-click to Open or right-click to see other options...
The problem with this is that it doesn't intuitively allow someone to start new documents or find old ones. To start a new letter, you first need to start the application for letter writing, which means you have to know where to look. To load an old letter, you wither have to go through the application, the "recent documents list", or the file system...
As you can see, the verbs here are "start", "continue". and "write". The user's action is TASK oriented, not object-oriented. An interface that allows you to do choose a TASK at the top level gives a better starting point to the user (I use uppercase to denote the specific idea I'm discussing here). Note that none of what I'm about to describe are new ideas, but they're worth considering...
A TASK menu might have choices like "write an e-mail" or "play a game"; though, of course, more specific. Some may think at this point, "Well, that's just like the "Start" menu in Windows!" Not quite: the TASKs must be listed with intuitive, easy to understand names. "Write a Letter" as opposed to "MS Word 2000" or "Emacs". In a sense, the TASK menu is more like the "New..." submenu you'll find when you right-click on the Windows desktop, except TASKs are not always for document-creation.
A TASK menu wouls also support continuing saved work: "Work on an existing letter", "Continue a StarCraft campaign", etc. One must be careful to balance what is available at the top-level and what choices become available under specific applications. "Print letter" may be useful at the top-level, but it would be better if this option were only available whle one was working on the letter.
A few more notes: 1) The file system should be invisible. As someone proposed in another comment, the OS should support finding saved work using searches or heuristics (ie. recent document lists, etc). A hierarchical directory scheme should still be available for users who like to organize their data that way, but it need not necessarily reflect the underlying data structures.
2) Applications should be invisible. Applications implement some set of TASKS for the user; we might expect that in the near future all apps will be downloaded, so users can simply search the net for a new TASK they may want to do. For example, I may not have "Create flow chart" implemented by any app on my local machine, but I could search for that task and find a number of apps (Visio, etc) that can implement it. I choose one, it downloads and installs itself, and I'm up and running. Maybe even better, the actual app is stored remotely -- my system just stores my files and configuration information.
3) There's no idea of "saving" a document: all work is logged (as with a versioning system); users can return to any snapshot of their work through history. By default, the most recent version is loaded, but a "Continue from old version" option might be available as well. Check out the Elephant File System to get a better idea of how this might work.
Well, I've gone on quite a bit about what I hope is a different way of looking at things than what you're used to. I'm sure there are plenty of issues that would make this sort of system a pain for current computer users, but remember we're thinking about future users. Also note that voice recognition won't solve anything without a redesign of the standard UI: I'd hate to have to spell out filenames and name specific applications when all I want to do is "Start a new letter..."
I'm sure this has been discussed on Slashdot before, but a general question related to this and many other articles:
If the only rule of property were "if it can be digitized, it's free of charge", would things still work? In such a world, software, books, music, art -- and all other forms of information -- would be available for free over the network.
Software writers could still charge to provide support, publishers could charge to provide bound books, other companies could charge to burn music onto CDs, artists could charge to do live performances, ads, and merchandising.
A lot of time and research has been spent on trying to protect or track information on the web so that only people who have paid for it can use it. If the world were reshaped so that information were free, this would be a non-issue (one could still have private information, but your privacy is based on trusting the parties you share information with).
There would still be value in physical goods -- books, houses, CDs, etc. And, of course, advertising can be "bundled" with information to generate revenue.
People who attend performances can record and freely distribute the show -- you're paying for the experience of being there when it happens, after all. But what happens if someone records a TV channel and immediately rebroadcasts it with their own ads? Or no ads at all? TV stations then lose all motive to lisence particular shows (what if NBC could rebroadcast the Superbowl a split second after ABC airs it live?).
And what about artists who just want to create their music and get paid, but don't want to do merchandising or performances? And game writers don't want to sit by the support phones all day -- they want to be able to live off the fruits of their labor. None of us wants to see ads for Cocoa Puffs scrolling along the bottom of our Quake screen.
Is such a world too ideal? Or could it be made to work? And even if it were possible, would it be better, and why?
PeopleNet -- personal web pages: from geocities (DumbNet! or MahirNet) to the more advanced (any cobination of InfoNet/CultureNet/TechNet/X-Net/UnderNet).
SchoolNet -- schools and colleges -- kinda TechNet/InfoNet hybrids...
Apologies for lack of newlines -- this is the actual output. It's shorter because it takes advantage of using the ASCII numbers instead of quoting quotes, and the like. Yours is pretty cool too -- I hadn't seen one that just uses characters. Here's one more in Scheme/Lisp:
((lambda (x) (list x (list (quote quote) x))) (quote (lambda (x) (list x (list (quote quote) x)))))
Has anyone noticed that the "Y2K Experiences" posted here necessarily come from people who: 1) Have electricity 2) Have an OS that still works 3) Have a browser that still works, and 4) Have an ISP that still works
With this sort of sampling bias, we really shouldn't be expecting too many "horror" stories... Most will be "yeah, my stuff still works, which is why I can post this..."
Regarding wearable devices for the computer display, a few questions: 1) Is it possible to make a display that is see-through (though perhaps darkened)? This way, you could see the information but also adjust your focus to see in front of you. It looked like one of the models might have something like this on. 2) Instead of a large headset or a targeting-device looking visor, could a display be packed into a simple monacle (ie. one of those round thingys you hold in place with your eye). The "chain" could carry the necessary information to the display. Such a thing might actually be subtle enough to be practical. Yeah, right. 3) Obviously, wearable displays bring up a number of UI issues. A lot of people seem to be focussing on voice interface, but that only seems right for text entry (if you've tried some of the original voice interfaces for Windows from 5 years ago, you'll know what I mean: "Open File", "Next Window"...) -- some sort of handheld pointer device seems necessary too. Either that, or something that responds to hand movement (or possibly eye movement, etc). What would work? 4) Finally, it seems that people might need to rething the GUI in general for wearable displays. Simply tossing up the standard windowed layout may not be best for mobile computing. And screen real-estate is also at a premium. What might be a better design.
Even given all this, I'm still concerned about trying to focus on something that's less than 2 inches from my eye...
One thing to consider is that CGI scripts impose a large delay in processing just because they have to fork off a process. Whether you use C or Perl may not matter if the time to invoke the script is significantly longer than the actual processing time. Perl is easier to use and faster for development (as mentioned by others), so it's better than C for scripting. Also, Perl is interpreted (rather than compiled), so bug fizes and patches are far easier to deploy. btw, you ca improve performance by abandoning CGI scripts altogether and looking at processes that use web-server threads (check out Philip and Alex's Guide to Web Publishing for info).
Your book describes a slew of interesting applications for crypto protocols, including electronic money orders, digital time-stamping, and secure multi-party computation. What are the remaining crypto problems of interest to the general public which have not been solved? (secure distribution of digital media comes to mind -- can you sell someone a music file, allow them to use the file anywhere, but make sure no one else can use it?)
1) For those who mention that you may not want to use Java because of speed issues, keep in mind that there are Java compilers available which can give you much better performance than interpretted bytecodes. It's write-once-compile-anywhere instead of run-everywhere. I'm sure there are issues with compiling bytecodes, though, but it's just an idea.
2) Another note is that, depending on your application, you may not need something so general as an ORB for use between your processes. For example, if your distributed processes are retrieving and updating shared data, why not use a network-accessible database? There are plenty of database interfaces available for many languages, and this might simplify your system if you have large, simple data structures. It's of course a speed loss and an increase in complexity, but databases are much more mature than ORBs. Think about whether or not a database might be better for your application.
Of course, I haven't addressed the problem of using the same code on multiple platforms; but I think others are doing a good job of that. But I have to agree that more information on your specific application might be helpful. Good luck!
Yeah, but the obvious question is then "Who makes the categories" and "What categories are right / fair"? Yahoo attempts to categorize the web, and many sites appear in multiple categories. These categories aren't rated in any way that I know of. And then there's the issue of what features of a site/category to rate -- movies have sex/violence/profanity levels, but these are mostly for parental restriction of children. When it comes to issues of personal preference, having ratings based like "site enjoyed by slashdot readers and hated by Reactionary Republicans" would be more useful. A "Dewey Decimal System" for web sites (or news articles) won't really cut it, IMHO. However, categorization may be the only practical way to get the general populace to rate things.
Another issue is the large data / small readership problem brought up in a previous post. Unless organizations are willing to go and rate site upon site, how will there ever be enough rating information to be useful? Rating books and albums works on Amazon.com partially because there's a simple 5-star customer review system (even simpler than categorization) and partially because it's a restricted data domain. Also, if someone writes a review for one book they've read, they're likely to write reviews for others.
Maybe web sites should offer a "Rate Me" button linked to some third-party rating company. Inspired surfers can follow the link and rate the site on a few static categories or offer their own comments. This could also give us cross-information of the "surfers who liked this site also liked..." variety. I personally find that information very useful when looking for CDs. Oftentimes I find albums I would never have heard of, but the system also points me to bestsellers which are similar. Going to the bestseller then gives me more information on other good CDs. Could this work for web sites and news articles as well?
The main problem with this models is most sites won't offer a "Rate Me!" button. Alternatively, a rating company could set up a "meta-site" in which you can surf (using frames, for example) and have a "Rate This Site" button in the margins. Unfortunately, rating by URL is risky since the often change, but it's a first step.
Anyways, I guess my point is rating systems go beyond how they're designed; you also must consider how they're deployed (as other posters have mentioned). Solve that problem, stick an ad banner on it, and you've got the next great web fortune which will be bought out by Microsoft and eventually hacked by someone reading this.
Although I had programmed a few toy things in my undergrad classes, I didn't really learn how to hack till I went and worked at a software engineering firm for a few months. There's a difference bewteen my sophomore classes (one assignment was to explore inheritence in C++ by creating new character classes in a simple game) and implementing bugs/fixing features in a large system (my first assignment as an intern was to use yacc to create a language for remotely booting machines over a serial line -- I hadn't even learned C or worked with Unix yet. That changed quickly).
Still, I find I use some things I learned in school mixed with some real world experience -- not too surprising. Having a sense of how a program should be structured can affect how easy it is to maintain and how well it runs. But a student who has only learned C may not realize that a slower, interpreted language like Tcl or Perl may be better for web-server code. Coders who only learn Java may not even know how to manage memory correctly or what the machine-level representation of code is. As much as abstraction is a useful tool for programmers, top-to-bottom knowledge is important when designing anything more than a toy system. That means having the formal knowledge of how computer systems work and what designs/data structures are useful and having the practical knowledge of how to actually make your vision work.
P.S. I actually wrote "implementing bugs/fixing features" before I realized what I had just said. Freud? Who's Freud?
Now that Apple has introduces the G4 with nice, fast vector processing instructions, should we expect an even steeper decrease in the time it takes to crack these keys by the general public? Apple advertises 1 GFlop/s normally, but upto 4 GFlop/s in certain cases. Give that an earlier poster mentioned that these algorithms are massively parallizable, I wouldn't be surprised if a key-factorizing program could be written for the G4 which ran close to the 4 Gflop/s boundary. And given the 18-month-till-speeds-double trend, we have much to worry about.
Slashdot Mirror
MIT's Oxygen Project describes a handheld device that has a lot in common with the one described in this article:
One important difference is that the design of this devise uses a standard small display instead of the proposed eyepiece. IIRC, the original design for MIT's handheld did yous an viewport-type display, but they must have ditched that idea for some reason. However, we can expect thgat small displays will reach much higher resolutions (wile remaining low power) in the near future, so this may be ok.
Also, the Oxygen project proposes that "environmental" cumputers complement these handhelds by providing wall displays for public use (think the Start Trek Enterprise hallways) and allowing handhelds to offload computing power to the larger, in-wall computers.
I got up and went over to the local YMCA to vote. Then I realized that (1) that's not where I'm supposed to vote, even though it's the closest poll and (2) I forgot to change my registration when I moved last year, so I can't vote anyways. Sigh. And I was psyched to vote this year, too.
I just hope someone implements secure internet registration and voting by 2004.
I think there's also another problem with your example: "int" is a primitive type (not an object), so it is always passed by value. These examples should explain the differences between the three languages C, C++, and Java:
/* pass by value; call this using halve(a).
/* pass by reference; call this using halve(&a).
/* pass by reference; call this using halve(a).
/* 'h' is the reference to the object passed
/* note that the reference itself is passed
C always passes by value; you get pass-by-reference by passing a pointer to the desired object:
void halve(int va) {
va = va/2;
'a' does not change outside the function */
}
void halve(int *pa) {
*pa = (*pa)/2;
'a' is halved outside this function */
}
C++ is like C, but also adds language support for pass-by-reference:
void halve(int &ra) {
ra = ra/2;
'a' is halved outside this fuction */
}
Java is always pass-by-value: primitive types like 'int' are treated just like the C case. However, you cannot pass a pointer to an 'int' like in C. Instead, you have to use an object reference. The reference to an object argument is copied pass-by-value, so the object is effectively passed-by-reference:
class IntHolder {
public int a;
}
void halve(IntHolder h) {
h.a = h.a/2;
to this method. We can follow this
reference and change the original object */
h = null;
by value, so this assignment does NOT
affect the object outside this method. */
}
Hope this helps.
--S
I agree that 3DES is slow, and I'm by no means saying that I support it. But from what I see (and please correct me if I'm wrong), most e-commerce and online banking systems use 3DES or the RC4 stream cipher for session encryption. Both ciphers have been around for a while and have excellent library support.
So long as the millions of e-commerce and online banking customers are satisfied with the performance, industry has no reason to take a risk on better protocols. In fact, some users like the fact that encrypted connections are slower -- it makes them feel that they're more secure!
As you mentioned, there are applications that need fast crypto, and these may push the industry towards better protocols. But my guess is that unless someone shows that 3DES can be broken quickly and easily AND then steals a bunch of credit card numbers, the average consumer isn't going to care.
Public outcry is the strongest motivater out there; industry demand comes second; academic arguments fall dead last.
--Sameer
Most applications are still using triple-DES (3DES) because it's been around so long and analyzed thouroghly. This doesn't mean it's the most secure or has the best performance, but lots of developers just want a "proven" technology.
Twofish looks like it's done pretty well against the competing ciphers, but my guess is a new cipher will only catch on if it's widely deployed. For example, if Netscape and IE both support Twofish for secure websites and Web Devlopers start using it, then it'll boom. But people need motivation -- right now consumers aren't complaining about the security or performance of 3DES, so it's sticking around...
Most modern GUIs focus on the object->action technique: select an object, then select an action to apply to that object. For example, select an icon on the desktop, then double-click to Open or right-click to see other options...
The problem with this is that it doesn't intuitively allow someone to start new documents or find old ones. To start a new letter, you first need to start the application for letter writing, which means you have to know where to look. To load an old letter, you wither have to go through the application, the "recent documents list", or the file system...
As you can see, the verbs here are "start", "continue". and "write". The user's action is TASK oriented, not object-oriented. An interface that allows you to do choose a TASK at the top level gives a better starting point to the user (I use uppercase to denote the specific idea I'm discussing here). Note that none of what I'm about to describe are new ideas, but they're worth considering...
A TASK menu might have choices like "write an e-mail" or "play a game"; though, of course, more specific. Some may think at this point, "Well, that's just like the "Start" menu in Windows!" Not quite: the TASKs must be listed with intuitive, easy to understand names. "Write a Letter" as opposed to "MS Word 2000" or "Emacs". In a sense, the TASK menu is more like the "New..." submenu you'll find when you right-click on the Windows desktop, except TASKs are not always for document-creation.
A TASK menu wouls also support continuing saved work: "Work on an existing letter", "Continue a StarCraft campaign", etc. One must be careful to balance what is available at the top-level and what choices become available under specific applications. "Print letter" may be useful at the top-level, but it would be better if this option were only available whle one was working on the letter.
A few more notes:
1) The file system should be invisible. As someone proposed in another comment, the OS should support finding saved work using searches or heuristics (ie. recent document lists, etc). A hierarchical directory scheme should still be available for users who like to organize their data that way, but it need not necessarily reflect the underlying data structures.
2) Applications should be invisible. Applications implement some set of TASKS for the user; we might expect that in the near future all apps will be downloaded, so users can simply search the net for a new TASK they may want to do. For example, I may not have "Create flow chart" implemented by any app on my local machine, but I could search for that task and find a number of apps (Visio, etc) that can implement it. I choose one, it downloads and installs itself, and I'm up and running. Maybe even better, the actual app is stored remotely -- my system just stores my files and configuration information.
3) There's no idea of "saving" a document: all work is logged (as with a versioning system); users can return to any snapshot of their work through history. By default, the most recent version is loaded, but a "Continue from old version" option might be available as well. Check out the Elephant File System to get a better idea of how this might work.
Well, I've gone on quite a bit about what I hope is a different way of looking at things than what you're used to. I'm sure there are plenty of issues that would make this sort of system a pain for current computer users, but remember we're thinking about future users. Also note that voice recognition won't solve anything without a redesign of the standard UI: I'd hate to have to spell out filenames and name specific applications when all I want to do is "Start a new letter..."
--Sameer
That's a big shelf...
I'm sure this has been discussed on Slashdot before, but a general question related to this and many other articles:
If the only rule of property were "if it can be digitized, it's free of charge", would things still work? In such a world, software, books, music, art -- and all other forms of information -- would be available for free over the network.
Software writers could still charge to provide support, publishers could charge to provide bound books, other companies could charge to burn music onto CDs, artists could charge to do live performances, ads, and merchandising.
A lot of time and research has been spent on trying to protect or track information on the web so that only people who have paid for it can use it. If the world were reshaped so that information were free, this would be a non-issue (one could still have private information, but your privacy is based on trusting the parties you share information with).
There would still be value in physical goods -- books, houses, CDs, etc. And, of course, advertising can be "bundled" with information to generate revenue.
People who attend performances can record and freely distribute the show -- you're paying for the experience of being there when it happens, after all. But what happens if someone records a TV channel and immediately rebroadcasts it with their own ads? Or no ads at all? TV stations then lose all motive to lisence particular shows (what if NBC could rebroadcast the Superbowl a split second after ABC airs it live?).
And what about artists who just want to create their music and get paid, but don't want to do merchandising or performances? And game writers don't want to sit by the support phones all day -- they want to be able to live off the fruits of their labor. None of us wants to see ads for Cocoa Puffs scrolling along the bottom of our Quake screen.
Is such a world too ideal? Or could it be made to work? And even if it were possible, would it be better, and why?
PeopleNet -- personal web pages: from geocities (DumbNet! or MahirNet) to the more advanced (any cobination of InfoNet/CultureNet/TechNet/X-Net/UnderNet).
SchoolNet -- schools and colleges -- kinda TechNet/InfoNet hybrids...
main(){char q=34, n=10,*a="main() {char q=34,n=10,*a=%c%s%c;printf(a,q,a,q,n);}%c";printf( a,q,a,q,n);}
Apologies for lack of newlines -- this is the actual output. It's shorter because it takes advantage of using the ASCII numbers instead of quoting quotes, and the like. Yours is pretty cool too -- I hadn't seen one that just uses characters. Here's one more in Scheme/Lisp:
((lambda (x) (list x (list (quote quote) x))) (quote (lambda (x) (list x (list (quote quote) x)))))
Has anyone noticed that the "Y2K Experiences" posted here necessarily come from people who:
1) Have electricity
2) Have an OS that still works
3) Have a browser that still works, and
4) Have an ISP that still works
With this sort of sampling bias, we really shouldn't be expecting too many "horror" stories... Most will be "yeah, my stuff still works, which is why I can post this..."
:) awaiting "Smartass" moderation...
Regarding wearable devices for the computer display, a few questions:
1) Is it possible to make a display that is see-through (though perhaps darkened)? This way, you could see the information but also adjust your focus to see in front of you. It looked like one of the models might have something like this on.
2) Instead of a large headset or a targeting-device looking visor, could a display be packed into a simple monacle (ie. one of those round thingys you hold in place with your eye). The "chain" could carry the necessary information to the display. Such a thing might actually be subtle enough to be practical. Yeah, right.
3) Obviously, wearable displays bring up a number of UI issues. A lot of people seem to be focussing on voice interface, but that only seems right for text entry (if you've tried some of the original voice interfaces for Windows from 5 years ago, you'll know what I mean: "Open File", "Next Window"...) -- some sort of handheld pointer device seems necessary too. Either that, or something that responds to hand movement (or possibly eye movement, etc). What would work?
4) Finally, it seems that people might need to rething the GUI in general for wearable displays. Simply tossing up the standard windowed layout may not be best for mobile computing. And screen real-estate is also at a premium. What might be a better design.
Even given all this, I'm still concerned about trying to focus on something that's less than 2 inches from my eye...
One thing to consider is that CGI scripts impose a large delay in processing just because they have to fork off a process. Whether you use C or Perl may not matter if the time to invoke the script is significantly longer than the actual processing time. Perl is easier to use and faster for development (as mentioned by others), so it's better than C for scripting. Also, Perl is interpreted (rather than compiled), so bug fizes and patches are far easier to deploy. btw, you ca improve performance by abandoning CGI scripts altogether and looking at processes that use web-server threads (check out Philip and Alex's Guide to Web Publishing for info).
Your book describes a slew of interesting applications for crypto protocols, including electronic money orders, digital time-stamping, and secure multi-party computation. What are the remaining crypto problems of interest to the general public which have not been solved? (secure distribution of digital media comes to mind -- can you sell someone a music file, allow them to use the file anywhere, but make sure no one else can use it?)
Two comments:
1) For those who mention that you may not want to use Java because of speed issues, keep in mind that there are Java compilers available which can give you much better performance than interpretted bytecodes. It's write-once-compile-anywhere instead of run-everywhere. I'm sure there are issues with compiling bytecodes, though, but it's just an idea.
2) Another note is that, depending on your application, you may not need something so general as an ORB for use between your processes. For example, if your distributed processes are retrieving and updating shared data, why not use a network-accessible database? There are plenty of database interfaces available for many languages, and this might simplify your system if you have large, simple data structures. It's of course a speed loss and an increase in complexity, but databases are much more mature than ORBs. Think about whether or not a database might be better for your application.
Of course, I haven't addressed the problem of using the same code on multiple platforms; but I think others are doing a good job of that. But I have to agree that more information on your specific application might be helpful. Good luck!
Yeah, but the obvious question is then "Who makes the categories" and "What categories are right / fair"? Yahoo attempts to categorize the web, and many sites appear in multiple categories. These categories aren't rated in any way that I know of. And then there's the issue of what features of a site/category to rate -- movies have sex/violence/profanity levels, but these are mostly for parental restriction of children. When it comes to issues of personal preference, having ratings based like "site enjoyed by slashdot readers and hated by Reactionary Republicans" would be more useful. A "Dewey Decimal System" for web sites (or news articles) won't really cut it, IMHO. However, categorization may be the only practical way to get the general populace to rate things.
..." variety. I personally find that information very useful when looking for CDs. Oftentimes I find albums I would never have heard of, but the system also points me to bestsellers which are similar. Going to the bestseller then gives me more information on other good CDs. Could this work for web sites and news articles as well?
Another issue is the large data / small readership problem brought up in a previous post. Unless organizations are willing to go and rate site upon site, how will there ever be enough rating information to be useful? Rating books and albums works on Amazon.com partially because there's a simple 5-star customer review system (even simpler than categorization) and partially because it's a restricted data domain. Also, if someone writes a review for one book they've read, they're likely to write reviews for others.
Maybe web sites should offer a "Rate Me" button linked to some third-party rating company. Inspired surfers can follow the link and rate the site on a few static categories or offer their own comments. This could also give us cross-information of the "surfers who liked this site also liked
The main problem with this models is most sites won't offer a "Rate Me!" button. Alternatively, a rating company could set up a "meta-site" in which you can surf (using frames, for example) and have a "Rate This Site" button in the margins. Unfortunately, rating by URL is risky since the often change, but it's a first step.
Anyways, I guess my point is rating systems go beyond how they're designed; you also must consider how they're deployed (as other posters have mentioned). Solve that problem, stick an ad banner on it, and you've got the next great web fortune which will be bought out by Microsoft and eventually hacked by someone reading this.
Although I had programmed a few toy things in my undergrad classes, I didn't really learn how to hack till I went and worked at a software engineering firm for a few months. There's a difference bewteen my sophomore classes (one assignment was to explore inheritence in C++ by creating new character classes in a simple game) and implementing bugs/fixing features in a large system (my first assignment as an intern was to use yacc to create a language for remotely booting machines over a serial line -- I hadn't even learned C or worked with Unix yet. That changed quickly).
Still, I find I use some things I learned in school mixed with some real world experience -- not too surprising. Having a sense of how a program should be structured can affect how easy it is to maintain and how well it runs. But a student who has only learned C may not realize that a slower, interpreted language like Tcl or Perl may be better for web-server code. Coders who only learn Java may not even know how to manage memory correctly or what the machine-level representation of code is. As much as abstraction is a useful tool for programmers, top-to-bottom knowledge is important when designing anything more than a toy system. That means having the formal knowledge of how computer systems work and what designs/data structures are useful and having the practical knowledge of how to actually make your vision work.
P.S. I actually wrote "implementing bugs/fixing features" before I realized what I had just said. Freud? Who's Freud?
Now that Apple has introduces the G4 with nice, fast vector processing instructions, should we expect an even steeper decrease in the time it takes to crack these keys by the general public? Apple advertises 1 GFlop/s normally, but upto 4 GFlop/s in certain cases. Give that an earlier poster mentioned that these algorithms are massively parallizable, I wouldn't be surprised if a key-factorizing program could be written for the G4 which ran close to the 4 Gflop/s boundary. And given the 18-month-till-speeds-double trend, we have much to worry about.