From what I can tell, it's a more sensible way of ordering documents. What I'd like to see is an approach where the documents are represented by thumbnails rather than just icons.
Although it looks overly-complex, bear in mind that this is research. They're trying out all the possibilities to see which ones "fit". I reckon a refined version of this interface could be very good indeed.
Yes, but the search promotion these days is (I think) largely an influence of the web, so it's not something that would've been so apparent back then. I'm not sure that Windows Indexing Service was really designed to handle the high-performance querying which is necessary to make these systems work, either. But yes, they've had full-text indexing for a while.
Also, just to give them a little benefit of the doubt, I think Vista has been in development for more than two years. So it's conceivable that they aren't "stealing" Apple's ideas, for example, but that Apple just beat them in releasing those features.
I think that, in more cases that not, you'd be right here. A lot of the features Vista has been lauded for "stealing" from Apple have been obvious advances for a while (prevalence of search over browsing, 3D-accelerated desktop systems, etc. are all fairly predictable). Vista steals very few design ideas from Apple, in any case (search? that was obvious - it's stolen from Google as much as anyone; desktop widgets? available for Windows and Linux as third-party systems well before Dashboard made people think that Apple "invented" them). As much as I like OSX, I hate the fact that Apple are hailed as so "innovative" to the exclusion of other hard-working companies who do work just as good, simply because they market themselves so well. I feel a lot of companies and organisations doing good work (and I'm gonna controversially include Microsoft here) are being a little hard done-by in this regard.
More widely, though, I'm not opposed to "idea theft" in the IT field. There's a reason so many people are opposed to software patents.
To be fair, though, most commercial development (apparently) happens with SOAP, whereas REST is used more by amateur etc. projects. So SOAP is still popular in business. I think I'd personally rather use REST though, yes, but saying "SOAP isn't popular" doesn't really work because it's popular where the money is, which is something of a factor.
I think that, if anything, they're beginning to show that they're more willing to deal with OSS now. Back then, they had very little understanding of it other than an undefined threat. More recently they've started treating OSS as more of a competitor, which is about as much as anyone can reasonably expect of them.
Sounds like a Firefox browser that integrates a half-dozen third-party plugins to me.
Essentially, yes, but it bundles and integrates them in a way that would be extremely difficult to do in a single bundle of extensions — it's very slick.
I really like Flock, and I have done for some time. Firefox and Flock extensions are usually largely interoperable, and I can't see the two browsers hurting one another. If anything, they'll help each other. A lot of people like to dig into Flock by complaining that they don't need its functions, but that shows little other than the fact that Flock is not for them. Flock isn't designed to kill Firefox, it's designed to work well alongside it and attract a different user base.
You can change the heapsize that Java uses, it's generally wise to have it at a value which is suitable for your system, and for the software being run. A particular problem with older versions was that the defaults were not particularly sensible, and few people actually changed them. One change in Java 5's virtual machine was an overhaul to attempt to autodetect "sensible" settings for when none are specified.
I wouldn't recommend running Java apps on a system with less than 256MB of RAM, though. One would hope such systems were fairly old now anyway, though.
Well, it's a case of which "unsafe" things you allow, I suppose. I don't personally think that direct memory manipulation through pointers and the like helps you if you're using a rich language, and you don't want to actually write something which manipulates memory as its primary function (like a garbage collector or whatever). Dynamic typing is a different matter though, particularly for Rapid Application Development. Another fun-looking language for the CLI is Boo, which is "Python-inspired", with (optional) stronger typing and more influence from CLI languages, rather than an actual dialect of Python, as IronPython is.
I wasn't suggesting you do it, I was pondering about whether it'd work. I'm afraid I don't know of any native clients for OSX that are any good though, or I'd suggest them. G'luck finding one.:)
A myth?? Don't tell me it is a myth. I can start up Azereus on my Mac and experience it first hand. The only reason I keep that piece of crap around is because, for the most part, I dont' have to interact with it to use it.
For what it does, it's pretty fast in operation. But, that said, it's pretty slow, because what it does is so complicated. So yeah, it's an annoying one.
But I LIKE native applications. Why dont' developers understand that? Users don't care how cool the language is or how portable it is. They just want it to run, and the faster and more integrated with the OS, the better.
Integration is coming, hopefully. The current focus of Java core development is with desktop integration stuff, so hopefully that'll get better soon. The speed issue isn't really an issue — Java is generally as fast as native code. Its use in servers shows this very well, and I hope that desktop apps demonstrating this are along soon.
The biggest complaints with the performance of Java programs on the desktop fall into three categories, in my experience:
"It's not responding quickly enough" - typically the fault of the GUI framework, which in the case of Swing doesn't double-buffer and so on, so appears slow, and in the case of SWT (which is what Azureus uses) a lot of the native components for some systems just aren't very good.
Startup pause. This is because Java is a JITted language, and there's a compilation phase before the program runs. I realise this makes it a little hard to justify using it in the realm of smaller systems like widgets and so on, but for applications that are only started once, this is a fairly minor issue.
High memory use. Although Java's memory use is high, this memory is not generally all used at any one time. This complaint tends to be brought by people who don't understand how garbage-collected languages work, and have gotten a false impression of the "bloat" of a Java program by looking at its resident size.
Actually that's only true of multicast delegates — there are some which only ever point to one function, although they're obviously not used so much since the main use of delegates is the event/subscriber pattern.
Of course, there's always the issue that function pointers, in most implementations, are inherently unsafe, so they're quite hard to wedge into a "safe" language like C#. It's one of those quandary things. I'm not convinced that, in the paradigm that C# implements, there's all that much use for function pointers as it is, though.
Well, I'd say that you've just managed to make the "trade-offs" point perfectly. *nix (and assuming, by all the Ks, KDE) is the better choice for you. Well researched.
Windows tends to be a better fit for me on my main system, whereas my secondary ones all run Linux and GNOME. It just fits my pattern of usage better. This is, as has been pointed out, a matter of tradeoffs.
I want focus follows mouse. I *don't* want autoraise on focus. I *dont* want autoraise on click. I *do* want drop to the bottom of the stack on some easily accessible hotkey. I *do* like the current selection available to paste. I *do* want to use the middle mousebutton for something sensible when selecting text.
I think the TweakUI PowerToy can do this. It's a "hidden setting", since very few people actually want to use it it's assumed that those who do will be sufficiently computer-literate to do the 30 seconds of web searches required to find the answer.
I'm not a big fan of over-the-top transparent configuration. It makes the system far more difficult to use, which is why most user-centric systems (OSX is far worse than Windows or GNOME for "hiding things") do practice some sort of hiding. Showing so many flexible settings is valuable to some expert users, though. I suppose it's a matter of what you want from it. Considering the target userbase of OSX, Windows, and GNOME, I think they've made a reasonable choice there.
This cracks me up. As we head towards multi-core and massively-multi-core, you are telling me that things are going to get better for interprative languages? Compilers are about to kicked in the pants because we can only do thread-level-parallelism for so long (uh, lets say N=4.. when do those quad-cores come out? Early 07?).... The trend towards parallelism is going make compilers infinitely more importants as (memory bandwidth + computation bandwidth) gets the additions of a new, third term... communication bandwidth. It's just one more thing compilers are going to have to learn to deal with... and interpretative languages are going to fall farther behind... not catch up.
What about JITted languages? Compiler advances apply equally well to them, and they can often apply the changes without even having to redistribute the executable — the JIT engine simply gets more efficient, learns how to use these systems, and suddenly the bytecode of your old app is optimised on-load to use them too.
That does apply to purely-interpreted languages, though, but how many of them are there really these days?
To be fair, delegates (which is most likely what is being discussed) are not syntactic sugar. They're a feature of the CLR allowing one to treat functions as objects. Although Java and C# are not very different languages (to say the least), delegates are a language feature of C# that Java could really use (many people use anonymous classes or lots of seperate classes with single methods to achieve what can be done with simple methods in C#), particularly for GUI functions.
I agree though; "syntactic sugar" is a term that is bandied around altogether too often. Syntactic sugar is accused of reducing a languages base simplicity to gain the advantage of making a specific use-case simpler, but it's not as simple as that in practice. Some "syntactic sugar" extends well universally and acts to enhance the language — it's a question of good design.
Java apps are written by developers who only care about themselves, not their customers.
Nonsense. What if they have a customer who cares about reliability? Writing it native will increase the cost hugely, compared to Java. There's plenty of reasons to write things in Java. The fact that the default GUI toolkit is lacking compared to the rest of the platform (and since it's the focus of current development on Java, it's likely that this is not a trend that will continue).
Furthermore, the only native alternative to Azureus I've seen which comes close is uTorrent, and it's not cross-platform, and specially designed to be lightweight so it misses a lot of features.
To be fair, you can write GTK, Qt, and Cocoa apps in Java. "Bloat and hideousness" is largely a myth (people who stare at top all day might notice more memory use, but that's about where Java's "bloat" ends).
The problem you're mentioning is with Swing (the GUI toolkit) though, yes. And it is a problem. Swing can be unweildy and inconsistent with the platform, particularly on Linux. This is being worked on as a priority for the next Java version, but it's a real shame it's taken this long to happen. The fact that you need a prerelease version of Java to use a workable GTK theme is discouraging, but at least it's there now.
Java has proven itself to be fast and reliable on the server-side, but it's never (until, hopefully, soon) really had the GUI muscle to back it up. But with any luck, soon it shall, and we can get away from having to rely on native applications so much.
I know you will have had a bad experience with GUI Java apps. Most people have. But there's no core trait of Java causing it not to work well. It just doesn't work well in the current and previous versions. This is a solvable problem.
I'm not any sort of expert, but I believe that OpenSSL is an implementation of an existing standard, whereas the things up for debate here are the next-generation standards to use. Furthermore, these standards are for wireless connections, which isn't something that OpenSSL has anything to do with.
Slashdot Mirror
From what I can tell, it's a more sensible way of ordering documents. What I'd like to see is an approach where the documents are represented by thumbnails rather than just icons.
Although it looks overly-complex, bear in mind that this is research. They're trying out all the possibilities to see which ones "fit". I reckon a refined version of this interface could be very good indeed.
These days? Probably to search (from your homepage or the search bar) or use a bookmark.
Nice, I didn't know that. Interesting.
Yes, but the search promotion these days is (I think) largely an influence of the web, so it's not something that would've been so apparent back then. I'm not sure that Windows Indexing Service was really designed to handle the high-performance querying which is necessary to make these systems work, either. But yes, they've had full-text indexing for a while.
I think that, in more cases that not, you'd be right here. A lot of the features Vista has been lauded for "stealing" from Apple have been obvious advances for a while (prevalence of search over browsing, 3D-accelerated desktop systems, etc. are all fairly predictable). Vista steals very few design ideas from Apple, in any case (search? that was obvious - it's stolen from Google as much as anyone; desktop widgets? available for Windows and Linux as third-party systems well before Dashboard made people think that Apple "invented" them). As much as I like OSX, I hate the fact that Apple are hailed as so "innovative" to the exclusion of other hard-working companies who do work just as good, simply because they market themselves so well. I feel a lot of companies and organisations doing good work (and I'm gonna controversially include Microsoft here) are being a little hard done-by in this regard.
More widely, though, I'm not opposed to "idea theft" in the IT field. There's a reason so many people are opposed to software patents.
To be fair, though, most commercial development (apparently) happens with SOAP, whereas REST is used more by amateur etc. projects. So SOAP is still popular in business. I think I'd personally rather use REST though, yes, but saying "SOAP isn't popular" doesn't really work because it's popular where the money is, which is something of a factor.
I think that, if anything, they're beginning to show that they're more willing to deal with OSS now. Back then, they had very little understanding of it other than an undefined threat. More recently they've started treating OSS as more of a competitor, which is about as much as anyone can reasonably expect of them.
Essentially, yes, but it bundles and integrates them in a way that would be extremely difficult to do in a single bundle of extensions — it's very slick.
I really like Flock, and I have done for some time. Firefox and Flock extensions are usually largely interoperable, and I can't see the two browsers hurting one another. If anything, they'll help each other. A lot of people like to dig into Flock by complaining that they don't need its functions, but that shows little other than the fact that Flock is not for them. Flock isn't designed to kill Firefox, it's designed to work well alongside it and attract a different user base.
This is about hardware drivers, not interoperability standards. These things are not relevant.
It's the mouse I've always wanted, and now I have it. I rule!
You can change the heapsize that Java uses, it's generally wise to have it at a value which is suitable for your system, and for the software being run. A particular problem with older versions was that the defaults were not particularly sensible, and few people actually changed them. One change in Java 5's virtual machine was an overhaul to attempt to autodetect "sensible" settings for when none are specified.
I wouldn't recommend running Java apps on a system with less than 256MB of RAM, though. One would hope such systems were fairly old now anyway, though.
Well, it's a case of which "unsafe" things you allow, I suppose. I don't personally think that direct memory manipulation through pointers and the like helps you if you're using a rich language, and you don't want to actually write something which manipulates memory as its primary function (like a garbage collector or whatever). Dynamic typing is a different matter though, particularly for Rapid Application Development. Another fun-looking language for the CLI is Boo, which is "Python-inspired", with (optional) stronger typing and more influence from CLI languages, rather than an actual dialect of Python, as IronPython is.
I wasn't suggesting you do it, I was pondering about whether it'd work. I'm afraid I don't know of any native clients for OSX that are any good though, or I'd suggest them. G'luck finding one. :)
I wonder if it'd be possible to create a cut-down version of Azureus (which behaves more like uTorrent) which runs faster?
For what it does, it's pretty fast in operation. But, that said, it's pretty slow, because what it does is so complicated. So yeah, it's an annoying one.
Integration is coming, hopefully. The current focus of Java core development is with desktop integration stuff, so hopefully that'll get better soon. The speed issue isn't really an issue — Java is generally as fast as native code. Its use in servers shows this very well, and I hope that desktop apps demonstrating this are along soon.
The biggest complaints with the performance of Java programs on the desktop fall into three categories, in my experience:
Actually that's only true of multicast delegates — there are some which only ever point to one function, although they're obviously not used so much since the main use of delegates is the event/subscriber pattern.
Of course, there's always the issue that function pointers, in most implementations, are inherently unsafe, so they're quite hard to wedge into a "safe" language like C#. It's one of those quandary things. I'm not convinced that, in the paradigm that C# implements, there's all that much use for function pointers as it is, though.
Well, I'd say that you've just managed to make the "trade-offs" point perfectly. *nix (and assuming, by all the Ks, KDE) is the better choice for you. Well researched.
Windows tends to be a better fit for me on my main system, whereas my secondary ones all run Linux and GNOME. It just fits my pattern of usage better. This is, as has been pointed out, a matter of tradeoffs.
I think the TweakUI PowerToy can do this. It's a "hidden setting", since very few people actually want to use it it's assumed that those who do will be sufficiently computer-literate to do the 30 seconds of web searches required to find the answer.
I'm not a big fan of over-the-top transparent configuration. It makes the system far more difficult to use, which is why most user-centric systems (OSX is far worse than Windows or GNOME for "hiding things") do practice some sort of hiding. Showing so many flexible settings is valuable to some expert users, though. I suppose it's a matter of what you want from it. Considering the target userbase of OSX, Windows, and GNOME, I think they've made a reasonable choice there.
I don't see how non-native languages can't just change paradigm as well. This is not a native vs. interpreted/etc. issue at all.
What about JITted languages? Compiler advances apply equally well to them, and they can often apply the changes without even having to redistribute the executable — the JIT engine simply gets more efficient, learns how to use these systems, and suddenly the bytecode of your old app is optimised on-load to use them too.
That does apply to purely-interpreted languages, though, but how many of them are there really these days?
To be fair, delegates (which is most likely what is being discussed) are not syntactic sugar. They're a feature of the CLR allowing one to treat functions as objects. Although Java and C# are not very different languages (to say the least), delegates are a language feature of C# that Java could really use (many people use anonymous classes or lots of seperate classes with single methods to achieve what can be done with simple methods in C#), particularly for GUI functions.
I agree though; "syntactic sugar" is a term that is bandied around altogether too often. Syntactic sugar is accused of reducing a languages base simplicity to gain the advantage of making a specific use-case simpler, but it's not as simple as that in practice. Some "syntactic sugar" extends well universally and acts to enhance the language — it's a question of good design.
Nonsense. What if they have a customer who cares about reliability? Writing it native will increase the cost hugely, compared to Java. There's plenty of reasons to write things in Java. The fact that the default GUI toolkit is lacking compared to the rest of the platform (and since it's the focus of current development on Java, it's likely that this is not a trend that will continue).
Furthermore, the only native alternative to Azureus I've seen which comes close is uTorrent, and it's not cross-platform, and specially designed to be lightweight so it misses a lot of features.
To be fair, you can write GTK, Qt, and Cocoa apps in Java. "Bloat and hideousness" is largely a myth (people who stare at top all day might notice more memory use, but that's about where Java's "bloat" ends).
The problem you're mentioning is with Swing (the GUI toolkit) though, yes. And it is a problem. Swing can be unweildy and inconsistent with the platform, particularly on Linux. This is being worked on as a priority for the next Java version, but it's a real shame it's taken this long to happen. The fact that you need a prerelease version of Java to use a workable GTK theme is discouraging, but at least it's there now.
Java has proven itself to be fast and reliable on the server-side, but it's never (until, hopefully, soon) really had the GUI muscle to back it up. But with any luck, soon it shall, and we can get away from having to rely on native applications so much.
I know you will have had a bad experience with GUI Java apps. Most people have. But there's no core trait of Java causing it not to work well. It just doesn't work well in the current and previous versions. This is a solvable problem.
PHP? No. What about Java? It's more than capable of doing this as well as a native solution.
I'm not any sort of expert, but I believe that OpenSSL is an implementation of an existing standard, whereas the things up for debate here are the next-generation standards to use. Furthermore, these standards are for wireless connections, which isn't something that OpenSSL has anything to do with.
So basically, it's not relevant, I'm afraid.