"Email is harder, because it's fundamentally peer-to-peer (layered through a series of client-server interactions), which means the end users actually have to manage a digital identity."
That, and email encryption is mostly done either through soft-certificates or - more commonly - through PGP. There are hardly any mail systems that integrate PGP, although they are available as add on. Even so, I believe the user interface is still much harder than e.g. websites with SSL. Also, as you rightly said, end users not only have to manage a digital identify, most of the time they have to handle the other person's digital identities as well. E.g. here at home I cannot verify any signatures that I can verify on the computer at my work, because I do not have an up to date certificate store.
Of course there is also SSL with client side authentication. Although this is very usefull for B2B transactions (web services), you will hardly see any uses for end users. Even though both Mozilla and IE have build in support (although the Mozilla version tended to be broken for a pretty long time, and the IE version also has its fair share of problems).
See mythbusters. Go right ahead. It's probably not good for the car, but it won't (directly) kill the engine. Maybe heat it up a bit. Cleaning fluids are much worse, since they neutralize the oil, so the engine will burn itself up in notime due to friction.
"1.Don't assume all customers are idiots, especially when they call for support."
The ones that sound promising over the phone normally are your worst nightmare. They tend to do too much their own way, and since 90% of all problems are in the top 10 of problems already known and solved, you want the customer to do *exactly* what you want.
"2.Hire technical support people that know something about computers. And let them have the power to do real technical support instead of insisting that they follow the checklists."
See above. For the other part, you need one or two nerds in each team that can solve the hairy problems.
"3.Don't use proprietary hardware. More specifically, all components inside the machines should be standard as much as possible (for example, use standard PSUs with standard pinouts and not proprietary ones with custom DELL pinouts). Would make it easier for DELL to just switch suppliers if they e.g. decided that brand x power supplies sucked and brand y were better. This gives DELL negotiation power over suppliers (whereas if they had a custom PSU, the company that makes them has more leverage since the costs to have another company continue to make the custom PSU are expensive relatively speaking)"
It does not work that way. Dell needs to extensively specify and test one kind of PSU thouroughly, and then negotiate a good deal for the on time delivery to keep stocks low. Maybe renegotiate when times goes by. Just "switching power supplies" does not work. If Dell uses proprietary PSU's, they won't be very different from the ones that are in use, and suppliers would not have too many problems delivering Dell specific ones.
"4.This also extends to software. Do not use any proprietary drivers. All hardware should use the same drivers as you would use if you bought the hardware in a box from a retail store. All drivers should have separate installers included directly with the machine and/or be available to download from the web site such that it is possible to install a normal non DELL non OEM copy of Windows on the DELL machine and not have hardware that wont work right because the only way to get the drivers is to install the special DELL version of windows."
This is mostly already the case, at least for business computers. Laptops are a different and more difficult story, since the range of specific internal components is that much higher, and (maybe more importantly) they are only sold through a single supplier. Compare this with the large number of components you can for a specific desktop computer; these parts *need* their own driver (although this is changing as more and more get soldered onto motherboards). Custom drivers from Dell seem to be simple rebrands with a specific installer. The trick sometimes is to find out the same part in a retail version and download the correct driver for that (e.g. specific logitech mouse).
"5.Tone down the crap that is pre-installed. All spyware should be removed completely. All demos and time limited software should have uninstall options and also any limitations in the software (such as anti-virus programs with shorter subscription lengths than retail boxed copies have) should be clearly documented."
Apart from the documentation, this seems to be the case most of the time as well. Maybe this is different in the states.
"although I'm sure OEMs save a ton of money and hassle with recovery disks...."
Maybe the OEMs because it makes it easier on their tech. support lines. For their clients it is hell. That's why I would always check if the system comes with an original Windows disk and a driver disk, and - if possible - only uses standard components. Most of the time, I use the driver disk only once or twice; I use it to install the network card driver. The rest of the drivers and software are upgraded to their latest versions over the internet. Although a recovery disk may seem easy, it also means that any problem that has been found between the release date of the driver (many months before the actual recovery disk has been created, most of the time) will reoccur after installation. And then you can upgrade all the drivers *again*.
Recovery disks are one of the many things that make Microsoft such a PITA.
I would not call myself an expert on multi-threading (yet) - that's one reason why I am reading the book. But as I mentioned I am in the process of writing a multi-threaded implementation and I've written a few before. But most of the time you don't need to be an expert if you are just using a technology without going too deep. Anyway, there have been quite a few changes regarding the Java API and I've not fully read up into that yet.
The book starts off by showing all the common multi-threading problems. Hardly a way to sell multi-threading. Also I do not use threads to use my processor to the max. That would be foolish. The design goal is to maximize the speed of my application and implementation ease. If more applications do this as well, then there could be a significant win in using multi-core processors. It's like firefox that you so judge so unfairly. It's a good, rather safe browser that's more nimble and extensible than its predecessor - many people use and love it. What more do you want? What more do they market?
Anyway, the book is called: Concurrent Programming in Java, Second Edition, Doug Lea (Addison-Wesley) - it's reviewed by o.a. Joshua Bloch, who has written Java Puzzlers. You can imagine that this book is also slightly critical to common Java uses. So maybe you should reconsider before writing a comment like that. No offense intended.
Well, while downloading and parring/unrarring, it is very nice to still be able to view a movie you just downloaded. This is very basic stuff that millions of users out there are doing. Don't forget that things like bit torrent are pretty easy to make multithreaded. I would be *very* surprised if Azureus is only running a single thread. Of course the OS and apps should also be able to support multi-threading in a meaningfull way, and random access disk IO should be maximized as well (flash drives?). Currently it's as good as impossible to view a movie if both cores are busy or if *any* disk I/O is taking place (hint, use multiple disks). It's a bit like security; the system is only as strong as its weakest component.
"And of course threading is all non-safe and stuff."
Yes, and running multiple threads for fine grained tasks might not be a good idea. Maybe it can put it into threads when it has run for some time and the VM sees that it might want to split the loop iterations in the future. Of course, it must be sure that it is thread-safe and that the performance won't go down. It could this by trial and error or by knowing the processing and communication speeds of the architecture. Having a multithreaded loop is nice, but it's a long way from solving the multi-threading problem in any significant way.
Yup, when my Unreal crashes or doesn't quit, I love having a fully operational (X2) core left. Of course, if the application *would* have been multi-threaded, I might have two processors bound by this application. So lets have 32 cores with one for the operating system and its fully tested apps. Or a real time OS that leaves it's core processes (e.g. task manager) enough room to run.
Of course, 99% of the time this game also takes the keyboard and screen with it, so even 256 cores are no help then. Linux/X is not much better either. In the end its the (operating) system that makes most difference, and the number of cores is nice, but non-essential. And of course current HDD's are not up to multi-tasking. Everybody that has tried to run two copy commands at the same time will know what I am talking about.
Hmm, this comment turned out to be a bit of a mess, but you get the general idea.
Software *functionality* and reliability increases as well. Better managability, error reporting, memory management, security etc. all take their toll. Of course you could call all this bloat, but I doubt that we would like to do without in the end. What I see is that software is not that slow - more the opposite - on current CPU architectures. The architecture (loading all components in advance), memory usage and IO are the most annoying aspects of current software. Of course there is bloat, and of course this will take performance, but how much performance problems do you really have because of bloat if you come to think of it? And how much of that can be removed by faster single thread performance?
"And of course, I'd be remiss to not mention the "suck it up and use threads" school of thought, but my feeling is that if programmers in general haven't gotten it right after 20 years, the claim that programmers are especially stupid becomes less plausible, and "the technology is uselessly complex in practice" must be the right answer."
I have to disagree on this. There have been many developments that would aid developers in writing better code, which also leads to easier multi-threading: - managed code and garbage collection (Java GC also uses a tread); - new and better multi-threaded API's; - better code analysis; - better debuggers; - more components.
Currently I am reading a book on Java concurrency, and although it is indeed hard, the ready availability of a multi-threading API (including optimized, thread safe collections) makes it much easier to code with multiple threads. This will make it possible for mediocre programmers to do something with multi-threading as well. It's probably easier than trying to understand any of the other models.
Not that it matters too much; many, many programs will never be faster even with multiple threads, because 1) they are already fast enough, 2) they are I/O bound or 3) suffering from lack of performance for other reasons (database connections, memory usage etc). Note that sometimes threads are just the most likely model. I am currently in the (ever slow) task of writing a binary news client in Java. I would not even know where to start without threads - one per connection *at least*.
This is the same reasoning that many people apply to jobs. You don't like one part of a job, so you should resign and go to another job. Nevermind if the other jobs apply similar practices or have other drawbacks. Vista sure has its good points, but this for sure aint one of them. And since the damn thing will come pre-installed - something that *should* be forbidden due to unfair practices by MS - many people simply won't have this choice. So a petition is probably more effective - getting people not to buy it is a futile task.
When I use a file open dialog box from spring, I cannot open folders because when I press enter to open them, it selects the folder and returns instead. That simple fact makes Swing *completely* useless to me. Swing is was and will ever be a bad idea. It's just horrible to work with as well - WAY to many members in each class, way to many options and it always tries to emulate everything - and does so badly.
There are many good things about Swing, and it's interface is surely written in a better Java dialect than SWT (the constants in SWT are, e.g., just horrible), and the functionality is astounding. But the idea of simply emulating everything is not working. The whole idea of a Java interface that looks exactly the same on any platform is just plain STUPID. People don't use many platforms at the same time. They use one platform and want everything to look and work great *on that platform*.
Netbeans is snappy, yes. It's also one of the worst interfaces that I've seen in my *life*. Note that I've tried every NetBeans version from 3 to 5.5. I always get stuck using it for even simple programs. And the content assist and refactoring are *way* behind those of Eclipse. It's better for GUI building (without additional plugins) but after my last, simple, GUI project crashed never to return to full functionality, it was the 6th or 7th NetBeans to go into the bin.
What about modular software updates? The operating system doing all the installing and removing of applications? Real time operation? Removal of the ever present dependency of file systems? OS assisted versioning control? Saving all settings and reusing them for new OS installs? More direct, secure, communication between software components? Restarting drivers without taking the OS down? Crap, a system key that takes me back to a usable screen when a DirectX (or OpenGL on Linux) game is hanging would be an improvement.
In other words: I don't think there aren't enough truly new things in the latest operating systems. Sure, there are innovations, but basically the systems haven't changed a bit since MacOS and Windows 95, with Microsoft being one of the biggest contributers to that. In many ways, the latest operating systems are still shells. I can understand that compatability issues are important, but what's keeping them from at least offering better support for the latest and greatest? Windows 2000 is rather usable, but there are so many things wrong with the *entire design* that it is hard to know where to start.
Comparing OS'es is probably usefull, but having some truly interesting things build in would be much more interesting.
Not clear enough! Should have said: wet the sponge first *with water*. I just tried it with various cleaning fluids (containing alcohol, various kinds of oils, chlorides etc.) and it did not go all that well.
MD2, MD4 and MD5 as well as Panama are broken. Tiger seems to be an old hash function that has at least 16 rounds broken. ADLER32 and CRC32 are not *secure* hash functions, just checksums. RIPEMD-160 is also quite old, and simply said, the number of bits (160 obviously) only provide a maximum of 80 bits protection. So, with SHA-1 under attack, your HashCalc "only" provides the SHA-2 family of secure hashes. An inclusion of WHIRLPOOL would have been nice. I put only between "" because there are not many true and tried hash algorithms out there that are up to the task. Actually, that is one of the main gripes of Bruce Schneider with the current state of cryptography.
CRC32 is fine for detecting errors in downloads, but it doesn't provide a way to test for genuinity. If that is all you need, CRC32 is fine.
The slow performance of Eclipse is not due to the JVM, it's about the SWT library and it's bindings with the native libraries. There was an SWT port called SWT Fox that quickened things up a bit. It doesn't seem to be maintained anymore, but the performance speedup was very noticable. Changing the VM probably won't make the slightest of difference.
That cost me two moderations. Why aren't moderations in a discussion depended on the *branch* of the discussion? Oh well...
"... we'd have 6+ GHz P4s by now that would have been competitive with current Core 2 chips."
It probably would come with its own generator and liquid cooling solution as well. Lets build some friendlier chips instead, that still perform well and have nice extra's like virtualization and such. I love this new path these new chips have taken. I sometimes wonder if my computer is actually *on* sometimes, because of the lack of noise. P4, rest in pieces.
It's not as much retrieving the phones (or, in this case, GPS devices), it's about apprehending the thieves. How many small crimes are actually solved by the police? But you can rest assured that many, many crimes are performed by a small group of people. Getting these people out of the street and putting them straight is what it is all about. Also, if people are being caught, it's a message out there to all the other (wannabe) thieves; crime does not pay - not that this message is true all the time, but this is the message nonetheless.
As science advances, we learn more and more about the forces that drive nature, and the laws they abide by. Those examples you gave us don't violate any of the known physical lays. I find it a bit disturbing that the advancement of science is taken to mean that everything will become possible. Instead, we better know the posibilities and certainly the impossibilities. Maybe we will find a way around these laws, but I highly doubt it.
I for one would really like to explore the universe and make contact with alien species. Unfortunately, my just wishing this is the case doesn't make it so.
Fortunately, home pc's like to run multiple things in parallel. Especially if flash or other memory takes over from HDD's for running the OS and applications, there will be something to do for multi-processors. The state of current programs is pretty abysmal regarding multi-threading. Many programs do things in batches instead of delegating tasks to other threads. And for many programs this makes sense, because any (parallel) IO would kill the performance anyway. If that goes away, there is quite a lot to optimize.
Fortress looks more like a tool to do scientific programming. Although some home PC tasks might suit that bill (PAR checking uses some mathematics, for instance), many others won't, so we will have to use the more orthodox methods presented by Java or C# instead. And that *can* certainly be done. A parallel for loop seems to me something to avoid, since it sounds suspiciously to very fine grained parallelism, but I might do it not enough credit with this statement.
Most programmers would not understand all that mathematical mumbo jumbo anyway. Did you look at the examples? Not something to use in your basic word-processor application that.
Getting code quickly developed and creating components out of used code is as much important with high end computing as with other disciplines. What good is a 128 node supercomputer if it stands there waiting for someone to implement the code? And as there are Java to native compilers out there, there will be native compilers for Fortress as well. Even if there aren't, the JVM (which is what the current version runs on) is pretty fast. It's faster than C++ in many cases (e.g., when C++ programmers start to use smart pointers), and much more reliable, with good multi-threading support build in.
Anyway, seeing that this is intended to run on big hardware, I don't see how a 'slashvertisement' would do it any good. There won't be many/.ers with big iron in their computer rooms, dorms or garages, and those who do would undoubtedly already heard of this development.
Hopefully with some kind of wysiwyg kind of IDE, because the main reasons of the mathematical notation of source code is for the programmers themselves. If they are staring at tagged ASCII or Unicode, it doesn't make much sense. Allthough checking the correct working of the code would be interesting.
Ok, I'll have to agree on that. There are some seriously bad Java Docs out there. The XML digitital signature is another example. A programmer just following the docs would simply check if the signature would match, and think the document was signed. If you would send a message that signed signed something completely different, the program would still say that the signature was valid. That's just the URL that points to an incorrect locations, there are about a dozen other checks that need to be performed that are just not mentioned.
If the documentation is lacking, even experienced programmers could go wrong. What if someone substituted a different URL for the scheme? Would it go to blackmagic.eu because it is was not found in the local repository? Why do these libraries start and go on the internet without asking anyway? Why not make the local storage the default? Oh well.
Slashdot Mirror
"Email is harder, because it's fundamentally peer-to-peer (layered through a series of client-server interactions), which means the end users actually have to manage a digital identity."
That, and email encryption is mostly done either through soft-certificates or - more commonly - through PGP. There are hardly any mail systems that integrate PGP, although they are available as add on. Even so, I believe the user interface is still much harder than e.g. websites with SSL. Also, as you rightly said, end users not only have to manage a digital identify, most of the time they have to handle the other person's digital identities as well. E.g. here at home I cannot verify any signatures that I can verify on the computer at my work, because I do not have an up to date certificate store.
Of course there is also SSL with client side authentication. Although this is very usefull for B2B transactions (web services), you will hardly see any uses for end users. Even though both Mozilla and IE have build in support (although the Mozilla version tended to be broken for a pretty long time, and the IE version also has its fair share of problems).
To make diesel out of sugar, I just have to pour it in the company coffee. Problem solved (well, I still have to drink it).
See mythbusters. Go right ahead. It's probably not good for the car, but it won't (directly) kill the engine. Maybe heat it up a bit. Cleaning fluids are much worse, since they neutralize the oil, so the engine will burn itself up in notime due to friction.
"1.Don't assume all customers are idiots, especially when they call for support."
The ones that sound promising over the phone normally are your worst nightmare. They tend to do too much their own way, and since 90% of all problems are in the top 10 of problems already known and solved, you want the customer to do *exactly* what you want.
"2.Hire technical support people that know something about computers. And let them have the power to do real technical support instead of insisting that they follow the checklists."
See above. For the other part, you need one or two nerds in each team that can solve the hairy problems.
"3.Don't use proprietary hardware. More specifically, all components inside the machines should be standard as much as possible (for example, use standard PSUs with standard pinouts and not proprietary ones with custom DELL pinouts). Would make it easier for DELL to just switch suppliers if they e.g. decided that brand x power supplies sucked and brand y were better. This gives DELL negotiation power over suppliers (whereas if they had a custom PSU, the company that makes them has more leverage since the costs to have another company continue to make the custom PSU are expensive relatively speaking)"
It does not work that way. Dell needs to extensively specify and test one kind of PSU thouroughly, and then negotiate a good deal for the on time delivery to keep stocks low. Maybe renegotiate when times goes by. Just "switching power supplies" does not work. If Dell uses proprietary PSU's, they won't be very different from the ones that are in use, and suppliers would not have too many problems delivering Dell specific ones.
"4.This also extends to software. Do not use any proprietary drivers. All hardware should use the same drivers as you would use if you bought the hardware in a box from a retail store. All drivers should have separate installers included directly with the machine and/or be available to download from the web site such that it is possible to install a normal non DELL non OEM copy of Windows on the DELL machine and not have hardware that wont work right because the only way to get the drivers is to install the special DELL version of windows."
This is mostly already the case, at least for business computers. Laptops are a different and more difficult story, since the range of specific internal components is that much higher, and (maybe more importantly) they are only sold through a single supplier. Compare this with the large number of components you can for a specific desktop computer; these parts *need* their own driver (although this is changing as more and more get soldered onto motherboards). Custom drivers from Dell seem to be simple rebrands with a specific installer. The trick sometimes is to find out the same part in a retail version and download the correct driver for that (e.g. specific logitech mouse).
"5.Tone down the crap that is pre-installed. All spyware should be removed completely. All demos and time limited software should have uninstall options and also any limitations in the software (such as anti-virus programs with shorter subscription lengths than retail boxed copies have) should be clearly documented."
Apart from the documentation, this seems to be the case most of the time as well. Maybe this is different in the states.
"although I'm sure OEMs save a ton of money and hassle with recovery disks...."
Maybe the OEMs because it makes it easier on their tech. support lines. For their clients it is hell. That's why I would always check if the system comes with an original Windows disk and a driver disk, and - if possible - only uses standard components. Most of the time, I use the driver disk only once or twice; I use it to install the network card driver. The rest of the drivers and software are upgraded to their latest versions over the internet. Although a recovery disk may seem easy, it also means that any problem that has been found between the release date of the driver (many months before the actual recovery disk has been created, most of the time) will reoccur after installation. And then you can upgrade all the drivers *again*.
Recovery disks are one of the many things that make Microsoft such a PITA.
I would not call myself an expert on multi-threading (yet) - that's one reason why I am reading the book. But as I mentioned I am in the process of writing a multi-threaded implementation and I've written a few before. But most of the time you don't need to be an expert if you are just using a technology without going too deep. Anyway, there have been quite a few changes regarding the Java API and I've not fully read up into that yet.
The book starts off by showing all the common multi-threading problems. Hardly a way to sell multi-threading. Also I do not use threads to use my processor to the max. That would be foolish. The design goal is to maximize the speed of my application and implementation ease. If more applications do this as well, then there could be a significant win in using multi-core processors. It's like firefox that you so judge so unfairly. It's a good, rather safe browser that's more nimble and extensible than its predecessor - many people use and love it. What more do you want? What more do they market?
Anyway, the book is called: Concurrent Programming in Java, Second Edition, Doug Lea (Addison-Wesley) - it's reviewed by o.a. Joshua Bloch, who has written Java Puzzlers. You can imagine that this book is also slightly critical to common Java uses. So maybe you should reconsider before writing a comment like that. No offense intended.
Well, while downloading and parring/unrarring, it is very nice to still be able to view a movie you just downloaded. This is very basic stuff that millions of users out there are doing. Don't forget that things like bit torrent are pretty easy to make multithreaded. I would be *very* surprised if Azureus is only running a single thread. Of course the OS and apps should also be able to support multi-threading in a meaningfull way, and random access disk IO should be maximized as well (flash drives?). Currently it's as good as impossible to view a movie if both cores are busy or if *any* disk I/O is taking place (hint, use multiple disks). It's a bit like security; the system is only as strong as its weakest component.
"And of course threading is all non-safe and stuff."
Yes, and running multiple threads for fine grained tasks might not be a good idea. Maybe it can put it into threads when it has run for some time and the VM sees that it might want to split the loop iterations in the future. Of course, it must be sure that it is thread-safe and that the performance won't go down. It could this by trial and error or by knowing the processing and communication speeds of the architecture. Having a multithreaded loop is nice, but it's a long way from solving the multi-threading problem in any significant way.
Yup, when my Unreal crashes or doesn't quit, I love having a fully operational (X2) core left. Of course, if the application *would* have been multi-threaded, I might have two processors bound by this application. So lets have 32 cores with one for the operating system and its fully tested apps. Or a real time OS that leaves it's core processes (e.g. task manager) enough room to run.
Of course, 99% of the time this game also takes the keyboard and screen with it, so even 256 cores are no help then. Linux/X is not much better either. In the end its the (operating) system that makes most difference, and the number of cores is nice, but non-essential. And of course current HDD's are not up to multi-tasking. Everybody that has tried to run two copy commands at the same time will know what I am talking about.
Hmm, this comment turned out to be a bit of a mess, but you get the general idea.
Software *functionality* and reliability increases as well. Better managability, error reporting, memory management, security etc. all take their toll. Of course you could call all this bloat, but I doubt that we would like to do without in the end. What I see is that software is not that slow - more the opposite - on current CPU architectures. The architecture (loading all components in advance), memory usage and IO are the most annoying aspects of current software. Of course there is bloat, and of course this will take performance, but how much performance problems do you really have because of bloat if you come to think of it? And how much of that can be removed by faster single thread performance?
"And of course, I'd be remiss to not mention the "suck it up and use threads" school of thought, but my feeling is that if programmers in general haven't gotten it right after 20 years, the claim that programmers are especially stupid becomes less plausible, and "the technology is uselessly complex in practice" must be the right answer."
I have to disagree on this. There have been many developments that would aid developers in writing better code, which also leads to easier multi-threading:
- managed code and garbage collection (Java GC also uses a tread);
- new and better multi-threaded API's;
- better code analysis;
- better debuggers;
- more components.
Currently I am reading a book on Java concurrency, and although it is indeed hard, the ready availability of a multi-threading API (including optimized, thread safe collections) makes it much easier to code with multiple threads. This will make it possible for mediocre programmers to do something with multi-threading as well. It's probably easier than trying to understand any of the other models.
Not that it matters too much; many, many programs will never be faster even with multiple threads, because 1) they are already fast enough, 2) they are I/O bound or 3) suffering from lack of performance for other reasons (database connections, memory usage etc). Note that sometimes threads are just the most likely model. I am currently in the (ever slow) task of writing a binary news client in Java. I would not even know where to start without threads - one per connection *at least*.
"If you can't see the sarcasm dripping from above, check your glasses."
Can't see any sarcasm dripping of my glasses neither...
This is the same reasoning that many people apply to jobs. You don't like one part of a job, so you should resign and go to another job. Nevermind if the other jobs apply similar practices or have other drawbacks. Vista sure has its good points, but this for sure aint one of them. And since the damn thing will come pre-installed - something that *should* be forbidden due to unfair practices by MS - many people simply won't have this choice. So a petition is probably more effective - getting people not to buy it is a futile task.
When I use a file open dialog box from spring, I cannot open folders because when I press enter to open them, it selects the folder and returns instead. That simple fact makes Swing *completely* useless to me. Swing is was and will ever be a bad idea. It's just horrible to work with as well - WAY to many members in each class, way to many options and it always tries to emulate everything - and does so badly.
There are many good things about Swing, and it's interface is surely written in a better Java dialect than SWT (the constants in SWT are, e.g., just horrible), and the functionality is astounding. But the idea of simply emulating everything is not working. The whole idea of a Java interface that looks exactly the same on any platform is just plain STUPID. People don't use many platforms at the same time. They use one platform and want everything to look and work great *on that platform*.
Netbeans is snappy, yes. It's also one of the worst interfaces that I've seen in my *life*. Note that I've tried every NetBeans version from 3 to 5.5. I always get stuck using it for even simple programs. And the content assist and refactoring are *way* behind those of Eclipse. It's better for GUI building (without additional plugins) but after my last, simple, GUI project crashed never to return to full functionality, it was the 6th or 7th NetBeans to go into the bin.
What about modular software updates? The operating system doing all the installing and removing of applications? Real time operation? Removal of the ever present dependency of file systems? OS assisted versioning control? Saving all settings and reusing them for new OS installs? More direct, secure, communication between software components? Restarting drivers without taking the OS down? Crap, a system key that takes me back to a usable screen when a DirectX (or OpenGL on Linux) game is hanging would be an improvement.
In other words: I don't think there aren't enough truly new things in the latest operating systems. Sure, there are innovations, but basically the systems haven't changed a bit since MacOS and Windows 95, with Microsoft being one of the biggest contributers to that. In many ways, the latest operating systems are still shells. I can understand that compatability issues are important, but what's keeping them from at least offering better support for the latest and greatest? Windows 2000 is rather usable, but there are so many things wrong with the *entire design* that it is hard to know where to start.
Comparing OS'es is probably usefull, but having some truly interesting things build in would be much more interesting.
Not clear enough! Should have said: wet the sponge first *with water*. I just tried it with various cleaning fluids (containing alcohol, various kinds of oils, chlorides etc.) and it did not go all that well.
MD2, MD4 and MD5 as well as Panama are broken. Tiger seems to be an old hash function that has at least 16 rounds broken. ADLER32 and CRC32 are not *secure* hash functions, just checksums. RIPEMD-160 is also quite old, and simply said, the number of bits (160 obviously) only provide a maximum of 80 bits protection. So, with SHA-1 under attack, your HashCalc "only" provides the SHA-2 family of secure hashes. An inclusion of WHIRLPOOL would have been nice. I put only between "" because there are not many true and tried hash algorithms out there that are up to the task. Actually, that is one of the main gripes of Bruce Schneider with the current state of cryptography.
CRC32 is fine for detecting errors in downloads, but it doesn't provide a way to test for genuinity. If that is all you need, CRC32 is fine.
The slow performance of Eclipse is not due to the JVM, it's about the SWT library and it's bindings with the native libraries. There was an SWT port called SWT Fox that quickened things up a bit. It doesn't seem to be maintained anymore, but the performance speedup was very noticable. Changing the VM probably won't make the slightest of difference.
That cost me two moderations. Why aren't moderations in a discussion depended on the *branch* of the discussion? Oh well...
"... we'd have 6+ GHz P4s by now that would have been competitive with current Core 2 chips."
It probably would come with its own generator and liquid cooling solution as well. Lets build some friendlier chips instead, that still perform well and have nice extra's like virtualization and such. I love this new path these new chips have taken. I sometimes wonder if my computer is actually *on* sometimes, because of the lack of noise. P4, rest in pieces.
It's not as much retrieving the phones (or, in this case, GPS devices), it's about apprehending the thieves. How many small crimes are actually solved by the police? But you can rest assured that many, many crimes are performed by a small group of people. Getting these people out of the street and putting them straight is what it is all about. Also, if people are being caught, it's a message out there to all the other (wannabe) thieves; crime does not pay - not that this message is true all the time, but this is the message nonetheless.
As science advances, we learn more and more about the forces that drive nature, and the laws they abide by. Those examples you gave us don't violate any of the known physical lays. I find it a bit disturbing that the advancement of science is taken to mean that everything will become possible. Instead, we better know the posibilities and certainly the impossibilities. Maybe we will find a way around these laws, but I highly doubt it.
I for one would really like to explore the universe and make contact with alien species. Unfortunately, my just wishing this is the case doesn't make it so.
Fortunately, home pc's like to run multiple things in parallel. Especially if flash or other memory takes over from HDD's for running the OS and applications, there will be something to do for multi-processors. The state of current programs is pretty abysmal regarding multi-threading. Many programs do things in batches instead of delegating tasks to other threads. And for many programs this makes sense, because any (parallel) IO would kill the performance anyway. If that goes away, there is quite a lot to optimize.
Fortress looks more like a tool to do scientific programming. Although some home PC tasks might suit that bill (PAR checking uses some mathematics, for instance), many others won't, so we will have to use the more orthodox methods presented by Java or C# instead. And that *can* certainly be done. A parallel for loop seems to me something to avoid, since it sounds suspiciously to very fine grained parallelism, but I might do it not enough credit with this statement.
Most programmers would not understand all that mathematical mumbo jumbo anyway. Did you look at the examples? Not something to use in your basic word-processor application that.
Getting code quickly developed and creating components out of used code is as much important with high end computing as with other disciplines. What good is a 128 node supercomputer if it stands there waiting for someone to implement the code? And as there are Java to native compilers out there, there will be native compilers for Fortress as well. Even if there aren't, the JVM (which is what the current version runs on) is pretty fast. It's faster than C++ in many cases (e.g., when C++ programmers start to use smart pointers), and much more reliable, with good multi-threading support build in.
/.ers with big iron in their computer rooms, dorms or garages, and those who do would undoubtedly already heard of this development.
Anyway, seeing that this is intended to run on big hardware, I don't see how a 'slashvertisement' would do it any good. There won't be many
Hopefully with some kind of wysiwyg kind of IDE, because the main reasons of the mathematical notation of source code is for the programmers themselves. If they are staring at tagged ASCII or Unicode, it doesn't make much sense. Allthough checking the correct working of the code would be interesting.
Ok, I'll have to agree on that. There are some seriously bad Java Docs out there. The XML digitital signature is another example. A programmer just following the docs would simply check if the signature would match, and think the document was signed. If you would send a message that signed signed something completely different, the program would still say that the signature was valid. That's just the URL that points to an incorrect locations, there are about a dozen other checks that need to be performed that are just not mentioned.
If the documentation is lacking, even experienced programmers could go wrong. What if someone substituted a different URL for the scheme? Would it go to blackmagic.eu because it is was not found in the local repository? Why do these libraries start and go on the internet without asking anyway? Why not make the local storage the default? Oh well.