Ho hum. You figure Linux and other free software will soon start to fade out, maybe remaining as a bit player like shareware today. I think it's still on its way up and in, and will displace a lot more proprietary software before it peaks. We can't both be right. Wait and see, I guess.
I do think we have a little signal mismatch as far as defining free software. You say, for example,
TCP/IP and Unix were not free. They were funded by research grants from DARPA, and also various corporations like AT&T.
Funded by grants and corporations? Yes. Free? Yes. I don't see how those two are mutually exclusive. The real point is that DARPA and the University of California--Berkeley (AT&T had little to do with TCP/IP) found it worth their while to fund something that would be made available for free.
Likewise, when I mentioned HPC, you replied:
Its being pushed by various companies as a replacement for Unix, for their various agendas. IBM is just looking to sell the
hardware, so if they can get a customer to 'save' money on the OS, and steal a customer from Sun in doing so, then they looooove
Linux.
Once again - true, but that doesn't make IBM's investment somehow "non-free software". The fact is, this supports my point, which I guess I haven't made very clearly, so here it is: Free software (in my opinion) will continue to grow because the software landscape will continue to evolve, as it is already doing, such that it is in the best interests of certain companies to fund it. Yes, that's right. It's in IBM's best interest to give away thousands of hours of engineering talent for free.
Perfect example - look at SGI. They wanted to move from their MIPS-based big iron to the Intel Itanium, because in the long run Itanium gives you a lot more bang for the buck. (Best to leave unsaid what this implies about MIPS.) But they have a problem: their Unix platform, IRIX, has been developed for 15 years or so on MIPS and only in the past 4 years or so (version 6.5) has it achieved any respectable stability. Porting IRIX to the Itanium would take a long time, and then you have to convince all the third party vendors to ship Itanium IRIX binaries of all their products. Enter Linux. Linux runs on Itanium already, and it has a market presence. So SGI builds the Altix platform based on (a) their big iron NUMA technologies, (b) the Itanium chip (up to 64 per box) and (c) Linux.
Now, IRIX is famous for running well on huge machines. Linux was famous for running well on much smaller machines (4-8 CPUs seemed to be the practical limit, fairly recently). To get Linux to the point where they could use it on the Altix required a certain amount of investment by SGI. And yet, they figured it was cheaper to point their engineers at Linux and say "customise this for the Altix hardware, and make it scale to 64 CPUs" than the point those same engineers at IRIX and say "move this to Itanium".
(Why was this cheaper for SGI? Because IBM was already doing half the work already - to make Linux scale to their big machines! Crucial point to understand, if you wonder how the economics of free software cooperation can possibly work.)
If I'm reading you right, you wouldn't really consider this "free software" any more, since SGI (in this example) has invested so much of their own capital into it. I guess it's a matter of semantics - no matter who invested what money, the product is available for free to all comers, same as the original Linux.
ok. You don't see free software taking over "database servers and other backoffice functions":
Even with free alternatives, my company would still go with Sun; their database is already on Sun,
uses Sun hardware, and they can promise an easy upgrade. Also, there are people in-house who understand this stuff. Retraining
people to use OpenSQL kind of seems like the cart lead
Well I would think that the shared libs would just be black boxes. As long as the ABI is the same who cares what the internals of
the library is?
Right. But for 32/64-bit, the ABI is not the same. Take malloc() for example. It returns a 'void *' (or 'char *' in pre-ANSI C). In 32-bit mode this is a 32-bit pointer. In 64-bit mode it is a 64-bit pointer.
Thus you really can't mix 32-bit and 64-bit code without a lot of hackery - like the Apple 68k/PPC "fat binary". The modern equivalent would probably be IBM's AIX libraries, which are traditional.a archives that sometimes contain a shared library as one archive member. Presumably you could put two shared libraries, with different ABIs, in the same archive file - but I don't know if the AIX dynamic linker is smart enough to do the right thing there or not.
The basic thrust of them was that free software does not tend to be free (as you somewhat claim).
You have to pay more for support and implimentation, retraining, etc, so the costs and benefits come out to be somewhat equal
Uh. I never claimed that free software was "really free" in terms of auxilliary costs. That was just for the sake of argument. Based on your earlier statement --
Take MS vs. Linux. Since nobody is really making money from Linux, a victory for them in the desktop OS market would benefit nobody, and
only hurt MS (the current leader).
-- I assumed you didn't want to talk about support costs. Because if you're paying for support, obviously someone is making money on Linux after all.
Of course implementing a completely new computing infrastructure isn't free - no matter the up-front costs of purchasing the software. Of course every company thinking of doing such a thing should evaluate their support resources, their retraining costs, the possible backlash from their employees, as well as any possible benefits. Of course Linux won't actually "take over" the market until it makes economic sense, in light of these points, for the average company to implement it.
My post took your hypothesis - "a victory in the [Linux] desktop OS market" - and attempted to demonstrate the fallacy of the conclusion - "would benefit nobody". Now you're back to talking about support costs, which clearly benefit (for example) IBM Global Services.
I have read a bunch of articles on this subject lately.
For every case study that says Linux ends up being too expensive to implement, there are other case studies that show how companies save thousands of dollars by switching to Linux. It all depends on the specifics of your situation. It is often claimed, for example, that a good Linux administrator can manage a lot more servers at a time than a good Windows 2000 administrator. (Assume for the moment that this is actually true.) Then, if your company has a lot of servers, that's a very large potential savings you will see immediately (i.e. as soon as you lay off your Windows administrators and hire fewer Linux administrators)... but if you're a small shop with only have 3 servers and one guy taking care of them, this won't really work in your favor.
Your statements really come off more as OS penis-envy than as factual statements.
I'm sorry you misread the tone, then. My intent was to set up your premise that Linux somehow manages to "win" the OS desktop market... then follow the money to see who, in fact, does benefit. I did not intend to assert that a desktop OS victory was, in fact, imminent. In other words, what you take as "penis envy" was not actually meant to be factual, just conjectural.
I see free software to be a passing fad, like the shareware fad of the 80s. Eventually, these people are going
to want to make real money for their work.
Could be. I don't see myself quitting free software any time soon - programming is just too much fun to only do it when I'm getting paid - but who knows? Myself, I think free software will continue to inch up the ladder... first it was ubiquitous in low-level things like TCP/IP stacks (all the Unix TCP/IP code, and even Microsoft's, are derived from free software)... next it was web server software (Apache has been on the rise since its inception and now controls a comfortable majority of web sites) and scripting languages (Perl is used just about everywhere in the world, and Python and TCL are embedded in a lot of commercial applications)... now we're seeing Linux settle into the high-performance computing market... next will be database servers and other "backoffice
Still, I can see a potential problem. If you have a Linux distribution, some binaries will want to be 32bit, and some will want to
be 64bit (what other purpose would there be to having such a compatibility mode). But shared libraries (libc.so) would be really
nasty.
Standard practice is to use different lib directories for different binary formats. HP-UX, for example, has/usr/lib (old PA-RISC 1.1),/usr/lib/pa2.0 (PA-RISC 2.0, which I think is ABI-compatible so this is a mere optimisation) and/usr/lib/pa20_64 (PA-RISC 2.0 64-bit, in which HP also took the opportunity to ditch their crufty format in favor of ELF).
Modern dynamic linkers / loaders have no problem associating specific binary formats with specific library search paths. I think trying to lump multiple binary formats into a "fat" binary or library - or to support a "mixed-format" ABI - is not generally considered worth the hassle.
Well, how many systems that use ELF have a/proc fs like Linux? Only one. Your idea might work, but it's not portable. Linux is not
the only one with ELF. Most current *nixes and *nix-likes use ELF nowadays.
You know, at that level it really doesn't matter. Have you seen any commercial software for Unix? I swear, Unix commercial software houses almost all do the same thing: launch their application with a 15k shell script that supports 6 platforms, sometimes 2 or 3 versions of certain platform OSes, and sometimes separate 32- and 64-bit binaries.
This 15k script is about the ugliest shell code you'll ever see outside of bugtraq, but it seems to be SOP for these people. (I swear, Unix software vendors must never hire anyone who knows any advanced shell scripting. Not factoring out common code between OS cases. Odd and inconsistent indentation. Always using '>' and '>>' to redirect each command to the same file, instead of using 'exec' or redirecting a whole block at a time. No short variable names - slavish adherence to company-specific name prefixes and uppercase letters. Copy/paste instead of 'for' loops. Useless use of cat, grep | awk, etc. Useless, verbose comments, or none at all. Needlessly complex sed expressions. Use of sed instead of ${x%y}, even though they use other ksh'isms. Long strings of if / elif / elif instead of case statements. And sometimes they even use csh!) And that's not counting the 100k INSTALL.sh script that comes on the root directory of the CD and is basically more of the same.
Believe me, with the beautiful exception of Livermore Software Technology Corp (makers of LS-DYNA, whose entire install procedure consists of downloading a binary, gunzipping it, and arranging to have an environment variable point to your license file), all the proprietary Unix software I've seen is more or less as described above. Shipping a separate set of binaries / libraries for IA64, x86-64 and x86 wouldn't faze them a bit.
Maybe you don't see anything wrong with it, but that just demonstrates your ignorance of the real world and why anti-trust laws
exist.
MrResistor, I mostly agree with your points, but seriously, folks, you've got to stop this sort of reasoning. Maybe it demonstrates his ignorance of the real world. Or maybe, just maybe, it demonstrates that he has -- shock horror -- a different perspective on the real world.
"Anti-Trust Laws are Good and Necessary" is not an undisputed axiom, like Euclid's five postulates or Brooks' Law. I happen to think they are, and so do most people, I guess, but some think trust busting an anachronism that has outlived its usefulness. Just like quota-based affirmative action.
Take MS vs. Linux. Since nobody is really making money from Linux, a victory for them in the desktop OS market would benefit
nobody, and only hurt MS (the current leader).
Interesting economics you have there. Let's start by accepting your misleading simplification that nobody makes money on Linux. We'll assume Linux is completely free and any company that wants to implement it does not have to spend any money buying support contracts, etc. Furthermore, we'll assume that, SCO allegations notwithstanding, Linux manages to make it "into the enterprise" as a drop-in replacement for Windows and various other proprietary software, without any visible help from any money spent by anyone.
So let's explore cui bono (roughly, "who stands to benefit"). In a zero-sum world:
Microsoft loses $X billion per year because nobody buys Windows
the rest of the businesses and individuals in the world gain $X billion, all told, since they no longer have to buy Windows
Consider (a) the number of people who work for Microsoft and thus benefit from the sale of Windows, and (b) the number of people who don't work for Microsoft but do operate computers, who thus would benefit from not having to buy Windows. Hint: the second group vastly outnumbers the first.
Of course there are ripple effects both ways. If everyone continues to buy Windows, those Microsoft employees will continue to feed the economy by buying houses, going to restaurants, funding politicians, maintaining gym memberships, etc. On the other hand, if everyone stops buying Windows and saves their businesses $100000 per year by using something that is (simplified, remember) free instead, they can all cut their costs, lower their output prices, and ultimately benefit all the consumers of their products - even non-computer-owners, who are not directly affected by the Windows Tax.
Now, that is the zero-sum view. If you make money, I lose money, and vice versa. The real world is a lot more interesting than that, though. In the real world, if someone can manage to produce software for free, then equivalent software that must be paid for is an economic inefficiency. That is, if every employee of Microsoft Corporation is in fact redundant because their job is somehow accomplished by some anonymous coward in the free software world, then that means their labor should really be allocated doing something more useful to society.
Of course, none of this logic applies to the viewpoint of those people who are invested in Microsoft's success - employees, shareholders, paper MCSE's, etc. I imagine those people are the ones you're really talking about here, but your language certainly didn't reflect this.
Prelinking is already there. Have a look at this page for an introduction
Thanks, yes, that's the utility I was talking about. Apparently the necessary compiler / linker / loader support is now shipped with gcc 3.2, binutils 2.13.9x and glibc 2.3. Good to know - it's about time! The ELF binary format gave us enormous flexibility compared to older / simpler formats... but the catch was the comparably enormous run-time linking cost. Prelinking eliminates most of the latter, so it's in general a really Good Thing.
Nah, it handles certain start-up costs for complex applications better. This may or may not have anything to do with multithreading per se.
And you can tell the I/O is crap just by looking at KDE's performance when
compared to Win2k. Windows just flies.
I don't run KDE, but I understand that it has had speed issues in the past because it uses a lot of interconnected C++ shared libraries, which really tax the dynamic loader. The Windows link scheme, by the way, is much more primitive (read: fast at runtime). Microsoft also uses a hack (disk layout profiling) to speed up load time further. (Not that "hack" is necessarily a bad thing - after all it does get the job done.)
A couple of years ago, Jakub Jelinek came up with a utility similar to IRIX Quickstart for ELF binaries / libraries, which does "prelinking" to dramatically reduce relocation overhead at runtime in the common cases (without sacrificing flexibility, for the uncommon cases). A side effect is reducing memory usage due to COW. I never heard what happened to that project - anyone know if it is considered production-quality yet, or if binutils / glibc will be shipping it any time soon? Apparently it helped KDE quite a bit.
Hmm, what effect would the AS io scheduler have on compilation speeds?
Well, in serious compiling, you're mostly CPU-bound, so the I/O scheduling shouldn't make much difference. Of course, if you have a large project and are using recursive Makefiles (which is of course Considered Harmful, but still widely used), the 'make' processes will be doing a lot of fork/exec-ing and a lot of disk reads. The disk reads should be improved, but who knows? Try it yourself.
How
is the kernel set up? Is there a different IO scheduler for every different type of IO device (network, disk, etc)?
Dude, you don't even want to know how many ways you can schedule network packets in Linux. I mean, don't even go there. (:
(Yes, different I/O is scheduled in different ways.)
What about something like USB where you have no idea what kind of device is at the other end?
I don't know enough about USB to say, but certainly if you have a USB-based "storage class" device, such as a ZIP drive or keychain flash thingy, those requests will be subject to the scheduler in the story before they ever hit the USB bus. Likewise if you are using your network for, say, NFS traffic: reads and writes will go through the filesystem scheduler before they hit the network packet scheduler.
On some operating systems,
there is another layer sitting between the file system and the user which provides record and block management. If I open a file
for sequential read or write then the record/block manager knows that it could use read-ahead or write-behind.
Record and block management? Oh, the horror!
Seriously, as of about a month ago, there is now an implementation of fadvise in the 2.5 kernel, which allows an application to provide "hints" to the disk scheduler such as you propose. For example, you can specify that a file descriptor is POSIX_FADV_RANDOM, meaning that you expect your access patterns to be random, and therefore read-ahead is not useful.
Alternatively, you can open a file with the O_DIRECT flag, which is another sort of hint that you want the OS to get in your way as little as possible. I believe in O_DIRECT mode you have to provide I/O in 512-byte chunks, but I'm not certain.
Now this IO scheduler is opening up a whole new can of worms, it's a new chunk of code called "scheduler" and all hackers know
scheduling. In the past it has been fairly simple.
Larry McVoy (who should need no introduction) once said: "Screwing around with the elevator is in general a waste of time, but it is a rite of passage for all I/O people." OK, OK, so the disk scheduler is a bit higher-level than the elevator, but I still think it's a cool quote.
Speaking specifically to C programs here, porting from 32-bit to 64-bit is not a fun process. A variable declared as "int" switches
in allocation size. This is good and bad.
You had me until that part. While it is technically possible for a compiler and runtime environment to use a 64-bit int size, I am not aware of any that actually do. Precisely because of portability problems with legacy code. Instead, the common convention (which I know is used in HP-UX, Digital Unix, Linux and IRIX, and probably most other 64-bit platforms as well) is that an int is 32 bits, and a long int is 64 bits, as are all pointer types. (This is known as the LP64 model.)
The three biggest 32-bit-isms / portability problems I've seen:
(a) assuming you can stuff a pointer value into an int (correct answer: either use a union, or (as seen in the Linux kernel) a long int); (b) [not strictly a 32-bit-ism] ignoring alignment issues which may exist for anything bigger than a char; (c) not handling sign extension properly in implicit casting (on 32-bit platforms such casting often doesn't change the word size).
Large instruction word is (on my opinion) not a huge disadvantage - now the price of memory is cheap, and if you make bus wider, the speed of loading the code will be the same.
What do the following have in common?
cache size
memory bandwidth
cache associativity
absolute memory usage
Answer: things that cost real money, and the lack of which will hurt you quite tangibly, after you have doubled the instruction word size. The last perhaps least, but still.
Your "pro" arguments aren't very convincing either:
- easy to create compiler
Not if the compiler wants to conserve memory bandwidth. If you don't want to completely blow your caches and TLB, you'll still have to be careful to cluster your variables appropriately. Maybe you meant: easy to create proof-of-concept, non-optimising compilers.
- do not need very tricky register optimizations
A solved problem - read the article.
- easy to create chip logic
Another solved problem. Any chip real estate you hope to gain would be more than made up by the necessary increases in L1 cache and cache controller logic.
If you really think using memory instead of registers is the way of the future, go read up on the SPARC architecture and "register windows". Not a new idea, and, while clever, not particularly more effective than classic CISC registry + stack designs.
AND THERE IS NO REAL DOWNSIDE to 64 bit CPU's. Program footprints and cache/memory usage may become
higher but computers have bigger and cheaper harddrive/RAM/(L1/L2 caches) that more than compensate for it.
Man, what a load of crock. The downside is that program footprints and cache/memory usage may become higher. The fact that you can spend money and compensate for these things on a 64-bit CPU implies that you could just as well spend that same money and improve performance on your old 32-bit platform. What was your point again?
Your argument sounds a lot like "my SUV isn't any more expensive to operate than your compact, since gas prices have come down".
Certainly, there are ways 64-bit processing can speed things up. Memory access beyond 2 or 4 GB, if needed by your target application, is one such. Certain scientific processing is another. And if you can have a 64-bit platform without paying the code size cost, like you can with the AMD Hammer in 32-bit mode, it's probably a good thing overall. But it's just plain stupid to say that everyone will benefit from 64 bits, or that the 64-bitness somehow comes for free.
Windows was pathetically slow on those machines, in comparison to them with Digital Unix, or in comparison to my Pentium 133Mhz
workstation. Even in comparison to Pentium 166Mhz machines running BSDi 3.0, the Alphas were very slow, even though the Alphas were
stuffed full of memory.
I've never run NT on Alpha, but my understanding is that Microsoft took the easy way out and ran NT basically as a 32-bit OS. Linux, OTOH, fully supports 64-bit and has done so ever since the Alpha port matured. Microsoft finally had to bite the bullet and fix their 32-bit-isms when then came out with Win2k for ia64, but that was years later.
The Alpha also gets you on unaligned memory accesses - if you and your compiler are not careful, you can force some very slow OS traps. I wouldn't be surprised if your applications were slow partly because of this.
I was never particularly fond of the DEC Alphas. I didn't like Digital Unix much at all, and the power-that-be wouldn't even
let me consider Linux on them.
Hmmm, what's not to like about Digital Unix? I always thought it was quite nice, as proprietary Unixes go. It was slower than Linux, due to its microkernel layer.
Hey, wait - isn't he the guy who wrote "Spell My Name with an S"?
According to Google, that story was indeed a play upon his own name and the fact that so many people couldn't spell it. I never actually made that connection until now. OK, now I'm feeling a little stupid and redundant....
Oh, wow, would the good doctor have something to say to you! It's "Asimov," with an 's'. You might watch for nocturnal visitations
from a very angry ghost with a wicked sense of humor.
Hey, wait - isn't he the guy who wrote "Spell My Name with an S"?
At $1500 for many of even the cheap RAID cabinets without disks, it's easy to see this as an entry-level RAID solution for someone
that already has a few firewire disks and wants a redundancy or even for people that would make their own setup ($70 firewire
enclosure + $85 80 GB IDE disk) and don't want the expense or need the performance of a full-blown ultra3 SCSI setup.
Ah, ok, but in that case I don't see anything wrong with plain old software RAID.
(I am *really* tired of hearing all this
nonsense about a supposed technical need for artificially scarce namespace)
See, this is the point I've never quite understood. How is the.com namespace more scarce than a proposed open TLD namespace? It seems to me that the two setups are basically identical, except that in the present case everyone has to type ".com" at the end.
If what you don't like is the artificial price inflation of registering a second-level under.com, due to the dynamics of Netsol and the resellers, then say so. But I don't see how an open season on TLDs would solve that problem - somebody still has to manage registrations, after all, and I don't see why they would get any cheaper or more efficient just because you're registering under '.' rather than '.com'.
In a world where anyone and everyone can start allocating their own top-level domain, though, you're effectively folding the
traffic from both of today's 'com' and 'net' and 'org' servers into the root servers.
This is a political distinction, not a technical distinction. Namely, who owns the servers with the high-volume traffic. (Currently Network Solutions, as the registrar for.com/.net/.org/.gov/.edu and probably others.)
It's not like this would create a new technical problem. It's a solved problem, just not one the root servers currently have. Worst case, ICANN contracts Netsol to do the root servers (if they don't already - I don't know who actually runs the root servers at present.)
The DNS software isn't the problem here. What you're recommending is basically a flat DNS namespace, where 90% or more of the
present-day DNS traffic is moved directly to the root servers.
As opposed to 90% or more of the present-day DNS traffic going through the.com /.net TLD servers? I don't see how the one is any different from the other, except for who owns the servers (Netsol, in the case of gtld-servers.net, which manages.com and.net; they also of course own nstld.com, which manages.org).
Excellent question! The current method entails pre-seeding each DNS server with a copy of named.root which is
available from hoary old RS.INTERNIC.NET, the site that used to distribute/etc/hosts back in my misspent youth.
The root servers currently just service the root level - not the.com level. The.com level is taken care of by a host (pun intended) of machines at Network Solutions called *.gtld-servers.net.
So don't worry about the scalability of millions of TLDs. Netsol has already had to solve that problem - it would be no different (well, maybe one extra order of magnitude) to move those all down to the root level.
(No real benefit, either, btw - the usable / desirable namespace is basically the same size as before.)
But, if we free the namespace, we will greatly increase the number of root nameservers (a good thing) which will make the
named.root file unmanageably long
There are only 13.com name servers, [a-m].gtld-servers.net (compare this to the 13 root servers, [a-m].root-servers.net), and they manage to service the huge.com and.net namespaces..org only has nine servers (*.nstld.com, also at Network Solutions). What makes you think the brave new No Particular TLD world would need any more than that?
Slashdot Mirror
Ho hum. You figure Linux and other free software will soon start to fade out, maybe remaining as a bit player like shareware today. I think it's still on its way up and in, and will displace a lot more proprietary software before it peaks. We can't both be right. Wait and see, I guess.
I do think we have a little signal mismatch as far as defining free software. You say, for example,
Funded by grants and corporations? Yes. Free? Yes. I don't see how those two are mutually exclusive. The real point is that DARPA and the University of California--Berkeley (AT&T had little to do with TCP/IP) found it worth their while to fund something that would be made available for free.
Likewise, when I mentioned HPC, you replied:
Once again - true, but that doesn't make IBM's investment somehow "non-free software". The fact is, this supports my point, which I guess I haven't made very clearly, so here it is: Free software (in my opinion) will continue to grow because the software landscape will continue to evolve, as it is already doing, such that it is in the best interests of certain companies to fund it. Yes, that's right. It's in IBM's best interest to give away thousands of hours of engineering talent for free.
Perfect example - look at SGI. They wanted to move from their MIPS-based big iron to the Intel Itanium, because in the long run Itanium gives you a lot more bang for the buck. (Best to leave unsaid what this implies about MIPS.) But they have a problem: their Unix platform, IRIX, has been developed for 15 years or so on MIPS and only in the past 4 years or so (version 6.5) has it achieved any respectable stability. Porting IRIX to the Itanium would take a long time, and then you have to convince all the third party vendors to ship Itanium IRIX binaries of all their products. Enter Linux. Linux runs on Itanium already, and it has a market presence. So SGI builds the Altix platform based on (a) their big iron NUMA technologies, (b) the Itanium chip (up to 64 per box) and (c) Linux.
Now, IRIX is famous for running well on huge machines. Linux was famous for running well on much smaller machines (4-8 CPUs seemed to be the practical limit, fairly recently). To get Linux to the point where they could use it on the Altix required a certain amount of investment by SGI. And yet, they figured it was cheaper to point their engineers at Linux and say "customise this for the Altix hardware, and make it scale to 64 CPUs" than the point those same engineers at IRIX and say "move this to Itanium".
(Why was this cheaper for SGI? Because IBM was already doing half the work already - to make Linux scale to their big machines! Crucial point to understand, if you wonder how the economics of free software cooperation can possibly work.)
If I'm reading you right, you wouldn't really consider this "free software" any more, since SGI (in this example) has invested so much of their own capital into it. I guess it's a matter of semantics - no matter who invested what money, the product is available for free to all comers, same as the original Linux.
ok. You don't see free software taking over "database servers and other backoffice functions":
Right. But for 32/64-bit, the ABI is not the same. Take malloc() for example. It returns a 'void *' (or 'char *' in pre-ANSI C). In 32-bit mode this is a 32-bit pointer. In 64-bit mode it is a 64-bit pointer.
Thus you really can't mix 32-bit and 64-bit code without a lot of hackery - like the Apple 68k/PPC "fat binary". The modern equivalent would probably be IBM's AIX libraries, which are traditional .a archives that sometimes contain a shared library as one archive member. Presumably you could put two shared libraries, with different ABIs, in the same archive file - but I don't know if the AIX dynamic linker is smart enough to do the right thing there or not.
Uh. I never claimed that free software was "really free" in terms of auxilliary costs. That was just for the sake of argument. Based on your earlier statement --
-- I assumed you didn't want to talk about support costs. Because if you're paying for support, obviously someone is making money on Linux after all.
Of course implementing a completely new computing infrastructure isn't free - no matter the up-front costs of purchasing the software. Of course every company thinking of doing such a thing should evaluate their support resources, their retraining costs, the possible backlash from their employees, as well as any possible benefits. Of course Linux won't actually "take over" the market until it makes economic sense, in light of these points, for the average company to implement it.
My post took your hypothesis - "a victory in the [Linux] desktop OS market" - and attempted to demonstrate the fallacy of the conclusion - "would benefit nobody". Now you're back to talking about support costs, which clearly benefit (for example) IBM Global Services.
For every case study that says Linux ends up being too expensive to implement, there are other case studies that show how companies save thousands of dollars by switching to Linux. It all depends on the specifics of your situation. It is often claimed, for example, that a good Linux administrator can manage a lot more servers at a time than a good Windows 2000 administrator. (Assume for the moment that this is actually true.) Then, if your company has a lot of servers, that's a very large potential savings you will see immediately (i.e. as soon as you lay off your Windows administrators and hire fewer Linux administrators) ... but if you're a small shop with only have 3 servers and one guy taking care of them, this won't really work in your favor.
I'm sorry you misread the tone, then. My intent was to set up your premise that Linux somehow manages to "win" the OS desktop market ... then follow the money to see who, in fact, does benefit. I did not intend to assert that a desktop OS victory was, in fact, imminent. In other words, what you take as "penis envy" was not actually meant to be factual, just conjectural.
Could be. I don't see myself quitting free software any time soon - programming is just too much fun to only do it when I'm getting paid - but who knows? Myself, I think free software will continue to inch up the ladder ... first it was ubiquitous in low-level things like TCP/IP stacks (all the Unix TCP/IP code, and even Microsoft's, are derived from free software) ... next it was web server software (Apache has been on the rise since its inception and now controls a comfortable majority of web sites) and scripting languages (Perl is used just about everywhere in the world, and Python and TCL are embedded in a lot of commercial applications) ... now we're seeing Linux settle into the high-performance computing market ... next will be database servers and other "backoffice
Standard practice is to use different lib directories for different binary formats. HP-UX, for example, has /usr/lib (old PA-RISC 1.1), /usr/lib/pa2.0 (PA-RISC 2.0, which I think is ABI-compatible so this is a mere optimisation) and /usr/lib/pa20_64 (PA-RISC 2.0 64-bit, in which HP also took the opportunity to ditch their crufty format in favor of ELF).
Modern dynamic linkers / loaders have no problem associating specific binary formats with specific library search paths. I think trying to lump multiple binary formats into a "fat" binary or library - or to support a "mixed-format" ABI - is not generally considered worth the hassle.
You know, at that level it really doesn't matter. Have you seen any commercial software for Unix? I swear, Unix commercial software houses almost all do the same thing: launch their application with a 15k shell script that supports 6 platforms, sometimes 2 or 3 versions of certain platform OSes, and sometimes separate 32- and 64-bit binaries.
This 15k script is about the ugliest shell code you'll ever see outside of bugtraq, but it seems to be SOP for these people. (I swear, Unix software vendors must never hire anyone who knows any advanced shell scripting. Not factoring out common code between OS cases. Odd and inconsistent indentation. Always using '>' and '>>' to redirect each command to the same file, instead of using 'exec' or redirecting a whole block at a time. No short variable names - slavish adherence to company-specific name prefixes and uppercase letters. Copy/paste instead of 'for' loops. Useless use of cat, grep | awk, etc. Useless, verbose comments, or none at all. Needlessly complex sed expressions. Use of sed instead of ${x%y}, even though they use other ksh'isms. Long strings of if / elif / elif instead of case statements. And sometimes they even use csh!) And that's not counting the 100k INSTALL.sh script that comes on the root directory of the CD and is basically more of the same.
Believe me, with the beautiful exception of Livermore Software Technology Corp (makers of LS-DYNA, whose entire install procedure consists of downloading a binary, gunzipping it, and arranging to have an environment variable point to your license file), all the proprietary Unix software I've seen is more or less as described above. Shipping a separate set of binaries / libraries for IA64, x86-64 and x86 wouldn't faze them a bit.
MrResistor, I mostly agree with your points, but seriously, folks, you've got to stop this sort of reasoning. Maybe it demonstrates his ignorance of the real world. Or maybe, just maybe, it demonstrates that he has -- shock horror -- a different perspective on the real world.
"Anti-Trust Laws are Good and Necessary" is not an undisputed axiom, like Euclid's five postulates or Brooks' Law. I happen to think they are, and so do most people, I guess, but some think trust busting an anachronism that has outlived its usefulness. Just like quota-based affirmative action.
Interesting economics you have there. Let's start by accepting your misleading simplification that nobody makes money on Linux. We'll assume Linux is completely free and any company that wants to implement it does not have to spend any money buying support contracts, etc. Furthermore, we'll assume that, SCO allegations notwithstanding, Linux manages to make it "into the enterprise" as a drop-in replacement for Windows and various other proprietary software, without any visible help from any money spent by anyone.
So let's explore cui bono (roughly, "who stands to benefit"). In a zero-sum world:
Consider (a) the number of people who work for Microsoft and thus benefit from the sale of Windows, and (b) the number of people who don't work for Microsoft but do operate computers, who thus would benefit from not having to buy Windows. Hint: the second group vastly outnumbers the first.
Of course there are ripple effects both ways. If everyone continues to buy Windows, those Microsoft employees will continue to feed the economy by buying houses, going to restaurants, funding politicians, maintaining gym memberships, etc. On the other hand, if everyone stops buying Windows and saves their businesses $100000 per year by using something that is (simplified, remember) free instead, they can all cut their costs, lower their output prices, and ultimately benefit all the consumers of their products - even non-computer-owners, who are not directly affected by the Windows Tax.
Now, that is the zero-sum view. If you make money, I lose money, and vice versa. The real world is a lot more interesting than that, though. In the real world, if someone can manage to produce software for free, then equivalent software that must be paid for is an economic inefficiency. That is, if every employee of Microsoft Corporation is in fact redundant because their job is somehow accomplished by some anonymous coward in the free software world, then that means their labor should really be allocated doing something more useful to society.
Of course, none of this logic applies to the viewpoint of those people who are invested in Microsoft's success - employees, shareholders, paper MCSE's, etc. I imagine those people are the ones you're really talking about here, but your language certainly didn't reflect this.
Thanks, yes, that's the utility I was talking about. Apparently the necessary compiler / linker / loader support is now shipped with gcc 3.2, binutils 2.13.9x and glibc 2.3. Good to know - it's about time! The ELF binary format gave us enormous flexibility compared to older / simpler formats ... but the catch was the comparably enormous run-time linking cost. Prelinking eliminates most of the latter, so it's in general a really Good Thing.
Nah, it handles certain start-up costs for complex applications better. This may or may not have anything to do with multithreading per se.
I don't run KDE, but I understand that it has had speed issues in the past because it uses a lot of interconnected C++ shared libraries, which really tax the dynamic loader. The Windows link scheme, by the way, is much more primitive (read: fast at runtime). Microsoft also uses a hack (disk layout profiling) to speed up load time further. (Not that "hack" is necessarily a bad thing - after all it does get the job done.)
A couple of years ago, Jakub Jelinek came up with a utility similar to IRIX Quickstart for ELF binaries / libraries, which does "prelinking" to dramatically reduce relocation overhead at runtime in the common cases (without sacrificing flexibility, for the uncommon cases). A side effect is reducing memory usage due to COW. I never heard what happened to that project - anyone know if it is considered production-quality yet, or if binutils / glibc will be shipping it any time soon? Apparently it helped KDE quite a bit.
Well, in serious compiling, you're mostly CPU-bound, so the I/O scheduling shouldn't make much difference. Of course, if you have a large project and are using recursive Makefiles (which is of course Considered Harmful, but still widely used), the 'make' processes will be doing a lot of fork/exec-ing and a lot of disk reads. The disk reads should be improved, but who knows? Try it yourself.
Dude, you don't even want to know how many ways you can schedule network packets in Linux. I mean, don't even go there. (:
(Yes, different I/O is scheduled in different ways.)
I don't know enough about USB to say, but certainly if you have a USB-based "storage class" device, such as a ZIP drive or keychain flash thingy, those requests will be subject to the scheduler in the story before they ever hit the USB bus. Likewise if you are using your network for, say, NFS traffic: reads and writes will go through the filesystem scheduler before they hit the network packet scheduler.
Record and block management? Oh, the horror!
Seriously, as of about a month ago, there is now an implementation of fadvise in the 2.5 kernel, which allows an application to provide "hints" to the disk scheduler such as you propose. For example, you can specify that a file descriptor is POSIX_FADV_RANDOM, meaning that you expect your access patterns to be random, and therefore read-ahead is not useful.
Alternatively, you can open a file with the O_DIRECT flag, which is another sort of hint that you want the OS to get in your way as little as possible. I believe in O_DIRECT mode you have to provide I/O in 512-byte chunks, but I'm not certain.
Larry McVoy (who should need no introduction) once said: "Screwing around with the elevator is in general a waste of time, but it is a rite of passage for all I/O people." OK, OK, so the disk scheduler is a bit higher-level than the elevator, but I still think it's a cool quote.
You had me until that part. While it is technically possible for a compiler and runtime environment to use a 64-bit int size, I am not aware of any that actually do. Precisely because of portability problems with legacy code. Instead, the common convention (which I know is used in HP-UX, Digital Unix, Linux and IRIX, and probably most other 64-bit platforms as well) is that an int is 32 bits, and a long int is 64 bits, as are all pointer types. (This is known as the LP64 model.)
The three biggest 32-bit-isms / portability problems I've seen: (a) assuming you can stuff a pointer value into an int (correct answer: either use a union, or (as seen in the Linux kernel) a long int); (b) [not strictly a 32-bit-ism] ignoring alignment issues which may exist for anything bigger than a char; (c) not handling sign extension properly in implicit casting (on 32-bit platforms such casting often doesn't change the word size).
What do the following have in common?
Answer: things that cost real money, and the lack of which will hurt you quite tangibly, after you have doubled the instruction word size. The last perhaps least, but still.
Your "pro" arguments aren't very convincing either:
Not if the compiler wants to conserve memory bandwidth. If you don't want to completely blow your caches and TLB, you'll still have to be careful to cluster your variables appropriately. Maybe you meant: easy to create proof-of-concept, non-optimising compilers.
A solved problem - read the article.
Another solved problem. Any chip real estate you hope to gain would be more than made up by the necessary increases in L1 cache and cache controller logic.
If you really think using memory instead of registers is the way of the future, go read up on the SPARC architecture and "register windows". Not a new idea, and, while clever, not particularly more effective than classic CISC registry + stack designs.
Man, what a load of crock. The downside is that program footprints and cache/memory usage may become higher. The fact that you can spend money and compensate for these things on a 64-bit CPU implies that you could just as well spend that same money and improve performance on your old 32-bit platform. What was your point again?
Your argument sounds a lot like "my SUV isn't any more expensive to operate than your compact, since gas prices have come down".
Certainly, there are ways 64-bit processing can speed things up. Memory access beyond 2 or 4 GB, if needed by your target application, is one such. Certain scientific processing is another. And if you can have a 64-bit platform without paying the code size cost, like you can with the AMD Hammer in 32-bit mode, it's probably a good thing overall. But it's just plain stupid to say that everyone will benefit from 64 bits, or that the 64-bitness somehow comes for free.
I've never run NT on Alpha, but my understanding is that Microsoft took the easy way out and ran NT basically as a 32-bit OS. Linux, OTOH, fully supports 64-bit and has done so ever since the Alpha port matured. Microsoft finally had to bite the bullet and fix their 32-bit-isms when then came out with Win2k for ia64, but that was years later.
The Alpha also gets you on unaligned memory accesses - if you and your compiler are not careful, you can force some very slow OS traps. I wouldn't be surprised if your applications were slow partly because of this.
Hmmm, what's not to like about Digital Unix? I always thought it was quite nice, as proprietary Unixes go. It was slower than Linux, due to its microkernel layer.
According to Google, that story was indeed a play upon his own name and the fact that so many people couldn't spell it. I never actually made that connection until now. OK, now I'm feeling a little stupid and redundant....
Hey, wait - isn't he the guy who wrote "Spell My Name with an S"?
Ah, ok, but in that case I don't see anything wrong with plain old software RAID.
Just wanted to add that I appreciated your use of obviate here. (:
See, this is the point I've never quite understood. How is the .com namespace more scarce than a proposed open TLD namespace? It seems to me that the two setups are basically identical, except that in the present case everyone has to type ".com" at the end.
If what you don't like is the artificial price inflation of registering a second-level under .com, due to the dynamics of Netsol and the resellers, then say so. But I don't see how an open season on TLDs would solve that problem - somebody still has to manage registrations, after all, and I don't see why they would get any cheaper or more efficient just because you're registering under '.' rather than '.com'.
This is a political distinction, not a technical distinction. Namely, who owns the servers with the high-volume traffic. (Currently Network Solutions, as the registrar for .com/.net/.org/.gov/.edu and probably others.)
It's not like this would create a new technical problem. It's a solved problem, just not one the root servers currently have. Worst case, ICANN contracts Netsol to do the root servers (if they don't already - I don't know who actually runs the root servers at present.)
As opposed to 90% or more of the present-day DNS traffic going through the .com / .net TLD servers? I don't see how the one is any different from the other, except for who owns the servers (Netsol, in the case of gtld-servers.net, which manages .com and .net; they also of course own nstld.com, which manages .org).
The root servers currently just service the root level - not the .com level. The .com level is taken care of by a host (pun intended) of machines at Network Solutions called *.gtld-servers.net.
So don't worry about the scalability of millions of TLDs. Netsol has already had to solve that problem - it would be no different (well, maybe one extra order of magnitude) to move those all down to the root level.
(No real benefit, either, btw - the usable / desirable namespace is basically the same size as before.)
There are only 13 .com name servers, [a-m].gtld-servers.net (compare this to the 13 root servers, [a-m].root-servers.net), and they manage to service the huge .com and .net namespaces. .org only has nine servers (*.nstld.com, also at Network Solutions). What makes you think the brave new No Particular TLD world would need any more than that?