I'm admittedly guessing, but I think that figure probably includes a whole lot of wireless technologies, not all of which are available to the average consumer. Yes, it includes cell technologies (GPRS being a completely acceptable -- if not hugely expensive -- way of accessing the Internet) -- cell technologies probably make up the great bulk of that figure. However, there are fee-based WiFi Hotspot providers here in Canada (generally in the larger centres), so they probably get counted too (such providers typically only provide service in specific venues -- for example, Bell AccessZone, which provides WiFi service in the Air Canada Centre, and in VIA Rail first class lounges (and on in first class sections of the Toronto - Montreal corridor trains).
It may also count satellite-based Internet, and could also possibly include microwave uplinks available to corporations. Without a breakdown it is difficult to know -- it appears to me that they're just throwing out a Really Big Number for investors to chew on. After all, who doesn't want a slice off of a Really Big Pie?
It's kind of funny to click on the Core Duo version and read about how the much faster it is than the G5 model, when they are still trying to sell the same G5 model.
The Intel iMac is much faster than the old G5s when it comes to raw processing power, however that presumes that the software you want to run is available for Intel Mac. I'm sure there are a lot of design houses out that which rely on Photoshop and other graphic design and video/audio editing software which hasn't been ported to Intel OS X yet, and which are in need of new machines.
Apple can't afford to drop all of the G5-based systems until the software that drives the sales of their higher end systems is made Universal.
I doubt that it really uses 20MB. It just appears to use 20MB. What's almost certainly really happening is that it's mapping 20MB more of virtual memory, of which very little is actually used. For example, if the program needs a class or two from some JAR, the JVM will mmap() the entire JAR file, reserving virtual address space for all of it, even though only the pages that actually get read will be faulted in and consume real RAM. So several megabytes of virtual address space has been "consumed", but only a few KB of actual RAM is used.
I'm quite aware of how to properly profile memory for Java applications, and yes, there is a 20MB difference in actively used memory. The virtual memory claimed is siginificantly higher than what I quoted -- where it's using ~35MB of real memory, the process is claiming a whopping 453MB of virtual memory (which of course isn't allocated at all, and thus doesn't really affect much of anything performance or RAM wise). Opening all four possible dialogs at once bumps that memory usage up to closer to 50MB.
I have a pile of Java memory profiling tools that all agree with this memory usage assessment. Now it's possible that the low level implementation on Mac OS X is more hungry than on some other platforms, but in my testing this is relatively equivalent to running it on Linux and Windows.
Sorry, but Swing is memory hungry. It tends to show in complex applications, which is one reason why I've kept the jSyncManager as simple as possible in terms of GUI.
Things I !@$!@$!$@!@ hate about java: $CLASSPATH. It's slow. Memory Frigging Pig. Jsp (hint: slow, memory pig). Zealots who point to benchmarks to point out how fast it is. It's not. It's slow, go ask your users.
I have asked my users, and they tend to be surprised at how fast the jSyncManager is. At one time it was measurably faster than Palm's own HotSync Manager for Windows -- nearly 50% faster in some tests. And the jSyncManager is 100% pure Java. And the parsing code for the protocol stacks and data types is pretty complex. We've had users running this code on old Pentium-class systems, and the execution speed is still on par with native solutions.
So yes, I've asked my users, and they're typically surprised that Java can be so fast. The key is having a developer who knows how to optimize code, with a sound design. Doing a lot of the heavy lifting work yourself doesn't hurt either (i.e.: not relying on a lot of external frameworks), as does using as much parallelization as possible.
Sorry, but Java speed complaints are mostly bunk. Swing does have some performance issues (although this can differ from platform to platform), but Java as a whole is quite fast. You simply have to have developers who know what they're doing when it comes to optimization and overall program design to make the most of it.
I have never heard of anyone who did not use Swing because of its memory usage.
Are you new around here?;)
Admittedly, I use Swing. I don't avoid it because of its memory requirements, but they are a source of continued concern to me. Admittedly, the issue doesn't get as much attention these days as RAM continues to become ever more inexpensive, but there is still serious room for improvement. Read my other posting here on this subject for some examples.
Swing is flexible, and can create some nice GUIs. I don't like how much coding this requires (as I've mentioned elsewhere in this thread, Sun really needs to look at how Apple has solved the GUI design issue with Interface Builder, where instead of trying to create source code that has to be compiled to generate your UI, it gets serialized at design time, and deserialized at runtime (which has the added benefit that you can modify your GUI without the need for a recompile)), and I really don't like how quickly Swing can chew up RAM. Yes, I have a gig and a quarter of RAM, but no, I'm not in a hurry to fill it up as quickly as I possibly can either. I have yet to see a single platform where Swing wasn't a memory hog.
I don't think it is fair to use the swing memory argument anymore. It is really something that has been worked on.
I agree that there have been improvements, but I'm sorry -- I do think it's fair to continue to take Sun to task for this still.
A quick example -- the jSyncManager, my most popular OSS application. It can be run in either GUI or console mode. In both, the engine code is identical -- only the user interface differs. Firing it up in GUI mode uses about 35MB of RAM on my Mac OS X 10.4.5 based PowerBook. Firing it up in console mode uses ~15MB of memory.
That's a 20MB difference, and that is just after start-up. The GUI has a single window, with three menus, and a total of 11 menu items. There are NO widgets in the window -- instead it just has a graphic (it's meant to be run minimized -- the menus allow access to help, configuration items, and the log window). And yet that uses 20MB.
Activating every menu item that bring up a GUI dialog once, with the exception of the Help subsystem (which uses JavaHelp) brings it up to ~45MB of memory usage. Bringing up everything including JavaHelp once causes it to use ~55MB of memory. That is 40MB of GUI, and it is all absolutely trivial stuff -- excluding JavaHelp, it's probably less than 50 widgets all together.
True -- I have 1.25GB of RAM in my system, so 40MB is barely even noticed. Still, this is an absolutely trivial GUI (the complexity is in the data synchronization engine -- again, this application is meant to be a "fire-and-forget", run it in the background program which handles PalmOS data synchronization, and doesn't typically require any user input other than configuration).
For a more complex comparison, I fired up "Tapear", a clinical document management system that is part of another Open Source project I work on known as OpenTAPAS. It has only one window, but has hundreds of widgets of all types in it, with multiple tabs for a whole variety of different view types. It doesn't have much of anything in terms of an "engine", as it retreives all of its data from a remote database. After loading it up and opening up a single patient, it uses 80MB of RAM -- more than even my entire IDE (Xcode) uses by 25MB.
(I should note that all the above tests were done with the latest release version of Java 1.5 for Mac OS X (PPC)).
One more example -- Limewire 4.9 uses ~75MB of RAM with no transfers.
Sorry, but Swing is still quite memory hungry. Can you imagine running all of your applications as Java applications? Improvements are being made, but I think there is room for further improvements in this regard.
Honest question - what do you mean by saying that SWT is 'nonstandard'?
It's not part of the Java standard from Sun. That isn't to say that SWT itself doesn't conform to its own defacto SWT standard -- it's just not part of the Java standard. It is my understanding that legally, IBM can't advertise SWT as being "Java", and can't even technically call Eclipse a Java IDE (even though it does the job just fine).
Sun needs to take a look at what Apple has done with Interface Builder and Cocoa. It should then replicate a similar system in Java for designing and describing Java GUIs. Now that Java 1.5 has java.beans.XMLEncoder available, this should be significantly easier for them to accomplish.
GUI development in Java is still painful and problematic. Which is too bad, as I'm actually a proponent of Java on the desktop (although IMO only Apple has got this right, with their JAR Bundler tool, such that you can distribute a Java application to users such that it appears to them to be just like any other application -- they never have to be even be aware that it's a Java application).
Why is there more than one Java GUI tool kit? The best answer is that one size does not fit all
That hardly answers the original question -- it's true, but it doesn't answer the statement in question. That would be like saying:
Why is the sky blue? The best answer is that 1 + 1 = 2
The reason why there are three toolkits is simply: originally, Sun developed AWT. AWT was introduced with Java 1.0 as a way to obsfucate the drawing of common GUI widgets on a variety of platforms, using the native widget set. Unfortunately, this was problematic for many platforms, and wasn't very flexible.
Thus, Sun developed Swing. It supported more widgets, and did a lot of its own drawing in order to appear and generally layout the same across different platforms.
Swing, unfortunately, has some design limitations, not the least of which is that it is very memory hungry. When IBM decided to "port" VisualAge for Java from being a Smalltalk-based product over to using Java, they found that Swing wasn't up to the task, so they decided to develop their own widget toolkit, called SWT. SWT wasn't exactly intended for use outside Eclipse, mind you -- it's just that many developers decided to use it as such.
So we're left with a bit of a GUI mess on our hands in the Java world -- one I really wish would be fixed. Swing works, but it can be slow and memory intensive. SWT is non-standard, and requires a platform-specific module which users may not already have installed (which means either you have to tell them to download and install it, or you have to create a bunch of installers for different platforms to allow them to run your SWT-based application).
That is why we have thre different toolkits. For all intents and purposes, the bulk of AWT is deprecated and shouldn't be used for its widgets. It is simply difficult to get rid of due to the number of legacy applications out there which are still using it, and which will probably never be updated to use Swing.
Okay, is this just one big conspiracy or not? I have *NEVER* had a Coral Cache link work. Not once.
You said it. I'm glad I'm not the only one.
It looks to me like Corel Cache can be Slashdotted as well. Indeed, the only time I ever find that Corel Cache helps me to read a story that/. links to is when someone submits the Corel Cache link, and I can then go to the original story that is supposed to be cached, because the rest of/. is hammering Corel Cache instead.
Corel Cache doesn't have a special "Bandwidth of the Infinite" spell it can cast when the/. hordes descend upon a site.
The cost of developing software is anything but negligible.
Yes, but you don't have to create a fully working product in order to have a "working model" for a software patent. All that you would have to do is create something simple which demonstrates the invention being patented in effect.
I've done it. Like I said, one of my previous employers decided to file patents in two countries for two "inventions" I created which working there. One of them I came up with one night at home, while watching TV. It can be demonstrated in less than 12 lines of code. Took 5 minutes to think up, and 5 minutes to implement a fully working demonstration of the invention in action. It took orders of magnitude more time and effort on the legal side to file the patent than it did to invent and implement in the first place.
(I should note here that the invention mentioned above has never, to my knowledge, even been used in a shipping product. It wasn't "invented" in conjunction with the project I was employed to work on either. It was something I came up with working on a personal project on my own time that I happened to mention to my manager during a friendly conversation. He thought it was novel enough to bring in the patent team, and they ran with it).
You don't patent "Windows". Software patents are typically relatively simple ideas that anyone in the field could have thought up if they had encountered a similar problem, which is one reason why so many people are against software patents in the first place. The actual process of "invention" for my first patent cost my employer nothing. The implementation of a working model likewise cost them nothing. And even if I had invented and implemented the working model on work time, it would have taken me about an hour.
I don't think a working model of Amazon's "one click purchasing" would take all that long to think up and create a working model either. Again, "working model" doesn't necessarily mean "put into a big, massive shipping product", and as such the costs of creating such a working model in software can be kept quite a bit lower than a hardware invention.
The power glove was #7 and the intellivision disc was #4??? The intellivision controller was great for lots of games. I wasted more of my life on Discs Of Tron and Treasure of Tarmin than probably any other games (except maybe MOO2).
I'm with you -- the Intellivision controller doesn't belong on that list. Sure it was different from what we're used to today, but in general, it worked quite well. So much so that my Intellivision still works just fine, all these decades later.
My only complaint about it would be the overlays. Not the idea of the overlays -- just how the actual overlays were made, and how the top laminate over time would peel up, making them really hard to insert.
I think I might have to get my Intellivision out of storage and hook it up this weekend for some really old school gaming. Utopia, here I come!
To discourage "thought-sweatshops" that just invent without investing, I'd bring back the working model requirement for granting a patent. Forcing the inventor to spend real money to create that which was thought up would both encourage commercialization -- pushing the invention to the prototype stage -- and discourage indiscriminate legal land-grabs with blankets of frivolous patents.
I don't disagree that this is a good idea, however I don't think it would help a whole lot for some of these patents, as they can be done purely in software, using off-the-shelf hardware. As such, the cost to create a working prototype for such an invention is negligible.
One of my former employers decided to patent a few software constructs I invented. One of them can be implemented as a working model in as little as a dozen lines of code. Not much of an added barrier there.
If it's the game that everyone is expecting then, yes.
I'm assuming by "everyone" he means the people developing the game, so the translation is "We aren't far enough into development to have done any real play testing, so we don't know if it's any fun to play yet.
For us it's about making a proper impact on the platform. It has to be something with huge significance, so we won't be rushed.
In other words, the key to the product isn't whether or not it's a good game in its own right, but whether or not it will sell XBox 360's. This makes it sound like game development has been co-opted by the hardware division accountants. I'm not sure if this is a such a good thing or not.
Yaz.
Re:yep, great benchmarks, but lacking in features.
on
MacBook Pro Benchmarks
·
· Score: 2, Informative
it HAS a FW400 port. it just doesnt do FW800 mode. its a complete mystery why that feature was so hard to add. it certainly wasnt space.
You're right -- it's the fact that no controller chipset from Intel supports FW800 that is the reason.
Apple went with Intel-based systems, including the chipset. Intel, so far as I've been able to determine through their website, has FW400 support in their chipsets, but no FW800. Adding a custom FW800 chip to the system would be non-trivial (as it's more than just space to drop in a chip -- you have to be able to connect it to the system bus somehow).
Yaz.
Re:yep, great benchmarks, but lacking in features.
on
MacBook Pro Benchmarks
·
· Score: 1
Do people still use AV outs on a notebook? Every projector I've seen in the last several years had DVI/VGA hookups.
Get your laptop out of the boardroom once in a while, okay?:). I use composite and S-Video out all the time, often to play videos and video blogs I've downloaded off the net on my TV.
Of course, I do so using the Apple mini-DVI to Composite/S-Video adapter. I don't need a million-and-one ports built into my PowerBook.
Yaz.
Re:yep, great benchmarks, but lacking in features.
on
MacBook Pro Benchmarks
·
· Score: 1
Especially when previous generations had this standard. technology is supposed to evolve, not de-volve.
Look, like it or not very few Mac users have ever used the FW800 port. I have both a 12" PowerBook G4 and a PowerMac G5. I have a few FW400 devices, but not a single FW800 device. If I had FW800 on the PowerBook, about the only use it might be put to would be to transfer very large data files between the PB and the PM.
This certainly isn't the first time Apple (or any other laptop maker for that matter) removed ports from their system. I doubt that even 1% of PowerBook owners use their FW800 ports. The majority will live just fine without it in this generation of systems.
Nobody has ever said that the removal of FW800 in the MacBook Pro line is final. It could still make its appearance in the 17" model (or whatever size might replace the 17" model -- as Apple hasn't announced anything yet, I'm not going to assume anything). It may just be a matter of getting Intel to support FW800 in its board controller chipsets used in the new system. Whatever it is, it's hardly the end of the world for most Mac owners.
Yaz.
Re:yep, great benchmarks, but lacking in features.
on
MacBook Pro Benchmarks
·
· Score: 1
lets see here, what was it again, no firewire 800 for one thing, that's standard on powerbooks
It was standard on the 15" and 17" models, but has never been available on the 12" model. And somehow, we've survived.
Besides which, for those few who need it, I'd imagine a slot-card for the new MacBook Pro that features FW-800 will be available in the near future.
Care to point out where I even mentioned Gnome? I was talking about generic OSS project naming issues, and why many OSS projects choose relatively strange names, and my thoughts on what the strategy should be.
Have you even tried a little thing I like to call reading comprehension?
It could easily be toggled on or off as a config option for any given distro. It could, in short order, put an end to my biggest superficial gripe for linux apps, the goofy, confusing names (and perhaps even remove some of the damn Gs and Ks preceeding nearly EVERY application in my menus...come on, devs, I understand 'brand loyalty', but give it a break).
Well, just because I can understand why some projects may name themselves in an obscure way, isn't to say that I agree with it. There is a happy in-between here -- would it really have hurt them to append a descriptive word to the end? Names don't have to be just one word, and many companies will attach a "branded" word to a "descriptive" word to make up their product name. OSS projects can do the same, but all too many don't, be it out of fear, or thinking they can make a name for their project being being different.
While I don't disagree that a lot of OSS software uses poor naming onventions, as an OSS developer myself, I can understand the reasons behind it.
Let's face it -- the obvious descriptive names are typically already taken. OSS developers want to write software -- they don't want to have to spend a lot of time doing name searches in order to ensure they aren't infringing on a trademark used by some tiny software house out in BF Nowhere, and they typically don't have the resources to fend off a legal attack. Thus, the tendancy these days is to pick (or make up) some sort of really obscure name that hopefully isn't going to attract negative attention from litigation-happy corporate lawyers, and then hopefully make a name for yourself.
Naming is difficult, even within the corporate world. But at least within the corporate world you have people who can do research on existing trademarks, and will hopefully come up with a suitable name for your new product -- and then have the lawyers to fight it as necessary. OSS projects don't have such resources.
Just take a look at your own example -- "Rendevous". Apple was forced to change the name to "Bonjour" due to trademark infringement with another company.
If Apple, with its bevy of lawyers and billions of dollars, can run into such a problem, what is the poor OSS developer to do? Picking some obscure name that nobody is likely to call their product is a good (but hardly guaranteed) way to avoid the problem in the first place.
I guess the "young 'uns" around here forget that having a definitive end state in a game hasn't always been the case. For a very long time, video games were simply set-up to see how far you could go, and who could get the highest score in a repetitive system that simply became more difficult as time progressed (usually by simply running faster). Games were often as much about concentration and a test of reflexes, with a bit of path planning here and there, and rarely had any semblance of story. You just kept playing, trying to get your name up on the high score list, knowing that the only end was when your last life was consumed (or the last of your quarters:) ).
Apple is taking advantage of their monopoly position disallowing the playing of itunes purchased music on non iPod players. This means if you bought music for your iPod.. you have to stick to iPod or lose the ability to transport your music?
The technical answer is "no". You can still transport your music to various Apple-blessed devices (like the Motorola ROKR), or to any system that runs iTunes. It doesn't have to be on an iPod.
Of course, you can always burn your iTMS purchased music to a standard audio CD, and then do whatever you want with it. The music will play on any CD player, and can be re-ripped in whatever format you like (although I would suggest a lossless format).
Plus when your HDD dies.. you cant regain your music.
The music will still exist on your iPod, and can be retrieved. You can't retrieve it through iTunes itself, but the music is there in a hidden directory tree.
Of course, data loss is data loss, and isn't unique to music. Backups are important. Apple's Backup software has a built-in backup plan specifically to backup your purchased iTunes Music.
Furthermore, because Fairplay DRM is closed.. if you are a band and want to sell your music (with DRM).. you have to do it on the iTunes store.. or your music will not have the protection of DRM if it's to be put on iPods (iPod owners being a massive marketshare.. this is essential for success). The alternative is DRM free mp3.. but then you lose the ability to protect your music. I hate DRM as much as the next guy.. but this isnt helping the situation to have Apple doing this.
Uh, no. While I've never seen the contract artists have with iTMS, from what I understand it is not exclusive. Artists are still allowed to license their music to other services, which use other DRM schemes. So no, it's not Fairplay or the highway -- if you're the copyright holder of the music, you can use whatever additional DRM schemes with other providers for other players if you want.
Maybe someone would be nice enough to make an interface for PC gamers like me?
This hasn't been a problem for the existing PlayStation 2 for quite some time -- it has USB ports, and quite readily supports USB mice and keyboards.
Where the problem comes in is that not all games support them as input -- indeed, very few do. This makes sense in some areas, as many PS2 games are designed with PS2 input in mind. Games ported from the PC world to the PS2 however generally do benefit from keyboard/mouse input, and this is where games which don't support them for input are a real PITA.
So the current PlayStation 2 doesn't have any hardware limitations that make this impossible -- it's been possible since day 1, and I've had a mouse and keyboard attached to my PS2 for several years now. What is needed is more users with such a set-up, to put pressure on game developers to ensure such input options are viable in more games (where it makes sense to do so).
Slashdot Mirror
I'm admittedly guessing, but I think that figure probably includes a whole lot of wireless technologies, not all of which are available to the average consumer. Yes, it includes cell technologies (GPRS being a completely acceptable -- if not hugely expensive -- way of accessing the Internet) -- cell technologies probably make up the great bulk of that figure. However, there are fee-based WiFi Hotspot providers here in Canada (generally in the larger centres), so they probably get counted too (such providers typically only provide service in specific venues -- for example, Bell AccessZone, which provides WiFi service in the Air Canada Centre, and in VIA Rail first class lounges (and on in first class sections of the Toronto - Montreal corridor trains).
It may also count satellite-based Internet, and could also possibly include microwave uplinks available to corporations. Without a breakdown it is difficult to know -- it appears to me that they're just throwing out a Really Big Number for investors to chew on. After all, who doesn't want a slice off of a Really Big Pie?
Yaz.
The Intel iMac is much faster than the old G5s when it comes to raw processing power, however that presumes that the software you want to run is available for Intel Mac. I'm sure there are a lot of design houses out that which rely on Photoshop and other graphic design and video/audio editing software which hasn't been ported to Intel OS X yet, and which are in need of new machines.
Apple can't afford to drop all of the G5-based systems until the software that drives the sales of their higher end systems is made Universal.
Yaz.
I'm quite aware of how to properly profile memory for Java applications, and yes, there is a 20MB difference in actively used memory. The virtual memory claimed is siginificantly higher than what I quoted -- where it's using ~35MB of real memory, the process is claiming a whopping 453MB of virtual memory (which of course isn't allocated at all, and thus doesn't really affect much of anything performance or RAM wise). Opening all four possible dialogs at once bumps that memory usage up to closer to 50MB.
I have a pile of Java memory profiling tools that all agree with this memory usage assessment. Now it's possible that the low level implementation on Mac OS X is more hungry than on some other platforms, but in my testing this is relatively equivalent to running it on Linux and Windows.
Sorry, but Swing is memory hungry. It tends to show in complex applications, which is one reason why I've kept the jSyncManager as simple as possible in terms of GUI.
Yaz.
I have asked my users, and they tend to be surprised at how fast the jSyncManager is. At one time it was measurably faster than Palm's own HotSync Manager for Windows -- nearly 50% faster in some tests. And the jSyncManager is 100% pure Java. And the parsing code for the protocol stacks and data types is pretty complex. We've had users running this code on old Pentium-class systems, and the execution speed is still on par with native solutions.
So yes, I've asked my users, and they're typically surprised that Java can be so fast. The key is having a developer who knows how to optimize code, with a sound design. Doing a lot of the heavy lifting work yourself doesn't hurt either (i.e.: not relying on a lot of external frameworks), as does using as much parallelization as possible.
Hav eyou tried Jake2, the pure Java version of Quake 2? I have no speed issues playing it on my 1.33Ghz PowerBook -- it works like a champ.
Sorry, but Java speed complaints are mostly bunk. Swing does have some performance issues (although this can differ from platform to platform), but Java as a whole is quite fast. You simply have to have developers who know what they're doing when it comes to optimization and overall program design to make the most of it.
Yaz.
Are you new around here? ;)
Admittedly, I use Swing. I don't avoid it because of its memory requirements, but they are a source of continued concern to me. Admittedly, the issue doesn't get as much attention these days as RAM continues to become ever more inexpensive, but there is still serious room for improvement. Read my other posting here on this subject for some examples.
Swing is flexible, and can create some nice GUIs. I don't like how much coding this requires (as I've mentioned elsewhere in this thread, Sun really needs to look at how Apple has solved the GUI design issue with Interface Builder, where instead of trying to create source code that has to be compiled to generate your UI, it gets serialized at design time, and deserialized at runtime (which has the added benefit that you can modify your GUI without the need for a recompile)), and I really don't like how quickly Swing can chew up RAM. Yes, I have a gig and a quarter of RAM, but no, I'm not in a hurry to fill it up as quickly as I possibly can either. I have yet to see a single platform where Swing wasn't a memory hog.
Yaz.
I agree that there have been improvements, but I'm sorry -- I do think it's fair to continue to take Sun to task for this still.
A quick example -- the jSyncManager, my most popular OSS application. It can be run in either GUI or console mode. In both, the engine code is identical -- only the user interface differs. Firing it up in GUI mode uses about 35MB of RAM on my Mac OS X 10.4.5 based PowerBook. Firing it up in console mode uses ~15MB of memory.
That's a 20MB difference, and that is just after start-up. The GUI has a single window, with three menus, and a total of 11 menu items. There are NO widgets in the window -- instead it just has a graphic (it's meant to be run minimized -- the menus allow access to help, configuration items, and the log window). And yet that uses 20MB.
Activating every menu item that bring up a GUI dialog once, with the exception of the Help subsystem (which uses JavaHelp) brings it up to ~45MB of memory usage. Bringing up everything including JavaHelp once causes it to use ~55MB of memory. That is 40MB of GUI, and it is all absolutely trivial stuff -- excluding JavaHelp, it's probably less than 50 widgets all together.
True -- I have 1.25GB of RAM in my system, so 40MB is barely even noticed. Still, this is an absolutely trivial GUI (the complexity is in the data synchronization engine -- again, this application is meant to be a "fire-and-forget", run it in the background program which handles PalmOS data synchronization, and doesn't typically require any user input other than configuration).
For a more complex comparison, I fired up "Tapear", a clinical document management system that is part of another Open Source project I work on known as OpenTAPAS. It has only one window, but has hundreds of widgets of all types in it, with multiple tabs for a whole variety of different view types. It doesn't have much of anything in terms of an "engine", as it retreives all of its data from a remote database. After loading it up and opening up a single patient, it uses 80MB of RAM -- more than even my entire IDE (Xcode) uses by 25MB.
(I should note that all the above tests were done with the latest release version of Java 1.5 for Mac OS X (PPC)).
One more example -- Limewire 4.9 uses ~75MB of RAM with no transfers.
Sorry, but Swing is still quite memory hungry. Can you imagine running all of your applications as Java applications? Improvements are being made, but I think there is room for further improvements in this regard.
Yaz.
It's not part of the Java standard from Sun. That isn't to say that SWT itself doesn't conform to its own defacto SWT standard -- it's just not part of the Java standard. It is my understanding that legally, IBM can't advertise SWT as being "Java", and can't even technically call Eclipse a Java IDE (even though it does the job just fine).
Sun needs to take a look at what Apple has done with Interface Builder and Cocoa. It should then replicate a similar system in Java for designing and describing Java GUIs. Now that Java 1.5 has java.beans.XMLEncoder available, this should be significantly easier for them to accomplish.
GUI development in Java is still painful and problematic. Which is too bad, as I'm actually a proponent of Java on the desktop (although IMO only Apple has got this right, with their JAR Bundler tool, such that you can distribute a Java application to users such that it appears to them to be just like any other application -- they never have to be even be aware that it's a Java application).
Yaz.
You are, of course, quite correct. It has just been one of those days, I suppose :P.
Yaz.
That hardly answers the original question -- it's true, but it doesn't answer the statement in question. That would be like saying:
The reason why there are three toolkits is simply: originally, Sun developed AWT. AWT was introduced with Java 1.0 as a way to obsfucate the drawing of common GUI widgets on a variety of platforms, using the native widget set. Unfortunately, this was problematic for many platforms, and wasn't very flexible.
Thus, Sun developed Swing. It supported more widgets, and did a lot of its own drawing in order to appear and generally layout the same across different platforms.
Swing, unfortunately, has some design limitations, not the least of which is that it is very memory hungry. When IBM decided to "port" VisualAge for Java from being a Smalltalk-based product over to using Java, they found that Swing wasn't up to the task, so they decided to develop their own widget toolkit, called SWT. SWT wasn't exactly intended for use outside Eclipse, mind you -- it's just that many developers decided to use it as such.
So we're left with a bit of a GUI mess on our hands in the Java world -- one I really wish would be fixed. Swing works, but it can be slow and memory intensive. SWT is non-standard, and requires a platform-specific module which users may not already have installed (which means either you have to tell them to download and install it, or you have to create a bunch of installers for different platforms to allow them to run your SWT-based application).
That is why we have thre different toolkits. For all intents and purposes, the bulk of AWT is deprecated and shouldn't be used for its widgets. It is simply difficult to get rid of due to the number of legacy applications out there which are still using it, and which will probably never be updated to use Swing.
And then there is Cocoa-Java...
Yaz.
You said it. I'm glad I'm not the only one.
It looks to me like Corel Cache can be Slashdotted as well. Indeed, the only time I ever find that Corel Cache helps me to read a story that /. links to is when someone submits the Corel Cache link, and I can then go to the original story that is supposed to be cached, because the rest of /. is hammering Corel Cache instead.
Corel Cache doesn't have a special "Bandwidth of the Infinite" spell it can cast when the /. hordes descend upon a site.
Yaz.
Yes, but you don't have to create a fully working product in order to have a "working model" for a software patent. All that you would have to do is create something simple which demonstrates the invention being patented in effect.
I've done it. Like I said, one of my previous employers decided to file patents in two countries for two "inventions" I created which working there. One of them I came up with one night at home, while watching TV. It can be demonstrated in less than 12 lines of code. Took 5 minutes to think up, and 5 minutes to implement a fully working demonstration of the invention in action. It took orders of magnitude more time and effort on the legal side to file the patent than it did to invent and implement in the first place.
(I should note here that the invention mentioned above has never, to my knowledge, even been used in a shipping product. It wasn't "invented" in conjunction with the project I was employed to work on either. It was something I came up with working on a personal project on my own time that I happened to mention to my manager during a friendly conversation. He thought it was novel enough to bring in the patent team, and they ran with it).
You don't patent "Windows". Software patents are typically relatively simple ideas that anyone in the field could have thought up if they had encountered a similar problem, which is one reason why so many people are against software patents in the first place. The actual process of "invention" for my first patent cost my employer nothing. The implementation of a working model likewise cost them nothing. And even if I had invented and implemented the working model on work time, it would have taken me about an hour.
I don't think a working model of Amazon's "one click purchasing" would take all that long to think up and create a working model either. Again, "working model" doesn't necessarily mean "put into a big, massive shipping product", and as such the costs of creating such a working model in software can be kept quite a bit lower than a hardware invention.
Yaz.
I'm with you -- the Intellivision controller doesn't belong on that list. Sure it was different from what we're used to today, but in general, it worked quite well. So much so that my Intellivision still works just fine, all these decades later.
My only complaint about it would be the overlays. Not the idea of the overlays -- just how the actual overlays were made, and how the top laminate over time would peel up, making them really hard to insert.
I think I might have to get my Intellivision out of storage and hook it up this weekend for some really old school gaming. Utopia, here I come!
(And yes, I do have "Tron: Deadly Discs" :) ).
Yaz.
I don't disagree that this is a good idea, however I don't think it would help a whole lot for some of these patents, as they can be done purely in software, using off-the-shelf hardware. As such, the cost to create a working prototype for such an invention is negligible.
One of my former employers decided to patent a few software constructs I invented. One of them can be implemented as a working model in as little as a dozen lines of code. Not much of an added barrier there.
Yaz.
I'm assuming by "everyone" he means the people developing the game, so the translation is "We aren't far enough into development to have done any real play testing, so we don't know if it's any fun to play yet.
In other words, the key to the product isn't whether or not it's a good game in its own right, but whether or not it will sell XBox 360's. This makes it sound like game development has been co-opted by the hardware division accountants. I'm not sure if this is a such a good thing or not.
Yaz.
You're right -- it's the fact that no controller chipset from Intel supports FW800 that is the reason.
Apple went with Intel-based systems, including the chipset. Intel, so far as I've been able to determine through their website, has FW400 support in their chipsets, but no FW800. Adding a custom FW800 chip to the system would be non-trivial (as it's more than just space to drop in a chip -- you have to be able to connect it to the system bus somehow).
Yaz.
Get your laptop out of the boardroom once in a while, okay? :). I use composite and S-Video out all the time, often to play videos and video blogs I've downloaded off the net on my TV.
Of course, I do so using the Apple mini-DVI to Composite/S-Video adapter. I don't need a million-and-one ports built into my PowerBook.
Yaz.
Look, like it or not very few Mac users have ever used the FW800 port. I have both a 12" PowerBook G4 and a PowerMac G5. I have a few FW400 devices, but not a single FW800 device. If I had FW800 on the PowerBook, about the only use it might be put to would be to transfer very large data files between the PB and the PM.
This certainly isn't the first time Apple (or any other laptop maker for that matter) removed ports from their system. I doubt that even 1% of PowerBook owners use their FW800 ports. The majority will live just fine without it in this generation of systems.
Nobody has ever said that the removal of FW800 in the MacBook Pro line is final. It could still make its appearance in the 17" model (or whatever size might replace the 17" model -- as Apple hasn't announced anything yet, I'm not going to assume anything). It may just be a matter of getting Intel to support FW800 in its board controller chipsets used in the new system. Whatever it is, it's hardly the end of the world for most Mac owners.
Yaz.
It was standard on the 15" and 17" models, but has never been available on the 12" model. And somehow, we've survived.
Besides which, for those few who need it, I'd imagine a slot-card for the new MacBook Pro that features FW-800 will be available in the near future.
Yaz.
Care to point out where I even mentioned Gnome? I was talking about generic OSS project naming issues, and why many OSS projects choose relatively strange names, and my thoughts on what the strategy should be.
Have you even tried a little thing I like to call reading comprehension?
Yaz.
Well, just because I can understand why some projects may name themselves in an obscure way, isn't to say that I agree with it. There is a happy in-between here -- would it really have hurt them to append a descriptive word to the end? Names don't have to be just one word, and many companies will attach a "branded" word to a "descriptive" word to make up their product name. OSS projects can do the same, but all too many don't, be it out of fear, or thinking they can make a name for their project being being different.
Yaz.
While I don't disagree that a lot of OSS software uses poor naming onventions, as an OSS developer myself, I can understand the reasons behind it.
Let's face it -- the obvious descriptive names are typically already taken. OSS developers want to write software -- they don't want to have to spend a lot of time doing name searches in order to ensure they aren't infringing on a trademark used by some tiny software house out in BF Nowhere, and they typically don't have the resources to fend off a legal attack. Thus, the tendancy these days is to pick (or make up) some sort of really obscure name that hopefully isn't going to attract negative attention from litigation-happy corporate lawyers, and then hopefully make a name for yourself.
Naming is difficult, even within the corporate world. But at least within the corporate world you have people who can do research on existing trademarks, and will hopefully come up with a suitable name for your new product -- and then have the lawyers to fight it as necessary. OSS projects don't have such resources.
Just take a look at your own example -- "Rendevous". Apple was forced to change the name to "Bonjour" due to trademark infringement with another company.
If Apple, with its bevy of lawyers and billions of dollars, can run into such a problem, what is the poor OSS developer to do? Picking some obscure name that nobody is likely to call their product is a good (but hardly guaranteed) way to avoid the problem in the first place.
Yaz.
Neither did Pac Man for that matter.
I guess the "young 'uns" around here forget that having a definitive end state in a game hasn't always been the case. For a very long time, video games were simply set-up to see how far you could go, and who could get the highest score in a repetitive system that simply became more difficult as time progressed (usually by simply running faster). Games were often as much about concentration and a test of reflexes, with a bit of path planning here and there, and rarely had any semblance of story. You just kept playing, trying to get your name up on the high score list, knowing that the only end was when your last life was consumed (or the last of your quarters :) ).
Yaz.
Yeah, but apparantly some people are only hearing about it now.
Yaz.
The technical answer is "no". You can still transport your music to various Apple-blessed devices (like the Motorola ROKR), or to any system that runs iTunes. It doesn't have to be on an iPod.
Of course, you can always burn your iTMS purchased music to a standard audio CD, and then do whatever you want with it. The music will play on any CD player, and can be re-ripped in whatever format you like (although I would suggest a lossless format).
The music will still exist on your iPod, and can be retrieved. You can't retrieve it through iTunes itself, but the music is there in a hidden directory tree.
Of course, data loss is data loss, and isn't unique to music. Backups are important. Apple's Backup software has a built-in backup plan specifically to backup your purchased iTunes Music.
Uh, no. While I've never seen the contract artists have with iTMS, from what I understand it is not exclusive. Artists are still allowed to license their music to other services, which use other DRM schemes. So no, it's not Fairplay or the highway -- if you're the copyright holder of the music, you can use whatever additional DRM schemes with other providers for other players if you want.
Yaz.
This hasn't been a problem for the existing PlayStation 2 for quite some time -- it has USB ports, and quite readily supports USB mice and keyboards.
Where the problem comes in is that not all games support them as input -- indeed, very few do. This makes sense in some areas, as many PS2 games are designed with PS2 input in mind. Games ported from the PC world to the PS2 however generally do benefit from keyboard/mouse input, and this is where games which don't support them for input are a real PITA.
So the current PlayStation 2 doesn't have any hardware limitations that make this impossible -- it's been possible since day 1, and I've had a mouse and keyboard attached to my PS2 for several years now. What is needed is more users with such a set-up, to put pressure on game developers to ensure such input options are viable in more games (where it makes sense to do so).
Yaz.