The difference is significant, actually. For example, the Aqua look and feel has been considered one of the most complete Swing L&F engines. However, the file chooser dialog looks the same in a Swing application running in Panther as it did running in Jaguar. And in fact, it does not resemble neither Jaguar nor Panther's file open dialog.
The new implementation of tabs (NSTabView/JTabbedPane) in Panther is a row of buttons instead of tabs. The buttons do appear in a Swing application using JTabbedPane, _but_, the inside of the tabbed pane is only partially shaded when it's supposed to be entirely. This looks terrible since it's partially native but not-quite-there.
Eclipse's SWT has neither of these problems, nor does it have dozens of other problems that Swing has in Aqua.
I have used Subclipse. It is very good and mostly feature complete. Not quite perfect, but much better than any Subversion integration available for Netbeans based off their generic version control system. At least that I've seen.
We stopped whining about Chretien because he's leaving office. In a few months time, we will begin whining about the dictator Paul Martin and his evil plans to invade the sovereign province of Alberta with his army of Quebecois.
I have a better backup system than you could ever dream of.... It takes time to restore those images from tape.
I dream of a backup system where data can be restored instantly, and an infinite number of revisions of an infinite amount of data can be stored on a device the size of my little toe. And these little-toe sized devices are so cheap that I run off a hundred copies of them every night, and store them in different places across the world. And they're secu...
I think you get the idea. I can dream of a lot better than tape.
Yes, you are missing something. A kilogram is a unit of mass, not weight. Mass is independant of gravitational forces, always measured relative to other known masses. Weight is measured based upon force and newtons. A scale in your bathroom measures weight with a spring, and hence is susceptible to gravitational shifts. A mass balance measures mass with a set of known masses, which are constant regardless of the gravitational forces (though a balance, as a tool, doesn't work too well without some gravitational forces).
I think the odds against this are staggering, since a game with 5 years of development is going to have higher expectations than anything up to but excluding Master of Orion 3.
Why did you have to bring up the painful memory of that horrendous failure of a computer game? I drove across the city at way illegal speeds to pick it up the second I found out a copy had hit the shelves. My disappointment still makes me growl at the box sitting on my shelf. I hate you. I hate all of you. Especially you, MOO3! I'll kill you! Gaaarg!
You don't outgrow SourceForge. Look at some of the projects hosted there - ViM, Python, several Kernel patches, and much more. Some of the projects there are open-source behemoths, with millions of users.
Yeah, but at least one of those projects is looking for other hosting. There has been discussion on the python-dev mailing list lately about moving away from SourceForge.
Personally, I think that SourceForge is a great tool for small developing projects. It is pretty versatile and works pretty well. However, for a project as large as Python, a more customized and set of development tools may be able to help development. And although SourceForge works pretty well, it's not perfect. Anonymous CVS access only rarely works lately, for example.
I hate VSS with a passion. We've been using it as our Source Control system for many many years where I work. Lately, we get corrupt databases about every week or so. How does it happen? Usually people are connecting to VSS from home through a VPN, and the tunnel breaks in the middle of a checkin to the database. Since VSS's database is managed by the client, if it fails halfway through it is easy for the database to get corrupted. Additionally, the entire VSS database is writable for our entire development staff, hence no access control at all.
It is easy to fix a lightly corrupted VSS database with their dumb tool. Who the hell wants to do that, though?
So once upon a time, the database got corrupted and wouldn't magically fix. A couple of us showed off CVS to our manager and convinced him, eventually, to give CVS a try. We had it integrated on every developer's box through Jalandi Igloo, and moved all the projects over to a CVS server.
The experiment failed, and we're back on VSS now. Why did it fail? The developers found that Jalandi Igloo was about an order of magnitude slower than VSS's visual studio integration. Personally, I didn't have any problem with it. Occasionally Igloo would hang for a few minutes during a simple operation like a commit or a get. It was a pain, I'll admit, but we got many things out of it: A source control database that was text based and easily correctable, a source control system with sane branching, and the happiness of moving away from VSS. But the developers complained, some of them saying that utter frustration at CVS' speed was causing them to loose 100% of their productive time because they were so frustrated. [What dicks, eh? How can a slow source control system keep you from coding at all?] Others complained of more realistic productive time losses.
Anyways, we're back on VSS now. So now, when I go to edit a file that isn't checked out, sometimes it takes 5 minutes to check it out through visual studio. It just depends on who else is accessing the database at that moment, and how it gets locked. *le sigh*.
On a related note, I highly recommend Subversion as a source control system rather than CVS these days. The Subversion website could really use some work on becoming focused towards people who are interested in the software, rather than their developing of it, though. But I don't know of any visual studio integration worth mentioning, yet.
The reason why new computers seem much faster is not because of the higher clock speed per se, but because systems are having to literally chew through gigabytes of bloat borne of incompetence and for-profit-motive intentional bad-design for the purposes of encouraging new computer purposes.
Gigabytes of bloat in software is not born of incompetence. Well, maybe a little. Programmers developing that software keep making software easier to write by adding new technologies and developing new programming libraries. For example, Gnome and KDE have grown in size as libraries like gconf have been added to make software easier to develop.
Windows 3.11 was small and from a user's point of view it may have done 95% of the things that average people do with computers today. But no software developer in their right mind would prefer to write new software for Windows 3.11 rather than for Windows XP. Since those days, common libraries like MS's foundation classes have become more bug-free, new common controls have added functionality to the most basic of objects that previously would take days to write yourself, and technologies like COM and ActiveX have permitted modular and reusable components where previously code would have to be re-written and re-developed for every application.
Someday, I'll be able to write a highly graphical game like Doom 3 in a beautiful language like Python.:)
Really, I think that higher powered computers allow programmers to write software more easily. When you need a piece of software, and an in-house programmer can write it in a few hours rather than a few weeks, but only if you have a 3 GHz machine to run it on... that's muchly worth while. It's possible.
I was reading this article and thinking to myself two seperate thoughts: "Well, that's odd...", and "Uh huh... who cares?".
I work for a non-IT consulting company. Me and the team of ~20 developers here write software for engineers to use in petroleum engineering consulting. All of the software, 100% of it, it developed for Windows. I look around and see 0% Linux developers, and 100% Windows developers. But, alright, obviously my survey is baised. However, I only know one single developer here who has ever used Linux, or any operating system other than Windows. The two of us both have our shiny Powerbooks sitting next to our desktop computers while we work, for e-mail and web browsing and the occasional graphics work. I think the statistic that only 50% of developers use Windows is rather odd... since 95% of users are using Windows. Are there huge fields of programmers who develop cross-platform software and trust that it will work in Windows without testing it? Or develop server-side software only, which never sees a user?
Secondly, who cares. I look at a project like Mozilla, and I can see that a lot of the developers are on non-Windows OSes. But I think the majority of even Mozilla users are Windows users. I advocate Mozilla to my friends and family, installing it on computers and replacing IE/OutlookE, and everyone is happy. They're using Mozilla and Windows, and I think this is highly common. FTL even replaced the 'INTERNET' icon on his grandmother's computer with Mozilla, and I believe the only comment she ever had was about the cute dragon. Developers may be using non-MS platforms, but they're still developing for users who are in Windows. Right? Or is half the world using Linux on their desktop, and I'm in some la-la land?
I concur entirely. This was basically the same experience that I had in buying my TiBook, and one of my friends just concluded in buying a new 12" Powerbook.
Apple's advertising is as good as it gets, and people want their products. Physical stores exist so people can check to make sure the product really exists, and really looks as damn sexy as they thought it would.
> Humans are like breakfast cereal: "Contents may settle during shipping." Even if the bus is full at one stop, you can always sqeeze another body on by the time it reaches the next stop.
Were this the case, then they would be able to fit more bodies on the bus. However, it was clearly stated that they cannot fit any more bodies on the bus. Therefore, they cannot fit any more bodies on the bus.
I can accept that the bus driver may not know this until after he stops and opens the door, and nobody can get on. But he could blow by a half dozen more stops after he's tried one and nobody could get on.
I'm sure you're aware that in the cold of winter, people get quite irate when a bus passes their stop and doesn't pick them up, but it's always bugged the hell out of me that they do. I have faith in the educated and experienced bus driver who must have a reason for not stopping.
If they can't fit any more bodies on the bus, and nobody wants to get off, why would they stop? So that the bus driver can waste valuable time opening the door and closing it, with nothing accomplished?
*sigh*. Yeah... or at least we should hire some blocks of metal, put skates on them, and leave them on the ice. I think it'd be an improvement. The team might not win, but I bet it won't screw up as much.
Check out the University of BC's Public Knowledge Project's Open Journal Systems. I've heard good things about it. It runs on PHP and MySQL, and should be pretty easy to setup. They have a demonstration online you can take a look at.
Keep in mind those politicians who aren't interested in technology are there because you put them in power. (Well, at least in the states...) If you want more technically competant congressmen, some technically competant people need to quit their jobs as IT/IS folks and start campaigning instead. I personally would prefer that they stay disinterested in technology as long as they aren't savvy in the field. That's how we get things like the DMCA. Well, rich corporations buying legislation helps there too.
Don't I hear half of slashdot whining about being unemployed all the time too? Of course, if you're unemployed, you may be overly incompetant to be a politician... well, let's be realistic, it's hard to be more incompetant than the current politicians.;)
I've been developing a Mozilla-based application component since August 2001. It's an HTML-rendering MOO client, and recently I've been pouring some 90% of my free time into working on it.
75% of that 90% of my free time lately has been updating the application to newer standards which have come into place since August 2001. For example, the Navigator/Mail/Editor/Chatzilla options used to be on the 'Tasks' menu in Mozilla, and were moved to the 'Window' menu around 1.0rc1. Bang, suddenly my application stops working properly, and less importantly, stops being a friendly component which works like all the others. A patch from a friend moved just about everything over to the 1.0rc1 way of doing things, and all was fine. Not everything worked flawlessly, though. The 'MOO Client' menu option didn't have an associated key visible, and the 'Window' menu inside MOOzilla didn't have any visible keys. The menus inside the application had long since stopped graying-out/disabling properly depending on what you have selected in the window. Many hours of last weekend was spent fixing these problems by conforming to new command handler expectations, and so on. (Where 'new' means 'changed since 0.9.6'.;))
XUL is a wonderful tool. However, it runs dog slow on OS X. You don't have to take my word for it, just look at the Pheonix project. Pheonix is available for Windows and Linux, but not for OS X. Why? Because Chimera exists for OS X, which is faster (I'm using it right now) and integrates with the OS better. But... it doesn't support XUL. That's why it's faster. So where is my Mozilla application left? Stuck in the massive Mozilla suite when it's run in OS X. Mozilla, at startup, uses over 120 megs of RAM on my TiBook. Thank God for good VMs.
When initially writting MOOzilla, the XUL documentation was shit. The only place to go for any idea of how things really worked was deep inside the Mozilla source. And sure enough, this worked. The official XUL documentation at that time had sections which trailed off in 'blah blah blah' often because someone got bored of writting. I specifically remember it once read 'This is very important because blah blah blah'. Arrrg! How frustrating!
Mozilla is a powerful application development environment. XUL is a wonderful tool. Books like this one are going to make the world a better place for Mozilla component developers. And more cross-platform software developed with Mozilla makes the world a better place for users. Now... if only we can somehow apply this book heavily to the head of people who don't want to download Mozilla to try out an application, because they don't want to use it as a web browser. *sigh*.
I have used MFC serialization in the most bizarre and difficult ways. In normal usage, adding new data into an existing set of serialized data is really, really easy. Just make sure that every object you serialize stores it's own version number when you write it it out. Increment the version number when you make a change to the serialization out, and pay attention to the version number when you're reading in the object.
If you're creating a new version of your application, say re-writting the code from scratch, it is easy to write a set of classes that can read old product files and convert them into your new object structure. In fact, I've even written code that re-writes the runtime dynamic class names in a serialized data file just so it can be read in by a new generation piece of software.
The ability to make compound documents with MFC is unbelievably sweet. I was part of a development team which created a single unified file format with a compound document architecture that was readable by 5 different pieces of software. Each piece of software had it's own slot in the compound document to write their own specific data out. I could derive my own classes off the base data classes, and they would be runtime created by the serialization when reading files. It was the sweetest little file system ever.
Could it be done with XML? Yes. Would I prefer to work with XML? In principle, yes. Did I suggest that we use XML for a world-readable data export? Yes. But management would prefer to write up contracts with other companies to share data reading specs. And sure enough, that worked, and our products sold. So MFC serialization was sweet from a programmer's point of view, and was practical from management's point of view.
If the server is going to be needed for tasks that a 64 bit processor would help with, then an Itanium might not be a bad idea. However, I'd be surprised if it would be worth the cost unless you have very specific applications planned for the machine. I'd suggest that using the extra money to invest in a larger multiprocessor server might be more flexible and useful in the wide range of tasks that a server in a University lab is bound to be exposed to.
Of course, since I'm at Carleton, I'll say anything to try to stop U of Ottawa from having hardware I can't get my hands on.;)
As a co-author and currently sole developer of a Mozilla component application, I feel I'm qualified to voice an opinion on this. (MOOzilla being the application)
Mozilla is really damn cool. You can do some amazing things by combining existing Mozilla code with your application. For example, yesterday I discovered a way to dump an entire MOO/MUD session into an HTML file by using a function in nsContentAreaUtils.js. This was funky. It was not, however, exactly what I wanted, so I now need to write similar code myself. The point is that Mozilla is great...
But I can't see using it for anything that doesn't somehow relate to web browsing or networking. I know there have been efforts to do elaborate things like writting Office suites in Mozilla, but I don't think it's really feasible because the API availble through XPCOM is more geared towards this kind of web-based development. In MFC, for example, you have access to beautiful serialization and dynamic runtime creation and other nifty stuff that makes coding easy.
As for games, well, Transgaming's WineX is currently exceeding many people's expectations with regard to DirectX gaming on Linux. Heck, they had Warcraft 3 working within a couple weeks after it launched. Where's Warcraft 3 for OSX?
Slashdot Mirror
The difference is significant, actually. For example, the Aqua look and feel has been considered one of the most complete Swing L&F engines. However, the file chooser dialog looks the same in a Swing application running in Panther as it did running in Jaguar. And in fact, it does not resemble neither Jaguar nor Panther's file open dialog.
The new implementation of tabs (NSTabView/JTabbedPane) in Panther is a row of buttons instead of tabs. The buttons do appear in a Swing application using JTabbedPane, _but_, the inside of the tabbed pane is only partially shaded when it's supposed to be entirely. This looks terrible since it's partially native but not-quite-there.
Eclipse's SWT has neither of these problems, nor does it have dozens of other problems that Swing has in Aqua.
I have used Subclipse. It is very good and mostly feature complete. Not quite perfect, but much better than any Subversion integration available for Netbeans based off their generic version control system. At least that I've seen.
We stopped whining about Chretien because he's leaving office. In a few months time, we will begin whining about the dictator Paul Martin and his evil plans to invade the sovereign province of Alberta with his army of Quebecois.
I dream of a backup system where data can be restored instantly, and an infinite number of revisions of an infinite amount of data can be stored on a device the size of my little toe. And these little-toe sized devices are so cheap that I run off a hundred copies of them every night, and store them in different places across the world. And they're secu...
I think you get the idea. I can dream of a lot better than tape.
Yes, you are missing something. A kilogram is a unit of mass, not weight. Mass is independant of gravitational forces, always measured relative to other known masses. Weight is measured based upon force and newtons. A scale in your bathroom measures weight with a spring, and hence is susceptible to gravitational shifts. A mass balance measures mass with a set of known masses, which are constant regardless of the gravitational forces (though a balance, as a tool, doesn't work too well without some gravitational forces).
Why did you have to bring up the painful memory of that horrendous failure of a computer game? I drove across the city at way illegal speeds to pick it up the second I found out a copy had hit the shelves. My disappointment still makes me growl at the box sitting on my shelf. I hate you. I hate all of you. Especially you, MOO3! I'll kill you! Gaaarg!
Yeah, but at least one of those projects is looking for other hosting. There has been discussion on the python-dev mailing list lately about moving away from SourceForge.
Personally, I think that SourceForge is a great tool for small developing projects. It is pretty versatile and works pretty well. However, for a project as large as Python, a more customized and set of development tools may be able to help development. And although SourceForge works pretty well, it's not perfect. Anonymous CVS access only rarely works lately, for example.
I hate VSS with a passion. We've been using it as our Source Control system for many many years where I work. Lately, we get corrupt databases about every week or so. How does it happen? Usually people are connecting to VSS from home through a VPN, and the tunnel breaks in the middle of a checkin to the database. Since VSS's database is managed by the client, if it fails halfway through it is easy for the database to get corrupted. Additionally, the entire VSS database is writable for our entire development staff, hence no access control at all.
It is easy to fix a lightly corrupted VSS database with their dumb tool. Who the hell wants to do that, though?
So once upon a time, the database got corrupted and wouldn't magically fix. A couple of us showed off CVS to our manager and convinced him, eventually, to give CVS a try. We had it integrated on every developer's box through Jalandi Igloo, and moved all the projects over to a CVS server.
The experiment failed, and we're back on VSS now. Why did it fail? The developers found that Jalandi Igloo was about an order of magnitude slower than VSS's visual studio integration. Personally, I didn't have any problem with it. Occasionally Igloo would hang for a few minutes during a simple operation like a commit or a get. It was a pain, I'll admit, but we got many things out of it: A source control database that was text based and easily correctable, a source control system with sane branching, and the happiness of moving away from VSS. But the developers complained, some of them saying that utter frustration at CVS' speed was causing them to loose 100% of their productive time because they were so frustrated. [What dicks, eh? How can a slow source control system keep you from coding at all?] Others complained of more realistic productive time losses.
Anyways, we're back on VSS now. So now, when I go to edit a file that isn't checked out, sometimes it takes 5 minutes to check it out through visual studio. It just depends on who else is accessing the database at that moment, and how it gets locked. *le sigh*.
On a related note, I highly recommend Subversion as a source control system rather than CVS these days. The Subversion website could really use some work on becoming focused towards people who are interested in the software, rather than their developing of it, though. But I don't know of any visual studio integration worth mentioning, yet.
Gigabytes of bloat in software is not born of incompetence. Well, maybe a little. Programmers developing that software keep making software easier to write by adding new technologies and developing new programming libraries. For example, Gnome and KDE have grown in size as libraries like gconf have been added to make software easier to develop.
Windows 3.11 was small and from a user's point of view it may have done 95% of the things that average people do with computers today. But no software developer in their right mind would prefer to write new software for Windows 3.11 rather than for Windows XP. Since those days, common libraries like MS's foundation classes have become more bug-free, new common controls have added functionality to the most basic of objects that previously would take days to write yourself, and technologies like COM and ActiveX have permitted modular and reusable components where previously code would have to be re-written and re-developed for every application.
Someday, I'll be able to write a highly graphical game like Doom 3 in a beautiful language like Python. :)
Really, I think that higher powered computers allow programmers to write software more easily. When you need a piece of software, and an in-house programmer can write it in a few hours rather than a few weeks, but only if you have a 3 GHz machine to run it on... that's muchly worth while. It's possible.
#include
int main()
{
assert(0 != 1);
return 0;
}
I was reading this article and thinking to myself two seperate thoughts: "Well, that's odd...", and "Uh huh... who cares?".
I work for a non-IT consulting company. Me and the team of ~20 developers here write software for engineers to use in petroleum engineering consulting. All of the software, 100% of it, it developed for Windows. I look around and see 0% Linux developers, and 100% Windows developers. But, alright, obviously my survey is baised. However, I only know one single developer here who has ever used Linux, or any operating system other than Windows. The two of us both have our shiny Powerbooks sitting next to our desktop computers while we work, for e-mail and web browsing and the occasional graphics work. I think the statistic that only 50% of developers use Windows is rather odd... since 95% of users are using Windows. Are there huge fields of programmers who develop cross-platform software and trust that it will work in Windows without testing it? Or develop server-side software only, which never sees a user?
Secondly, who cares. I look at a project like Mozilla, and I can see that a lot of the developers are on non-Windows OSes. But I think the majority of even Mozilla users are Windows users. I advocate Mozilla to my friends and family, installing it on computers and replacing IE/OutlookE, and everyone is happy. They're using Mozilla and Windows, and I think this is highly common. FTL even replaced the 'INTERNET' icon on his grandmother's computer with Mozilla, and I believe the only comment she ever had was about the cute dragon. Developers may be using non-MS platforms, but they're still developing for users who are in Windows. Right? Or is half the world using Linux on their desktop, and I'm in some la-la land?
I concur entirely. This was basically the same experience that I had in buying my TiBook, and one of my friends just concluded in buying a new 12" Powerbook.
Apple's advertising is as good as it gets, and people want their products. Physical stores exist so people can check to make sure the product really exists, and really looks as damn sexy as they thought it would.
Yeah, sure, anything that takes 3 hours on a PC takes 5 hours on a Mac. Like watching a DVD.
> Humans are like breakfast cereal: "Contents may settle during shipping." Even if the bus is full at one stop, you can always sqeeze another body on by the time it reaches the next stop.
Were this the case, then they would be able to fit more bodies on the bus. However, it was clearly stated that they cannot fit any more bodies on the bus. Therefore, they cannot fit any more bodies on the bus.
I can accept that the bus driver may not know this until after he stops and opens the door, and nobody can get on. But he could blow by a half dozen more stops after he's tried one and nobody could get on.
I'm sure you're aware that in the cold of winter, people get quite irate when a bus passes their stop and doesn't pick them up, but it's always bugged the hell out of me that they do. I have faith in the educated and experienced bus driver who must have a reason for not stopping.
If they can't fit any more bodies on the bus, and nobody wants to get off, why would they stop? So that the bus driver can waste valuable time opening the door and closing it, with nothing accomplished?
*sigh*. Yeah... or at least we should hire some blocks of metal, put skates on them, and leave them on the ice. I think it'd be an improvement. The team might not win, but I bet it won't screw up as much.
Check out the University of BC's Public Knowledge Project's Open Journal Systems. I've heard good things about it. It runs on PHP and MySQL, and should be pretty easy to setup. They have a demonstration online you can take a look at.
Try Python.
Keep in mind those politicians who aren't interested in technology are there because you put them in power. (Well, at least in the states...) If you want more technically competant congressmen, some technically competant people need to quit their jobs as IT/IS folks and start campaigning instead. I personally would prefer that they stay disinterested in technology as long as they aren't savvy in the field. That's how we get things like the DMCA. Well, rich corporations buying legislation helps there too.
;)
Don't I hear half of slashdot whining about being unemployed all the time too? Of course, if you're unemployed, you may be overly incompetant to be a politician... well, let's be realistic, it's hard to be more incompetant than the current politicians.
I've been developing a Mozilla-based application component since August 2001. It's an HTML-rendering MOO client, and recently I've been pouring some 90% of my free time into working on it.
75% of that 90% of my free time lately has been updating the application to newer standards which have come into place since August 2001. For example, the Navigator/Mail/Editor/Chatzilla options used to be on the 'Tasks' menu in Mozilla, and were moved to the 'Window' menu around 1.0rc1. Bang, suddenly my application stops working properly, and less importantly, stops being a friendly component which works like all the others. A patch from a friend moved just about everything over to the 1.0rc1 way of doing things, and all was fine. Not everything worked flawlessly, though. The 'MOO Client' menu option didn't have an associated key visible, and the 'Window' menu inside MOOzilla didn't have any visible keys. The menus inside the application had long since stopped graying-out/disabling properly depending on what you have selected in the window. Many hours of last weekend was spent fixing these problems by conforming to new command handler expectations, and so on. (Where 'new' means 'changed since 0.9.6'. ;))
XUL is a wonderful tool. However, it runs dog slow on OS X. You don't have to take my word for it, just look at the Pheonix project. Pheonix is available for Windows and Linux, but not for OS X. Why? Because Chimera exists for OS X, which is faster (I'm using it right now) and integrates with the OS better. But... it doesn't support XUL. That's why it's faster. So where is my Mozilla application left? Stuck in the massive Mozilla suite when it's run in OS X. Mozilla, at startup, uses over 120 megs of RAM on my TiBook. Thank God for good VMs.
When initially writting MOOzilla, the XUL documentation was shit. The only place to go for any idea of how things really worked was deep inside the Mozilla source. And sure enough, this worked. The official XUL documentation at that time had sections which trailed off in 'blah blah blah' often because someone got bored of writting. I specifically remember it once read 'This is very important because blah blah blah'. Arrrg! How frustrating!
Mozilla is a powerful application development environment. XUL is a wonderful tool. Books like this one are going to make the world a better place for Mozilla component developers. And more cross-platform software developed with Mozilla makes the world a better place for users. Now... if only we can somehow apply this book heavily to the head of people who don't want to download Mozilla to try out an application, because they don't want to use it as a web browser. *sigh*.
As a matter of fact...
I have used MFC serialization in the most bizarre and difficult ways. In normal usage, adding new data into an existing set of serialized data is really, really easy. Just make sure that every object you serialize stores it's own version number when you write it it out. Increment the version number when you make a change to the serialization out, and pay attention to the version number when you're reading in the object.
If you're creating a new version of your application, say re-writting the code from scratch, it is easy to write a set of classes that can read old product files and convert them into your new object structure. In fact, I've even written code that re-writes the runtime dynamic class names in a serialized data file just so it can be read in by a new generation piece of software.
The ability to make compound documents with MFC is unbelievably sweet. I was part of a development team which created a single unified file format with a compound document architecture that was readable by 5 different pieces of software. Each piece of software had it's own slot in the compound document to write their own specific data out. I could derive my own classes off the base data classes, and they would be runtime created by the serialization when reading files. It was the sweetest little file system ever.
Could it be done with XML? Yes. Would I prefer to work with XML? In principle, yes. Did I suggest that we use XML for a world-readable data export? Yes. But management would prefer to write up contracts with other companies to share data reading specs. And sure enough, that worked, and our products sold. So MFC serialization was sweet from a programmer's point of view, and was practical from management's point of view.
If the server is going to be needed for tasks that a 64 bit processor would help with, then an Itanium might not be a bad idea. However, I'd be surprised if it would be worth the cost unless you have very specific applications planned for the machine. I'd suggest that using the extra money to invest in a larger multiprocessor server might be more flexible and useful in the wide range of tasks that a server in a University lab is bound to be exposed to.
Of course, since I'm at Carleton, I'll say anything to try to stop U of Ottawa from having hardware I can't get my hands on. ;)
As a co-author and currently sole developer of a Mozilla component application, I feel I'm qualified to voice an opinion on this. (MOOzilla being the application)
Mozilla is really damn cool. You can do some amazing things by combining existing Mozilla code with your application. For example, yesterday I discovered a way to dump an entire MOO/MUD session into an HTML file by using a function in nsContentAreaUtils.js. This was funky. It was not, however, exactly what I wanted, so I now need to write similar code myself. The point is that Mozilla is great...
But I can't see using it for anything that doesn't somehow relate to web browsing or networking. I know there have been efforts to do elaborate things like writting Office suites in Mozilla, but I don't think it's really feasible because the API availble through XPCOM is more geared towards this kind of web-based development. In MFC, for example, you have access to beautiful serialization and dynamic runtime creation and other nifty stuff that makes coding easy.
In the box, when you purchase W3.