MSN China says it must comply with local laws, but there is no Chinese law against the use of these words.
Well, I guess "law" here means actions to not anger the government. A government (not only the Chinese) can always find a real law to cause you trouble with if they think you deserve a little punishment for some offense. Or they just pass one;-)
After all these years of computer development, there is only one commercial PC operating system around (please note the word 'commercial').
Almost. I've just read that YellowTab (server is down ATM) has just sent their Zeta OS (formerly known as Be OS) to the press and that retailers will receive the packages in about two weeks... so there is a competitor. But I wouldn't hold my breath until it can rival Windows in number of copies sold;-)
And then there's eComStation, formerly known as OS/2, the "would have been better if marketing would have done a better job" brother of WinNT.
I'll explain to you why I'd like to have one of those Intel Macs: I'd like to have Mac OS X, but I can't afford a Mac (laptop).
Please note that while the following may sound like Windows-bashing it's really just my personal feelings and impressions. YMMV, and normally I don't like doing OS/language/dick-size wars in any way but you want to hear why someone would prefer Mac OS X over Windows;-)
I've switched from Windows to Linux about six years ago, and as a Linux power user I just don't get how primitive Windows is compared to todays Linux distros (yes, you read that right). Windows has a lot of advantages over Linux, the major ones are better 3rd party software installation/deinstallation and better support from both hardware and software makers. But it also has a lot of problems and is trying to educate the user too often or trying to enforce certain things even when the users knows better.
Windows has a nice idea, but why did they leave half-done feeling. For example, take the "Open file" dialog: there's a nice bar on the left with quick access icons to common locations. Why can't I add my own or remove ones that I think are unnecessary ? Nice idea, but they left too early. I miss a ton of UNIX features OS-wise and a lot of KDE features GUI-wise
(e.g. shade windows, multiple desktops, better file dialog, external task bar just to name a few).
And I don't get why Windows has no symlinks (all they have is this half-done hardlinks to directories, AKA junctions), why there are 10.000 APIs to access the devices instead of making them available as files and thus accessable with just a dozen standard file operations, why the shell is so primitive and lacking, why you sometimes can't start an executable on a SMB share while someone else is running it, why you can't overwrite or delete files that are in use by other applications, etc. pp. Joe Average and his mom don't care, but once you actually have to work with Windows you quickly see the limitations and warts of Windows.
This is why I've always wanted a Mac since Mac OS X came out, but I currently can't afford one (except for the Mini, but I need a laptop). It's UNIX with a really nice GUI and nice ideas. That's why I'm happy that I won't have to wait that long to finally get Mac OS X, although I'm not happy that they've ditched the PowerPC architecture. The x86 CPU architecture was hack to get to market quickly and we still have to pay for that (e.g. no real "general purpose" registers, every register has a special meaning except for the xmm registers which are too big for normal work). When switching to Intel chips I can really hope they do their own architecture and don't do the mistake of using that crappy IBM PC architecture (I'm talking about BIOS, the BIOS interrupts, PnP, A20, all that stuff that already were bad ideas 20 years ago but were done to quickly get to market as well).
I can give a concrete example on how we solved a few problems with Windows applications in a Linux-only environment.
I worked on a big migration project here in Bavaria, where the complete Blood Donation Service Of The Bavarian Red Cross switched from individual Windows desktops to a centralized application server/thin client system. I estimate this are about 1000 users affected. The migration was done about two years ago.
A short overview: The users are using Linux based thin clients which I've developed to connect to an array of application servers on which I've worked as well. Every site has its own application servers, in Munich we currently have three or four of them (Dual PIII 1.4GHz, 2GB RAM) and IIRC about 200 people do their daily work on them... no performance problems, but if we had we just would add another server. The thin clients connect to the servers through DNS round robin which is enough load balancing in this case. The application servers are just normal SuSE 8.0 servers with KDE 3.1 where I've configured KDE to restrict what users may do (e.g. they are not allowed to move the Kicker bar... we did things like this to prevent support calls like "My start bar is now on the right, help !";-).
Now, the Blood Donation Service people who are working in the areas where the donated blood is prepared and checked for diseases rely on a specific application which only runs on Windows. We evaluated running this application with Wine but it wasn't good enough for this application back then. To make a long story short, this is how we're doing it:
We have a few Linux servers on which we're running Windows terminal servers (I don't know which Windows) in VMWares. I explain the reason for this later. Clients who are working on the application servers connect to the Windows servers with rdesktop. The users' home directories are on NFS servers which means they get their home directory on every application server and on the Windows servers as well. This works very well. Only a few dozen people need to access Windows servers because of this and another industry-specific application.
We needed to identify which thin client is accessing the Windows application. Because rdesktop runs on the application server we needed to do a trick: I've enhanced our thin clients to include a finger server which tells finger clients the MAC address of the thin client. When the users log in to the application server the MAC address is finger'ed from the thin client and stored in an environment variable. And when the users then start their rdesktop the MAC address is passed as host name;-) So Windows thinks the user is connecting from, say, a computer called 00AB12CD34EF and this can be evaluated on the Windows side:-)
Now for the reason why we run Windows in VMWares: the whole point of our architecture is that we have a master site where all bavarian application servers are configured (new applications get installed there, for example) and they synchronize through rsync to all sites. This means all application servers are in sync and changes are only done on exactly one server. We wanted to do the same with Windows. In short: it's not possible with Windows-only methods and applications because of some limitations of Windows. The best solution is to run Windows in a Linux VMWare and rsync the VMWare disk from the master server to all site servers:-)
This setup is running full-scale (i.e. in the complete Blood Donation Service of Bavaria) for about one and a half years, and it's running very well. No major problems. Even the 50+ secretaries didn't have any major problems (except for a bug in the Linux version of Acrobat Reader 5.0.x and PDF forms);-)
Problem is that Cell doesn't support AltiVec, AFAIK. This could be kind of a showstopper... but given Cell's extremely cool multimedia potential I really hope Apple would at least try to make a Mac with Cell:-)
No, the "locking" is done by encrypting the files and deleting the originals. It encrypts all files with certain endings (for example.jpg,.db,.doc,.pdf and.zip). If you don't have a backup and your undelete fails you have no way of restoring these files (I don't know which algorithm is used to encrypt the files but if he used AES you'll have let a really, really heavy machine brute-force for quite some days).
At least to a client of ours, who makes industrial machines and lasers, the biggest advantage of open source is that you know its future since you can control it yourself, if you must. After all you have the source at hand ! And if a feature is missing or misbehaving you can fix it yourself instead of waiting for months for a vendor to fix it.
That must be in real mode, where the 8086 back from 1981(?) is emulated. All x86's boot into this mode, even today... and waste our time, money, and hardware/BIOS developers nerves. In real mode you only have 16bit opcodes and registers but needed to be able to address more than just 64kB of RAM, so they introduced a way (segment and offset) to address with 24bit (like the whole processor, this was a quick hack to bring a 16bit version of the 8080 to market as fast as possible... we're still paying for the awful design decisions made back then).
You may have been running 64 bit linux for a little while on the x86 but you strike me as a guy never seen the joys of real mode vs. protected mode. You should Google up some of the angst filled rants from programmers who had to deal with it back in the day.
Note: my memory may serve me wrong, the following could contain errors.
The difference of real and protected mode that was alien to the developers wasn't so much about 16 or 32 bit but about the way memory was addressed. In real mode memory is addressed with a 24 bit hack and people where used to that. Additionally, they didn't have to care about memory protection and setting stuff up, real mode is just plain simple to use.
By contrast, the transition from 32 bit (protected mode) to 64 bit is very soft, as far as I remember there are a few new opcodes and a few new registers, but the hard stuff like addressing memory hasn't changed much to my knowledge... then again maybe someone who actually knows some AMD64 assembler could shed some light here ?
Actually for any large svn project, the users will notice a significant speed difference between a svn server that uses the efficient binary-formatted BDB backend compared to one that uses the ASCII-formatted FSFS.
FSFS is not "ASCII-formatted". And I didn't notice any difference when I switched our 3GB repository from BDB to FSFS half a years ago:-)
If you work on an svn-based project like KDE which is already run by somebody else, you will most likely be stuck with their choice of backend, more often than not you'll get all the hazards (and efficiency) of a Berkeley backend.
But in this case you don't have to worry as it's not your problem any more;-) And you're not the one to implement the backup (which everyone with a little common sense does). As a user you can't notice the backend differences anyways (except for a small corner-case: the speed of "svn annotate").
Because it's ugly and not very user friendly... if you've seen commercial bug trackers or stuff like Trac you'll notice the difference. Don't get me wrong, Bugzilla is a valuable tool and it does the job it needs to do, but the UI is horrible.
What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning
File/directory renaming. This is one of the most important things: you can easily move files around in a repository and thus rearrange your project directory structure. I'm forced to work on a big commercial project where we use CVS and the directory layout has grown like a cancer because some idiots couldn't get the layout clean in the first place and noone was able to correct it later (the CVS admin lacks the knowledge and the work necessary has become too big). This is a common CVS problem.
Atomic commits.
Cheap copies (which are used instead of tags and branches, more on this below).
Optional WebDAV support.
True binary file support (SVN only stores the deltas to previous versions while CVS has to store the complete file again if something changed... try versioning a 128MB binary file with CVS and watch your disk usage go up by 128MB with each commit).
There are two things that you'll find different when comming from CVS:
The first is the fact that you don't version single files but the whole repository. This is very strange at first, but you'll quickly notice that it's much better than versioning single files as most of the time a source change like a feature implementation affects more than one file. With CVS you don't know that two files were changed at once and that these changes belong together: with SubVersion you instantly know because you see that at revision XY two files where changed.
The other thing that seems odd is the "lack" of branches and tags like they're used in CVS: in CVS the repository file path stays the same while the working copy content is different according to the tag/branch. In SubVersion, you'll make a copy of a directory (in the repository) to start a branch. Thus the file path is different. I think the SubVersion way is cleaner and also more user/developer friendly but people that use CVS for years won't agree, I think;-)
SubVersion as a whole has more clean, thought-out-design feel, IMHO. Being a former CVS user myself I guarantee you that after working with SubVersion for a while CVS feels a bit hacked together.
If you're scared by the BDB backend then use the FSFS backend which is a filesystem based backend, like CVS uses RCS files.
We're using SubVersion for over two years now, versioning our in-house Linux distribution with which we're doing our products and we've never had any data loss (though we had some trouble with BDB back in the 0.xx days).
I don't want to bash RedHat on it, but I already have it: Ubuntu Hoary starts GDM before some stuff (I could see the startup of ACPId after the "starting GDM" message and before the GDM really appeared).
SuSE does this already as well... at least in 9.2, I think in 9.1 as well but I can't tell for sure. Heck, even Windows does this for years now !
There's still a lot of room for improvement. I once saw a nice demo implementation of a boot process controlled by make. The idea was that you specify the boot scripts and their dependencies in a Makefile and then do a "make -j" which will run as many as possible in parallel. Normal SysV init still runs each script one after another... parallel rc script execution would be the next big performance thing in the Linux startup procedure, IMHO.
If you've ever made a homepage or had to develop a web-based frontend for some application you'll quickly discover how bad IE is:
No transparent PNG support. There is a butt-ugly work around but my tests showed that the PNGs were shown 99% transparent, not 100%.
Crappy CSS support. IE doesn't even fully support CSS 1 ! I think CSS 1 is about ten years old now...
The CSS that are implemented by IE are often buggy.
JavaScript support is different.
All those non-standard HTML enhancements that IE introduced are carried around by people who don't care and then blame all other browsers to be crappy because they don't support IE's non-standard enhancements.
This is why I care for FireFox gaining momentum. Either FireFox will replace IE as the default browser (unlikely) or it will at least put some pressure on MicroSoft to try to improve IE (likely, it already happens).
That said, I really don't like Java. So many little things that make C# a better language....delegates/events, unsigned, easy interop with native code, structs, enums (which java finally got), ref and out parameters, no stupid physical directory hierarchies to match packages, etc...
You're right, I forgot about these language features. And yes, C# is a nicer language, but the question is whether those syntactic sugars justify switching the established framework and tools. After all, that's going to cost a lot of time and effort and without any other technical benefits I doubt nicer syntactic language features are worth the effort.
I've you're used to Java's SWING layouting, you'll find C#/.NET ridiculous and primitive.
In.NET, you only have one, fixed layouting mechanism which uses either "Dock" or "Anchor" (read specifics in MSDN's Control class documentation, specifically the "Anchor" and "Dock" properties).
If you're doing UI prototypes I really think that this is a severe limitation.
Other arguments against C#:
Java is a mature plattform, C#/.NET is quite new compared to Java
There are more people that know how to code in Java than people that know how to code in C# (it's not hard switching from one to other language-wise, but it's a hell of a lot different framework-wise)
While implementations of.NET exist for other plattforms (GNU Portable.NET/dotGNU and Mono) they are not completely compatible yet, especially not in the GUI side (I know that since I've fixed a lot of System.Windows.Forms bugs in Portable.NET the last months as part of my work). Compare that to the known-to-be-good cross-plattform support of Java !
Ask why the people that want to use C# think that C# is better suited for the job than Java. I'm pretty sure those people just recommend because it's currently the Programming-Language-Of-The-Month and buzzword-compliant. IMHO most technical reasons really speak against C# (except for properties and foreach, which just are nice syntactic sugar but really aren't worth the huge work of switching).
Ask what benefits those people expect to gain. Switching your existing stuff will cost a lot of money: it'll cost time for people to learn C# and especially the.NET framework, you'll surely have to use different tools which you'll have to deal with and especially learn their flaws and work around them.
Most people will like to use C# with MicroSoft's Visual Studio.NET because they know it and think it's good. Be warned that this is a nice IDE but is really bad at maintaining big projects. Especially big projects with subprojects. VS.NET often makes simple tasks that the developers of VS.NET didn't anticipate extremely hard or even impossible (for example, if you have several subprojects which depend on each other you can't have them compile into one directory: VS.NET will hold some files open and then complain that it can't open those files because "another" application has this file already open; MS knows this problem but simply says "don't compile into one directory", which will force you to do "unnatural" workarounds). I think VS.NET is a nice IDE for beginners and intermediates, but it way too limited and flawed for big projects.
In fact IMHO this is the only reason. All other reasons are ridiculous. To work there ? Oh come on, who likes to work ? To live there ? Why, the air is bad and it's rather boring up there. To survive ? The dumbest reason ever.
What's so bad with admitting that we humans are just f***ing curious ?:-)
A great many europeans say that about americans as well, so be happy that just not liking someone doesn't always result in a nuke being thrown;-) Earth would be a very lonely place then...
I prefer.cpio.bz2 because unlike tar cpio can handle special devices just fine (or do I miss some switch for tar which makes it able to handle devices and links ?). Since it's also in the POSIX standard this should be pretty portable as well.
Slashdot Mirror
MSN China says it must comply with local laws, but there is no Chinese law against the use of these words.
Well, I guess "law" here means actions to not anger the government. A government (not only the Chinese) can always find a real law to cause you trouble with if they think you deserve a little punishment for some offense. Or they just pass one ;-)
After all these years of computer development, there is only one commercial PC operating system around (please note the word 'commercial').
Almost. I've just read that YellowTab (server is down ATM) has just sent their Zeta OS (formerly known as Be OS) to the press and that retailers will receive the packages in about two weeks... so there is a competitor. But I wouldn't hold my breath until it can rival Windows in number of copies sold ;-)
And then there's eComStation, formerly known as OS/2, the "would have been better if marketing would have done a better job" brother of WinNT.
I'll explain to you why I'd like to have one of those Intel Macs: I'd like to have Mac OS X, but I can't afford a Mac (laptop).
Please note that while the following may sound like Windows-bashing it's really just my personal feelings and impressions. YMMV, and normally I don't like doing OS/language/dick-size wars in any way but you want to hear why someone would prefer Mac OS X over Windows ;-)
I've switched from Windows to Linux about six years ago, and as a Linux power user I just don't get how primitive Windows is compared to todays Linux distros (yes, you read that right). Windows has a lot of advantages over Linux, the major ones are better 3rd party software installation/deinstallation and better support from both hardware and software makers. But it also has a lot of problems and is trying to educate the user too often or trying to enforce certain things even when the users knows better.
Windows has a nice idea, but why did they leave half-done feeling. For example, take the "Open file" dialog: there's a nice bar on the left with quick access icons to common locations. Why can't I add my own or remove ones that I think are unnecessary ? Nice idea, but they left too early. I miss a ton of UNIX features OS-wise and a lot of KDE features GUI-wise (e.g. shade windows, multiple desktops, better file dialog, external task bar just to name a few).
And I don't get why Windows has no symlinks (all they have is this half-done hardlinks to directories, AKA junctions), why there are 10.000 APIs to access the devices instead of making them available as files and thus accessable with just a dozen standard file operations, why the shell is so primitive and lacking, why you sometimes can't start an executable on a SMB share while someone else is running it, why you can't overwrite or delete files that are in use by other applications, etc. pp. Joe Average and his mom don't care, but once you actually have to work with Windows you quickly see the limitations and warts of Windows.
This is why I've always wanted a Mac since Mac OS X came out, but I currently can't afford one (except for the Mini, but I need a laptop). It's UNIX with a really nice GUI and nice ideas. That's why I'm happy that I won't have to wait that long to finally get Mac OS X, although I'm not happy that they've ditched the PowerPC architecture. The x86 CPU architecture was hack to get to market quickly and we still have to pay for that (e.g. no real "general purpose" registers, every register has a special meaning except for the xmm registers which are too big for normal work). When switching to Intel chips I can really hope they do their own architecture and don't do the mistake of using that crappy IBM PC architecture (I'm talking about BIOS, the BIOS interrupts, PnP, A20, all that stuff that already were bad ideas 20 years ago but were done to quickly get to market as well).
You might want to re-evaluate Wine, it's become a lot better than it was 3 years ago. And of course CodeWeavers are available to help if you need us.
I know... but the established system works well enough and in these dimensions you tend to stick to Never change a running system :-)
I can give a concrete example on how we solved a few problems with Windows applications in a Linux-only environment.
I worked on a big migration project here in Bavaria, where the complete Blood Donation Service Of The Bavarian Red Cross switched from individual Windows desktops to a centralized application server/thin client system. I estimate this are about 1000 users affected. The migration was done about two years ago.
A short overview: The users are using Linux based thin clients which I've developed to connect to an array of application servers on which I've worked as well. Every site has its own application servers, in Munich we currently have three or four of them (Dual PIII 1.4GHz, 2GB RAM) and IIRC about 200 people do their daily work on them... no performance problems, but if we had we just would add another server. The thin clients connect to the servers through DNS round robin which is enough load balancing in this case. The application servers are just normal SuSE 8.0 servers with KDE 3.1 where I've configured KDE to restrict what users may do (e.g. they are not allowed to move the Kicker bar... we did things like this to prevent support calls like "My start bar is now on the right, help !" ;-).
Now, the Blood Donation Service people who are working in the areas where the donated blood is prepared and checked for diseases rely on a specific application which only runs on Windows. We evaluated running this application with Wine but it wasn't good enough for this application back then. To make a long story short, this is how we're doing it:
We have a few Linux servers on which we're running Windows terminal servers (I don't know which Windows) in VMWares. I explain the reason for this later. Clients who are working on the application servers connect to the Windows servers with rdesktop. The users' home directories are on NFS servers which means they get their home directory on every application server and on the Windows servers as well. This works very well. Only a few dozen people need to access Windows servers because of this and another industry-specific application.
We needed to identify which thin client is accessing the Windows application. Because rdesktop runs on the application server we needed to do a trick: I've enhanced our thin clients to include a finger server which tells finger clients the MAC address of the thin client. When the users log in to the application server the MAC address is finger'ed from the thin client and stored in an environment variable. And when the users then start their rdesktop the MAC address is passed as host name ;-) So Windows thinks the user is connecting from, say, a computer called 00AB12CD34EF and this can be evaluated on the Windows side :-)
Now for the reason why we run Windows in VMWares: the whole point of our architecture is that we have a master site where all bavarian application servers are configured (new applications get installed there, for example) and they synchronize through rsync to all sites. This means all application servers are in sync and changes are only done on exactly one server. We wanted to do the same with Windows. In short: it's not possible with Windows-only methods and applications because of some limitations of Windows. The best solution is to run Windows in a Linux VMWare and rsync the VMWare disk from the master server to all site servers :-)
This setup is running full-scale (i.e. in the complete Blood Donation Service of Bavaria) for about one and a half years, and it's running very well. No major problems. Even the 50+ secretaries didn't have any major problems (except for a bug in the Linux version of Acrobat Reader 5.0.x and PDF forms) ;-)
Problem is that Cell doesn't support AltiVec, AFAIK. This could be kind of a showstopper... but given Cell's extremely cool multimedia potential I really hope Apple would at least try to make a Mac with Cell :-)
No, the "locking" is done by encrypting the files and deleting the originals. It encrypts all files with certain endings (for example .jpg, .db, .doc, .pdf and .zip). If you don't have a backup and your undelete fails you have no way of restoring these files (I don't know which algorithm is used to encrypt the files but if he used AES you'll have let a really, really heavy machine brute-force for quite some days).
At least to a client of ours, who makes industrial machines and lasers, the biggest advantage of open source is that you know its future since you can control it yourself, if you must. After all you have the source at hand ! And if a feature is missing or misbehaving you can fix it yourself instead of waiting for months for a vendor to fix it.
Why do they say it accesses 2^24 bytes only?
That must be in real mode, where the 8086 back from 1981(?) is emulated. All x86's boot into this mode, even today... and waste our time, money, and hardware/BIOS developers nerves. In real mode you only have 16bit opcodes and registers but needed to be able to address more than just 64kB of RAM, so they introduced a way (segment and offset) to address with 24bit (like the whole processor, this was a quick hack to bring a 16bit version of the 8080 to market as fast as possible... we're still paying for the awful design decisions made back then).
You may have been running 64 bit linux for a little while on the x86 but you strike me as a guy never seen the joys of real mode vs. protected mode. You should Google up some of the angst filled rants from programmers who had to deal with it back in the day.
Note: my memory may serve me wrong, the following could contain errors.
The difference of real and protected mode that was alien to the developers wasn't so much about 16 or 32 bit but about the way memory was addressed. In real mode memory is addressed with a 24 bit hack and people where used to that. Additionally, they didn't have to care about memory protection and setting stuff up, real mode is just plain simple to use.
By contrast, the transition from 32 bit (protected mode) to 64 bit is very soft, as far as I remember there are a few new opcodes and a few new registers, but the hard stuff like addressing memory hasn't changed much to my knowledge... then again maybe someone who actually knows some AMD64 assembler could shed some light here ?
Actually for any large svn project, the users will notice a significant speed difference between a svn server that uses the efficient binary-formatted BDB backend compared to one that uses the ASCII-formatted FSFS.
FSFS is not "ASCII-formatted". And I didn't notice any difference when I switched our 3GB repository from BDB to FSFS half a years ago :-)
Of course if we had a data loss we'd just play in the backed up repository dump from the previous day ;-)
You can choose between a BDB based backend and a filesystem based backend.
If you work on an svn-based project like KDE which is already run by somebody else, you will most likely be stuck with their choice of backend, more often than not you'll get all the hazards (and efficiency) of a Berkeley backend.
But in this case you don't have to worry as it's not your problem any more ;-) And you're not the one to implement the backup (which everyone with a little common sense does). As a user you can't notice the backend differences anyways (except for a small corner-case: the speed of "svn annotate").
Why does bugzilla scare you?
Because it's ugly and not very user friendly... if you've seen commercial bug trackers or stuff like Trac you'll notice the difference. Don't get me wrong, Bugzilla is a valuable tool and it does the job it needs to do, but the UI is horrible.
What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning
There are two things that you'll find different when comming from CVS:
SubVersion as a whole has more clean, thought-out-design feel, IMHO. Being a former CVS user myself I guarantee you that after working with SubVersion for a while CVS feels a bit hacked together.
If you're scared by the BDB backend then use the FSFS backend which is a filesystem based backend, like CVS uses RCS files.
We're using SubVersion for over two years now, versioning our in-house Linux distribution with which we're doing our products and we've never had any data loss (though we had some trouble with BDB back in the 0.xx days).
I don't want to bash RedHat on it, but I already have it: Ubuntu Hoary starts GDM before some stuff (I could see the startup of ACPId after the "starting GDM" message and before the GDM really appeared).
SuSE does this already as well... at least in 9.2, I think in 9.1 as well but I can't tell for sure. Heck, even Windows does this for years now !
There's still a lot of room for improvement. I once saw a nice demo implementation of a boot process controlled by make. The idea was that you specify the boot scripts and their dependencies in a Makefile and then do a "make -j" which will run as many as possible in parallel. Normal SysV init still runs each script one after another... parallel rc script execution would be the next big performance thing in the Linux startup procedure, IMHO.
If you've ever made a homepage or had to develop a web-based frontend for some application you'll quickly discover how bad IE is:
This is why I care for FireFox gaining momentum. Either FireFox will replace IE as the default browser (unlikely) or it will at least put some pressure on MicroSoft to try to improve IE (likely, it already happens).
That said, I really don't like Java. So many little things that make C# a better language....delegates/events, unsigned, easy interop with native code, structs, enums (which java finally got), ref and out parameters, no stupid physical directory hierarchies to match packages, etc...
You're right, I forgot about these language features. And yes, C# is a nicer language, but the question is whether those syntactic sugars justify switching the established framework and tools. After all, that's going to cost a lot of time and effort and without any other technical benefits I doubt nicer syntactic language features are worth the effort.
I've you're used to Java's SWING layouting, you'll find C#/.NET ridiculous and primitive.
In .NET, you only have one, fixed layouting mechanism which uses either "Dock" or "Anchor" (read specifics in MSDN's Control class documentation, specifically the "Anchor" and "Dock" properties).
If you're doing UI prototypes I really think that this is a severe limitation.
Other arguments against C#:
Because we're curious.
In fact IMHO this is the only reason. All other reasons are ridiculous. To work there ? Oh come on, who likes to work ? To live there ? Why, the air is bad and it's rather boring up there. To survive ? The dumbest reason ever.
What's so bad with admitting that we humans are just f***ing curious ? :-)
A great many europeans say that about americans as well, so be happy that just not liking someone doesn't always result in a nuke being thrown ;-) Earth would be a very lonely place then...
My experience has been that ZIP doesn't compress as good as gzip, let alone bzip2. But yes, almost everyone can handle ZIPs.
.tar.gz, I'm not sure whether it can handle .tar.bz2 as well.
BTW, WinZIP can handle
I prefer .cpio.bz2 because unlike tar cpio can handle special devices just fine (or do I miss some switch for tar which makes it able to handle devices and links ?). Since it's also in the POSIX standard this should be pretty portable as well.