Why? If you're serious about optimization, you have to take every optimization guide of every CPU into account. Intel alone changed it around every time they published a new CPU. Of course, I'm a dinosaur and I actually read all the optimization rules, getting upset about minor changes. I've been programming assembly language for 25 years, and on 80x86 chips for 17 years.
You see, it's easy to be far behind on AMD technology. It's because I don't download AMD manuals often enough!
And that's, I guess, what happened in the case of software choosing inferior instructions for AMD. If you're only coding using the Intel manuals, you might think that a feature is not available on AMD, and hence, make the wrong choices.
So, that's the whole point.
I had an AMD box only once in my life, and only for a couple of months, so I never got myself acquainted with the latest AMD technology. As I pointed out to Chunk08, the latest AMD manuals that I have talk of MMX and SSE1, and the latest Intel manuals that I have talk about SSE2 and SSE3. So, I wouldn't know if there's SSE4.
All the CPU dependent code that I've written using these manuals checks for AMD and chooses inferior instructions for AMD, because I wasn't aware that there are AMD CPUs supporting these features. Me stupid!:-D
The last time I was dealing with AMD CPUs, the latest docs I had only had MMX and SSE1, but not SSE2 or SSE3 (which were in the latest Intel docs).
It's actually mandatory to check the CPU type before coding for a specific feature set. Since Intel and AMD CPUs have different feature sets that don't necessarily use the same feature bits, checking for AMD might be necessary.
So, my whole point is, you're getting upset about something that is standard procedure for CPU-dependent assembly language programming. Hundreds of thousands of assembly language programmers are doing that every day.
If someone isn't up to date with AMD features (like myself, like Lord Apathy pointed out), then naturally I'd make the wrong choices for AMD processor instructions.
code is actually added to the software to detect the type of processor and use suboptimal instructions with AMD processors. So its not just an issue with non-standardization. It's an issue with AMD processors. They don't support the features that Intels keeps putting into their CPUs to make them faster. If an assembly language programmer (or compiler writer) has to decide which instruction to choose, they're often confronted with limited choices on AMD CPUs. Take the SSE3 instruction set, for example, which exists on modern Pentium 4 but not AMD processors. An assembly language programmer (or compiler writer) has to choose then which AMD features to use, and there's AFAIK only SSE1 (and maybe SSE2) support (if it's enabled).
Among other things, I am an actual assembly language programmer, by passion, and I chose Intel CPUs for my boxes intentionally because they have a wider range of instructions (and also because they're more affordable!). When I want to support AMD CPUs, I have to read their manuals as well. So, unless I'm coding for an entire range of CPUs, I choose simply some specific features, test for their existence, and execute inferior code otherwise. Because I'm lazy, not because I'm conspiring against AMD!;-)
And C/C++ compilers, for instance, often output only generic code that would run on an 80286. If optimizations are enabled, the result strongly depends on the compiler. If someone is using Intel compilers, the output they'll be getting certainly doesn't support AMD processors, except with their defined functionality within the IA-32 architecture compliance range. AMD would do well by writing their own C/C++ compilers. Both the Intel and the AMD compilers (if they one day exist) should be free, or at least affordable, so that everyone can use them. Most Windows developers use Visual C++ or GCC, and their optimization (if it works) strongly depend on compiler switches, and so on. Most of the less experienced programmers out there aren't even aware of the compiler options, and if they are, they often don't check the output of the compiler. This what produces bug-ridden code, foremost (if the source code itself is bug-free).
So, you'll get this scenario: Developer team writes program in HLL (like C++). Program compiles and runs on the developer's machines. Coincidentially, they're all Intel boxes. Before the program is shipped, the compilation setup is switched to "release" mode, generating an optimized executable for circumstance XYZ (someone might've said "OK, we'll optimize for Pentium 4"), and running successful local tests. The code is then tested on a number of boxes, usually by a test team that's not aware of technical details. Their boxes happen to be Intel boxes as well, and a couple of AMD boxes, perhaps, but no-one notices. Then, the product is shipped. And bam! The program fails on a number of AMD boxes. Conspiracy? No, just bad testing and inconsiderate development!
One of AMD's contentions is that Intel's compiler is actually written to reduce speed and stability of programs it compiles when said programs are run on AMD processors. That's fairly normal because Intel and AMD don't sit on tables to consolidate their chip architectures and optimization strategies!;)
Assembly programmers know that AMD and Intel chips have a lot of different concepts. Even within the same product range, architecture changes and hence, optimization strategies. This is annoying to assembly programmers, because they have to optimize their code for every CPU there is.
A compiler can address optimization only when the CPU type is known. But that would mean compiling the program when it's on the user's computer. Instead, most programmers that use optimizers don't set the CPU type at all, which leaves the compiler to choose a default value, which nowadays might be a Pentium Pro level CPU (which would be ages old). If the programmer chooses to optimize for a particular CPU, say, Pentium 4, then the program will naturally run slower on AMD processors, because optimization strategies don't match.
Virtual machines like the JVM or the CLR can do a better job of optimization, because they know the user's CPU type.
So,... alright, I've had it with OpenSolaris for now!;-)
What I simply miss in this whole OpenSolaris business is a decent management console. Webmin doesn't work (login always fails), and SMC and other fun stuff has gone missing. Also, OpenSolaris changed a couple of concepts, so administration is changed somewhat.
There, I'm off to try the new OpenBSD now... in fact, I'm posting from it: Ah, the simplicity!:-P
Well, after a day or so testing it, I can say that it's fairly unstable. Services and packages don't work properly, like the network automagic service (NWAM) sometimes doesn't work. Developer packages like Netbeans don't work at all (broken dependencies) if installed by the package manager (also, there are multiple packages for the same application, which shall I select?). Today I installed it again because Vista died with obscure errors, this time giving it the whole hard drive. And yeah, NWAM doesn't work reliably, and I'll try installing developer packages again. Netbeans from java.sun.com (in the J2SDK+NB download) doesn't install now (installer silently fails). Etc. etc.; I guess I'll try using it some more. At least it's Solaris!;-)
It's possible to be used regardless if you set the thread affinity mask to a particular CPU. Then the RDTSC time stamp is quite usable. In fact, I've used it for over a decade for high-precision timing, especially on Windows with its awkward task scheduling (the performance timers in Windows often aren't sufficient). I've never encountered that time going backwards thing yet, thanks for mentioning it.
Linux might be - in some cases - easier to administrate (like when people just unpack the boxes, install the OS and a couple of packages and that's it, then never touch it again until it breaks), and might have lower TCO at first (you can run it on cheap custom or off-the-shelf boxes, OS license costs nil - although, Sun has been onto that for some years now - and you don't need special training for some administration tasks), but OSes like Solaris or AIX still have their place.
Once I set up an IBM pSeries server running AIX myself, just by using the awesome smit (and smitty) admin tools and by reading the manuals, in just a couple of hours. I admit Solaris is hard to admin if you don't find the right articles and documentation right away, but in my experience, Linux can be much more of a pain (except modern Ubuntu versions perhaps, but there are cases of updates that break the installation still, sometimes).
My favorite UN*X is AIX, followed by Solaris, then OpenBSD, then FreeBSD, then Fedora, then Ubuntu, and then Debian, and finally Slackware. You see from that, that Linux ranges for me on the end of the spectrum. I simply had too many problems with it. I'm glad I tried out other Linuxes after SuSE, btw. Otherwise, I would've abandoned Linux completely.
As a developer, I was deeply dissatisfied with some Linux systems. I decided not to program on Ubuntu in C or C++, for the time being, because I simply don't want to install all the documentation that I need manually (on Ubuntu, they're all single small packages). On FreeBSD and OpenBSD for instance, the entire documentation gets installed with the OS. The thing I hate most is when I type "man something" and I get a "file not found" message.
You see, this is not a "rhetoric", I'm not an affiliate of any organization. It's just my experiences as a user that formed my opinion.
Linux used to be very bug-ridden, and if that changes (or has changed), I'm glad. Linux is getting better every day, but that doesn't mean I have to program on Ubuntu, I'm content with using it as a multimedia platform. I prefer to program on Solaris and BSD (and AIX, if I could afford my own AIX box).
Only, that in some applications, it's not tens of files per second, it's thousands, or hundreds of thousands of files per second, as when you're checking and/or updating lots of small files, like source trees (for programs or web sites).
Yeah, it's not precise enough for some applications. picoseconds, or femtoseconds would've been more reasonable. Also, why not make a time stamp 128 bits instead of just 64 bits? Those 8 extra bytes wouldn't have made much of a difference. So, we'll have to wait for ext5 to support that...;-)
BTW, every IA-32 compliant CPU (PI,PII,III,4,etc. or Athlon etc.) has an instruction called RDTSC, which reads the CPU clock tick counter into a 64 bit register. This creates a timing facility that has a precision as high as the CPU clock. So 1 GHz clock cycle = 1 nanosecond precision.
Nanoseconds isn't that high a precision, when you think about the fact that everyone can buy a computer with 2.0 GHz nowadays, which would be a clock cycle of half a nanosecond (500 picoseconds).
Even my old Amiga 1000 computer had a timer with 2 nanosecond precision in 1986 with a CIA 8520 chip.
High-precision timestamps are used in cases when time stamps of files have to be compared to detected changes, as in the ubiquitous "make" program, which uses timestamps to detect whether a file has been modified.
The same applies to some scripting situations...
Anyway, the resolution is also geared at the big irons, on which processors run that exceed the teraflop range (1 THz cycle duration = 1 picosecond).
The reason why SuSE lost customers, is because they didn't test their packages. I cancelled my subscription after SuSE Linux 10.1, which had so many problems that I considered it worthless to use it any longer. SuSE does have some nice features, but they're useful only if they work. Also, I expect all packages in the repository to actually function, not crash when I run them. It makes no sense to include a package if it doesn't run. Other than to advertise "we have x packages in our distro". That's why I don't use SuSE anymore.
Addition: Compiz doesn't work for me, must be an earlier version, or, perhaps, a driver issue. It came up when I tried enabling visual effects in the GNOME Appearance applet, but GUI elements rendered incorrectly, most were invisible, and I needed a good bunch of fishing in the darkness to finally disable it again.;)
I downloaded OpenSolaris 2008.05, tested and installed it:
The LiveCD booted up very quickly, with a 64-bit x86 kernel on my Pentium Dual Core processor. Clicking on the driver info icon revealed that OpenSolaris recognized apparently all of my hardware correctly, including my USB MIDI interface. (printer was turned off, no scanner attached, so I don't know about them). One point of criticism about the LiveCD is that it doesn't initialize the network (network chip is recognized tho).
Next, I tried to install OpenSolaris on a free space on my second hard drive. The installer has a graphical user interface, and appears to be user-friendly. The driver selector panel is at first a bit weird to use, but its concept is easy enough to understand. After installation, however, I couldn't get Solaris to run, because I had the NeoGrub bootloader on the first hard disk (running GRUB4DOS), and I couldn't get it to mount the Solaris partition to boot from it. It also appears that the installer didn't install GRUB anywhere on the second drive (not in MBR, not at beginning of partition).
Then, I shrank my Windows Vista partition (which has to be on the first drive anyway), removed NeoGrub, and installed Solaris in the free space. That worked; BCD area is still intact. The Windows boot manager can be selected from the GRUB menu. I yet have to try to incorporate my Ubuntu and FreeBSD drives into the GRUB configuration.
After booting from hard disk using GRUB, Solaris comes up and boots into GDM. After logging in, I'm on the GNOME desktop. Testing the screen savers revealed that I have accelerated 3D (on an i915 compatible chipset; actually it's an i945). Compiz also seems to be installed somewhere, there's a Compiz configuration tool in GNOME. I didn't manage to use the cube, or anything, so I guess it has to be enabled first. Everything seems to work so far, I'm quite pleased with it!:) (Hell, I'm posting this using OpenSolaris!;) )
The only thing so far that doesn't work is an external USB drive that had been EFI formatted by Windows Vista. Disk sync errors are printed on the main console during boot. I haven't tried to mount the NTFS partition yet.
I'm curious about Solaris' stability. I've tried it 2 times already (Solaris 10 x86, two different releases, don't remember which), and the second time GNOME decayed to the point it was unusable, but that was GNOME 2.6.8. On OpenSolaris 2008.05, GNOME 2.20.1 is included. Let's see how well it works over time. Really, thanks guys, for making this release!:)
And to add to that: Linux was light years away from a proper AIO implementation in 2005 (perhaps still is). I consulted the man pages, and found nothing unusual until I saw the performance results. The signalling was also broken. I thought it was a common UN*X feature, being used to it for years of Solaris and AIX programming. That really shattered my belief in Linux. I had also assumed Linux had proper threading, but not so until 2.6, and on a totally unrelated note, in 1996 on Kernel 2.2.x (or was it 2.0.x), I found out that SYS V messaging was broken. Nice!! Talk about a hobbyist OS. No industrial-strength OS can afford to have those flaws, and that's what people are doing when they compare Linux to Solaris, and find that Linux would kill off Solaris in an instant. Not so, by far.
Linux 2.6 Kernel AIO (and its flaws)
Support for kernel AIO has been included in the 2.6 Linux kernel. (...) On ext2, ext3, jfs, xfs and nfs, these do not return an explicit error, but quietly default to synchronous or rather non-AIO behaviour (...) AIO read and write on sockets (doesn't return an explicit error, but quietly defaults to synchronous or rather non-AIO behavior) Linux kernel AIO to do list.
Google is your friend!;-)
(BTW and it was 2005 when I needed it; it killed the performance of my code because it was executed synchronously instead of asynchronously)
Well, it appears it's you who's grossly uninformed: If you read the proper specs, you'll see that the initial AIO implementation in Kernel 2.6 was performed synchronously. I don't know if this has been fixed now, but it was a major annoyance when I had to code for it.
You seem to be a MacOS X expert. Do you know if the Cocoa event handling is bug-ridden? I've had a problem once (as a user) with the text-to-speech function. It seemed the user interface got the keyboard input event at random. Sometimes it worked, sometimes it didn't. Is it a design flaw in Cocoa, or a bug in any involved application?
He goes on to talk about the lack of UI controls that are exported from "standard" Windows apps like Office to developers.
I think this is a general problem Microsoft has always had-- how many times have they introduced a new menubar or widget, not released this to any development environment That's true. If you look at what makes up the size of a Windows installation, it's over 90% components, of which 90% are undocumented (estimation). Just fire up an OLE browser, and see all the components that are documented nowhere. XP is 2 GB in size, and Vista 15 GB. Why don't they make all of these components available to developers? That would be a major step into making Windows more productive for developers.
This is where Apple seems to really come through-- rather than hide their new innovations (such as CoreGraphics, CoreData, etc), they immediately share them so that people who develop Mac applications have a much bigger common base of tools to work with. Why hide away the stuff that makes better [insert your system of choice here] programs?
In a way, Apple may actually be aiming for the simple, journeyman programmer that the author describes. They're more likely to use what's at hand-- you can make your iTunes clone without having to purchase nary a widget or toolkit! This sounds really interesting, indeed!
If I'd ever pick up on MacOS X programming, it would be for that reason. The libraries are really comprehensive. I hate XCode, but perhaps I can get other tools like Eclipse or something that could make this whole thing worthwhile. (And I'd need a more recent Mac, I only have a used old PowerPC box, which runs OpenBSD now; very stably so, btw)
However, Apple is major cash-cow business, they know how to sell new computers... Microsoft is less overt with that. But perhaps it'll bring me some joy as well, someday...;-)
Last time I lost data was because Windows Vista destroyed itself, after I installed FreeBSD on a spare partition. Apparently, Microsoft has changed the partition table layout again.
Linux is far from being up to par with a Solaris or AIX, or BSD.
For users, Linux is great; but for administrators and developers, it's not.
Does Linux support true AIO (asynchronous I/O) now? That's the most basic feature in Solaris or AIX, and required for some high-performance applications. Not to mention the threading and signalling quirks in various Linux kernel versions...
No, for programming, Linux is a nightmare... I just say "configure script", GNU autotools and other strange things that aren't properly documented.
It takes a proper UN*X platform to write a proper UN*X application. After it works on everything else, it can be ported to Linux...;-)
I can only say the featured article appears half-baked to me, and it's comical how Apple users always bring up GUI design issues, as if that was the most important thing in the world.
I tried Apple's XCode IDE last year, and I was put off by it's total lack of good UI design. XCode's editor cannot be customized, has a hair-line thin text cursor that is barely visible and a weird keyboard layout that originated somewhere in the 80ies (on MacOS and Amiga systems), that is totally uncomfortable to use nowadays. No mention of this in the article.
Also, the article mentions minor aspects of perceived Win32 and.NET flaws, when in fact the flaws are much bigger, and the short examples only give the impression that he has looked at them briefly at best. No mention of the GetFileSizeEx() function, for instance. The old GetFileSize() API was for NT 4 and Windows 95 and previous OSes (note how the older OSes have already been dropped from the platform compatibility list). GetFileSizeEx() API was new for Windows 2000, which is already over 8 years old.
Also, as has already been mentioned here, the article omits WPF, which is a fairly important development by Microsoft. It enables programmers to create 3D applications in XML! I tried it a number of times and it seems pretty good to me.
But the core statements about.NET and Win32 in that article are true. The.NET framework has (or rather, had, because we're talking.NET Framework 3.5 now) some very weak concepts. Also, the documentation team is far behind with the documentation; there's a lot to be left desired in that area. The Win32 API is much better documented still. If you develop your own controls, you might run into problems with.NET, because native timers and carets are not directly supported, for instance (Win32 API calls are required for that).
I've been developing mostly for Windows in the past 13 years, with the occasional UN*X and OS/2 thrown in, and I still find that all of them lack some of the flexibility and power of an AmigaOS, which I used and programmed on from 1986 to 2001. THAT would be the ideal development platform, because it allows unrestricted programming; sadly, Commodore folded in 1994, and not much good happened since then. GUI and development guidelines were followed by Amiga programmers voluntarily, out of interoperability concerns. All major (and many minor) applications had an ARexx scripting interface, for instance. GUI guidelines were often followed also, because the guideline manual (or chapter, in the older RKMs) was thin and easy to read. BTW, the Tool Info feature of the Workbench is still unmatched today. A user could easily configure their applications to their desires, or even configure the entire user experience to their liking, booting up Commodities (which were similar to Windows Services, except they supported user interfaces) as needed, that even sometimes changed how individual controls behaved. Tools like MagicMenu changed the entire menu system for all applications, and so on. Virtual memory and memory protection could be added by the user, and so on. There's much that needs to be said about the Amiga platform, that made it ideal for developers. For instance, the non-copying message system that was easily used to communicate between threads, making multithreaded applications easy, and that also served as an IPC mechanism.
I can tell you: On all so-called "modern platforms", everything is much, much more complicated than it needs to be. OS implementors only have to look at the things that have already existed, instead of reinventing the triangle-shaped wheel over and over.;-)
Check out the free versions of Microsoft's development tools sometime, called Visual Studio Express editions. AFAIK, they can be used by enterprise developers for free as well, check out the license. I guess, it's because they're supposed to be "appetizers" for "the real things". But they work quite well, if you don't demand too much.
The Windows SDK is also a free download, containing the full OS documentation, build environments and samples.
IMNSHO, that's just a non-issue to claim that development for Windows would be expensive.
Besides, there are other good, free development tools for Windows, like Watcom C/C++ (which is BTW the only compiler natively supporting DOS, Win 3.1, Win32, OS/2, and NLM development, with Linux support planned LTIC).
Free IDEs for.NET development include Eclipse, and others.
Slashdot Mirror
Why? If you're serious about optimization, you have to take every optimization guide of every CPU into account. Intel alone changed it around every time they published a new CPU. Of course, I'm a dinosaur and I actually read all the optimization rules, getting upset about minor changes. I've been programming assembly language for 25 years, and on 80x86 chips for 17 years.
You see, it's easy to be far behind on AMD technology. It's because I don't download AMD manuals often enough!
:-D
And that's, I guess, what happened in the case of software choosing inferior instructions for AMD. If you're only coding using the Intel manuals, you might think that a feature is not available on AMD, and hence, make the wrong choices.
So, that's the whole point.
I had an AMD box only once in my life, and only for a couple of months, so I never got myself acquainted with the latest AMD technology. As I pointed out to Chunk08, the latest AMD manuals that I have talk of MMX and SSE1, and the latest Intel manuals that I have talk about SSE2 and SSE3. So, I wouldn't know if there's SSE4.
All the CPU dependent code that I've written using these manuals checks for AMD and chooses inferior instructions for AMD, because I wasn't aware that there are AMD CPUs supporting these features. Me stupid!
The last time I was dealing with AMD CPUs, the latest docs I had only had MMX and SSE1, but not SSE2 or SSE3 (which were in the latest Intel docs).
It's actually mandatory to check the CPU type before coding for a specific feature set. Since Intel and AMD CPUs have different feature sets that don't necessarily use the same feature bits, checking for AMD might be necessary.
So, my whole point is, you're getting upset about something that is standard procedure for CPU-dependent assembly language programming. Hundreds of thousands of assembly language programmers are doing that every day.
If someone isn't up to date with AMD features (like myself, like Lord Apathy pointed out), then naturally I'd make the wrong choices for AMD processor instructions.
Among other things, I am an actual assembly language programmer, by passion, and I chose Intel CPUs for my boxes intentionally because they have a wider range of instructions (and also because they're more affordable!). When I want to support AMD CPUs, I have to read their manuals as well. So, unless I'm coding for an entire range of CPUs, I choose simply some specific features, test for their existence, and execute inferior code otherwise. Because I'm lazy, not because I'm conspiring against AMD!
And C/C++ compilers, for instance, often output only generic code that would run on an 80286. If optimizations are enabled, the result strongly depends on the compiler. If someone is using Intel compilers, the output they'll be getting certainly doesn't support AMD processors, except with their defined functionality within the IA-32 architecture compliance range. AMD would do well by writing their own C/C++ compilers. Both the Intel and the AMD compilers (if they one day exist) should be free, or at least affordable, so that everyone can use them. Most Windows developers use Visual C++ or GCC, and their optimization (if it works) strongly depend on compiler switches, and so on. Most of the less experienced programmers out there aren't even aware of the compiler options, and if they are, they often don't check the output of the compiler. This what produces bug-ridden code, foremost (if the source code itself is bug-free).
So, you'll get this scenario: Developer team writes program in HLL (like C++). Program compiles and runs on the developer's machines. Coincidentially, they're all Intel boxes. Before the program is shipped, the compilation setup is switched to "release" mode, generating an optimized executable for circumstance XYZ (someone might've said "OK, we'll optimize for Pentium 4"), and running successful local tests. The code is then tested on a number of boxes, usually by a test team that's not aware of technical details. Their boxes happen to be Intel boxes as well, and a couple of AMD boxes, perhaps, but no-one notices. Then, the product is shipped. And bam! The program fails on a number of AMD boxes. Conspiracy? No, just bad testing and inconsiderate development!
Assembly programmers know that AMD and Intel chips have a lot of different concepts. Even within the same product range, architecture changes and hence, optimization strategies. This is annoying to assembly programmers, because they have to optimize their code for every CPU there is.
A compiler can address optimization only when the CPU type is known. But that would mean compiling the program when it's on the user's computer. Instead, most programmers that use optimizers don't set the CPU type at all, which leaves the compiler to choose a default value, which nowadays might be a Pentium Pro level CPU (which would be ages old). If the programmer chooses to optimize for a particular CPU, say, Pentium 4, then the program will naturally run slower on AMD processors, because optimization strategies don't match.
Virtual machines like the JVM or the CLR can do a better job of optimization, because they know the user's CPU type.
So, ... alright, I've had it with OpenSolaris for now! ;-)
... in fact, I'm posting from it: Ah, the simplicity! :-P
What I simply miss in this whole OpenSolaris business is a decent management console. Webmin doesn't work (login always fails), and SMC and other fun stuff has gone missing. Also, OpenSolaris changed a couple of concepts, so administration is changed somewhat.
There, I'm off to try the new OpenBSD now
Well, after a day or so testing it, I can say that it's fairly unstable. Services and packages don't work properly, like the network automagic service (NWAM) sometimes doesn't work. Developer packages like Netbeans don't work at all (broken dependencies) if installed by the package manager (also, there are multiple packages for the same application, which shall I select?). Today I installed it again because Vista died with obscure errors, this time giving it the whole hard drive. And yeah, NWAM doesn't work reliably, and I'll try installing developer packages again. Netbeans from java.sun.com (in the J2SDK+NB download) doesn't install now (installer silently fails). Etc. etc.; I guess I'll try using it some more. At least it's Solaris! ;-)
It's possible to be used regardless if you set the thread affinity mask to a particular CPU. Then the RDTSC time stamp is quite usable. In fact, I've used it for over a decade for high-precision timing, especially on Windows with its awkward task scheduling (the performance timers in Windows often aren't sufficient). I've never encountered that time going backwards thing yet, thanks for mentioning it.
Linux might be - in some cases - easier to administrate (like when people just unpack the boxes, install the OS and a couple of packages and that's it, then never touch it again until it breaks), and might have lower TCO at first (you can run it on cheap custom or off-the-shelf boxes, OS license costs nil - although, Sun has been onto that for some years now - and you don't need special training for some administration tasks), but OSes like Solaris or AIX still have their place.
Once I set up an IBM pSeries server running AIX myself, just by using the awesome smit (and smitty) admin tools and by reading the manuals, in just a couple of hours. I admit Solaris is hard to admin if you don't find the right articles and documentation right away, but in my experience, Linux can be much more of a pain (except modern Ubuntu versions perhaps, but there are cases of updates that break the installation still, sometimes).
My favorite UN*X is AIX, followed by Solaris, then OpenBSD, then FreeBSD, then Fedora, then Ubuntu, and then Debian, and finally Slackware. You see from that, that Linux ranges for me on the end of the spectrum. I simply had too many problems with it. I'm glad I tried out other Linuxes after SuSE, btw. Otherwise, I would've abandoned Linux completely.
As a developer, I was deeply dissatisfied with some Linux systems. I decided not to program on Ubuntu in C or C++, for the time being, because I simply don't want to install all the documentation that I need manually (on Ubuntu, they're all single small packages). On FreeBSD and OpenBSD for instance, the entire documentation gets installed with the OS. The thing I hate most is when I type "man something" and I get a "file not found" message.
You see, this is not a "rhetoric", I'm not an affiliate of any organization. It's just my experiences as a user that formed my opinion.
Linux used to be very bug-ridden, and if that changes (or has changed), I'm glad. Linux is getting better every day, but that doesn't mean I have to program on Ubuntu, I'm content with using it as a multimedia platform. I prefer to program on Solaris and BSD (and AIX, if I could afford my own AIX box).
Only, that in some applications, it's not tens of files per second, it's thousands, or hundreds of thousands of files per second, as when you're checking and/or updating lots of small files, like source trees (for programs or web sites).
Yeah, it's not precise enough for some applications. picoseconds, or femtoseconds would've been more reasonable. Also, why not make a time stamp 128 bits instead of just 64 bits? Those 8 extra bytes wouldn't have made much of a difference. So, we'll have to wait for ext5 to support that ... ;-)
BTW, every IA-32 compliant CPU (PI,PII,III,4,etc. or Athlon etc.) has an instruction called RDTSC, which reads the CPU clock tick counter into a 64 bit register. This creates a timing facility that has a precision as high as the CPU clock. So 1 GHz clock cycle = 1 nanosecond precision.
Nanoseconds isn't that high a precision, when you think about the fact that everyone can buy a computer with 2.0 GHz nowadays, which would be a clock cycle of half a nanosecond (500 picoseconds).
...
Even my old Amiga 1000 computer had a timer with 2 nanosecond precision in 1986 with a CIA 8520 chip.
High-precision timestamps are used in cases when time stamps of files have to be compared to detected changes, as in the ubiquitous "make" program, which uses timestamps to detect whether a file has been modified.
The same applies to some scripting situations
Anyway, the resolution is also geared at the big irons, on which processors run that exceed the teraflop range (1 THz cycle duration = 1 picosecond).
The reason why SuSE lost customers, is because they didn't test their packages. I cancelled my subscription after SuSE Linux 10.1, which had so many problems that I considered it worthless to use it any longer. SuSE does have some nice features, but they're useful only if they work. Also, I expect all packages in the repository to actually function, not crash when I run them. It makes no sense to include a package if it doesn't run. Other than to advertise "we have x packages in our distro". That's why I don't use SuSE anymore.
Addition: Compiz doesn't work for me, must be an earlier version, or, perhaps, a driver issue. It came up when I tried enabling visual effects in the GNOME Appearance applet, but GUI elements rendered incorrectly, most were invisible, and I needed a good bunch of fishing in the darkness to finally disable it again. ;)
I downloaded OpenSolaris 2008.05, tested and installed it:
:) (Hell, I'm posting this using OpenSolaris! ;) )
:)
The LiveCD booted up very quickly, with a 64-bit x86 kernel on my Pentium Dual Core processor. Clicking on the driver info icon revealed that OpenSolaris recognized apparently all of my hardware correctly, including my USB MIDI interface. (printer was turned off, no scanner attached, so I don't know about them). One point of criticism about the LiveCD is that it doesn't initialize the network (network chip is recognized tho).
Next, I tried to install OpenSolaris on a free space on my second hard drive. The installer has a graphical user interface, and appears to be user-friendly. The driver selector panel is at first a bit weird to use, but its concept is easy enough to understand. After installation, however, I couldn't get Solaris to run, because I had the NeoGrub bootloader on the first hard disk (running GRUB4DOS), and I couldn't get it to mount the Solaris partition to boot from it. It also appears that the installer didn't install GRUB anywhere on the second drive (not in MBR, not at beginning of partition).
Then, I shrank my Windows Vista partition (which has to be on the first drive anyway), removed NeoGrub, and installed Solaris in the free space. That worked; BCD area is still intact. The Windows boot manager can be selected from the GRUB menu. I yet have to try to incorporate my Ubuntu and FreeBSD drives into the GRUB configuration.
After booting from hard disk using GRUB, Solaris comes up and boots into GDM. After logging in, I'm on the GNOME desktop. Testing the screen savers revealed that I have accelerated 3D (on an i915 compatible chipset; actually it's an i945). Compiz also seems to be installed somewhere, there's a Compiz configuration tool in GNOME. I didn't manage to use the cube, or anything, so I guess it has to be enabled first. Everything seems to work so far, I'm quite pleased with it!
The only thing so far that doesn't work is an external USB drive that had been EFI formatted by Windows Vista. Disk sync errors are printed on the main console during boot. I haven't tried to mount the NTFS partition yet.
I'm curious about Solaris' stability. I've tried it 2 times already (Solaris 10 x86, two different releases, don't remember which), and the second time GNOME decayed to the point it was unusable, but that was GNOME 2.6.8. On OpenSolaris 2008.05, GNOME 2.20.1 is included. Let's see how well it works over time. Really, thanks guys, for making this release!
And to add to that: Linux was light years away from a proper AIO implementation in 2005 (perhaps still is). I consulted the man pages, and found nothing unusual until I saw the performance results. The signalling was also broken. I thought it was a common UN*X feature, being used to it for years of Solaris and AIX programming. That really shattered my belief in Linux. I had also assumed Linux had proper threading, but not so until 2.6, and on a totally unrelated note, in 1996 on Kernel 2.2.x (or was it 2.0.x), I found out that SYS V messaging was broken. Nice!! Talk about a hobbyist OS. No industrial-strength OS can afford to have those flaws, and that's what people are doing when they compare Linux to Solaris, and find that Linux would kill off Solaris in an instant. Not so, by far.
Linux 2.6 Kernel AIO (and its flaws) Support for kernel AIO has been included in the 2.6 Linux kernel. (...) On ext2, ext3, jfs, xfs and nfs, these do not return an explicit error, but quietly default to synchronous or rather non-AIO behaviour (...) AIO read and write on sockets (doesn't return an explicit error, but quietly defaults to synchronous or rather non-AIO behavior) Linux kernel AIO to do list.
Google is your friend!
(BTW and it was 2005 when I needed it; it killed the performance of my code because it was executed synchronously instead of asynchronously)
Well, it appears it's you who's grossly uninformed: If you read the proper specs, you'll see that the initial AIO implementation in Kernel 2.6 was performed synchronously. I don't know if this has been fixed now, but it was a major annoyance when I had to code for it.
You seem to be a MacOS X expert. Do you know if the Cocoa event handling is bug-ridden? I've had a problem once (as a user) with the text-to-speech function. It seemed the user interface got the keyboard input event at random. Sometimes it worked, sometimes it didn't. Is it a design flaw in Cocoa, or a bug in any involved application?
If I'd ever pick up on MacOS X programming, it would be for that reason. The libraries are really comprehensive. I hate XCode, but perhaps I can get other tools like Eclipse or something that could make this whole thing worthwhile. (And I'd need a more recent Mac, I only have a used old PowerPC box, which runs OpenBSD now; very stably so, btw)
However, Apple is major cash-cow business, they know how to sell new computers
Last time I lost data was because Windows Vista destroyed itself, after I installed FreeBSD on a spare partition. Apparently, Microsoft has changed the partition table layout again.
Linux is far from being up to par with a Solaris or AIX, or BSD.
...
... I just say "configure script", GNU autotools and other strange things that aren't properly documented.
... ;-)
For users, Linux is great; but for administrators and developers, it's not.
Does Linux support true AIO (asynchronous I/O) now? That's the most basic feature in Solaris or AIX, and required for some high-performance applications. Not to mention the threading and signalling quirks in various Linux kernel versions
No, for programming, Linux is a nightmare
It takes a proper UN*X platform to write a proper UN*X application. After it works on everything else, it can be ported to Linux
I can only say the featured article appears half-baked to me, and it's comical how Apple users always bring up GUI design issues, as if that was the most important thing in the world.
.NET flaws, when in fact the flaws are much bigger, and the short examples only give the impression that he has looked at them briefly at best. No mention of the GetFileSizeEx() function, for instance. The old GetFileSize() API was for NT 4 and Windows 95 and previous OSes (note how the older OSes have already been dropped from the platform compatibility list). GetFileSizeEx() API was new for Windows 2000, which is already over 8 years old.
.NET and Win32 in that article are true. The .NET framework has (or rather, had, because we're talking .NET Framework 3.5 now) some very weak concepts. Also, the documentation team is far behind with the documentation; there's a lot to be left desired in that area. The Win32 API is much better documented still. If you develop your own controls, you might run into problems with .NET, because native timers and carets are not directly supported, for instance (Win32 API calls are required for that).
;-)
I tried Apple's XCode IDE last year, and I was put off by it's total lack of good UI design. XCode's editor cannot be customized, has a hair-line thin text cursor that is barely visible and a weird keyboard layout that originated somewhere in the 80ies (on MacOS and Amiga systems), that is totally uncomfortable to use nowadays. No mention of this in the article.
Also, the article mentions minor aspects of perceived Win32 and
Also, as has already been mentioned here, the article omits WPF, which is a fairly important development by Microsoft. It enables programmers to create 3D applications in XML! I tried it a number of times and it seems pretty good to me.
But the core statements about
I've been developing mostly for Windows in the past 13 years, with the occasional UN*X and OS/2 thrown in, and I still find that all of them lack some of the flexibility and power of an AmigaOS, which I used and programmed on from 1986 to 2001. THAT would be the ideal development platform, because it allows unrestricted programming; sadly, Commodore folded in 1994, and not much good happened since then. GUI and development guidelines were followed by Amiga programmers voluntarily, out of interoperability concerns. All major (and many minor) applications had an ARexx scripting interface, for instance. GUI guidelines were often followed also, because the guideline manual (or chapter, in the older RKMs) was thin and easy to read. BTW, the Tool Info feature of the Workbench is still unmatched today. A user could easily configure their applications to their desires, or even configure the entire user experience to their liking, booting up Commodities (which were similar to Windows Services, except they supported user interfaces) as needed, that even sometimes changed how individual controls behaved. Tools like MagicMenu changed the entire menu system for all applications, and so on. Virtual memory and memory protection could be added by the user, and so on. There's much that needs to be said about the Amiga platform, that made it ideal for developers. For instance, the non-copying message system that was easily used to communicate between threads, making multithreaded applications easy, and that also served as an IPC mechanism.
I can tell you: On all so-called "modern platforms", everything is much, much more complicated than it needs to be. OS implementors only have to look at the things that have already existed, instead of reinventing the triangle-shaped wheel over and over.
Check out the free versions of Microsoft's development tools sometime, called Visual Studio Express editions. AFAIK, they can be used by enterprise developers for free as well, check out the license. I guess, it's because they're supposed to be "appetizers" for "the real things". But they work quite well, if you don't demand too much.
.NET development include Eclipse, and others.
The Windows SDK is also a free download, containing the full OS documentation, build environments and samples.
IMNSHO, that's just a non-issue to claim that development for Windows would be expensive.
Besides, there are other good, free development tools for Windows, like Watcom C/C++ (which is BTW the only compiler natively supporting DOS, Win 3.1, Win32, OS/2, and NLM development, with Linux support planned LTIC).
Free IDEs for