> 1. The OS of the major supplier > 2. Linux > 3. the also rans....
You oversimplify. Greatly. It is not in dispute that more OSes run on x86 than any other platform. If we just select choice 2 only, there are about four or five Linux distros for PPC, one of which (Yellow Dog) is considered to be a major distribution. There are a couple of dozen major distros for x86 and nobody knows how many minor ones. Realistic non-also-ran choices that are more popular than YellowDog include Mandrake, Debian, Slackware, RedHat/Fedora/PinkTie/WhateverTheyCall ItNow, and SUSE. (Gentoo is getting to be borderline on being a major distro these days and I think runs on both, but more of the packages support x86 than PPC, which is typical.) Then there's the matter of application software (to say nothing of games); many packages work on Linux-x86 but do not run on PPC, even under Linux. (Granted, most of the best apps are properly cross-platform, but even then it's a lot harder to find precompiled versions for PPC.)
Breaking down choice 3 is even more telling; the also-ran OSes for the PPC architechture leave something to be desired. (Unless you consider BSD to be an also-ran...) The "also-ran" choices for x86 are things like Solaris.
It is true that the Apple hardware has some advantages, and the fact that Apple is careful only to put together a limited number of highly-tested combinations is one of the largest of those advantages.
(Another advantage is the ability to run Mac OS X, though that's only an advantage if you want to do that. (I thought about it but rejected it for the same reason I rejected the BeOS (another of the x86 also-rans, though it used to run on PPC at one time in the days before G3): these OSes do not allow the user to set global color preferences, and I absolutely NEED that because Evil Blinding White Backgrounds are the bane of my existence. Yes, I know most people don't care. I care. I have to care, because my eyes can't take eight straight hours of that many photons. (My eyes are more sensitive to light than average; I also have to squint when I go outside in the daytime, which I prefer not to do. I see very well at night...)))
So, anyway, back to topic... yes, PPC has advantages. However, the flip side is that the PPC architecture does limit your choices. It can be said that they are decent choices, but the limits are there. Trying to deny the limits or handwaive them away by summarizing all the world's operating systems into three categories doesn't change that.
> I'm sure somebody out there must know what they are called?
Ask a C programmer. It's mostly C (and maybe C++) programmers who spend time thinking about indentation styles. People who use lisp-based languages just let their editors' parenthesis-matching and automatic-indentation stuff sort it out, and Perl programmers worry more about semantics than syntax, or just put the whole block on one line if it's small. Python enforces its own brand of indentation at the language level, so its programmers can't really get into arguements about which option is visually better; they do what works. Most other languages are only really used by a relatively small group of people, so they don't get into the debates as heavily. That leaves Java, but I don't really know how Java programmers view indentation, since I haven't had much contact with Java people.
There *are* names for the different indentation styles, mostly taken from the most famous person or group or book that advocates them, such as Gnu, K&R, or whoever. But not being a C programmer I don't know which are which. Truth be told, I have a hard time remembering which is which between big endian and little endian as well; most of the data I work with is structured as a flat list or string of single-byte characters, and the languages I use are sufficiently "into" portability that they don't expose such details as in-memory byte-storage order to the programmer directly. The only time I've ever really had to do with it is when working with the occasional binary file format, but mostly I prefer to let someone else write a module for the format and then I just grab the module off of CPAN and use it:-)
No, I didn't forget per se. I chose not to mention that one because I was unsure of what terminology to use to concisely mention it without going into the details of the two positions. IOW, I didn't know what simple word to put on each side of the "vs", so I just skipped it. But yes, that's the other classic one. Of late, Perl vs Foo is becomming somewhat popular as well, but Foo varies so widely (everything from C to PHP) that I left that one out also.
There is one that I did forget, and should have included: OOP vs any other programming paradigm (procedural/imperative and functional are the most popular other choices). Though being a Perl geek I of course skirt around that one by advocating a multiparadigmatic approach. ("Yeah, see, this bit of code here greps the list of objects returned by somefunc for ones that return a true result for somemethod and does a map transform on the resulting list, producing a list of hasrefs of closures that it assigns to this lexically-scoped array. Each hashref of closures holds one of the objects in common between several subs, which will use the object to maintain state through subsequent calls, until the whole thing passes out of scope at the end of the block." There you've got OO, functional, and procedural programming all rolled together in one big happy family:-)
The very best keyboards are made by Avant. These are the ones that not only have full tactile feedback but also are fully remappable and provide full programmable macros. The remapping and macro programming can be done at the hardware level as long as you don't need to change any of the three keys that control the remapping (e.g., right Ctrl, the up arrow, or I forget the third one), or there's a Win32-based utility that you can use otherwise, which is what I do since I wanted to remap both the up arrow and right Ctrl. (Yeah, I'm using a completely custom layout.) With a keyboard this good, you almost don't need a mouse, except for graphics editing.
> Without making this into a religious war, can someone make the argument > of why case-sensitivity in a language is 'a good thing'?
If you look up "holy war" online and skip over anything having to do with real-world non-computer-geek religions, you'll find the following classic examples of holy war materiel: Emacs vs vi, big-endian vs little-endian, *nix vs non-*nix, CISC vs RISC, and case-sensitive vs case-insensitive.
In short, it's highly a matter of taste. Some people even like to have case-sensitivity in their filesystems. (Personally, I dislike that and think that should be optionally possible to turn it off in certain directory trees (particularly,/home).)
Personally, I don't mind case-sensitivity in a language, generally. Perl is very much case-sensitive, as is elisp, and neither has ever troubled me. The only time case-sensitivity in a language has really bothered me is in Inform -- but that was because of the incompatible _changes_ in the case sensitivity from Inform5 to Inform6, which caused a lot of my code to break. Now, that said, it is also possible for a language which is case-sensitive to go far wrong in its use of case by being inconsistent in a way that will leave you unsure which case is correct sometimes. For example, if a lot of the ready-made modules/libraries/whatever that you use are not consistent with one another in their use of case, that would be very bad. In elisp and Perl, I have not generally found that to be the case. I can't speak for Java; my attempts to learn Java have largely ended with "Ew, it's like C++".
> The only conceivable justification would be, "Well, Photoshop does it
And, come to think of it, Photoshop *doesn't* -- at least, Photoshop 6.5 for the Mac doesn't. It treats each image, toolbox, dialog box, or whatever as a separate toplevel window, just like Gimp does.
>Why don't they use a master window to contain all the other child Gimp windows?
Ack! That would be *horrible*. You'd be forced to maximize that big parent window, in order to have enough space to spread out all your various Gimp (sub)windows, but then it would block out everything behind; you could not, for example, leave a gnome-terminal window showing through behind below your image, so that you'd notice when your download/compile/whatever completed.
Please, don't force us into an opaque rectangle. There's no reason for such a heinous restriction. The only conceivable justification would be, "Well, Photoshop does it, so Gimp doesn't suck any worse than Photoshop". But even if it was in good company, it would still suck.
In other words, websites that are already so loaded with multimedia content that they're utterly unusable on a residential connection. Full-motion video advertisements will only reinforce what we already know about these sites: they are intended mainly to be viewed by people sitting on a T1 or better connection at work.
Normal websites that calculate their page load times based on a 56K dialup or even cable modem will obviously know better than to adopt this sort of thing.
Oh, I also store all of my email in a big fat directory tree, with *no* compression (not even lossless compression), just to make it easier to rgrep. The waste! Clearly I'm insane. Pay no attention at all to anything I say; I'm probably just a shill working for a hard drive manufacturer.
> Try either 384 average kbps VBR mp3 (if you have portable devices) > or 256 avg kbps VBR ogg. You *will* be amazed.
Or, I could just use WAV. The files are larger, but it's worth it for three reasons:
1. They sound better. Perfect, even. Full CD quality, all the
time, without exception, no artifacts *ever*.
2. Drive space is $cheap.
3. They sound better.
But then, I'm the kind of guy who also, being a stickler for quality irrespective of the extra $30 I might potentially have to spend on a slightly larger hard drive every two or three years as a result, careless spendthrift oaf of wanton indulgence that I am, stores all his images in PNG or even (gasp) XCF format (for preserving layers, to make future editing easier). So, obviously, you should ignore my opinions on lossy compression, as I'm clearly just being senseless and excessive beyond the bounds of all reason regarding the quality of my media files. I probably don't even tape music off the radio, citing "static" or somesuch inane balderdash as my reason.
> fork() does not just create a child process. It creates a child process > running the same program
Yes, obviously, the same program with the same state (initially; after the fork the two diverge). I use fork() on Windows all the time. Admittedly, I'm using Perl, not C/C++/VB, but are you telling me that ActiveState made up fork for Win32 out of whole cloth? That seems odd, since perl does not support fork on other platforms that don't have it (e.g., DOS). Further, if you compile the vanilla Perl sources on Windows (using e.g. cygwin) it supports fork just fine -- and, for that matter, threads.
Moreover, many applications not written in Perl appear to use fork on Windows, though (not being a C programmer) I have not examined how they do so. Apache, for example, appears to fork off multiple copies of itself, just as it does on POSIX systems.
If the Windows API doesn't have fork() as such, *something* must provide the same or equivalent functionality.
Umm, *where* did this idea come from? Yeah, Windows has some shortcomings, but no fork? Where did this idea come from? Of course it has fork -- it's had fork since Windows 95 came out (sooner if you count early versions of NT). Okay, the 3.x series didn't have fork, but 3.x was just a mostly-useless graphical shell.
> Why do so many people find the word "suite" to be synonymous with > "monolithic app"?
Because most of the components of the suite are not available as *birds yet. Navigator (if the browser itself is all you use) can be replaced with Firebird, and the truly adventurous can replace Messenger with Thunderbird, and Composer (which to me was never useful anyway) is I *think* available as a Thunderbird extension, but that's about it. Sunbird last I checked is so far a non-starter, and then there are the other components... where are they in the *bird series? They remain... unimplemented. Okay, I think DOM inspector is available as a Firebird extension, but then you can only use it to inspect Firebird; you cannot, for example, use it to look at the Thunderbird XUL (for theming purposes). So, basically, the *birds are still lacking that.
It's not the monolithicity of SeaMonkey that keeps people using it; it's the fact that it's essentially *complete* (well, except for Messenger, which is still missing quite a number of critical features, but that's another thread). The *birds are still very alpha; there are whole *categories* of features that nobody has even *looked* at implementing in them yet.
If all you want is the browser, Firebird can be used as a replacement for Navigator (though to get the full functionality of Navigator you have to install about twenty extensions and a small handful of minor things are still not up to snuff), but if you use the SeaMonkey whole suite, there is no non-monolithic replacement available yet from Mozilla.org.
Back when Decent II was still current and we were waiting for D3 to come out, along with the trailers and things, Parallax (or was it Interplay?) released some MP3s of some music for the game. That was my first introduction to the MP3 format; prior to that all the music I'd downloaded was either MIDI or WAV. I still *hugely* prefer MIDI for instrumental music; assuming your sound card is decent (not some onboard junk with no advanced wavetable), it sounds *much* more like real music. With a *good* sound card, it sounds like it was played by an orchestra and recorded, i.e., CD quality. MP3 on the other hand sounds approximately like JPEG looks -- ugly.
For vocal music, I use WAV format pretty much exclusively. (This makes downloading fairly impractical, but I get the CDs and rip the songs I want and store them on a hard drive. It's amazing how much music you can fit on a 30GB filesystem in full-quality WAV format if you only rip the songs you actually like.)
Recent AIX code? Yeah, I can think of several reasons why SCO would want to look at recent AIX code, and none of them have jack squat to do with Linux. If they could actually get that out of this, it might almost make the whole lawsuit thing worthwhile from their perspective (ethics aside). I can't see as how they're going to get it without some kind of due cause, though.
> > so what, exactly, is unethical about moving jobs overseas? > > Taking peoples livelyhood away
Moving a job overseas doesn't destroy a job; it moves it overseas. The same number of people are employed as before; it's just different people. I know it's a nice emotional plea to wine about people being out of work, but it is equally true that people now have work who didn't have it before.
Further, and more importantly, the negative ecconomic impact on the country the jobs were moved from (in this case the US) is extremely short-term (as in, definitely less than five years and often a matter of three months or less). Every job moved from the US to Ubbledubgong (a random third-world country -- Mexico, India, Brasil, Cameroun, wherever) pushes US currency into Ubbledubgong; this money does not vanish into thin air; it goes into Ubbledubgong. There it is spent and at some point it makes its way back to the US. The details are complicated (exchange rates are not as simple as you would like to think), but the long and short of it is that the people in Ubbledubgong purchase widgets (i.e., goods and/or services) that are imported from the US (which creates jobs) or from some other country that imports from the US (which, indirectly, amounts to the same thing).
What is more, the jobs that are moved overseas have a tendency on average to be less desirable than the jobs that are created as a result of the trade. This is not always the case for every job, but the averages work out. Trade is a *good* thing for the ecconomy.
> so that you can live your own pockets with a few more millions
It's the CEO's job to make decisions that are sound for the company. In many cases, moving jobs overseas is a sound decision. (In some cases not; moving phone support overseas is often a remarkably poor decision, because it makes frustrated customers, which is bad. I haven't looked at the HP decision in particular.) Doing your job is, last I checked, a good way to make money. If there were some ethical reason not to move the jobs overseas, then that would be different; doing evil to line your pockets is, of course, evil. Doing perfectly ethical good business to line your pockets, however, is still perfectly ethical good business.
Now, there are unethical things that can be done in the course of making what would otherwise be an ethical business move. Things like swearing up and down to your employees that the company is doing fine and there are no downsizings planned, when in fact you know very well you're about to axe a number of them, is unethical because it's dishonest.
> pay some overseas people a wage that will never allow them to buy all > these products your company is selling
It will raise their standard of living. Perhaps not enough to let them all buy HP computers tomorrow, no, but frankly that's not what they really need at the moment. Sure, it would be nice, but if you raise their standard of living to where they can get, say, indoor plumbing, that's actually much more immediately useful. Further, it stimulates the local eccomony there and indirectly creates additional jobs for additional people.
> Why do people think this form of globalization is going to better the world.
No, it won't better the world. (That would require changing human nature.) It will, however, better the ecconomy.
> People like her only care about bettering their own bank accounts.
I suspect that's mostly true -- and if it would be bad for the ecconomy, a lot of CEOs would probably do it anyway, if it meant more money for them personally. But in fact it's not bad for the ecconomy, not in the medium and long term.
> And look what happens when you buy all your hardware from random sources > and piece it all together... you get so many machines that lock up for no > reason at all.
That's if you get the cheapo junk. You can buy quality commodity PC components for a little more (still less than Apple hardware), or buy from a vendor such as Dell, which takes the individual component decisions out of your hands. This is all well and good, and you still have a choice what OS to run, too:-)
> Conductive is your friend. You want static dissipation.
You don't want to short things out. Having a nice ground handy would be good, but you don't want the whole bench to conduct current, especially the surface.
> Or M$ just uses the next service pack/patch to revise the EULA.
That would still take 2-3 months. And that's *after* captive-ntfs gets on the Microsoft radar, which is six months *after* it's widely deployed, which is six months from today. So we're still talking fifteen months -- enough time, in theory, for someone to code the desired capabilities into the native NTFS driver. (One of the big distros should probably pay someone to do this, though, as it hasn't happened up till now. Probably because most of the serious kernel hackers haven't used Windows since roughly 3.11 for Workgroups, as they have a tendency to live deep in server/developer space, where most of the "users" are programmers of some kind and even the managers have heard of Unix.)
> Also NTFS is preferable over FAT because FAT has no concept of file ownership.
This would only matter for situations with multiple users who don't trust one another, which basically either means servers (where if you're using Windows I feel sorry for you) or some kind of unusual desktop situation. I've seen many, many Windows desktops, but they were all either used by one person or were used by multiple people who all shared the same user account. I've not yet seen anyone actually using the Windows multiuser stuff in real life. I'm sure it happens, but it is not the typical situation.
And quite obviously the multiuser stuff is unimportant in a multiboot scenerio, since that's invariably a computer used by one person, or else different people use different OSes (e.g., the spouse uses Windows). Also, the other OS can mount the NTFS partition (albeit perhaps in read-only mode, at least if you don't want to screw things up -- until now), so security is already gone.
Frankly, even in a single-boot scenerio, a bootable removable drive pretty much removes all security these days, what with Knoppix and tomsrootboot and all those sorts of things. ISTR there's a floppy disk image out there that's made for changing the passwords in the WindowsXP registry. If you need real security, you frankly have to keep the user physically away from the computer, or use an encrypted filesystem that requires key entry on boot.
> Its almost like running windows 98.
I believe that was the primary #1 selling point of Windows XP. If it *weren't* almost like using Win98, it would have received about the same user response as Windows 2000, i.e., "make it go away". After Win2000 flopped in the market place (not flopped compared to NT4, but flopped in terms of being received by consumers as the next version after Win98), Microsoft backpedaled their no-more-versions-of-Win9x position, did some market research to find out what differences regular people saw between the two OSes, released WinMe (to tide over the OEMs who were carping about their position trying to sell either Win2000, which people wouldn't buy, or Win98SE, which was officially obsolete), and poured the results of that market research into WinXP. So yeah, it's almost like Windows 98. If you squint. At the time, security was not a major concern for most users. (It has in the time since become a more significant concern. Yes, end users can be slow catching on to things.)
> No crashes, no dependancy problems, just the hassle of compiling everything > before it'll work.
I've had some problems with it. Sometimes you can run into a situation where a new version of some package conflicts with the old version in some way that portage can't work out by itself, and so you have to manually unmerge the old version first. (You don't find this out until your emerge fails, and then you have to track down the issue.) Specifically, I ran into this problem twice with certain important Perl modules. Since they're a dependency for virtually everything, skipping over it is not an option.
I also had a really weird problem that may be fairly unusual, because I did not find any useful information on the web about it and as yet have not resolved it. I can't emerge coreutils, because during the compile it does *something* it's not supposed to do and portage kills it off and issues a sandbox error. This rather puts a damper on upgrading much of anything else, let me tell you. I'm typing this right now on Mandrake (which is installed on the other disk), because I don't want to deal with that issue at the moment.
Oh, and this is possibly a coincidence, but I've had two hard drives die while running Gentoo. I've run Mandrake for much longer (since 7.1) and only had the same number of drives (2) go bad -- and they went much more gradually, so that I was able to get my stuff off without much trouble. Again, this is very likely a coincidence, but it makes it hard for me to get as excited about Gentoo in practice as I'd like to be in theory.
> Novell bought System V Unix in 1994, at which time BSD was basically > obsolete and commercially worthless.
By most accounts, the general consensus is that in 1994 the AT&T Unix code base was also obsolete and commercially worthless.
> That's 10 years of continuous R&D not accounted for in your invented history.
That history is not invented. It's simplified, yes, but the details that are left out aren't really germaine. The claims SCO is making require the sort of exclusive rights that are belied by _this part_ of the history. Some other parts of the history are available on the web for the curious.
> I think it's important to note that the issue with the current Linux > kernel's NTFS support is its capabilities, not its quality.
Capabilities aren't part of quality? Do you want a car that can't make right turns? What about a car that can't make turns at all -- it would still be fine for driving straight ahead, and you could even put it in reverse...
> It can only write to a file without increasing its size - and no creating > or deleting files or directories.
This limits its usefulness in important ways. Not that it is if no value, but I would really like to think that in a few months someone will figure out how to (safely) lift these restrictions.
Slashdot Mirror
> 1. The OS of the major supplier
l ItNow, and SUSE. (Gentoo is getting
> 2. Linux
> 3. the also rans....
You oversimplify. Greatly. It is not in dispute that more OSes run on x86
than any other platform. If we just select choice 2 only, there are about
four or five Linux distros for PPC, one of which (Yellow Dog) is considered
to be a major distribution. There are a couple of dozen major distros for
x86 and nobody knows how many minor ones. Realistic non-also-ran choices
that are more popular than YellowDog include Mandrake, Debian, Slackware,
RedHat/Fedora/PinkTie/WhateverTheyCal
to be borderline on being a major distro these days and I think runs on
both, but more of the packages support x86 than PPC, which is typical.)
Then there's the matter of application software (to say nothing of games);
many packages work on Linux-x86 but do not run on PPC, even under Linux.
(Granted, most of the best apps are properly cross-platform, but even
then it's a lot harder to find precompiled versions for PPC.)
Breaking down choice 3 is even more telling; the also-ran OSes for the PPC
architechture leave something to be desired. (Unless you consider BSD to
be an also-ran...) The "also-ran" choices for x86 are things like Solaris.
It is true that the Apple hardware has some advantages, and the fact that
Apple is careful only to put together a limited number of highly-tested
combinations is one of the largest of those advantages.
(Another advantage is the ability to run Mac OS X, though that's only an
advantage if you want to do that. (I thought about it but rejected it for
the same reason I rejected the BeOS (another of the x86 also-rans, though
it used to run on PPC at one time in the days before G3): these OSes do not
allow the user to set global color preferences, and I absolutely NEED that
because Evil Blinding White Backgrounds are the bane of my existence. Yes,
I know most people don't care. I care. I have to care, because my eyes
can't take eight straight hours of that many photons. (My eyes are more
sensitive to light than average; I also have to squint when I go outside
in the daytime, which I prefer not to do. I see very well at night...)))
So, anyway, back to topic... yes, PPC has advantages. However, the flip
side is that the PPC architecture does limit your choices. It can be said
that they are decent choices, but the limits are there. Trying to deny the
limits or handwaive them away by summarizing all the world's operating
systems into three categories doesn't change that.
> I'm sure somebody out there must know what they are called?
:-)
Ask a C programmer. It's mostly C (and maybe C++) programmers who spend time
thinking about indentation styles. People who use lisp-based languages just
let their editors' parenthesis-matching and automatic-indentation stuff sort
it out, and Perl programmers worry more about semantics than syntax, or just
put the whole block on one line if it's small. Python enforces its own brand
of indentation at the language level, so its programmers can't really get
into arguements about which option is visually better; they do what works.
Most other languages are only really used by a relatively small group of
people, so they don't get into the debates as heavily. That leaves Java,
but I don't really know how Java programmers view indentation, since I haven't
had much contact with Java people.
There *are* names for the different indentation styles, mostly taken from
the most famous person or group or book that advocates them, such as Gnu,
K&R, or whoever. But not being a C programmer I don't know which are which.
Truth be told, I have a hard time remembering which is which between big
endian and little endian as well; most of the data I work with is structured
as a flat list or string of single-byte characters, and the languages I use
are sufficiently "into" portability that they don't expose such details as
in-memory byte-storage order to the programmer directly. The only time I've
ever really had to do with it is when working with the occasional binary file
format, but mostly I prefer to let someone else write a module for the format
and then I just grab the module off of CPAN and use it
> You forgot
:-)
No, I didn't forget per se. I chose not to mention that one because I was
unsure of what terminology to use to concisely mention it without going into
the details of the two positions. IOW, I didn't know what simple word to
put on each side of the "vs", so I just skipped it. But yes, that's the
other classic one. Of late, Perl vs Foo is becomming somewhat popular as
well, but Foo varies so widely (everything from C to PHP) that I left that
one out also.
There is one that I did forget, and should have included: OOP vs any
other programming paradigm (procedural/imperative and functional are the
most popular other choices). Though being a Perl geek I of course skirt
around that one by advocating a multiparadigmatic approach. ("Yeah, see,
this bit of code here greps the list of objects returned by somefunc for
ones that return a true result for somemethod and does a map transform on
the resulting list, producing a list of hasrefs of closures that it assigns
to this lexically-scoped array. Each hashref of closures holds one of the
objects in common between several subs, which will use the object to
maintain state through subsequent calls, until the whole thing passes
out of scope at the end of the block." There you've got OO, functional,
and procedural programming all rolled together in one big happy family
The Win32 build uses native Win32 widgets, but they don't say what widget sets
it uses on other platforms, and all the screenshots are Windows.
The very best keyboards are made by Avant. These are the ones that not only
have full tactile feedback but also are fully remappable and provide full
programmable macros. The remapping and macro programming can be done at the
hardware level as long as you don't need to change any of the three keys that
control the remapping (e.g., right Ctrl, the up arrow, or I forget the third
one), or there's a Win32-based utility that you can use otherwise, which is
what I do since I wanted to remap both the up arrow and right Ctrl. (Yeah,
I'm using a completely custom layout.) With a keyboard this good, you almost
don't need a mouse, except for graphics editing.
> Without making this into a religious war, can someone make the argument
/home).)
> of why case-sensitivity in a language is 'a good thing'?
If you look up "holy war" online and skip over anything having to do with
real-world non-computer-geek religions, you'll find the following classic
examples of holy war materiel: Emacs vs vi, big-endian vs little-endian,
*nix vs non-*nix, CISC vs RISC, and case-sensitive vs case-insensitive.
In short, it's highly a matter of taste. Some people even like to have
case-sensitivity in their filesystems. (Personally, I dislike that and
think that should be optionally possible to turn it off in certain
directory trees (particularly,
Personally, I don't mind case-sensitivity in a language, generally. Perl
is very much case-sensitive, as is elisp, and neither has ever troubled me.
The only time case-sensitivity in a language has really bothered me is in
Inform -- but that was because of the incompatible _changes_ in the case
sensitivity from Inform5 to Inform6, which caused a lot of my code to break.
Now, that said, it is also possible for a language which is case-sensitive
to go far wrong in its use of case by being inconsistent in a way that will
leave you unsure which case is correct sometimes. For example, if a lot of
the ready-made modules/libraries/whatever that you use are not consistent
with one another in their use of case, that would be very bad. In elisp and
Perl, I have not generally found that to be the case. I can't speak for
Java; my attempts to learn Java have largely ended with "Ew, it's like C++".
> The only conceivable justification would be, "Well, Photoshop does it
And, come to think of it, Photoshop *doesn't* -- at least, Photoshop 6.5
for the Mac doesn't. It treats each image, toolbox, dialog box, or whatever
as a separate toplevel window, just like Gimp does.
>Why don't they use a master window to contain all the other child Gimp windows?
Ack! That would be *horrible*. You'd be forced to maximize that big parent
window, in order to have enough space to spread out all your various Gimp
(sub)windows, but then it would block out everything behind; you could not,
for example, leave a gnome-terminal window showing through behind below your
image, so that you'd notice when your download/compile/whatever completed.
Please, don't force us into an opaque rectangle. There's no reason for such
a heinous restriction. The only conceivable justification would be, "Well,
Photoshop does it, so Gimp doesn't suck any worse than Photoshop". But even
if it was in good company, it would still suck.
> MSN, ESPN, Lycos and iVillage
In other words, websites that are already so loaded with multimedia content
that they're utterly unusable on a residential connection. Full-motion
video advertisements will only reinforce what we already know about these
sites: they are intended mainly to be viewed by people sitting on a T1 or
better connection at work.
Normal websites that calculate their page load times based on a 56K dialup or
even cable modem will obviously know better than to adopt this sort of thing.
Oh, I also store all of my email in a big fat directory tree, with *no*
compression (not even lossless compression), just to make it easier to rgrep.
The waste! Clearly I'm insane. Pay no attention at all to anything I say;
I'm probably just a shill working for a hard drive manufacturer.
> Try either 384 average kbps VBR mp3 (if you have portable devices)
> or 256 avg kbps VBR ogg. You *will* be amazed.
Or, I could just use WAV. The files are larger, but it's worth it for
three reasons:
1. They sound better. Perfect, even. Full CD quality, all the
time, without exception, no artifacts *ever*.
2. Drive space is $cheap.
3. They sound better.
But then, I'm the kind of guy who also, being a stickler for quality
irrespective of the extra $30 I might potentially have to spend on a slightly
larger hard drive every two or three years as a result, careless spendthrift
oaf of wanton indulgence that I am, stores all his images in PNG or even
(gasp) XCF format (for preserving layers, to make future editing easier).
So, obviously, you should ignore my opinions on lossy compression, as I'm
clearly just being senseless and excessive beyond the bounds of all reason
regarding the quality of my media files. I probably don't even tape music
off the radio, citing "static" or somesuch inane balderdash as my reason.
> fork() does not just create a child process. It creates a child process
> running the same program
Yes, obviously, the same program with the same state (initially; after the
fork the two diverge). I use fork() on Windows all the time. Admittedly,
I'm using Perl, not C/C++/VB, but are you telling me that ActiveState made
up fork for Win32 out of whole cloth? That seems odd, since perl does not
support fork on other platforms that don't have it (e.g., DOS). Further,
if you compile the vanilla Perl sources on Windows (using e.g. cygwin) it
supports fork just fine -- and, for that matter, threads.
Moreover, many applications not written in Perl appear to use fork on
Windows, though (not being a C programmer) I have not examined how they
do so. Apache, for example, appears to fork off multiple copies of itself,
just as it does on POSIX systems.
If the Windows API doesn't have fork() as such, *something* must provide
the same or equivalent functionality.
Umm, *where* did this idea come from? Yeah, Windows has some shortcomings,
but no fork? Where did this idea come from? Of course it has fork -- it's
had fork since Windows 95 came out (sooner if you count early versions of NT).
Okay, the 3.x series didn't have fork, but 3.x was just a mostly-useless
graphical shell.
> Why do so many people find the word "suite" to be synonymous with
> "monolithic app"?
Because most of the components of the suite are not available as *birds yet.
Navigator (if the browser itself is all you use) can be replaced with Firebird,
and the truly adventurous can replace Messenger with Thunderbird, and Composer
(which to me was never useful anyway) is I *think* available as a Thunderbird
extension, but that's about it. Sunbird last I checked is so far a non-starter,
and then there are the other components... where are they in the *bird series?
They remain... unimplemented. Okay, I think DOM inspector is available as a
Firebird extension, but then you can only use it to inspect Firebird; you
cannot, for example, use it to look at the Thunderbird XUL (for theming
purposes). So, basically, the *birds are still lacking that.
It's not the monolithicity of SeaMonkey that keeps people using it; it's the
fact that it's essentially *complete* (well, except for Messenger, which is
still missing quite a number of critical features, but that's another thread).
The *birds are still very alpha; there are whole *categories* of features
that nobody has even *looked* at implementing in them yet.
If all you want is the browser, Firebird can be used as a replacement for
Navigator (though to get the full functionality of Navigator you have to
install about twenty extensions and a small handful of minor things are
still not up to snuff), but if you use the SeaMonkey whole suite, there is
no non-monolithic replacement available yet from Mozilla.org.
That is why people continue to use SeaMonkey.
Back when Decent II was still current and we were waiting for D3 to come out,
along with the trailers and things, Parallax (or was it Interplay?) released
some MP3s of some music for the game. That was my first introduction to the
MP3 format; prior to that all the music I'd downloaded was either MIDI or WAV.
I still *hugely* prefer MIDI for instrumental music; assuming your sound card
is decent (not some onboard junk with no advanced wavetable), it sounds *much*
more like real music. With a *good* sound card, it sounds like it was played
by an orchestra and recorded, i.e., CD quality. MP3 on the other hand sounds
approximately like JPEG looks -- ugly.
For vocal music, I use WAV format pretty much exclusively. (This makes
downloading fairly impractical, but I get the CDs and rip the songs I want
and store them on a hard drive. It's amazing how much music you can fit
on a 30GB filesystem in full-quality WAV format if you only rip the songs
you actually like.)
Recent AIX code? Yeah, I can think of several reasons why SCO would want
to look at recent AIX code, and none of them have jack squat to do with
Linux. If they could actually get that out of this, it might almost make
the whole lawsuit thing worthwhile from their perspective (ethics aside).
I can't see as how they're going to get it without some kind of due cause,
though.
> > so what, exactly, is unethical about moving jobs overseas?
>
> Taking peoples livelyhood away
Moving a job overseas doesn't destroy a job; it moves it overseas. The same
number of people are employed as before; it's just different people. I know
it's a nice emotional plea to wine about people being out of work, but it is
equally true that people now have work who didn't have it before.
Further, and more importantly, the negative ecconomic impact on the country
the jobs were moved from (in this case the US) is extremely short-term (as
in, definitely less than five years and often a matter of three months or
less). Every job moved from the US to Ubbledubgong (a random third-world
country -- Mexico, India, Brasil, Cameroun, wherever) pushes US currency
into Ubbledubgong; this money does not vanish into thin air; it goes into
Ubbledubgong. There it is spent and at some point it makes its way back to
the US. The details are complicated (exchange rates are not as simple as
you would like to think), but the long and short of it is that the people
in Ubbledubgong purchase widgets (i.e., goods and/or services) that are
imported from the US (which creates jobs) or from some other country that
imports from the US (which, indirectly, amounts to the same thing).
What is more, the jobs that are moved overseas have a tendency on average to
be less desirable than the jobs that are created as a result of the trade.
This is not always the case for every job, but the averages work out. Trade
is a *good* thing for the ecconomy.
> so that you can live your own pockets with a few more millions
It's the CEO's job to make decisions that are sound for the company. In many
cases, moving jobs overseas is a sound decision. (In some cases not; moving
phone support overseas is often a remarkably poor decision, because it makes
frustrated customers, which is bad. I haven't looked at the HP decision in
particular.) Doing your job is, last I checked, a good way to make money.
If there were some ethical reason not to move the jobs overseas, then that
would be different; doing evil to line your pockets is, of course, evil.
Doing perfectly ethical good business to line your pockets, however, is
still perfectly ethical good business.
Now, there are unethical things that can be done in the course of making what
would otherwise be an ethical business move. Things like swearing up and down
to your employees that the company is doing fine and there are no downsizings
planned, when in fact you know very well you're about to axe a number of them,
is unethical because it's dishonest.
> pay some overseas people a wage that will never allow them to buy all
> these products your company is selling
It will raise their standard of living. Perhaps not enough to let them all
buy HP computers tomorrow, no, but frankly that's not what they really need
at the moment. Sure, it would be nice, but if you raise their standard of
living to where they can get, say, indoor plumbing, that's actually much
more immediately useful. Further, it stimulates the local eccomony there
and indirectly creates additional jobs for additional people.
> Why do people think this form of globalization is going to better the world.
No, it won't better the world. (That would require changing human nature.)
It will, however, better the ecconomy.
> People like her only care about bettering their own bank accounts.
I suspect that's mostly true -- and if it would be bad for the ecconomy, a
lot of CEOs would probably do it anyway, if it meant more money for them
personally. But in fact it's not bad for the ecconomy, not in the medium
and long term.
> And look what happens when you buy all your hardware from random sources
:-)
> and piece it all together... you get so many machines that lock up for no
> reason at all.
That's if you get the cheapo junk. You can buy quality commodity PC components
for a little more (still less than Apple hardware), or buy from a vendor such
as Dell, which takes the individual component decisions out of your hands.
This is all well and good, and you still have a choice what OS to run, too
> Conductive is your friend. You want static dissipation.
You don't want to short things out. Having a nice ground handy would be good,
but you don't want the whole bench to conduct current, especially the surface.
> Or M$ just uses the next service pack/patch to revise the EULA.
That would still take 2-3 months. And that's *after* captive-ntfs gets on the
Microsoft radar, which is six months *after* it's widely deployed, which is
six months from today. So we're still talking fifteen months -- enough time,
in theory, for someone to code the desired capabilities into the native NTFS
driver. (One of the big distros should probably pay someone to do this, though,
as it hasn't happened up till now. Probably because most of the serious kernel
hackers haven't used Windows since roughly 3.11 for Workgroups, as they have
a tendency to live deep in server/developer space, where most of the "users"
are programmers of some kind and even the managers have heard of Unix.)
> Such a restriction would also block current, commerical rescue-offerings,
> at least, UNLESS they licensed the driver themselves, somehow.
They probably already do, but if not it would be trivial for Microsoft to
arrange agreements with each of them.
> Also NTFS is preferable over FAT because FAT has no concept of file ownership.
This would only matter for situations with multiple users who don't trust one
another, which basically either means servers (where if you're using Windows
I feel sorry for you) or some kind of unusual desktop situation. I've seen
many, many Windows desktops, but they were all either used by one person or
were used by multiple people who all shared the same user account. I've not
yet seen anyone actually using the Windows multiuser stuff in real life. I'm
sure it happens, but it is not the typical situation.
And quite obviously the multiuser stuff is unimportant in a multiboot scenerio,
since that's invariably a computer used by one person, or else different people
use different OSes (e.g., the spouse uses Windows). Also, the other OS can
mount the NTFS partition (albeit perhaps in read-only mode, at least if you
don't want to screw things up -- until now), so security is already gone.
Frankly, even in a single-boot scenerio, a bootable removable drive pretty
much removes all security these days, what with Knoppix and tomsrootboot
and all those sorts of things. ISTR there's a floppy disk image out there
that's made for changing the passwords in the WindowsXP registry. If you
need real security, you frankly have to keep the user physically away from
the computer, or use an encrypted filesystem that requires key entry on boot.
> Its almost like running windows 98.
I believe that was the primary #1 selling point of Windows XP. If it *weren't*
almost like using Win98, it would have received about the same user response
as Windows 2000, i.e., "make it go away". After Win2000 flopped in the market
place (not flopped compared to NT4, but flopped in terms of being received by
consumers as the next version after Win98), Microsoft backpedaled their
no-more-versions-of-Win9x position, did some market research to find out
what differences regular people saw between the two OSes, released WinMe
(to tide over the OEMs who were carping about their position trying to sell
either Win2000, which people wouldn't buy, or Win98SE, which was officially
obsolete), and poured the results of that market research into WinXP. So
yeah, it's almost like Windows 98. If you squint. At the time, security was
not a major concern for most users. (It has in the time since become a more
significant concern. Yes, end users can be slow catching on to things.)
> No crashes, no dependancy problems, just the hassle of compiling everything
> before it'll work.
I've had some problems with it. Sometimes you can run into a situation where
a new version of some package conflicts with the old version in some way that
portage can't work out by itself, and so you have to manually unmerge the old
version first. (You don't find this out until your emerge fails, and then you
have to track down the issue.) Specifically, I ran into this problem twice
with certain important Perl modules. Since they're a dependency for virtually
everything, skipping over it is not an option.
I also had a really weird problem that may be fairly unusual, because I did
not find any useful information on the web about it and as yet have not
resolved it. I can't emerge coreutils, because during the compile it does
*something* it's not supposed to do and portage kills it off and issues a
sandbox error. This rather puts a damper on upgrading much of anything
else, let me tell you. I'm typing this right now on Mandrake (which is
installed on the other disk), because I don't want to deal with that issue
at the moment.
Oh, and this is possibly a coincidence, but I've had two hard drives die
while running Gentoo. I've run Mandrake for much longer (since 7.1) and
only had the same number of drives (2) go bad -- and they went much more
gradually, so that I was able to get my stuff off without much trouble.
Again, this is very likely a coincidence, but it makes it hard for me to
get as excited about Gentoo in practice as I'd like to be in theory.
> Novell bought System V Unix in 1994, at which time BSD was basically
> obsolete and commercially worthless.
By most accounts, the general consensus is that in 1994 the AT&T Unix code
base was also obsolete and commercially worthless.
> That's 10 years of continuous R&D not accounted for in your invented history.
That history is not invented. It's simplified, yes, but the details that
are left out aren't really germaine. The claims SCO is making require the
sort of exclusive rights that are belied by _this part_ of the history.
Some other parts of the history are available on the web for the curious.
> I think it's important to note that the issue with the current Linux
> kernel's NTFS support is its capabilities, not its quality.
Capabilities aren't part of quality? Do you want a car that can't make right
turns? What about a car that can't make turns at all -- it would still be
fine for driving straight ahead, and you could even put it in reverse...
> It can only write to a file without increasing its size - and no creating
> or deleting files or directories.
This limits its usefulness in important ways. Not that it is if no value,
but I would really like to think that in a few months someone will figure
out how to (safely) lift these restrictions.