Don't forget Digital's groundbreaking FX32 emulation software. FX32 allowed you to run x86 Windows software on Alpha NT. The cool part was that after running for a while in slow software emulation, FX32 went back through the x86 code and translated the hotspots into native Alpha code. It was not unusual for translated x86 applications to run faster under FX32 than they did on contemporary x86 machines!
(FX32 was a major help for the visual effects industry, where Alphas were really popular at one point - 3D apps like Lightwave were available in native Alpha versions, but all the support tools, like Photoshop, were not...)
One reason MS might not want to add these features to NT is that they want to maintain a high cost for porting apps between NT and UNIX-style systems.
Having some experience in this area I agree that NT's lack of true UNIX-style pipes, its inconsistent treatment of file descriptors, the file path issues (drive letters and forward slashes), and the lack of fork() are BIG barriers in porting in either direction.
Perhaps MS likes the fact that it's hard to port a large Windows program to any other OS. They benefit in the other direction too - since it's hard to port a large UNIX program to Windows, and Windows support is essential for the success of most mainstream software products, developers are likely to choose a Windows-only approach rather than starting on UNIX and porting over. (true, many large and successful software packages currently exist on both platforms - but in many cases it is obvious that one of the ports is just limping along with an inefficient compatibility layer)...
Incidentally, I find it very interesting that there are now only two major types of operating system APIs - Windows, and Everything Else. Ever since Apple dropped OS9 in favor of BSD, it seems like the only remaining viable platform that does NOT conform to UNIX logic is WIn32. Same thing with graphics - it's either GDI/DirectX, or Everything Else, i.e. X11/OpenGL... (well there's Quartz too I guess:).
Re:FUD disguised as a technical comment.
on
AMD's 64-bit Plot
·
· Score: 2
Thanks for the clarification. Just two minor comments. First, on "long" mode - it is my understanding that 64-bit Windows will use such a standard, since far too much Windows code depends on "long" being 32 bits. However, on UNIX style systems like Linux, "long" will be 64 bits (as it is on most other 64-bit systems).
I disagree that the move to 64 bits will not affect cache pressure. I can think of many applications where the data structures are mostly pointers (e.g. compilers or XML processors). In such cases, working sets could almost double as pointers become 64 bits.
ATI formerly released specs for their older cards. I don't think specs are available for the latest cards and their vertex/fragment program featuers. Also, ATI would not give out specs for their video in/out hardware (I asked them and was refused). As far as "openness" is concerned I consider them friendlier than NVIDIA, but not by much. The difference is outweighed by NVIDIA's large lead in driver quality (esp for Linux) and general support.
Re:And there will be one Master Ring
on
More on Longhorn
·
· Score: 2
I think you've touched on something really important. Microsoft's strong commitment to backwards compatibility is often overlooked as a factor in its success. Unfortunately this does not bode well for Linux... The areas of compatibility you mention - filesystem layout, software installation and configuration methods, etc - are the ones that differ MOST between distributions, and even different versions of the same distribution! I think that when Linux vendors decide to adopt a new replacement for an old package (e.g. xinetd for inetd or glibc 2.2/3 for 2.0), they too easily dismiss the "installed base" of knowledge and software that their customers have built around the old solution.
LOL yes! I remember using a program called Tapsis(?) for Compuserver that would dial up, grab all the messages you wanted, then disconnect. You'd read and reply on your own time, then make one more brief connection to transmit any replies. It saved a TON of money. I can't imagine being forced to use the same thing for the Web in general!:)
I thought Liquid Audio has its own DRM-crippled audio format...
(...which never achieved any success in the market, spurring the stockholders to try to liquidate (hah) the company's assets before they lose everything...)
Am I correct in assuming that there's a one-to-one mapping between simplified and traditional characters? For every character, that is, there's zero or one simplified forms and one traditional form?
Yes. There are a handful of oddball characters that have more than one traditional form or more than one simplified form, but your assumption is true for the vast majority of Chinese characters.
An oddball example is the character for "enough" (pronounced "gou4" in Mandarin) - it is sometimes written with the left and right-hand sides reversed. Each variant is a different Unicode codepoint (U+5920 and U+591F); and you'd definitely want to include these in a string-comparison function.:)
As bursch-X pointed out, you do need the Simplified-Traditional mapping in strcmp() or whatever comparison function you use for sorting. (however you are right in the sense that most kernel-level filesystems don't need to sort filenames, only compare equal-or-not-equal).
As a student of Chinese I have many Simplified and Traditional files on my system. You are right that Taiwanese users might not care too much about support for Simplified characters, but the reverse mapping is important since Traditional characters are making a comeback in mainland China... And unlike Hiragana and Katakana, the two character forms are completely interchangeable; someone who is literate in both will often not even be aware of which form he is reading.
I have not studied too much Japanese, but I know there is also the issue of certain words that can appear as either kanji or Hiragana...
I think there is an argument for providing these Unicode character mappings at the libc level, however I'd prefer to see them in a higher-level library that could be shared between GUI applications. (like the international text layout functions in libpango, which theoretically could serve all GNOME, KDE, and Xlib apps)
Internationalization IS the big problem. If you want open() to be "case-insensitive," the kernel must include not only the simple mapping from English uppercase letters to English lowercase letters, but also the mappings from Traditional to Simplified Chinese characters, Japanese Hiragana to Katakana, etc. (you're talking megabytes of kernel memory here).. Now you can and SHOULD do this kind of thing in user-space GUI libraries (e.g. File Open dialog boxes), but underneath the kernel should not do anything more than strict byte-matching.
In other words, blame Visual Studio for handling cases wrong...
You are talking about subdivision surfaces, not NURBS. SubDs have the advantage that they are much easier to construct for arbitrary topologies (stitching is not a problem as with NURBS). However, like polygons SubDs have no natural parameterization, so you have to spend some effort designing texture coordinates.
First you have to understand that the main design goal of glibc is code bloat. (I'm not kidding, static hello-world.c is >100KB). A lot of this is because glibc tries to support a large API, most of which is never used by most programs (e.g. locales). Also, glibc tends to lump lots of stuff into individual object files, so the linker does a worse job of discarding unused code. (the first call to printf() in your program pulls in tens of KB of stdio code)
The concept of uclibc and dietlibc is to support the 10% of APIs that 90% of programs use, and to behave better with static linking. uclibc makes some sacrifices to work better with glibc-based software (I don't have exact numbers since I don't use uclibc). dietlibc goes completely to the extreme; anything that can be cut is cut, and object code is carefully divided so that static executables only include the code they really need.
For concrete examples, see the static binaries compiled by dietlibc's author at ftp://foobar.math.fu-berlin.de:2121/pub/dietlibc/b in-i386 (cat is 3KB, tar is 63KB, the thttpd web server is 42KB - add them up and you are just about equal to hello-world.c with glibc). Compare these with the sizes of even dynamically-linked glibc binaries on your own system.
The reason you wouldn't want to use a cut-down libc for something like Gnome or KDE is that you'd have to recompile your entire system, including the X libraries and all other dependencies. (you can't use your existing X libraries since they are already linked to glibc). Along the way you are sure to run into one or two obscure C library APIs that only glibc implements.
I think eventually there is a chance that glibc will be replaced by one of the cut-down libcs. The degree of bloat in glibc is simply obscene, and on top of that there is the backwards-incompatibility problem. (many packages broke during the transitions from 2.1 to 2.2 to 2.3, which should never have happened with a stable thing like the C library). Linus himself has even floated this suggestion on the LKML. The question that remains is whether the full glibc API can be implemented without creating another bloated monster. (there is no real alternative, since glibc's API has been enshrined in the LSB already...)
On a similar note, I'd love to see GCC drop the problematic GNU STL for STLport. In my tests STLport has about half the cost in compile time and code size...
Yes, with Lightwave it is easy to move between machines and platforms because it comes with a USB dongle! One of the disadvantages of Maya is that it uses that infernal FlexLM license thief^H^H^H^H manager. (if your Ethernet card breaks, you gotta call Alias and beg for another license)
Incidentally, you might want to try to find an earlier version of Lightwave. I found the interface changes between 5.5 and 6.0 to be a huge leap backwards. In the later versions, all of the vital controls are buried deep in confusing menus; before 6.0 they were much easier to access. (in my own work I use 5.5 whenever possible, and only do final renders in 7.5 when I need specific features like HDRI)
I would focus your attention on Lightwave or Maya.
Lightwave is very easy to learn, has a very good modeler (for polygons and subdivision surfaces; no NURBS though), and a good rendering engine. Lightwave works really well out of the box, you won't need any additional software at the beginning.
Maya is the most flexible of commercial 3D packages; the modeler is good for NURBS and can handle polygons and subdivision surfaces too (though not as easily as Lightwave). Maya's animation features are unparalleled. However, the renderer isn't so great. Many professional Maya users export their scenes to a RenderMan-based renderer instead of using the bundled one.
If you had to get just one package, or you don't think you'd be able to set up a renderer for Maya, I would get Lightwave. If you are mostly concerned with animation and can expect some help in the lighting and rendering departments, get Maya.
Both Lightwave and Maya skills are valuable for getting 3D animation jobs. Lightwave is slightly more concentrated in game development and TV work, while Maya is more concentrated in film and TV.
Finally, don't put too much weight in the sample images you find for each package. The Lightwave website has a huge gallery of excellent work, but you have to keep in mind it's been around for many many years, and so its users have had plenty of time to figure out how to get good results from it. A newer package might not have that many impressive sample images, simply because there isn't a large community of experienced users yet.
The biggest news in this article is not the copy-prevention system - it's the watermark. This represents a completely new kind of digital rights restriction.
"The watermarks must be present for the player to recognize the disc and play the content. A bootleg DVD-Audio without the watermark would fail to play, Winograd said."
Do you see what this means? All CD players will play home-made CDs, all DVD players will play home-made (unencrypted) DVDs. But SACD players will not play home-made SACDs, only studio-made SACDs! In order to produce a SACD, you must sign away your copyrights to a major music studio.
SACD is the first digital format that completely locks out non-studio artists.
(yes I know exploiting the full quality of SACD requires a bunch of fancy equipment - heck, so does DVD - so when I say "home-made" I mean "made by anyone without a studio contract")
I think you are right about copy-prevented CDs being expected to fail. RIAA executives couldn't possibly be stupid enough to believe that any of these "mutant CD" schemes is really going to work. Plus I'm sure it raises their production costs quite a bit (they must have to pay Midbar et al for patent licenses).
What these schemes will accomplish is allow the industry to say to Congress, "Look, we tried copy prevention on our own, it didn't work, we need new laws that require DRM chips in everything."
(incidentally, Barbara Simons mentioned in a DRM session at Siggraph that she believed the DVD CSS cipher was deliberately made easy to break, as a similar form of entrapment)
I should add that the best part about my Makefile generator is that it contains much of the knowledge I've accumulated about portability.
For instance, to correctly link to OpenGL on Linux you say "-lGL" whereas on Windows you say "-lopengl32". Or to use threads on Linux you must compile with "-DREENTRANT" and link with "-lpthreads", whereas on Windows nothing special is required. In my simple build rule I can just say "this executable needs OpenGL and threads", and the Makefile generator spits out the correct compiler and linker options for each platform.
As I port my software to more platforms, I just add more intelligence to the Makefile generator. e.g. when I port to Mac OSX I'll simply add Makefile generation rules for whatever quirks OSX happens to have.
I personally don't like the auto* tools very much. They are difficult to set up and debugging them is a pain.
A nice feature of my system is that it spits out one huge Makefile for the whole project. This avoids the speed penalty and complexity of recursive make (one Makefile per directory). If there is no work to do, 'make' returns almost instantly.
IMHO the correct solution is to port the platform to the software, not the software to the platform. e.g. demand that the C compiler is always/usr/bin/cc and the X libraries are always in/usr/X11R6/lib (symlink them if necessary) rather than trying to figure out where they are on each system.
You can, with some loss of performance, use GCC on all of those platforms. That would cut out compiler quirks as a variable.
Don't write Makefiles yourself. Instead write a script that translates simple build rules (foo.cpp -> foo.o -> foo.exe) into a custom Makefile for each platform. I went this route after battling for years with complex Makefile rules that never quite worked.
I've done a bit of research on this - the X architecture is not fundamentally flawed - it's just that some things are implemented poorly.
Current X applications do not sync with the window managers well enough. e.g. on Windows, window resizing is synchronous with repainting, whereas on X it is asynchronous - leading to a slow, "sticky" feeling and painting artifacts.
Same thing with mouse tracking - the X display refresh is not synced in any way with mouse position updates, so moving a window around feels "sticky."
I claim that it is possible to achieve as good a "feel" as Windows/GDI without any modification of the X architecture. However, window managers and GUI toolkits will need to communicate better in order to reach this goal.
A good way to tackle this is to move as much code as possible out-of-line. I have a custom template container library where all of the major functions are implemented out-of-line - they work with void* pointers rather than a specific type. These void* containers are wrapped in a template class that just casts to/from void* and the templated type.
I've found that this approach is almost as flexible as the fully templated STL, and it compiles anywhere from 2-5 times faster and binaries are usually 2-5 times smaller than with STLport. (the improvement is even more dramatic in comparison with the inefficient GNU STL)
A good way to avoid these kinds of problems is to use a separate DNS host, such as EasyDNS. It provides an extra layer of indirection in front of your web and email providers, making it easy to switch if there are any problems.
Most people have their current web/mail ISP hosting their DNS records too. If the ISP goes out of service, not only do you lose web or mail access, but you can't immediately switch to a competitor - you have to wait at least a few days for the DNS transfer to take place.
With EasyDNS, I can cut over to a backup web or email provider in just an hour or two. If you use their email forwarding service, you can switch to a backup email account *instantly*. I keep at least 3 POP accounts at different ISPs as backups. This has saved my butt several times...
Slashdot Mirror
Don't forget Digital's groundbreaking FX32 emulation software. FX32 allowed you to run x86 Windows software on Alpha NT. The cool part was that after running for a while in slow software emulation, FX32 went back through the x86 code and translated the hotspots into native Alpha code. It was not unusual for translated x86 applications to run faster under FX32 than they did on contemporary x86 machines!
(FX32 was a major help for the visual effects industry, where Alphas were really popular at one point - 3D apps like Lightwave were available in native Alpha versions, but all the support tools, like Photoshop, were not...)
One reason MS might not want to add these features to NT is that they want to maintain a high cost for porting apps between NT and UNIX-style systems.
:).
Having some experience in this area I agree that NT's lack of true UNIX-style pipes, its inconsistent treatment of file descriptors, the file path issues (drive letters and forward slashes), and the lack of fork() are BIG barriers in porting in either direction.
Perhaps MS likes the fact that it's hard to port a large Windows program to any other OS. They benefit in the other direction too - since it's hard to port a large UNIX program to Windows, and Windows support is essential for the success of most mainstream software products, developers are likely to choose a Windows-only approach rather than starting on UNIX and porting over. (true, many large and successful software packages currently exist on both platforms - but in many cases it is obvious that one of the ports is just limping along with an inefficient compatibility layer)...
Incidentally, I find it very interesting that there are now only two major types of operating system APIs - Windows, and Everything Else. Ever since Apple dropped OS9 in favor of BSD, it seems like the only remaining viable platform that does NOT conform to UNIX logic is WIn32. Same thing with graphics - it's either GDI/DirectX, or Everything Else, i.e. X11/OpenGL... (well there's Quartz too I guess
Thanks for the clarification. Just two minor comments. First, on "long" mode - it is my understanding that 64-bit Windows will use such a standard, since far too much Windows code depends on "long" being 32 bits. However, on UNIX style systems like Linux, "long" will be 64 bits (as it is on most other 64-bit systems).
I disagree that the move to 64 bits will not affect cache pressure. I can think of many applications where the data structures are mostly pointers (e.g. compilers or XML processors). In such cases, working sets could almost double as pointers become 64 bits.
ATI formerly released specs for their older cards. I don't think specs are available for the latest cards and their vertex/fragment program featuers. Also, ATI would not give out specs for their video in/out hardware (I asked them and was refused). As far as "openness" is concerned I consider them friendlier than NVIDIA, but not by much. The difference is outweighed by NVIDIA's large lead in driver quality (esp for Linux) and general support.
I think you've touched on something really important. Microsoft's strong commitment to backwards compatibility is often overlooked as a factor in its success. Unfortunately this does not bode well for Linux... The areas of compatibility you mention - filesystem layout, software installation and configuration methods, etc - are the ones that differ MOST between distributions, and even different versions of the same distribution! I think that when Linux vendors decide to adopt a new replacement for an old package (e.g. xinetd for inetd or glibc 2.2/3 for 2.0), they too easily dismiss the "installed base" of knowledge and software that their customers have built around the old solution.
LOL yes! I remember using a program called Tapsis(?) for Compuserver that would dial up, grab all the messages you wanted, then disconnect. You'd read and reply on your own time, then make one more brief connection to transmit any replies. It saved a TON of money. I can't imagine being forced to use the same thing for the Web in general! :)
YES! The Delta IV was carrying several cameras. Video will be posted at http://www.eclipticenterprises.com/gallery_rocketc am.shtml
as soon as we get the tape. (I work with Ecliptic Enterprises, maker of the RocketCam(tm) system).
Or he assumes a road is there, closes his eyes, and then steps off a cliff.
I thought Liquid Audio has its own DRM-crippled audio format...
(...which never achieved any success in the market, spurring the stockholders to try to liquidate (hah) the company's assets before they lose everything...)
Yes. There are a handful of oddball characters that have more than one traditional form or more than one simplified form, but your assumption is true for the vast majority of Chinese characters.
An oddball example is the character for "enough" (pronounced "gou4" in Mandarin) - it is sometimes written with the left and right-hand sides reversed. Each variant is a different Unicode codepoint (U+5920 and U+591F); and you'd definitely want to include these in a string-comparison function. :)
As bursch-X pointed out, you do need the Simplified-Traditional mapping in strcmp() or whatever comparison function you use for sorting. (however you are right in the sense that most kernel-level filesystems don't need to sort filenames, only compare equal-or-not-equal).
As a student of Chinese I have many Simplified and Traditional files on my system. You are right that Taiwanese users might not care too much about support for Simplified characters, but the reverse mapping is important since Traditional characters are making a comeback in mainland China... And unlike Hiragana and Katakana, the two character forms are completely interchangeable; someone who is literate in both will often not even be aware of which form he is reading.
I have not studied too much Japanese, but I know there is also the issue of certain words that can appear as either kanji or Hiragana...
I think there is an argument for providing these Unicode character mappings at the libc level, however I'd prefer to see them in a higher-level library that could be shared between GUI applications. (like the international text layout functions in libpango, which theoretically could serve all GNOME, KDE, and Xlib apps)
Internationalization IS the big problem. If you want open() to be "case-insensitive," the kernel must include not only the simple mapping from English uppercase letters to English lowercase letters, but also the mappings from Traditional to Simplified Chinese characters, Japanese Hiragana to Katakana, etc. (you're talking megabytes of kernel memory here).. Now you can and SHOULD do this kind of thing in user-space GUI libraries (e.g. File Open dialog boxes), but underneath the kernel should not do anything more than strict byte-matching.
In other words, blame Visual Studio for handling cases wrong...
You are talking about subdivision surfaces, not NURBS. SubDs have the advantage that they are much easier to construct for arbitrary topologies (stitching is not a problem as with NURBS). However, like polygons SubDs have no natural parameterization, so you have to spend some effort designing texture coordinates.
First you have to understand that the main design goal of glibc is code bloat. (I'm not kidding, static hello-world.c is >100KB). A lot of this is because glibc tries to support a large API, most of which is never used by most programs (e.g. locales). Also, glibc tends to lump lots of stuff into individual object files, so the linker does a worse job of discarding unused code. (the first call to printf() in your program pulls in tens of KB of stdio code)
b in-i386
The concept of uclibc and dietlibc is to support the 10% of APIs that 90% of programs use, and to behave better with static linking. uclibc makes some sacrifices to work better with glibc-based software (I don't have exact numbers since I don't use uclibc). dietlibc goes completely to the extreme; anything that can be cut is cut, and object code is carefully divided so that static executables only include the code they really need.
For concrete examples, see the static binaries compiled by dietlibc's author at ftp://foobar.math.fu-berlin.de:2121/pub/dietlibc/
(cat is 3KB, tar is 63KB, the thttpd web server is 42KB - add them up and you are just about equal to hello-world.c with glibc). Compare these with the sizes of even dynamically-linked glibc binaries on your own system.
The reason you wouldn't want to use a cut-down libc for something like Gnome or KDE is that you'd have to recompile your entire system, including the X libraries and all other dependencies. (you can't use your existing X libraries since they are already linked to glibc). Along the way you are sure to run into one or two obscure C library APIs that only glibc implements.
I think eventually there is a chance that glibc will be replaced by one of the cut-down libcs. The degree of bloat in glibc is simply obscene, and on top of that there is the backwards-incompatibility problem. (many packages broke during the transitions from 2.1 to 2.2 to 2.3, which should never have happened with a stable thing like the C library). Linus himself has even floated this suggestion on the LKML. The question that remains is whether the full glibc API can be implemented without creating another bloated monster. (there is no real alternative, since glibc's API has been enshrined in the LSB already...)
On a similar note, I'd love to see GCC drop the problematic GNU STL for STLport. In my tests STLport has about half the cost in compile time and code size...
Yes, with Lightwave it is easy to move between machines and platforms because it comes with a USB dongle! One of the disadvantages of Maya is that it uses that infernal FlexLM license thief^H^H^H^H manager. (if your Ethernet card breaks, you gotta call Alias and beg for another license)
Incidentally, you might want to try to find an earlier version of Lightwave. I found the interface changes between 5.5 and 6.0 to be a huge leap backwards. In the later versions, all of the vital controls are buried deep in confusing menus; before 6.0 they were much easier to access. (in my own work I use 5.5 whenever possible, and only do final renders in 7.5 when I need specific features like HDRI)
I would focus your attention on Lightwave or Maya.
Lightwave is very easy to learn, has a very good modeler (for polygons and subdivision surfaces; no NURBS though), and a good rendering engine. Lightwave works really well out of the box, you won't need any additional software at the beginning.
Maya is the most flexible of commercial 3D packages; the modeler is good for NURBS and can handle polygons and subdivision surfaces too (though not as easily as Lightwave). Maya's animation features are unparalleled. However, the renderer isn't so great. Many professional Maya users export their scenes to a RenderMan-based renderer instead of using the bundled one.
If you had to get just one package, or you don't think you'd be able to set up a renderer for Maya, I would get Lightwave. If you are mostly concerned with animation and can expect some help in the lighting and rendering departments, get Maya.
Both Lightwave and Maya skills are valuable for getting 3D animation jobs. Lightwave is slightly more concentrated in game development and TV work, while Maya is more concentrated in film and TV.
Finally, don't put too much weight in the sample images you find for each package. The Lightwave website has a huge gallery of excellent work, but you have to keep in mind it's been around for many many years, and so its users have had plenty of time to figure out how to get good results from it. A newer package might not have that many impressive sample images, simply because there isn't a large community of experienced users yet.
"The watermarks must be present for the player to recognize the disc and play the content. A bootleg DVD-Audio without the watermark would fail to play, Winograd said."
Do you see what this means? All CD players will play home-made CDs, all DVD players will play home-made (unencrypted) DVDs. But SACD players will not play home-made SACDs, only studio-made SACDs! In order to produce a SACD, you must sign away your copyrights to a major music studio.
SACD is the first digital format that completely locks out non-studio artists.
(yes I know exploiting the full quality of SACD requires a bunch of fancy equipment - heck, so does DVD - so when I say "home-made" I mean "made by anyone without a studio contract")
Or you could just make an "analog" CD player that has a lossless digital output tapped in after the error correction circuits but before the DAC...
What these schemes will accomplish is allow the industry to say to Congress, "Look, we tried copy prevention on our own, it didn't work, we need new laws that require DRM chips in everything."
(incidentally, Barbara Simons mentioned in a DRM session at Siggraph that she believed the DVD CSS cipher was deliberately made easy to break, as a similar form of entrapment)
I should add that the best part about my Makefile generator is that it contains much of the knowledge I've accumulated about portability.
For instance, to correctly link to OpenGL on Linux you say "-lGL" whereas on Windows you say "-lopengl32". Or to use threads on Linux you must compile with "-DREENTRANT" and link with "-lpthreads", whereas on Windows nothing special is required. In my simple build rule I can just say "this executable needs OpenGL and threads", and the Makefile generator spits out the correct compiler and linker options for each platform.
As I port my software to more platforms, I just add more intelligence to the Makefile generator. e.g. when I port to Mac OSX I'll simply add Makefile generation rules for whatever quirks OSX happens to have.
I personally don't like the auto* tools very much. They are difficult to set up and debugging them is a pain.
/usr/bin/cc and the X libraries are always in /usr/X11R6/lib (symlink them if necessary) rather than trying to figure out where they are on each system.
A nice feature of my system is that it spits out one huge Makefile for the whole project. This avoids the speed penalty and complexity of recursive make (one Makefile per directory). If there is no work to do, 'make' returns almost instantly.
IMHO the correct solution is to port the platform to the software, not the software to the platform. e.g. demand that the C compiler is always
You can, with some loss of performance, use GCC on all of those platforms. That would cut out compiler quirks as a variable.
Don't write Makefiles yourself. Instead write a script that translates simple build rules (foo.cpp -> foo.o -> foo.exe) into a custom Makefile for each platform. I went this route after battling for years with complex Makefile rules that never quite worked.
I've done a bit of research on this - the X architecture is not fundamentally flawed - it's just that some things are implemented poorly.
Current X applications do not sync with the window managers well enough. e.g. on Windows, window resizing is synchronous with repainting, whereas on X it is asynchronous - leading to a slow, "sticky" feeling and painting artifacts.
Same thing with mouse tracking - the X display refresh is not synced in any way with mouse position updates, so moving a window around feels "sticky."
I claim that it is possible to achieve as good a "feel" as Windows/GDI without any modification of the X architecture. However, window managers and GUI toolkits will need to communicate better in order to reach this goal.
A good way to tackle this is to move as much code as possible out-of-line. I have a custom template container library where all of the major functions are implemented out-of-line - they work with void* pointers rather than a specific type. These void* containers are wrapped in a template class that just casts to/from void* and the templated type.
I've found that this approach is almost as flexible as the fully templated STL, and it compiles anywhere from 2-5 times faster and binaries are usually 2-5 times smaller than with STLport. (the improvement is even more dramatic in comparison with the inefficient GNU STL)
A good way to avoid these kinds of problems is to use a separate DNS host, such as EasyDNS. It provides an extra layer of indirection in front of your web and email providers, making it easy to switch if there are any problems.
Most people have their current web/mail ISP hosting their DNS records too. If the ISP goes out of service, not only do you lose web or mail access, but you can't immediately switch to a competitor - you have to wait at least a few days for the DNS transfer to take place.
With EasyDNS, I can cut over to a backup web or email provider in just an hour or two. If you use their email forwarding service, you can switch to a backup email account *instantly*. I keep at least 3 POP accounts at different ISPs as backups. This has saved my butt several times...