We're heavily reliant on cross-platform FS, heavily enough that we don't want to use an unsupported product.
Unsupported by whom? Lots of people are happy to support Samba - if you pay them. It's also supported as part of the standard install on HP-UX now, and I think on some other Unix versions (not to mention almost all Linux vendors).
...I mean, come on. Are you seriously suggesting that Microsoft supports SFU better than Red Hat supports Samba? The nature of the IT world is that any vendor will support their own products to whatever extent you desire, if you give them enough money. As will just about any third-party consultant. (Not that third-party consultants are much help for fixing bugs in SFU, due to its closed-source nature.)
Solaris expects you to use -L for compile time linking, but wants you to specify -R for runtime paths. If one doesn't specify -R on a normal platform, the OS usually is smart enough to figure out that the compile time path should be the runtime path. Not Solaris. It will freak out and say that it can't find the library that you linked with. Subsequently it is a bunch of Makefiles needing editing and/or environment variables needing to be set. Then compile again.
Hey! I miss that feature! I compile stuff on AIX occasionally, and it's pretty annoying that the linker assumes that my runtime library path should consist of all my -L flags. Yes, even relative ones! You may say, oh well, a long runtime link path doesn't really hurt, but if you want something to work reliably whether or not NFS mounts are behaving, you have to pay attention to this stuff.
The gcc developers many years ago tried to combine the -L and -R flags on Solaris (to make it more like other Unices), but eventually concluded that they would be losing too much flexibility. I agree.
MS didn't forget to secure XP, they broke the security on purpose for greater compatibility with 95/98 apps (which have no user-level security whatsoever.)
Which has nothing to do with raw sockets. Unix allows raw sockets - if you're root. NT allows raw sockets - if you're in the administrators group. XP allows raw sockets - if you're an administrator which for the default home setup means everybody.
I honestly don't get the people who say raw sockets are a security problem. By their arguments, everyone should be forced to use a private, proprietary network behind custom proxy servers, like AOL used to be, so they can't get out onto the raw internet and wreak havoc. Back before AOL became Yet Another ISP, it was darned difficult to launch script kiddie attacks from there against actual Internet sites....
I would scream bloody murder if the Linux gods took raw sockets away from me. Not that they'd be stupid enough to even think about that. Nobody questions the usefulness of tcpdump, which relies on raw sockets.
Re:Worse than running something as root
on
Linux Virus Alert
·
· Score: 1
In my experience,
automake produces write-only Makefiles.
Very well. This only matters, though, if you don't trust automake. If you do trust it, you can always just audit Makefile.am, then re-run automake and autoconf to produce Makefile.in and Makefile.
Sure, it's inconvenient, and I understand why having a readable Makefile is nice for auditing the install commands....
Re:This cracks me up.
on
Linux Virus Alert
·
· Score: 3, Informative
Sure, download and install the SDL version.
Dont require logging in as root to play it.
Is that so? I believe you are mistaken - SDL is only a wrapper library which calls out to existing methods of doing graphics (among other things).
One such method is Xlib, and I don't want to run an X server. Another is the Linux kernel framebuffer, and I'm not so interested in taking the performance hit of running in frame buffer mode (why do you think I use a text console in the first place - mostly for speed). A third is aalib, and I don't want to run Doom in ASCII art (slashdot reports about Quake notwithstanding). Which leaves me running SDL applications in... svgalib mode. Which requries root.
Svgalib is really old.. SDL is the way now.
"Xlib is really old.. Gtk+ is the way now."
The two statements are equivalent.
Re:Worse than running something as root
on
Linux Virus Alert
·
· Score: 2
Which brings up an interesting point: write-only code. I've tried to read and understand autoconf-generated Makefiles a few times, and given up with my head spinning. They're a tangled web of M4 macros and such.
Which autoconf-generated Makefiles? Try diffing your favorite write-only Makefile against its corresponding Makefile.in - I think you'll find that autoconf isn't doing the damage here. Maybe you meant automake, which takes a Makefile.am and produces Makefile.in.
If you are referring to the Makefiles in gcc, gdb and binutils - yes, they are hairy messes, which have little to do with autoconf and much to do with the complexity of accomplishing the task at hand without using any advanced 'make' features. Apparently the Free Software Foundation wants their software to compile with anybody's version of 'make' back to about 1985.
Sorry but if you have to run it as root, 90% of the time it is a sign of poor code and will probably suck anyways...
...or it uses svgalib. On Linux, at least, svgalib requires root to initialise itself.
I don't run an X server on my box - I hardly ever actually need graphics. So if I want to kick back with a round of Doom (don't laugh, I still enjoy it) I run the svgalib version.
There. Now you know. Go ahead and try to social-engineer me into replacing my Doom binary with one of yours. (:
A compiler being able to compile itself is an important "graduation ceremony". Any language that is incapable of compiling itself is obviously incomplete in some fundamental way.
Or just unsuited for writing compilers in. The gcc Fortran compiler is not written in Fortran, because C is a better language for that and the gcc developers know a C compiler will be available to build g77.
Apparently the Mono people decided to use C# for implementation even though it is interpreted (and JIT compiled) - an interesting decision IMO.
There are actually several meanings of "64-bit chip". If you mean "64-bit or wider data path through the CPU", then yes, performance is the reason people want that.
...so by this definition the 8088 was an 8-bit processor and the 386SX was 16-bit.
If you mean "uses 64-bit addresses", then yes, performance isn't really an issue, whereas increased program size is (e.g. large databases).
If you go by use address space, the 6502 is a 16-bit CPU. And the Pentium Pro is 36-bit. (Sort of.)
I think a third definition - width of general-purpose registers - is the commonly used one. In that case the 6502 is only 8-bit, the 8088 is 16-bit and the 386SX is 32-bit.
There is no particular reason why 64 bit processors should be faster than 32 bit processors ( or indeed why 16 bit processors should be faster than 8 bit processors!).
Actually, there is every reason to expect a larger word size to increase speed, in some applications. Thanks to Mr Turing we all know that any computer can basically do the job of any other, but have you ever written a 16-bit multiply routine on an 8-bit CPU? It's not hard or anything, but it is slow.
Of course, most desktop applications today do not need 64-bit numbers....
nt4 ships with an alpha version. i ran it for a while, silly stable, but not that fast compared to tru64.
Not having tried it, what I heard was that while NT ran on Alpha, it was still basically 32-bit. Just like Win95 was largely 16-bit even though it ran in 386 protected mode.
That would explain why Tru64 (which, like NT, is microkernel-based) was faster. Some say that to get the best performance on Alpha one should compile code with the Tru64 compilers but run it on Linux (the two are ABI-compatible).
but i'm afraid it will really confuse a lot of people out there
Yes but confuse which people? If you aren't willing to keep up with the issues of 2.0.x vs 2.2.x vs 2.2.x-ac vs 2.4.x vs 2.4.x-ac vs 2.4.x-mjc vs 2.5.x vs 2.5.x-dj, you will probably do just fine running your vendor-installed kernel, which is yet another branch, generally.
Now I don't get confused about those eight major branches - but hey, what a coincidence, I'm the target audience for some of those branches.
Does anyone in the real world care about the two branches of HP-UX 11.00? That is, the standard release and the ccr builds? What, you say? You've never heard of 11.00-ccr? My point exactly. Most people don't need to know or care.
Take system-independent includes for example: in Linux, they are placed in include/linux. Why? Well, presumably so you can't make portable code that works on a non-Linux platform.
Actually, that's system-dependent includes, and the reason is historical. Five years ago you had to #include<linux/*.h> for quite a few random things... but that was five years ago.
The world changed - glibc 2.1 came out - and nowadays you should never include <linux/*.h> except for OS-dependent stuff like CD burner software. The reason the directory still exists is that other files in/usr/include make use of it - but that's an implementation detail which as a mere software developer you shouldn't have to worry about.
Linux has proven to be questionable as a server os thanks to the recent bugs found in all the patches. A year ago I would but my job on linux as a server OS but today I would not.
Out of curiosity, what changed? The kernel you were so happy with a year ago - did it suddenly fail to work?
Or are you saying current kernels aren't as stable as the then-current kernels? If that's the case, just keep using those. I don't think I've ever heard anyone complain about the stability of 2.2.16 - 2.2.20 - people complaining about kernel instability are generally referring to 2.4. The 2.2 series isn't dead yet!
By adding more trees, kernel development will be slowed way to much. Lets concentrate on standardizing, not fragmenting the kernel.
No offense, but are you saying this as a kernel developer, or as a bystander? The developers themselves don't seem hostile to multiple trees at all - they usually maintain their own tree anyway. And judging by how many people developed against 2.2-ac rather than 2.2-linus, I'd say they like working that way.
The drawback here is if MJC doesn't accept responsibility for merging patches upstream to Marcelo. Alan has always been very good about this.
The different tracks for this new tree aughta be incorporated into the 2.5 tree.
Some of the patches in -mjc are being considered for 2.5 - some are not - for technical reasons. A maintainer doesn't have to choose between supporting 2.4 and 2.5 - why not do both? And if you want to support only 2.5, let MJC do the backport to 2.4. Conversely, if you want to support only 2.4, let Dave Jones do the forward port.
but the PreEmpt patch made no noticable difference, probably because I use a dual processor system.
Agreed, SMP makes preempt a lot less necessary.
Of the included patches; Reverse Mapping patch #9, Preemptible Kernel Patch, Lock-Break Patch, CPU affinity/proc entry, Netdev-random, Software Suspend, Real Time Scheduler for Linux, IDE updates. Which ones can we expect to have an impact on preformance ? and which ones simply fix a long standing problem?
I'm not sure about all of them, but:
Reverse Mapping: not sure if it helps VM performance by itself but it was designed to make it easier to perform certain VM-related optimisations.
Preemptible: you know what this one does - for UP systems in particular, should give lower latency. Good especially for smoother interactive feel (eg. mouse movements) and multimedia (eg. no-skip sound playback). Small performance hit.
Lock-Break: not sure what this is. I think it's about bug reporting - shouldn't be noticed in real life.
CPU affinity/proc entry: lets you associate a specific job with a specific CPU. "If you don't know whether you need it or not, you don't." Used to override the scheduler when you think you're smarter than it.
Netdev-random: collect entropy out of incoming network packet timings. Good especially for a headless, diskless server (like a floppy-based router) because most of the usual sources of entropy aren't present. Bad in that an external source can control your entropy input - considered a security risk by purists. Linus rejected this one because of objections on L-K by Ted Ts'o and others. You shouldn't need this on the desktop. Probably minimal performance impact.
Software suspend: save memory and device state to disk before letting a laptop (or a desktop I suppose) go to sleep or shut down - then restore on wakeup / bootup. Probably no performance impact, just a new feature. As you'll know if you use this on Windows 98 or Win2k, reliability is a big problem with this sort of thing thanks to its extreme dependence on hardware behaving to spec on power management issues.
Realtime Scheduler: allow a process to hog the CPU and have it basically any time it wants. Again, probably for multimedia purposes, or data collection, or other real-time tasks. I don't know the implementation details, or how hard the guarantees are.
IDE updates: Andre Hedrick and Linus Torvalds, um, do not get along very well. It's not personal (or not only that), Linus doesn't like Andre's philosophy of development - Andre sits on the IDE standards board, and in Linus's opinion trusts the standards too blindly - whereas Linus comes from a background of assuming that hardware won't follow its specs so you have to dig in and figure out what it does not just what it says it does.
This adds up to the sad fact that official 2.2 and 2.4 kernels are never even close to up-to-date w/r/t Hedrick's IDE work. New IDE drivers, random bug fixes, etc.
This is -exactly- what MS does with their kernels. It's really a great move. Think Win2k pro, server, advanced server, and datacenter server versions. They have different kernels.
Is that so? (If so, good move.) NT4 didn't. NT Workstation and NT Server shared the same kernel - or kernels, actually, a UP kernel and an SMP kernel.
Considering the quite different instruction scheduling properties of the Pentium/Pentium-MMX from CPUs that came before and after it, the fact that MS doesn't ship kernels compiled to optimise for a given CPU must have hurt. I don't know if they have any other measures to compensate.
("Must have hurt", past tense, because they almost certainly no longer optimise for a Pentium, if they ever did. And subsequent Intel CPUs are much more "compatible" in the optimisation sense.)
The difference is speed of generated code is not extreme though and in comparision with other main stream compilers (what would/. be without bashing MS) such as MSVC, it just blows the competition away.
Well, I don't do many speed benchmarks, but IBM's Visual Age C compiler (not free, mind!) generates much smaller code on AIX. [Yes, I tried gcc-Os.] I don't know about MSVC. Small object sizes are nice, they give me a warm fuzzy.
Unfortunately, I have to say I have encountered quite a bit of bugs in GCC:) That's ok though, it's not with the C compiler it's with the C++ compiler and the C++ specs suck so much, how can anyone blame GCC for messing up a bit;-)
Yeah, when I said gcc never crashed, I was referring to the C compiler.
I hardly do any C++ programming but I had to do some three or four years ago - and I remember spending a great deal of time chasing bugs that turned out to be the compiler. (In one instance I actually used __attribute__((weak)) to work around a bug where egcs g++ was producing two copies of a function and then complaining at link time!)
I have to say I'm in awe of how gcc can have an exception fall through multiple stack frames with little or no cost to the common case. (At least this is their claim - zero-cost exceptions on some architectures. I am not competent to intelligently evaluate this claim.) The C++ language has developed into ADA with s:Pascal:C:g, and I don't envy those who are trying to implement the whole thing.
...And at this point my post has to do with the release of Gnumeric 1.0 - how, again?
A good example of where the quality of open source software overrides the lack of support is with GCC. GCC is commonly used in production environments over other Unix compilers because it is such a better compiler than most other compilers.
A bit OT, but oh well. What you describe was certainly true in the past - vendor compilers were such a mixed bag that GCC has extensive release notes detailing how to bootstrap it with various other compilers without tripping numerous known bugs. And of course many vendors bundle a sub-optimal C compiler with the OS and make you pay extra for their Real Thing.
But gcc is not the Holy Grail of code generation. Not anymore. IBM and CodeWarrior both beat it senseless on PowerPC; Intel has something that apparently does better on x86, and a lot better on Itanium; DEC has kicked its butt on Alpha for years.
(Of course, gcc probably has more CPU backends than any other C compiler out there - but within a single architecture it often is not the best.)
Having said that, I still use gcc in preference to any other compiler - for several reasons. First, it's a known quantity, and if I want to use gcc extensions (varargs macros are probably my favorite) I can. Its warnings and errors are not objectively the clearest in the industry, but to me they are because I'm so used to them. I know the compiler will do exactly the same thing on AIX as it does on Linux and HP-UX, within reason, and I can skip the licensing issues (the HP-UX bundled compiler is lousy, and AIX doesn't bundle one at all). gcc doesn't crash (well, it did once, in 1993, and I sent off a bug report) and its code generation is good enough not to be an issue for me.
The fact that it's free also means that you can always get the latest version without having to relicense or upgrade.
Oh yeah, that too. I'm the Licensing Czar around here (nobody else has the moral fibre / anal retention to care enough, I think) and the reduced hassle of free software is great.
I consider myself to be very technically inclined having programmed in VB for the last 8 years doing kernel level programming. I don't believe in C programming because contrary to popular belief, VB can go just as low level as C and the newest VB compiler generates code that's every bit as fast.
Your post has quite a few troll-alert phrases, but I like to give people the benefit of the doubt (sometimes).
even used an optimised version of gcc 3.1 to increase the execution speed of the binaries.
For future reference, gcc 2.95.3 probably generates better code than 3.1 (certainly better than 3.0). What makes 3.x so special is that C++ support has improved and is stabilising. The C backend still has to catch up a bit.
Certainly it's not a good idea to compile the kernel with gcc 3.1 - because 2.95.x is what people mostly test with, and kernel bugs only shown by specific versions of gcc have definitely been known to happen before. (I understand this is also true of a lot of closed-source software - devel houses have to keep old versions of compilers around to support old versions of their software.)
several boxes running the new 2.4.9 kernel
Hmmm, that could be a problem. I don't run big enough servers to have noticed, but many people have complained that the 2.4.x series of kernels took a long time to stabilise - until very recently most people recommended 2.2.19 or 2.2.20 if you really wanted stability. I believe 2.4.16 is a fairly solid kernel, but it's been a long, strange trip.
Also, swap requirements are a little weird. I guess 2.4.17 has a fix that makes the kernel require less of it, but the VM design was not optimised for low swap usage, so it's probably good to overestimate.
Not to mention the fact that the Linux kernel itself lacks any support for any type of journaled filesystem, memory protection, SMP support, etc
Pure FUD - either you are a classic troll or you are very misinformed. Memory protection has been in Linux for about 10 years (i.e. since version 0.01). SMP has been supported for about 5 years, and has been scaling better and better with time. Journaled filesystems have been a little long in coming, but there are four separate ones available today - reiserfs, ext3fs, jfs and xfs. (The latter two are only available externally as patches.) Both reiserfs and ext3fs are said to be quite stable these days, although reiserfs has a history of being declared stable just before annoying bugs are found, so I personally would avoid it for now.
Not that more is better, but remember that Windows 2000 comes with only one journaled filesystem (NTFS).
with just one Win2K machine doing more work than all 3 of the Linux boxes.
I'm guessing, if that's the case, that something on the Linux boxes was seriously misconfigured. The 2.4.9 kernel compiled with gcc 3.1 and possibly with insufficient swap might have been a contributing factor. Also, unlike Windows 2000, Linux has a lot of things you can tune for performance, and it may not perform optimally out-of-the-box. YMMV. (If you don't wish to mess with such things, stick with Windows. I'm serious - there's nothing wrong with that.)
You could have misconfigured your kernel before building it, come to that. Running IDE drives without UltraDMA support, for example, or turning on 64GB memory support when you have less than 1GB of memory....
I'm afraid that for anything more than a hobby OS, Windows 98/NT/2K are your only choices.
So that's the reason so many shops have huge servers running Solaris, AIX, VM/CMS, IRIX, OpenVMS, MVE, etc?
Basically we came to the conclusion that at some point down the road, those in charge of the GPL could suddenly blindside folks like myself and invoke its draconian clauses requiring the source code to our software be released. While its possible this day may never come, I'd rather not have to take the chance.
I understand - and in fact I agree. The legal weight of a license is more important than the intent, because any number of circumstances can change the intent of a copyright holder. (Most commonly, the copyright changes hands for one reason or another, and the new owner feels differently than the old.)
That's why I based my post on quotes from the license texts, rather than on quotes from commentators. I still don't see how a lawyer could conclude that the output of gcc is covered by the GPL - unless either
a) he has a very shallow understanding of technical issues and is confused by the difference between a program and its output, or
b) he didn't read the auxilliary license texts such as that found in libgcc1.c to cover the corner case of the runtime library... or
c) "derivative work" really does have such a loose definition under copyright law as to include the assembly language output of gcc, which is not copied verbatim out of any gcc source, even instruction-by-instruction, but calculated on the fly... or
d) he is being overly cautious to cover his backside
I'm guessing (d). Well, whatever, go ahead and don't use gcc in-house if you truly think your counsel knows the issues. It's what you pay him for, after all. I think he's overly paranoid, but I don't have a problem with paranoia - it's quite useful sometimes.
I'm afraid I'm going to have to go with the advice of a legal team who specializes in intellectual property law rather than a poster on a third-rate message board.
Your choice, and your loss. You might, however, read Section 0, Paragraph 2 of the GPL. It is often overlooked:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).[emphasis mine] Whether that is true depends on what the Program does.
The output of gcc is not a derivative work (or "work based on the Program") - it is assembly language, with certain strings in it like "compiled by gcc 2.xx", but bears very little resemblance to any actual gcc code. Similar arguments apply to binutils (the assembler and linker). [Obviously, if you compile gcc with itself, you'll get a derivative work of gcc... but not because you used gcc to compile it!]
But wait! I hear you say. Doesn't gcc come with a runtime library which every program links to? Way ahead of you, bro. From the comments at the top of libgcc1.c:
In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file with other programs, and to distribute those programs without any restriction coming from the use of this file.
Then later, in case you missed it the first time:
As a special exception, if you link this library with other files, some of which are compiled with GCC, to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License.
Similar disclaimers appear in other files that might be construed as "GPL-tainting the output" of a program - the bison templates, for example. I can only conclude that the intent of the FSF is not only quite clear (only to cover distribution of their software, not to restrict use of it) but legally unambiguous.
Unauthorized software is easy to prevent. With M$, use NT/2000 and use global policy to prevent software installs, and make sure that the user is not part of either the local admin or local power user groups.
That may prevent formal installation of software, but it does nothing to prevent use of software which was designed to run without being formally installed. I don't know which category the CDS reader is in.
With Unix/BSD, it's pretty much the same theory, just ensure that the user is not part of the wheel or root group
But see above - most Unix software runs just fine without being installed in a root-only location. Unix software almost never uses a registry-type system, or anything not accessible to joe user. Free software lets you recompile with any install path you want, and non-free software is usually controlled by a startup script that sets a bunch of variables. (To be fair, there is sw that needs to run on boot, or bind to low ports, or access raw devices like (in some cases) the cdrom, but most software doesn't require root at all.)
You mean like when Scalia picked the winner of the presidential election? You might agree with the results, but the methods were 'from the bench', all right.
First of all, that wasn't "legislating from the bench". It was deciding a specific issue at hand. It is much worse when a court decides, out of the blue as it were, that something is or isn't Constitutional, when the Constitution itself doesn't say anything one way or the other. You know what I mean, I bet. Some federal judges seem to interpret the term unconstitutional to mean "unfair, in my book, and guess what, I'm a federal judge so my book is what counts". The famous Miranda decision in the 1960s is a good example. You might agree with the doctrine of testimony being inadmissible in criminal court if it was obtained without the defendent being informed of certain of his rights -- I happen to think it's a pretty good rule -- but to claim that the Constitution somewhere mandates this doctrine is pure fabrication. The "Miranda Rule" should have been legislated... by actual legislators, state and/or federal.
Second, what was the Court supposed to do in December 2000? Ignore the Gore lawsuit entirely? That's an implicit decision in favor of the lower court's decision, you know. By your reasoning it is "picking the winner".
Corollary: the Court (including Justice Scalia) had to make some judgment. Either way they were interfering with the Florida election commission procedure - either to uphold it (as they did) or strike it down. Insofar as this meddling can be considered "legislating", they didn't have much choice.
Third, picking the winner of the election was, or should have been, a secondary consideration, or rather, no consideration at all. I don't claim to know the hearts of the Justices, but they should have been deciding on a mere procedural matter which just happened to have major practical implications. Obviously, there had to be a winner and a loser - that's how elections work. It does not follow that the Court "picked the winner".
Slashdot Mirror
Unsupported by whom? Lots of people are happy to support Samba - if you pay them. It's also supported as part of the standard install on HP-UX now, and I think on some other Unix versions (not to mention almost all Linux vendors).
...I mean, come on. Are you seriously suggesting that Microsoft supports SFU better than Red Hat supports Samba? The nature of the IT world is that any vendor will support their own products to whatever extent you desire, if you give them enough money. As will just about any third-party consultant. (Not that third-party consultants are much help for fixing bugs in SFU, due to its closed-source nature.)
[OT, oh well]
Hey! I miss that feature! I compile stuff on AIX occasionally, and it's pretty annoying that the linker assumes that my runtime library path should consist of all my -L flags. Yes, even relative ones! You may say, oh well, a long runtime link path doesn't really hurt, but if you want something to work reliably whether or not NFS mounts are behaving, you have to pay attention to this stuff.
The gcc developers many years ago tried to combine the -L and -R flags on Solaris (to make it more like other Unices), but eventually concluded that they would be losing too much flexibility. I agree.
Which has nothing to do with raw sockets. Unix allows raw sockets - if you're root. NT allows raw sockets - if you're in the administrators group. XP allows raw sockets - if you're an administrator which for the default home setup means everybody.
I honestly don't get the people who say raw sockets are a security problem. By their arguments, everyone should be forced to use a private, proprietary network behind custom proxy servers, like AOL used to be, so they can't get out onto the raw internet and wreak havoc. Back before AOL became Yet Another ISP, it was darned difficult to launch script kiddie attacks from there against actual Internet sites....
I would scream bloody murder if the Linux gods took raw sockets away from me. Not that they'd be stupid enough to even think about that. Nobody questions the usefulness of tcpdump, which relies on raw sockets.
Very well. This only matters, though, if you don't trust automake. If you do trust it, you can always just audit Makefile.am, then re-run automake and autoconf to produce Makefile.in and Makefile.
Sure, it's inconvenient, and I understand why having a readable Makefile is nice for auditing the install commands....
Is that so? I believe you are mistaken - SDL is only a wrapper library which calls out to existing methods of doing graphics (among other things).
One such method is Xlib, and I don't want to run an X server. Another is the Linux kernel framebuffer, and I'm not so interested in taking the performance hit of running in frame buffer mode (why do you think I use a text console in the first place - mostly for speed). A third is aalib, and I don't want to run Doom in ASCII art (slashdot reports about Quake notwithstanding). Which leaves me running SDL applications in ... svgalib mode. Which requries root.
"Xlib is really old.. Gtk+ is the way now."
The two statements are equivalent.
Which autoconf-generated Makefiles? Try diffing your favorite write-only Makefile against its corresponding Makefile.in - I think you'll find that autoconf isn't doing the damage here. Maybe you meant automake, which takes a Makefile.am and produces Makefile.in.
If you are referring to the Makefiles in gcc, gdb and binutils - yes, they are hairy messes, which have little to do with autoconf and much to do with the complexity of accomplishing the task at hand without using any advanced 'make' features. Apparently the Free Software Foundation wants their software to compile with anybody's version of 'make' back to about 1985.
...or it uses svgalib. On Linux, at least, svgalib requires root to initialise itself.
I don't run an X server on my box - I hardly ever actually need graphics. So if I want to kick back with a round of Doom (don't laugh, I still enjoy it) I run the svgalib version.
There. Now you know. Go ahead and try to social-engineer me into replacing my Doom binary with one of yours. (:
Or just unsuited for writing compilers in. The gcc Fortran compiler is not written in Fortran, because C is a better language for that and the gcc developers know a C compiler will be available to build g77.
Apparently the Mono people decided to use C# for implementation even though it is interpreted (and JIT compiled) - an interesting decision IMO.
...so by this definition the 8088 was an 8-bit processor and the 386SX was 16-bit.
If you go by use address space, the 6502 is a 16-bit CPU. And the Pentium Pro is 36-bit. (Sort of.)
I think a third definition - width of general-purpose registers - is the commonly used one. In that case the 6502 is only 8-bit, the 8088 is 16-bit and the 386SX is 32-bit.
Actually, there is every reason to expect a larger word size to increase speed, in some applications. Thanks to Mr Turing we all know that any computer can basically do the job of any other, but have you ever written a 16-bit multiply routine on an 8-bit CPU? It's not hard or anything, but it is slow.
Of course, most desktop applications today do not need 64-bit numbers....
Not having tried it, what I heard was that while NT ran on Alpha, it was still basically 32-bit. Just like Win95 was largely 16-bit even though it ran in 386 protected mode.
That would explain why Tru64 (which, like NT, is microkernel-based) was faster. Some say that to get the best performance on Alpha one should compile code with the Tru64 compilers but run it on Linux (the two are ABI-compatible).
Yes but confuse which people? If you aren't willing to keep up with the issues of 2.0.x vs 2.2.x vs 2.2.x-ac vs 2.4.x vs 2.4.x-ac vs 2.4.x-mjc vs 2.5.x vs 2.5.x-dj, you will probably do just fine running your vendor-installed kernel, which is yet another branch, generally.
Now I don't get confused about those eight major branches - but hey, what a coincidence, I'm the target audience for some of those branches.
Does anyone in the real world care about the two branches of HP-UX 11.00? That is, the standard release and the ccr builds? What, you say? You've never heard of 11.00-ccr? My point exactly. Most people don't need to know or care.
Actually, that's system-dependent includes, and the reason is historical. Five years ago you had to #include<linux/*.h> for quite a few random things ... but that was five years ago.
The world changed - glibc 2.1 came out - and nowadays you should never include <linux/*.h> except for OS-dependent stuff like CD burner software. The reason the directory still exists is that other files in /usr/include make use of it - but that's an implementation detail which as a mere software developer you shouldn't have to worry about.
Out of curiosity, what changed? The kernel you were so happy with a year ago - did it suddenly fail to work?
Or are you saying current kernels aren't as stable as the then-current kernels? If that's the case, just keep using those. I don't think I've ever heard anyone complain about the stability of 2.2.16 - 2.2.20 - people complaining about kernel instability are generally referring to 2.4. The 2.2 series isn't dead yet!
No offense, but are you saying this as a kernel developer, or as a bystander? The developers themselves don't seem hostile to multiple trees at all - they usually maintain their own tree anyway. And judging by how many people developed against 2.2-ac rather than 2.2-linus, I'd say they like working that way.
The drawback here is if MJC doesn't accept responsibility for merging patches upstream to Marcelo. Alan has always been very good about this.
Some of the patches in -mjc are being considered for 2.5 - some are not - for technical reasons. A maintainer doesn't have to choose between supporting 2.4 and 2.5 - why not do both? And if you want to support only 2.5, let MJC do the backport to 2.4. Conversely, if you want to support only 2.4, let Dave Jones do the forward port.
Sounds like a good system to me.
Agreed, SMP makes preempt a lot less necessary.
I'm not sure about all of them, but:
This adds up to the sad fact that official 2.2 and 2.4 kernels are never even close to up-to-date w/r/t Hedrick's IDE work. New IDE drivers, random bug fixes, etc.
HTH.
Is that so? (If so, good move.) NT4 didn't. NT Workstation and NT Server shared the same kernel - or kernels, actually, a UP kernel and an SMP kernel.
Considering the quite different instruction scheduling properties of the Pentium/Pentium-MMX from CPUs that came before and after it, the fact that MS doesn't ship kernels compiled to optimise for a given CPU must have hurt. I don't know if they have any other measures to compensate.
("Must have hurt", past tense, because they almost certainly no longer optimise for a Pentium, if they ever did. And subsequent Intel CPUs are much more "compatible" in the optimisation sense.)
I've just compiled for woody/sid i386.
Of course you should never install random binaries you got from a slashdot poster. Who knows, they could be trojaned.
Well, I don't do many speed benchmarks, but IBM's Visual Age C compiler (not free, mind!) generates much smaller code on AIX. [Yes, I tried gcc-Os.] I don't know about MSVC. Small object sizes are nice, they give me a warm fuzzy.
Yeah, when I said gcc never crashed, I was referring to the C compiler.
I hardly do any C++ programming but I had to do some three or four years ago - and I remember spending a great deal of time chasing bugs that turned out to be the compiler. (In one instance I actually used __attribute__((weak)) to work around a bug where egcs g++ was producing two copies of a function and then complaining at link time!)
I have to say I'm in awe of how gcc can have an exception fall through multiple stack frames with little or no cost to the common case. (At least this is their claim - zero-cost exceptions on some architectures. I am not competent to intelligently evaluate this claim.) The C++ language has developed into ADA with s:Pascal:C:g, and I don't envy those who are trying to implement the whole thing.
...And at this point my post has to do with the release of Gnumeric 1.0 - how, again?
A bit OT, but oh well. What you describe was certainly true in the past - vendor compilers were such a mixed bag that GCC has extensive release notes detailing how to bootstrap it with various other compilers without tripping numerous known bugs. And of course many vendors bundle a sub-optimal C compiler with the OS and make you pay extra for their Real Thing.
But gcc is not the Holy Grail of code generation. Not anymore. IBM and CodeWarrior both beat it senseless on PowerPC; Intel has something that apparently does better on x86, and a lot better on Itanium; DEC has kicked its butt on Alpha for years.
(Of course, gcc probably has more CPU backends than any other C compiler out there - but within a single architecture it often is not the best.)
Having said that, I still use gcc in preference to any other compiler - for several reasons. First, it's a known quantity, and if I want to use gcc extensions (varargs macros are probably my favorite) I can. Its warnings and errors are not objectively the clearest in the industry, but to me they are because I'm so used to them. I know the compiler will do exactly the same thing on AIX as it does on Linux and HP-UX, within reason, and I can skip the licensing issues (the HP-UX bundled compiler is lousy, and AIX doesn't bundle one at all). gcc doesn't crash (well, it did once, in 1993, and I sent off a bug report) and its code generation is good enough not to be an issue for me.
Oh yeah, that too. I'm the Licensing Czar around here (nobody else has the moral fibre / anal retention to care enough, I think) and the reduced hassle of free software is great.
Your post has quite a few troll-alert phrases, but I like to give people the benefit of the doubt (sometimes).
For future reference, gcc 2.95.3 probably generates better code than 3.1 (certainly better than 3.0). What makes 3.x so special is that C++ support has improved and is stabilising. The C backend still has to catch up a bit.
Certainly it's not a good idea to compile the kernel with gcc 3.1 - because 2.95.x is what people mostly test with, and kernel bugs only shown by specific versions of gcc have definitely been known to happen before. (I understand this is also true of a lot of closed-source software - devel houses have to keep old versions of compilers around to support old versions of their software.)
Hmmm, that could be a problem. I don't run big enough servers to have noticed, but many people have complained that the 2.4.x series of kernels took a long time to stabilise - until very recently most people recommended 2.2.19 or 2.2.20 if you really wanted stability. I believe 2.4.16 is a fairly solid kernel, but it's been a long, strange trip.
Also, swap requirements are a little weird. I guess 2.4.17 has a fix that makes the kernel require less of it, but the VM design was not optimised for low swap usage, so it's probably good to overestimate.
Pure FUD - either you are a classic troll or you are very misinformed. Memory protection has been in Linux for about 10 years (i.e. since version 0.01). SMP has been supported for about 5 years, and has been scaling better and better with time. Journaled filesystems have been a little long in coming, but there are four separate ones available today - reiserfs, ext3fs, jfs and xfs. (The latter two are only available externally as patches.) Both reiserfs and ext3fs are said to be quite stable these days, although reiserfs has a history of being declared stable just before annoying bugs are found, so I personally would avoid it for now.
Not that more is better, but remember that Windows 2000 comes with only one journaled filesystem (NTFS).
I'm guessing, if that's the case, that something on the Linux boxes was seriously misconfigured. The 2.4.9 kernel compiled with gcc 3.1 and possibly with insufficient swap might have been a contributing factor. Also, unlike Windows 2000, Linux has a lot of things you can tune for performance, and it may not perform optimally out-of-the-box. YMMV. (If you don't wish to mess with such things, stick with Windows. I'm serious - there's nothing wrong with that.)
You could have misconfigured your kernel before building it, come to that. Running IDE drives without UltraDMA support, for example, or turning on 64GB memory support when you have less than 1GB of memory....
So that's the reason so many shops have huge servers running Solaris, AIX, VM/CMS, IRIX, OpenVMS, MVE, etc?
I understand - and in fact I agree. The legal weight of a license is more important than the intent, because any number of circumstances can change the intent of a copyright holder. (Most commonly, the copyright changes hands for one reason or another, and the new owner feels differently than the old.)
That's why I based my post on quotes from the license texts, rather than on quotes from commentators. I still don't see how a lawyer could conclude that the output of gcc is covered by the GPL - unless either
a) he has a very shallow understanding of technical issues and is confused by the difference between a program and its output, or
b) he didn't read the auxilliary license texts such as that found in libgcc1.c to cover the corner case of the runtime library ... or
c) "derivative work" really does have such a loose definition under copyright law as to include the assembly language output of gcc, which is not copied verbatim out of any gcc source, even instruction-by-instruction, but calculated on the fly ... or
d) he is being overly cautious to cover his backside
I'm guessing (d). Well, whatever, go ahead and don't use gcc in-house if you truly think your counsel knows the issues. It's what you pay him for, after all. I think he's overly paranoid, but I don't have a problem with paranoia - it's quite useful sometimes.
(Score: -1, Offtopic)
IANAL, obviously
Your choice, and your loss. You might, however, read Section 0, Paragraph 2 of the GPL. It is often overlooked:
The output of gcc is not a derivative work (or "work based on the Program") - it is assembly language, with certain strings in it like "compiled by gcc 2.xx", but bears very little resemblance to any actual gcc code. Similar arguments apply to binutils (the assembler and linker). [Obviously, if you compile gcc with itself, you'll get a derivative work of gcc ... but not because you used gcc to compile it!]
But wait! I hear you say. Doesn't gcc come with a runtime library which every program links to? Way ahead of you, bro. From the comments at the top of libgcc1.c:
Then later, in case you missed it the first time:
Similar disclaimers appear in other files that might be construed as "GPL-tainting the output" of a program - the bison templates, for example. I can only conclude that the intent of the FSF is not only quite clear (only to cover distribution of their software, not to restrict use of it) but legally unambiguous.
That may prevent formal installation of software, but it does nothing to prevent use of software which was designed to run without being formally installed. I don't know which category the CDS reader is in.
But see above - most Unix software runs just fine without being installed in a root-only location. Unix software almost never uses a registry-type system, or anything not accessible to joe user. Free software lets you recompile with any install path you want, and non-free software is usually controlled by a startup script that sets a bunch of variables. (To be fair, there is sw that needs to run on boot, or bind to low ports, or access raw devices like (in some cases) the cdrom, but most software doesn't require root at all.)
First of all, that wasn't "legislating from the bench". It was deciding a specific issue at hand. It is much worse when a court decides, out of the blue as it were, that something is or isn't Constitutional, when the Constitution itself doesn't say anything one way or the other. You know what I mean, I bet. Some federal judges seem to interpret the term unconstitutional to mean "unfair, in my book, and guess what, I'm a federal judge so my book is what counts". The famous Miranda decision in the 1960s is a good example. You might agree with the doctrine of testimony being inadmissible in criminal court if it was obtained without the defendent being informed of certain of his rights -- I happen to think it's a pretty good rule -- but to claim that the Constitution somewhere mandates this doctrine is pure fabrication. The "Miranda Rule" should have been legislated ... by actual legislators, state and/or federal.
Second, what was the Court supposed to do in December 2000? Ignore the Gore lawsuit entirely? That's an implicit decision in favor of the lower court's decision, you know. By your reasoning it is "picking the winner".
Corollary: the Court (including Justice Scalia) had to make some judgment. Either way they were interfering with the Florida election commission procedure - either to uphold it (as they did) or strike it down. Insofar as this meddling can be considered "legislating", they didn't have much choice.
Third, picking the winner of the election was, or should have been, a secondary consideration, or rather, no consideration at all. I don't claim to know the hearts of the Justices, but they should have been deciding on a mere procedural matter which just happened to have major practical implications. Obviously, there had to be a winner and a loser - that's how elections work. It does not follow that the Court "picked the winner".