Perfect for college students and people who can't afford/don't want to pay for more expensive food, there's always the Ramen Recipe Database (quick link to all recipes). Over 200 recipes and counting. It's amazing what people can do with Ramen when they try. Ramen by itself may not be all that nutritious, but with a little imagination you can make a full meal out of one of those little $0.15 packages.
Actually, it's not "Big Oh" but Ordo, and the capital 'o' is for show that it's the Ordo value for the worst case.
Yeah yeah yeah, I didn't want to get too pedantic. The common way to pronounce "O(n)" is "Big Oh (of) n", and so that's what I said. Going into why a big 'O' is used, and what it means, and the differences between O, o, Big Theta, Big Omega, etc is out of scope for this topic and my post. Therefore, I didn't get into that and just made the correction from 0(1) to O(1).
Remember, patronize only genuine alien-swirled crop circles!
Better yet, don't patronize any crop circles at all, since it's destruction of property (how would you like it if a bunch of jokers spray painted your house or car, or broke into your computer and muddled around with the files? It's all the same -- destruction of property). If Disney's really doing this, then I expect to see a rash of lawsuits against them as well.
Of course, if you believe that crop circles really are made by aliens, well... I guess it's time to break out the ol' tin foil hat.
Plus they are ban-happy. For some reason, it seems my entire subnet is banned (no, it's not because of me. I hadn't been in the channel for over a year and when I tried to log in.. Banned). That's a LOT of people being locked out. But I guess that's not a total loss considering the "help" most people would get in that channel.
Are you sure you just didn't have your identd not running or misconfigured? #Linux requires you run ident (it doesn't matter if you fake your ident or not, just so long as you are running some ident). Otherwise, you'll be banned.
www.codeguru.com - actually i don't know how good it is anymore. but about five years ago when i worked as a windows application developer i found alot of help there
I've not used CodeGuru much, so I can't really comment there. However, The Code Project seems to be rather popular, and even has some (unofficial) support through Microsoft. Another good site is WinProg.NET, the website for EFNet's #Winprog and also a site with a number of good tutorials and resources.
That said, there's really not much better than MSDN for looking up pretty much anything you want to know about developing for Windows. Of course, MSDN is more a reference than a tutorial site, so I can understand why new Windows programmers can feel lost in it. That's where sites like CodeGuru, The Code Project, et al come in.
And he can get a fancy alpha-blended PuTTY here. However, the way I understood it, he was asking for a server, not a client. PuTTY is only a client (ssh client, scp, sftp, etc).
Everything seems to be done in a calm reasonable manner with the exception of my constant kick/banning from #debian on openprojects.
If you're the same vhost-kiddie Jon from EFNet (the one who caused the *!jon@* username ban in EFNet's #Linux), then I'm sure all of your OPN #debian kickbans have been legitimate and warranted. I'm just surprised that they let you back in just to kickban you again, rather than keeping you out indefinitely.
Considering the name "Debian" came from "Deb" and "Ian", I'm of the opinion that it should be pronounced as such. "Dehb-ee-un". Then again, we may just be wading into Holy War territory, like "Li-nucks" vs. "Lie-nucks" vs "Lee-nucks" (who actually says the last?).
I agree 100%. I didn't mean I was going to bitch and moan, only that many/.'ers and other linux/*nix zealots do bitch and moan, and thus will continue to do so in the future as well. Having a 3D-accelerated desktop will only give them more fuel for the bitching and moaning, regardless of whether or not there really is a reason to complain.
Even if it failed, it would make MS push some features taht I think are smart like using 3D hardware to render the desktop to let you do all those cool window transitions and stuff.
Microsoft doesn't necessarily need Apple to push them in that direction, since they're already going there. Maybe not with Longhorn, but soon (say, within 5 years, which I guess isn't "soon" in computer time, but it's still relatively soon) you can expect DirectX to be the de facto standard for displaying anything on Windows. No more GDI, nor more GDI+ (which is better than GDI, but is not hardware accelerated by many drivers yet), OpenGL probably just as a wrapper for DX (or at least by default. I'm sure hardware vednors will still write OpenGL ICDs if the demand is there), etc.
Of course, once that happens, expect to hear even more bitching and complaining about having such a heavy GUI on a server-class OS (I guess they could stick with the current GUI for their server-level versions and the DX-based GUI for consumer-grade and workstation versions, but I doubt that would happen for consistency purposes). Anyway, by that time, a DirectX-based interface won't be any heavier (relatively) on future hardware than the current GUI is on current hardware.
Look: You're relying on skins to match the look&feel, which means you either pick a skin and use it on all platforms, or you have to programmatically figure out which platform you're on and pick the most-appropriate skin. Giving the user the option to pick their theme would work, too, but that's a bit of a cop-out if your goal is to fit in with the L&F of a given platform.
Feel: Assuming you figure out #1, you still have the issue of "feel", or more precisely "consistency". Just browsing the screenshots, it appears that the themes don't actually change the "feel" of any widgets, only the look. That means things like scrollbars are always going to have the NeXT-style arrows, even though things like Windows don't use those types of scroll ends. So, even though your app may now look like a native app, it's not going to act like one.
Skins can only do so much. In this case, I think choosing to use skins is a suboptimal solution. Why go to all the trouble to implement skinning in your application, when you could get native-L&F compatibility for free (and be able to leverage any system/widget kit-wide skinning capabilities) if the runtime was simply developed correctly?
Of course, exceptions can be made. Just as my own personal rule of thumb, if the application is "arty" (a media player, movie player, fancy image viewer, etc), then making it skinnable separate from the OS is a viable option. However, if the application is more mundane, like a word processor or some business app or an IRC client (this could probably fit in either category) or a web browser (good example: galeon; bad example: mozilla), you should try to blend into the look&feel for your target platform (.NET is a platform, but here I mean the platform on which the.NET platform is running and not the.NET platform itself). Of course, there have been numerous apps that have broken this rule of thumb (ever see the old IBM apps that came with the consumer Aptivas? a PIM that looked like a day organizer, a phone app that looked like a phone, etc. They were horrible. Even the CD player that looked like a CD player was awful, and I'm usually okay with media players being funky).
Because AWT was such a major success.
The precise behavior, look, etc should be specified for WinForms and then they should, if anything, be designed using GDK for a target, not GTK.
I can only assume you were being sarcastic about the success of AWT, so I won't bother with that. However, as far as Look&Feel goes, I believe that Swing got it wrong. According to Swing (and things like Mozilla's XUL), it's important for your application to look exactly the same across all systems on which it runs. I disagree, as do many others. Instead, your application should adopt the look&feel of the target platform you're using. Do you really want an ugly GTK-looking thing on Mac OS X? It will look really out of place among all the pretty OS X apps. Same goes for on Windows XP. The new Visual Style theming capability is great, but I get annoyed when I use an app that doesn't support visual styles. All of my other apps look great, all of them using the same theme. But there's just that one that looks completely out of place. No, it's better for something like this that you implement the backend using native widget sets, and your runtime will take care of figuring out what it should use (depending on where you're running of course).
The problem with AWT is that it was basically dumbed down, trying to find a least common denominator API that would make it easy to implement AWT for most platforms. Rather, a better approach would be what Windows.Forms does. It defines certain things (you have forms, buttons, scrollbars, toolbars, etc). Sure, a lot of these things are drawn directly from Windows, but they can be implemented on many other platforms as well. Maybe your GTK-based backend has to munge together three or for different widgets to implement some single widget in Windows.Forms, but that's okay. You do it once in the runtime, and then you don't ever have to do it again, and you don't limit the high-level API based on the limitations of the underlying API. If that means that Mono does end up just scrapping GTK and going directly down to GDK, so be it. I personally think they can implement Windows.Forms just fine using GTK.
Mono will survive because M$ is reported to be porting.NET to BSD...
Already been done. It's called Rotor, and is a Shared Source project, meaning you can see the source and modify it for non-commercial uses, and it even has a nice clause saying that you can't taint yourself by looking at the code (oh, if only the GPL had such a clause. Instead, I can't look at GPL'ed software for fear of tainting my thought processes and inadvertantly ending up with GPL'ed code in software I write). Rotor is mostly meant for academic use and study, and is just a reference implementation (for instance, the GC is very primitive, and is much better in the.NET runtime from Microsoft). However, it builds for both Windows and FreeBSD (probably other BSDs).
So... there will be a trunk for GNU/Linux...
Not from Microsoft. You could probably compile Rotor with minor changes on a Linux system, but it'll be completely unsupported by MSFT (well, more unsupported than Rotor already is, which doesn't have any official support but the dev team helps out when they can).
P.S.- I would suspect that XP is based in BSD but as i don't have access to XP sources or time to stroll at BSD sources... alas...
You'd be wrong, of course. The reason people bring this up is because Microsoft once used the reference implementation of the TCP/IP stack which just happened to come from a BSD (hrm... the BSD license is very liberal, not forcing you into any specific license, which makes it perfect for providing reference implementations -- anybody can start with that implementation and change it how they please and not be stuck with the GPL). XP is based on Win2K, which is based on NT4, which is based on earlier NTs, which ultimately derived from the same people that wrote VMS, so you could say that XP is a descendant (several generations removed) of VMS, but you won't find much (any?) VMS code in XP since NT wasn't directly based on VMS (just the concepts and ideas). (Throw some OS/2 in there, just to be complete.) However, XP != BSD, nor would I expect Microsoft to release any BSD-backed (or other *nix-backed) OS in the near-to-mid future (who knows about the long term, really? It's probably safe to say "not likely" here).
How does.NET prevent you from using a good text editor and command line tools? All the files, including forms, code, resource, and project files are simple text/XML files. That means that you can use any text editor, then use the command line compilation tools, which are vbc for VB.NET, cs for C#, etc.
What's more, if you don't want to use the VS.NET IDE, save yourself $800+ and just download the framework for free (I would post a URL, but my internet connection at work is all wonky. Look for it at MSDN). You get all the commandline tools necessary for compilation, so you can use your own text editor (vim, source insight, notepad if you must, etc), cobble together some makefiles, and build all the.NET apps you want for free. Sure, you don't get the fancy Forms designer, but if you're not doing GUI development, what's that matter? And if you are, well, anything you can do with the Forms designer, you can do with code.
But you're right, as it is, GTK# doesn't work on windows, but it might in the future.
And that's the problem. There shouldn't need to be any such thing as "GTK#", because Mono should be implementing Windows.Forms instead. It would then be the responsibility of the runtime on whatever system to translate these Windows.Forms calls into some widget set (Windows.Forms on Windows already translates these to Win32 calls, I believe the Rotor implementation for FreeBSD translates Windows.Forms to TK, and Mono should be implementing a GTK backend for this). The other plus for this is that if Mono in the future decides to use QT, or upgrades the runtime to use a newer, incompatible GTK version, there should be no change to the.NET app. You're not tied to GTK, just.NET. How the runtime implements Forms is not (should not be) a concern for the app-level programmer.
If you provide public transportation which is cheaper than driving, people will use it, you don't need to essentially force them to do so by charging an arm and a leg.
I disagree. Cheaper is usually not enough. It also has to be convenient. Personally, I don't use public transportation very often (never where I live, and only rarely when I visit other places) because it's just plain inconvenient (side note: I also enjoy driving my car, which means public transportation has to be able to provide an even higher utility for me to choose to use it). I disagree with taxing other forms of travel to encourage use of public transportation. If you want me to use it, make it affordable and convenient, and provide me with benefits that I won't get by driving my car (not necessarily monetary, either. Even with current gas prices, I'd still choose to drive than ride the transit system).
I guess if I were in a more populous area (Seattle only counts if you're in the downtown area, which I'm not) public transportation would be a more viable option. However, I'm not, and the current implementations here are not viable for me. Therefore, I don't use it even though 50% of my registration renewal fee is a public transportation tax.
So for something like Windows 2000 is that a long time?
It's long-ish, but not overly long. For a comparison that you may be more familiar with, consider the time it takes to compile the Linux kernel, your chosen libc, other libs you'll eventually need (say, gtk and/or qt, etc), X, GNOME or KDE, some apps (xmms, xine, a couple editors, etc), and probably 8 or 9 other things I'm forgetting right now. You'll probably come up with a similar number (probably smaller, but there's also probably less code in all the above tools).
That's not to say it can't be made faster. I don't know whether that time was on a multi-threaded compile or not, but I'd sure hope so given that their build machines were 4-way machines. Also, note that they didn't say what speed the P3s were. 4 P3-500s will surely compile slower than 2 p3-1.2GHzs. Nor did they say if those were Xeons or not (larger cache is better for compiling). The obvious solution is to throw hardware at the issue, but there are other things that can be done like incremental building, better sync/drains for multi-threaded compiles, more efficient compilers and build scripts, etc.
that and XP is ugly, so much fluff. i hate the colors and the 3d style bars. give me a win2k anyday, (or linux with kde which can be made to look different with ease)
ThemeXP is a site that you may find interesting, then. With a hack provided by TGTSoft to make XP not require visual styles be signed by Microsoft, you can change your theme to one of hundreds of themes out there. Don't like Luna or Classic? Find, go find something you do like over at ThemeXP. XP visual styles have really been maturing lately. When TGTSoft first did their hack, every theme released was just a recoloration or minor hack on Luna, or an attempt to copy Aqua. Now, there are some very neat, very professional-looking original themes out there. Check it out.
I think the difference here is that you assume that they're not pushing it right now (and thus, will do so in the future, if that's 3 or 5 or 7 years from now). From what I saw, it seems like they're not planning on doing marketing ever, whether they hit a useable state or not. I agree with you that right now is not the time to advertise their product. Maybe two years from now they should, but it sounds like they don't plan on it.
As far as Linux being a fluke in this regard, all I can say is that times change. Back when Linus was first starting Linux, nothing like that had ever really been done before (okay, so there was the GNU stuff, and the HURD that will never get out of alpha...). "Like that" meaning wide-scale collaboration via the internet on something that amounted to just a pet project at the time. People are jaded now. You can't just pop in to a relevant group on usenet and say "hey, I'm working on this neat OS, anybody want to help?" and get useful offers. Same goes for putting up a SourceForge page. In short, it's much harder these days to gather the kind of developer group Linus did because it's been done before. There's nothing really novel about it anymore. As for what that has to do with Linux "making it" without Linus having to market the kernel to the distributors, I think the fact that it gathered a large development group was enough for people to start consider distributing it as a full product rather than as a roll-your-own system. As a general rule of thumb, don't plan on those kinds of coincidences if your goal is to get people to use your software.
Slashdot Mirror
Perfect for college students and people who can't afford/don't want to pay for more expensive food, there's always the Ramen Recipe Database (quick link to all recipes). Over 200 recipes and counting. It's amazing what people can do with Ramen when they try. Ramen by itself may not be all that nutritious, but with a little imagination you can make a full meal out of one of those little $0.15 packages.
Yeah yeah yeah, I didn't want to get too pedantic. The common way to pronounce "O(n)" is "Big Oh (of) n", and so that's what I said. Going into why a big 'O' is used, and what it means, and the differences between O, o, Big Theta, Big Omega, etc is out of scope for this topic and my post. Therefore, I didn't get into that and just made the correction from 0(1) to O(1).
Just a nitpick. The term is "O(1)", not "0(1)", as in "Big Oh of 1" and not "Zero of 1".
Better yet, don't patronize any crop circles at all, since it's destruction of property (how would you like it if a bunch of jokers spray painted your house or car, or broke into your computer and muddled around with the files? It's all the same -- destruction of property). If Disney's really doing this, then I expect to see a rash of lawsuits against them as well.
Of course, if you believe that crop circles really are made by aliens, well ... I guess it's time to break out the ol' tin foil hat.
Not when Brazil has absolutely no laws against computer crime at all. We're protecting ourselves, there.
Are you sure you just didn't have your identd not running or misconfigured? #Linux requires you run ident (it doesn't matter if you fake your ident or not, just so long as you are running some ident). Otherwise, you'll be banned.
I've not used CodeGuru much, so I can't really comment there. However, The Code Project seems to be rather popular, and even has some (unofficial) support through Microsoft. Another good site is WinProg.NET, the website for EFNet's #Winprog and also a site with a number of good tutorials and resources.
That said, there's really not much better than MSDN for looking up pretty much anything you want to know about developing for Windows. Of course, MSDN is more a reference than a tutorial site, so I can understand why new Windows programmers can feel lost in it. That's where sites like CodeGuru, The Code Project, et al come in.
And he can get a fancy alpha-blended PuTTY here. However, the way I understood it, he was asking for a server, not a client. PuTTY is only a client (ssh client, scp, sftp, etc).
Well, that obviously depends on whether you're talking about "Linux" or "Lunix", of course.
If you're the same vhost-kiddie Jon from EFNet (the one who caused the *!jon@* username ban in EFNet's #Linux), then I'm sure all of your OPN #debian kickbans have been legitimate and warranted. I'm just surprised that they let you back in just to kickban you again, rather than keeping you out indefinitely.
If you're a different Jon, then nevermind.
Considering the name "Debian" came from "Deb" and "Ian", I'm of the opinion that it should be pronounced as such. "Dehb-ee-un". Then again, we may just be wading into Holy War territory, like "Li-nucks" vs. "Lie-nucks" vs "Lee-nucks" (who actually says the last?).
I bought a German car, and it's not diesel-based, so the simple act of buying a German car does not necessarily mean it's not going to use gasoline.
I agree 100%. I didn't mean I was going to bitch and moan, only that many /.'ers and other linux/*nix zealots do bitch and moan, and thus will continue to do so in the future as well. Having a 3D-accelerated desktop will only give them more fuel for the bitching and moaning, regardless of whether or not there really is a reason to complain.
Microsoft doesn't necessarily need Apple to push them in that direction, since they're already going there. Maybe not with Longhorn, but soon (say, within 5 years, which I guess isn't "soon" in computer time, but it's still relatively soon) you can expect DirectX to be the de facto standard for displaying anything on Windows. No more GDI, nor more GDI+ (which is better than GDI, but is not hardware accelerated by many drivers yet), OpenGL probably just as a wrapper for DX (or at least by default. I'm sure hardware vednors will still write OpenGL ICDs if the demand is there), etc.
Of course, once that happens, expect to hear even more bitching and complaining about having such a heavy GUI on a server-class OS (I guess they could stick with the current GUI for their server-level versions and the DX-based GUI for consumer-grade and workstation versions, but I doubt that would happen for consistency purposes). Anyway, by that time, a DirectX-based interface won't be any heavier (relatively) on future hardware than the current GUI is on current hardware.
Are you sure you don't mean "a lot" instead, considering that "alot" isn't a word?
Two problems with that.
- Look: You're relying on skins to match the look&feel, which means you either pick a skin and use it on all platforms, or you have to programmatically figure out which platform you're on and pick the most-appropriate skin. Giving the user the option to pick their theme would work, too, but that's a bit of a cop-out if your goal is to fit in with the L&F of a given platform.
- Feel: Assuming you figure out #1, you still have the issue of "feel", or more precisely "consistency". Just browsing the screenshots, it appears that the themes don't actually change the "feel" of any widgets, only the look. That means things like scrollbars are always going to have the NeXT-style arrows, even though things like Windows don't use those types of scroll ends. So, even though your app may now look like a native app, it's not going to act like one.
Skins can only do so much. In this case, I think choosing to use skins is a suboptimal solution. Why go to all the trouble to implement skinning in your application, when you could get native-L&F compatibility for free (and be able to leverage any system/widget kit-wide skinning capabilities) if the runtime was simply developed correctly?Of course, exceptions can be made. Just as my own personal rule of thumb, if the application is "arty" (a media player, movie player, fancy image viewer, etc), then making it skinnable separate from the OS is a viable option. However, if the application is more mundane, like a word processor or some business app or an IRC client (this could probably fit in either category) or a web browser (good example: galeon; bad example: mozilla), you should try to blend into the look&feel for your target platform (.NET is a platform, but here I mean the platform on which the .NET platform is running and not the .NET platform itself). Of course, there have been numerous apps that have broken this rule of thumb (ever see the old IBM apps that came with the consumer Aptivas? a PIM that looked like a day organizer, a phone app that looked like a phone, etc. They were horrible. Even the CD player that looked like a CD player was awful, and I'm usually okay with media players being funky).
quoting the whole parent, for it was from an AC:
I can only assume you were being sarcastic about the success of AWT, so I won't bother with that. However, as far as Look&Feel goes, I believe that Swing got it wrong. According to Swing (and things like Mozilla's XUL), it's important for your application to look exactly the same across all systems on which it runs. I disagree, as do many others. Instead, your application should adopt the look&feel of the target platform you're using. Do you really want an ugly GTK-looking thing on Mac OS X? It will look really out of place among all the pretty OS X apps. Same goes for on Windows XP. The new Visual Style theming capability is great, but I get annoyed when I use an app that doesn't support visual styles. All of my other apps look great, all of them using the same theme. But there's just that one that looks completely out of place. No, it's better for something like this that you implement the backend using native widget sets, and your runtime will take care of figuring out what it should use (depending on where you're running of course).
The problem with AWT is that it was basically dumbed down, trying to find a least common denominator API that would make it easy to implement AWT for most platforms. Rather, a better approach would be what Windows.Forms does. It defines certain things (you have forms, buttons, scrollbars, toolbars, etc). Sure, a lot of these things are drawn directly from Windows, but they can be implemented on many other platforms as well. Maybe your GTK-based backend has to munge together three or for different widgets to implement some single widget in Windows.Forms, but that's okay. You do it once in the runtime, and then you don't ever have to do it again, and you don't limit the high-level API based on the limitations of the underlying API. If that means that Mono does end up just scrapping GTK and going directly down to GDK, so be it. I personally think they can implement Windows.Forms just fine using GTK.
Already been done. It's called Rotor, and is a Shared Source project, meaning you can see the source and modify it for non-commercial uses, and it even has a nice clause saying that you can't taint yourself by looking at the code (oh, if only the GPL had such a clause. Instead, I can't look at GPL'ed software for fear of tainting my thought processes and inadvertantly ending up with GPL'ed code in software I write). Rotor is mostly meant for academic use and study, and is just a reference implementation (for instance, the GC is very primitive, and is much better in the .NET runtime from Microsoft). However, it builds for both Windows and FreeBSD (probably other BSDs).
Not from Microsoft. You could probably compile Rotor with minor changes on a Linux system, but it'll be completely unsupported by MSFT (well, more unsupported than Rotor already is, which doesn't have any official support but the dev team helps out when they can).
You'd be wrong, of course. The reason people bring this up is because Microsoft once used the reference implementation of the TCP/IP stack which just happened to come from a BSD (hrm ... the BSD license is very liberal, not forcing you into any specific license, which makes it perfect for providing reference implementations -- anybody can start with that implementation and change it how they please and not be stuck with the GPL). XP is based on Win2K, which is based on NT4, which is based on earlier NTs, which ultimately derived from the same people that wrote VMS, so you could say that XP is a descendant (several generations removed) of VMS, but you won't find much (any?) VMS code in XP since NT wasn't directly based on VMS (just the concepts and ideas). (Throw some OS/2 in there, just to be complete.) However, XP != BSD, nor would I expect Microsoft to release any BSD-backed (or other *nix-backed) OS in the near-to-mid future (who knows about the long term, really? It's probably safe to say "not likely" here).
What's more, if you don't want to use the VS.NET IDE, save yourself $800+ and just download the framework for free (I would post a URL, but my internet connection at work is all wonky. Look for it at MSDN). You get all the commandline tools necessary for compilation, so you can use your own text editor (vim, source insight, notepad if you must, etc), cobble together some makefiles, and build all the .NET apps you want for free. Sure, you don't get the fancy Forms designer, but if you're not doing GUI development, what's that matter? And if you are, well, anything you can do with the Forms designer, you can do with code.
And that's the problem. There shouldn't need to be any such thing as "GTK#", because Mono should be implementing Windows.Forms instead. It would then be the responsibility of the runtime on whatever system to translate these Windows.Forms calls into some widget set (Windows.Forms on Windows already translates these to Win32 calls, I believe the Rotor implementation for FreeBSD translates Windows.Forms to TK, and Mono should be implementing a GTK backend for this). The other plus for this is that if Mono in the future decides to use QT, or upgrades the runtime to use a newer, incompatible GTK version, there should be no change to the .NET app. You're not tied to GTK, just .NET. How the runtime implements Forms is not (should not be) a concern for the app-level programmer.
I disagree. Cheaper is usually not enough. It also has to be convenient. Personally, I don't use public transportation very often (never where I live, and only rarely when I visit other places) because it's just plain inconvenient (side note: I also enjoy driving my car, which means public transportation has to be able to provide an even higher utility for me to choose to use it). I disagree with taxing other forms of travel to encourage use of public transportation. If you want me to use it, make it affordable and convenient, and provide me with benefits that I won't get by driving my car (not necessarily monetary, either. Even with current gas prices, I'd still choose to drive than ride the transit system).
I guess if I were in a more populous area (Seattle only counts if you're in the downtown area, which I'm not) public transportation would be a more viable option. However, I'm not, and the current implementations here are not viable for me. Therefore, I don't use it even though 50% of my registration renewal fee is a public transportation tax.
It's long-ish, but not overly long. For a comparison that you may be more familiar with, consider the time it takes to compile the Linux kernel, your chosen libc, other libs you'll eventually need (say, gtk and/or qt, etc), X, GNOME or KDE, some apps (xmms, xine, a couple editors, etc), and probably 8 or 9 other things I'm forgetting right now. You'll probably come up with a similar number (probably smaller, but there's also probably less code in all the above tools).
That's not to say it can't be made faster. I don't know whether that time was on a multi-threaded compile or not, but I'd sure hope so given that their build machines were 4-way machines. Also, note that they didn't say what speed the P3s were. 4 P3-500s will surely compile slower than 2 p3-1.2GHzs. Nor did they say if those were Xeons or not (larger cache is better for compiling). The obvious solution is to throw hardware at the issue, but there are other things that can be done like incremental building, better sync/drains for multi-threaded compiles, more efficient compilers and build scripts, etc.
ThemeXP is a site that you may find interesting, then. With a hack provided by TGTSoft to make XP not require visual styles be signed by Microsoft, you can change your theme to one of hundreds of themes out there. Don't like Luna or Classic? Find, go find something you do like over at ThemeXP. XP visual styles have really been maturing lately. When TGTSoft first did their hack, every theme released was just a recoloration or minor hack on Luna, or an attempt to copy Aqua. Now, there are some very neat, very professional-looking original themes out there. Check it out.
Yeah, that would be it. Curse my metal fingers.
I think the difference here is that you assume that they're not pushing it right now (and thus, will do so in the future, if that's 3 or 5 or 7 years from now). From what I saw, it seems like they're not planning on doing marketing ever, whether they hit a useable state or not. I agree with you that right now is not the time to advertise their product. Maybe two years from now they should, but it sounds like they don't plan on it.
As far as Linux being a fluke in this regard, all I can say is that times change. Back when Linus was first starting Linux, nothing like that had ever really been done before (okay, so there was the GNU stuff, and the HURD that will never get out of alpha ...). "Like that" meaning wide-scale collaboration via the internet on something that amounted to just a pet project at the time. People are jaded now. You can't just pop in to a relevant group on usenet and say "hey, I'm working on this neat OS, anybody want to help?" and get useful offers. Same goes for putting up a SourceForge page. In short, it's much harder these days to gather the kind of developer group Linus did because it's been done before. There's nothing really novel about it anymore. As for what that has to do with Linux "making it" without Linus having to market the kernel to the distributors, I think the fact that it gathered a large development group was enough for people to start consider distributing it as a full product rather than as a roll-your-own system. As a general rule of thumb, don't plan on those kinds of coincidences if your goal is to get people to use your software.