Or it could simply be people who have publically stated they automatically mod down any posts that have a subject of "MOD PARENT
UP".
Heh - I don't have any problem with "MOD PARENT UP". The two categories of posts I usually mod down, other than outright trolls, are (a) "I know I'll get modded down for this, but..." and (b) "whine whine whine look, my post got modded down and I'm so brilliant that I couldn't possibly have deserved it, and I'm also so sensitive that I'm taking it as a personal insult about my penis size, whine whine whine".
Let the flames begin. Sure, I still use 80-90% of my points to mod up. But those two categories are really annoying. It's why modslapping was invented.
Apache got its name because of all the patches and fixes that have been made to the original code (from MIT I think), many to solve
security problems.
Not MIT, UIUC. And what makes you think the original "patches" were security-related? Back then, the code base was still immature, and needed development in a lot of areas, not just security auditing.
And, while the original NCSA code did have a few well-publicised security holes, Apache forked back in 1994, or was it late 1993? Since then it's had major releases 1.0, 1.1, 1.2, 1.3 and now the 2.0 series. Eight or ten years of code evolution is quite enough to divorce a code base from its parent, so whatever security problems modern releases of Apache may or may not have, I doubt any of them date back to any actual NCSA code.
What if Segway came back with ones
with a max speed of 5 mph. Would that be alright?
Sure, but imagine the modchips. (: But yeah, given a 5 mph speed limit, preferably with a hardware governor (user-settable via a dial, perhaps) or at least a speedometer, I'd say put 'em on the sidewalk. Just like Rascal scooters.
I ask you then, should running also be prohibited? It is certainly faster than walking.
No. A runner is 70 lbs lighter than a guy on a Segway. Probably considerably lighter than that, in fact, demographically speaking. Also the runner is slower - nobody can sustain 12 mph for long, except very experienced runners who certain know how to keep out of people's way and should be able to jump over small children if worst came to worst. (Try that on a Segway.) I suspect most people sustain 8 mph or less, over any distance. (I bet most people can't sustain 12 mph for even one city block.)
Average male runner: say 185 lbs going 8 mph. Average male Segway rider, say 200+70 lbs at 10 mph. If momentum approximates mv, that's a factor of 1.8, which makes quite a difference. And, oh, yeah - reaction time window is inversely proportional to speed, as well, which is another way of saying that what we really care about is kinetic energy. Which factor is 2.3.
What other people do,
if it doesn't harm you, is none of your business.
[emphasis mine]
If people really cared about public health risk (from Segways) from a
medical-cost point of view, they'd advocate increased premiums for people in risk categories, they wouldn't try to make those
activities illegal.
Substitute "motorcycle" for "Segway" and tell me why your logic still makes sense.
Hint: I'm not worried about a Segway owner hurting himself. I'm worried about him hurting me. Ride your Segway all you want on your private tennis court, where you can't hurt anyone but yourself. Or on a street, along with me on my bicycle, where the worst you can do is dent someone's car door and owe 'em a couple hundred bucks.
Sure, people say the Segway is foolproof, so maneuverable that nobody will possibly barrel into me at 12 mph. Bollocks. That's a lot of momentum for someone who isn't paying attention where he's going - and don't forget the oncoming pedestrians who also aren't paying attention to where they're going. Nor should they have to. That's their turf and they're entitled to daydream without some moron mowing them down.
I'd be willing to comprimise: speed limit 5 mph, or just walk the stupid thing like I have to do with my bike. In fact it would make sense to manufacture the Segway with a speed governor dial with a 5 mph click, to make it easy to gauge this.
Well in my line of work (automotive outsourcing) You can't even buy licenses for many of our products (unigraphics, catia) for
Alpha.
Hmm, I could have sworn Catia V4 was available for Tru64. Naturally V5 is not, but then again V5 on Unix is a mere afterthought anyway. I don't know anything about UGS. For other needs in the automotive world, I know MSC and LSTC both support Alpha for at least some products.
Oh AIX was pure fun, considering before that I was on CMS for like a month, and VMS for like 6
Oh, indeed. (: Nothing like VMS and a mainframe OS to put things in perspective. I guess even AIX 3.2 would be a relief at that point.
Come to think of it, AIX from a user perspective is just another Unix. It's only from a programmer or administrator perspective that its quirks really show. And as of v4.2 and v4.3 it has gained enough POSIX compliance that it's not such a bear to program for anymore either.
"Yahoo" does not occur naturally in the english language, whatever that really means.
wtf? "Whatever that really means" indeed. Can you give an example of a word which does occur naturally in the English language?
I can think of four categories of etymology: (1) borrowed from another language, (2) borrowed from slang, jargon or other specialised lexicon, (3) coined by an individual, or (4) lost in the mists of time. Categories (2) and (4) can probably be reduced to (1) and (3). English has a great deal of (1). Literary allusions like yahoo would be in (3). Which of the four would you consider to "occur naturally"?
Why slow down the cpu fan? Your cpu's going to make the same amount of heat whether you have a fast fan, slow fan, or no fan at all.
Well, not if the CPU has temperature sensors that trigger clock speed changes. But otherwise, you're right. Note also that the fan itself produces a certain small amount of heat, or at least air turbulence, which amounts to heat, thanks to energy conservation.
I knew I was going to get in trouble with that one - I couldn't remember for sure how you folks pronounced it. Even so, there are lots of words that aren't commonly pronounced as one would expect from their etymologies - I just can't think of any so blatant as "ki-lah-me-turr" as we say over here.
I'd prefer my 20 years in the computer industry to say more about me than how I pronounce the name of an obscure operating system.
I never meant to impugn your experience in the computer industry, just your experience with an obscure operating system. (:
and oh btw, the reason tunelling over HTTP works is because many desktops only have Internet access via an HTTP proxy rather than
every desk in the company being NATed to the internet.
Hm, that's actually not a bad reason. Not that NATing is much harder than HTTP proxying, IMHO, but hey, it's all about choices.
Having listened to the audio file of Linus Torvalds saying Linux, I have to disagree. He calls it Leenooks, not Lihnux.
Ah, but that audio file was made back in '92 or so. Since then Linus moved to California and lost much/most of his accent. "Leee-noos" has become "Lie-nus" and "Lee-noox" has become "Linnux".
However, as a native speaker of American English, I don't feel the need to pronounce Linux the same way as a native speaker of Finnish.
Swedish, actually. (: But look at it this way, as a native speaker of American English: suppose you're talking about a baseball player with a.320 batting average. You say this as "zero point three two" while everyone around you says "three twenty". You can argue all you want that "zero point three two" is more correct and logical, but you still sound like a guy who doesn't follow baseball. (Not that there's anything wrong with that.)
Of course it is. It's also, as I said, a very efficient way to telegraph the fact that you're out of touch.
I call him Lienus, I call his program Lienux
I don't say Linnus, so I don't say Linnux
I suppose you're one of those who pronounces km as "kill-o-meter" too, eh? I know this is hard to grasp, but etymology does not always dictate the preferred pronunciation. In this case we're talking about a registered trademark, and the trademark holder calls it "Linnux" - despite also calling himself "Lienus". By remarkable coincidence, this convention is shared by everyone I've met whose knowledge and skill of Linux I could respect.
But this is silly. Pronounce it any way you want. Realise, though, that whether you like it or not, your accent conveys information about you. Hard fact o' life. And to me, your stance labels you as either non-technical or a Linux newbie. (Not that there's anything wrong with that.)
Hello Nitpick, PERL still is and always has been an abbreviation of "Practical Extraction and Reporting Language" and as far as I
have learned, abbreviations are spelled with all caps.
Little credit here? Duh, I know what Perl (once known as "Pearl", by the way) stood for. But no, abbreviations are not always spelled with all caps, and they are not always treated nunc et semper as abbreviations. In this particular case, nobody in authority - from the legions of Perl hackers out there to Larry Wall himself - refers to it as PERL any more. I believe that practice died out well before the release of Perl 5, say '93 or '94. Indeed, referring to it in all caps, like prounouncing Linux Lienux, is a very efficient way to telegraph the fact that you are out of touch.
What, praytell, do you propose to replace it with?
Something else.
As I thought.
Like I stated before, who here actually USES the client-server capabilities of X? Apart from a small bunch of
people, I presume almost none.
I do, as do many people I know, but that's not really the point. The point is, you have not yet proven or demonstrated that X is bloated to begin with - or, if it is, that its bloat is even measurable on current desktop setups - or, even if it is, that the client/server design is to blame.
It's old, it's archaic and it's in need of something sleek, small and fast to follow it up.
Nice set of assertions you got there, backed up with some lovely handwaving.
My counter-assertion is that while X is old (and "archaic", whatever that means here), it was designed so well to begin with that it has aged gracefully and is not at all in need of replacement. I further assert that your miserably slow experience with Linux on your Athlon has little or nothing to do with X per se and should be blamed on something else.
designing an graphics sustem would be quite impossible for me atm.
Then, pardon my bluntness, but you're not really qualified to comment on whether an existing graphics system is even good or bad, much less whether its design and implementation are so horrible as to warrant a complete redesign. I happen to think that X's shortcomings (yes, it has some) are for the most part fairly easy to fix or work around, thanks to its excellent original design.
And hey, aren't you the one who thinks all abbreviations should be in caps? What's with "atm"? (:
I'm pretty sure there are people
working on alternatives atm though.
Yes. The best-known would be Fresco, which (though I have no first-hand knowledge of this) looks to be a lot more feature-rich / bloated than X. (I believe Fresco uses CORBA throughout, for one thing. If you thought network transparency was an unnecessary layer of abstraction, aka "bloat", check out CORBA. And yes, it's spelled in all-caps.)
I often see that so
called "desktop distros" include stuff such as PERL, Apache, MySQL, PHP, ProFTPd... What the hell would one random computer user do
with these programs?
Uhhhh. What is "PERL"? Closest match I found is "Perl", a scripting language heavily used in system maintenance procedures. Kind of important if you want to, say, install packages and stuff. (Actually I don't know about RH8, which is what we're presumably talking about here, but a lot of Debian packages require a minimal Perl install to support the packaging scripts.)
Oh - for future reference, saying "PERL" rather than "Perl" is a lot more damaging to your credibility than any mere spelling mistake I can think of. (:
Although the one thing that could improve all of linux is the removal of X. God, it is SLOW, Windows 98 booted faster on my p300
with 64mb and this is an AMD at 1667mhz with 1024mb!
What, praytell, do you propose to replace it with?
While I haven't seen the source code myself (yet), I heard it is about as
bloated and obscure as it is.
Then you should listen less to people who don't know what they're talking about. (Yes, that means reading less Slashdot.) On my box X takes about 3 seconds to start. This is so dwarfed by the startup time for GNOME, it's not even funny. If I logged in and out often enough for it to matter (hmmm, looks like my last login was 1 Dec), I think I'd switch back to vanilla fvwm2.
Now I know that it is fashionable in certain circles to assume that since X is 15 years old and has "unnecessary" features like network transparency and is still binary compatible after all these years, that it must be the cause of all of life's bloat problems. Sorry, but it just ain't so. Not that X couldn't be improved - it's being improved all the time. But it's not the pig you think it is.
Why can't Liunx kernel developers come up with an API for binary kernel modules and keep it stable at least between minor kernel
releases so that users could use third party kernel modules withfout having to recompile them for each kernel upgrade?
They could - but it's not worth it. This may sound heartless, but there are tradeoffs involved. To fix Bug Foo, you can either (a) apply a band-aid fix that maintains full backward compatibility, but looks ugly, sacrifices a tiny amount of performance, and possibly hides other bugs... or (b) rethink the design and update the various bits in the kernel that use the old design - thereby breaking any external module that happens to rely on the same old design. (Scenario exaggerated a bit.) So which do you do?
If you're a Windows kernel programmer, you almost always do (a). There is a large customer base that rely on the ability to use third-party drivers seamlessly and cannot be depended on to even have a C compiler available (since you didn't bundle one with your OS!) and backward compatibility is paramount.
If you're working on AIX or Solaris, you usually to (a), but probably not always. Once again, customers are depending on this, and the culture is that black-box kernel modules are OK, because the kernel itself is a black box so who cares anyway. Device drivers aren't a biggie because the hardware is vertically integrated, typically - but Oracle for example ships a couple of AIX kernel modules that provide facilities for application-specific optimisations.
On Linux, it depends on the development cycle. Between stable series, they almost always go with (b), because great importance is attached to clean code, clean design, and minimal baggage. Within a stable series, sometimes option (a) is better in that it is often a less invasive change with less short-term potential for causing other bugs. However, unlike AIX, Solaris or Windows, Linux has a userbase accustomed to having a C compiler installed, and accustomed to having kernel source available. Thus, since we all treat the kernel as the open book it is, we are much less tolerant of other core components being binary-only than are users of other platforms. Besides, the driver support that ships directly with the Linux kernel is second only to Microsoft's - the commercial Unix vendors don't even come close - and in many cases Linux ships with a driver for something Windows doesn't. (Microsoft can get away with this because for anything they don't directly support, they can count on the hardware vendor providing a driver.)
In any case, since almost all of the core of a typical Linux installation is free software, there is little need to be overly concerned with the needs of those hardware and software vendors unwilling to play the game. In other words, the fact that source is almost all freely available gives the developers the freedom to fix things correctly rather than concentrating on minimal ABI disruption.
Contrary to popular Slashdot opinion, this attitude quite often actually helps the Linux driver scene: vendors who try providing closed-source drivers for their hardware often see that this is a losing and pointless game, and open up their specs and/or their in-house drivers. For each hardware vendor you name that has been driven away from Linux by the hassle of binary module support, I can name several that either provide and support open source drivers on their own dime, or at least give out spec sheets and answer questions in a semi-cooperative manner.
It is a curious fact of life that many companies, given the choice, will keep their driver (and other) source locked away as tightly as possible... but if you hold a hard line and say "open source or else suffer various support headaches with closed source" they figure out a way to make it happen. Even the reviled NVidia did this once upon a time, back in '96 or so - after much wrangling they donated a Riva TNT driver to XFree86. (That was a fiasco at first. They initially released obfuscated source code - that is, partially preprocessed code that was intentionally difficult to read in certain places - but later rectified this by posting their "real" source. Speculation at the time was that the obfuscation was done to hide evidence: a major competitor (3Dfx? I can't remember now) had sued them for theft of IP and the suit was still in progress.)
Is this a hack? It sounds like a workaround, but maybe it's just creative use of existing tools.
Creative use of existing tools.
It sounds like you're a little confused about what preempt mode is and isn't. So here goes - HTH. It isn't the ability to preempt a running job in favor of scheduling a new job. That's called "preemptive multitasking", and Linux has had it since Day 1. It also isn't multiprocessing - running multiple jobs simultaneously via multiple CPUs. Linux has had that since, oh, 1995, I think (kernel 2.0).
Preemption, in this context, means interrupting one job to schedule another while the first job is busy running something within the kernel itself. You see, most processes ("jobs") run part of the time in user space where they are executing their own instruction streams, and part of the time in kernel space where the kernel is working on their behalf - reading disk files, sending messages to other processes, etc. Now, while the process is in user space, it can be preempted at any time, whenever the scheduler decides it has used its fair share of CPU and it's someone else's turn. (This is preemptive multitasking. MS-DOS and MacOS 9 didn't have it - on those systems, a single process can run as long as it wants, and is only stopped when it voluntarily gives up the CPU.)
Kernel space is another matter. If you ask the kernel to, say, read a disk file, it will usually put your process to sleep until the file comes back from the disk, and will schedule other processes in the meantime - but for various other work the kernel does on your behalf, it does not normally interrupt itself periodically to make sure you still have time left on the clock, as it were. Thus, if a process makes heavy use of kernel facilities, there may be (relatively) long periods of time where the process should "in fairness" relinquish the CPU but it won't because it's "in kernel mode".
The reason for this rule - the reason the kernel scheduler never jumps in and preempts other kernel code - is that by doing so it would be quite easy to corrupt the state of kernel variables. This one is hard to explain if you haven't learned about locking primitives in programming courses, and unnecessary to explain if you have. Suffice it to say that arbitrarily grabbing the CPU and switching to another task is prone to basically the same failure modes as having multiple CPUs running different tasks simulatneously - i.e. SMP mode.
So, what's the problem with not preempting kernel code? Say you have another process doing highly interactive things, like a game, or an MP3 player, or even the X server tracking your mouse movements. Ideally you want it to react to new events (keyboard and mouse input, for example) as quickly as possible, so your system feels "snappy". Which is a problem if another process happens to be taking its own sweet time in kernel mode while you impatiently wiggle your mouse for half a second, wondering if the system is frozen.
Note that if you have multiple CPUs and use an SMP kernel, this "latency problem" is not nearly so bad. Since any one of your multiple CPUs may be available to service your all-important "main snappy application", the chance of seeing unacceptible delays is greatly reduced.
With me so far?
So here's what the preempt patch does. It changes the above-mentioned rule so that the scheduler is allowed to interrupt other kernel code without explicit permission, just as it does with user-mode code. If the kernel happens to be in a critical section (another technical term hard to explain to those who don't already know it), it should already have taken a lock in the SMP-mode case, so preempt-mode just redefines the lock/unlock operation as "disable preempt mode" / "reenable preempt mode". Thus, the kernel can sit and do all the work it wants to, and as long as it isn't holding any locks, the scheduler can pause it and run something more important (like letting your MP3 player trickle a bit more music into your sound card so the sound card won't run out, at which time you'd hear a skip).
I guess the terminology is really up to the reader, but in my opinion, while this is a "hack" in the sense of "clever program snippet", I think "creative use of existing facilities" is a good description. The key here is the realisation that the problem of how to preempt the kernel in arbitrary places is very similar to the problem of letting multiple copies of the kernel run at once on different CPUs, and since the latter is basically a solved problem (it was, in fact, probably the biggest difference between the 2.0 and 2.2 kernels), Robert Love was able to reuse this infrastructure to solve the vast majority of the problems with the former, in one fell swoop. Of course, preempt mode had other problems which had to be solved other ways, but SMP support was the major thing that paved the way.
(By the way, this wasn't Robert Love's idea originally. Linus Torvalds expressed it some time around the 2.4.0 era, but didn't feel like doing the work himself. I don't know if it was his original thought or if all this has been done before. I suspect Solaris, at least, uses a similar trick.)
Is this similar or analogous to Intel's new chip that acts like a multiprocessor?
Completely different. Intel's HyperThreading mode uses cooperative (not preemptive) multitasking implemented within the chip itself. At least that's my guess. Each virtual CPU runs until it hits whatever Intel deems a good stopping point, then changes hats and lets the other virtual CPU have a go. It works because a lot of facilities in the CPU can go underutilised because of bottlenecks elsewhere (fetching memory into L1 cache, for example), so by simulating two CPUs you can often keep these resources busier.
the whole point of my post is "I pay, I get to bitch, period."
So why, oh why, are you doing it on Slashdot? You never paid me for the privilege you speak of, and I think I speak for most if not all of us here.
You need to get the "if it's open source you don't get to complaing about it" idea right out of your head. This is no longer a
hobby dude. It's a business. That means customer service issues fucking matter.
So get on the phone with your Red Hat customer service rep already. They're paid to listen to your bellyaching. You gave them your "business" and they take their "customer service issues" seriously.
In this environment, though, you're wrong. To me, to many of us on Slashdot, Linux is still a hobby (dude). I read the 50-page changelogs for fun. I read linux-kernel for fun. I occasionally hack on Linux for fun. Who are you to say I should treat Linux as a business?
(Before you say you weren't talking to me specifically - note that my statements apply to a good many kernel hackers.)
The binary drivers
are also STILL superior to the GPL Nvidia drivers. That is a fact, I am afraid.
Wow, that's weird - here's a driver written by engineers on paid company time, with full access to spec sheets and with the hardware guys on speed-dial. And they actually work better than drivers reverse-engineered out of thin air because nobody at NVidia was willing to give them so much as a lousy PDF? Who woulda thought?
And this has to do with GPL being a poor development model how?
Just as linux is taking off, it seems the kernel developers, over philosphical nonsense, have
decided to shoot linux in the face and try to drive it back into obscurity.
Where have you been living for the past four years, that you think Linux is "just taking off"? Oh, and how exactly did the kernel developers shoot Linux in the face? I assume you're no longer talking about NVidia here, since the kernel change mentioned in the article wouldn't affect the nv binary module at all, or 99% of other modules for that matter. How is the kernel developers' motivations to be considered philosophical nonsense? (I guess this would be similar to the philosophical nonsense that might motivate book publishers to forbid Barnes & Noble to sell books with a replacement dust jacket emblazoned with "www.bn.com" across the bottom of the front cover?)
prevent people from properly using THE best video card on the market, and you kill linux's growth.
What? Is someone trying to prevent me from using the 3DLabs Wildcat 7210? Do tell - I must have missed that headline.
If you do not wish to abide by the GPL of software you modify then
you cannot distribute your software to others.
Precisely.
However, a pretty interesting point.
And one that a surprisingly small percentage of wonks involved in GPL flamw^Wdiscussions seem to understand. Sometimes I almost get the feeling that many such people actually haven't read the GPL at all, where this point is spelled out quite clearly.
you'd be interested to hear what it
has over previous versions before you think about upgrading. To non-tech people that means a clear and simple explanation of what
the changes are (not some market-droid nonsense). At the moment, tech people like us get the opportunity to learn our way into
finding these things out. Not everybody can do this.
Look, it's pretty simple.
If you can understand Robert Love, or the various what-to-expect documents floating around, go ahead and upgrade your kernel as soon as your excitement level overcomes your natural apprehension for trying out new, untested kernel releases.
If you can't, wait until your kernel vendor (UnitedLinux, etc) release an RPM for you to install. If they want you to buy the shiny new SuSE Linux 12.0, they'll put a bullet point list of new features on the box. Precisely which of these new features are due to their using a heavily patched kernel 2.6.3, and which are due to their use of gcc 3.4, kde 4.0.2, and the Ogg Theora 0.5 codec - well, who really cares? Not (the hypothetical) you.
Now the Kernel developers see fit to make Linux about `Freedom and Choice, the freedom to run whatever software i want, how ever i
want, as long as everything on the system is 100% open source. '
Where on earth did you get the ideas that either binary-only drivers or any other binary-only software have been disallowed?
Sheesh, RTFA already. Do you even know what the syscall table is? Hint, 99% or more of the modules out there don't need to touch it. (By "need" I mean it would be a reasonable approach to the problems a given module is designed to solve.)
I wonder when they will remove the ability to run non-open source applications in User-space land so that things like UT2003 wont
work anymore
Ummm, yeah, you do that. Perhaps you can spend a few sleepless nights curled up in a shivering ball on your bed wondering when the Kernel Gestapo will kick in your door, boot up your l33t XP/Mandrake dual boot and forcibly upgrade it to some unholy GNU/Palladium. Or maybe you can imagine some dark day when Linus sends you The Announcement: your kernel is vulnerable to a horrible hack, you must upgrade with this hotfix NOW, and oh by the way here's a 15-page EULA you have to click through, don't worry it's all fine print except the bit where they disable all heathen, politically incorrect software such as BitKeeper, which Linus uses for source management.
Have you ever read anything, by the way, that would indicate that even one kernel hacker would support disabling non-free software? I certainly haven't, and I like to think I keep up on these things.
Slashdot Mirror
Heh - I don't have any problem with "MOD PARENT UP". The two categories of posts I usually mod down, other than outright trolls, are (a) "I know I'll get modded down for this, but..." and (b) "whine whine whine look, my post got modded down and I'm so brilliant that I couldn't possibly have deserved it, and I'm also so sensitive that I'm taking it as a personal insult about my penis size, whine whine whine".
Let the flames begin. Sure, I still use 80-90% of my points to mod up. But those two categories are really annoying. It's why modslapping was invented.
Not MIT, UIUC. And what makes you think the original "patches" were security-related? Back then, the code base was still immature, and needed development in a lot of areas, not just security auditing.
And, while the original NCSA code did have a few well-publicised security holes, Apache forked back in 1994, or was it late 1993? Since then it's had major releases 1.0, 1.1, 1.2, 1.3 and now the 2.0 series. Eight or ten years of code evolution is quite enough to divorce a code base from its parent, so whatever security problems modern releases of Apache may or may not have, I doubt any of them date back to any actual NCSA code.
What's that? Is it anything like futility?
Agreed, 100%. Sorry for the flame. (:
Sure, but imagine the modchips. (: But yeah, given a 5 mph speed limit, preferably with a hardware governor (user-settable via a dial, perhaps) or at least a speedometer, I'd say put 'em on the sidewalk. Just like Rascal scooters.
No. A runner is 70 lbs lighter than a guy on a Segway. Probably considerably lighter than that, in fact, demographically speaking. Also the runner is slower - nobody can sustain 12 mph for long, except very experienced runners who certain know how to keep out of people's way and should be able to jump over small children if worst came to worst. (Try that on a Segway.) I suspect most people sustain 8 mph or less, over any distance. (I bet most people can't sustain 12 mph for even one city block.)
Average male runner: say 185 lbs going 8 mph. Average male Segway rider, say 200+70 lbs at 10 mph. If momentum approximates mv, that's a factor of 1.8, which makes quite a difference. And, oh, yeah - reaction time window is inversely proportional to speed, as well, which is another way of saying that what we really care about is kinetic energy. Which factor is 2.3.
[emphasis mine]
Substitute "motorcycle" for "Segway" and tell me why your logic still makes sense.
Hint: I'm not worried about a Segway owner hurting himself. I'm worried about him hurting me. Ride your Segway all you want on your private tennis court, where you can't hurt anyone but yourself. Or on a street, along with me on my bicycle, where the worst you can do is dent someone's car door and owe 'em a couple hundred bucks.
Sure, people say the Segway is foolproof, so maneuverable that nobody will possibly barrel into me at 12 mph. Bollocks. That's a lot of momentum for someone who isn't paying attention where he's going - and don't forget the oncoming pedestrians who also aren't paying attention to where they're going. Nor should they have to. That's their turf and they're entitled to daydream without some moron mowing them down.
I'd be willing to comprimise: speed limit 5 mph, or just walk the stupid thing like I have to do with my bike. In fact it would make sense to manufacture the Segway with a speed governor dial with a 5 mph click, to make it easy to gauge this.
Hmm, I could have sworn Catia V4 was available for Tru64. Naturally V5 is not, but then again V5 on Unix is a mere afterthought anyway. I don't know anything about UGS. For other needs in the automotive world, I know MSC and LSTC both support Alpha for at least some products.
Oh, indeed. (: Nothing like VMS and a mainframe OS to put things in perspective. I guess even AIX 3.2 would be a relief at that point.
Come to think of it, AIX from a user perspective is just another Unix. It's only from a programmer or administrator perspective that its quirks really show. And as of v4.2 and v4.3 it has gained enough POSIX compliance that it's not such a bear to program for anymore either.
Oh you poor boy. That was when AIX sucked hard. What an introduction to Unix.
OTOH, that's after Solaris got over its lengthy 2.0 - 2.3 too broken for words period.
wtf? "Whatever that really means" indeed. Can you give an example of a word which does occur naturally in the English language?
I can think of four categories of etymology: (1) borrowed from another language, (2) borrowed from slang, jargon or other specialised lexicon, (3) coined by an individual, or (4) lost in the mists of time. Categories (2) and (4) can probably be reduced to (1) and (3). English has a great deal of (1). Literary allusions like yahoo would be in (3). Which of the four would you consider to "occur naturally"?
"Endumbened". I'll have to remember that one. The correct term, I believe, is "demoronised - but I like yours too.
Heh. There's definitely something pompous about using a first initial and middle name. Particularly if the first initial is J. Odd.
I wonder if J in this case is short for Jabba the.
Well, not if the CPU has temperature sensors that trigger clock speed changes. But otherwise, you're right. Note also that the fan itself produces a certain small amount of heat, or at least air turbulence, which amounts to heat, thanks to energy conservation.
I knew I was going to get in trouble with that one - I couldn't remember for sure how you folks pronounced it. Even so, there are lots of words that aren't commonly pronounced as one would expect from their etymologies - I just can't think of any so blatant as "ki-lah-me-turr" as we say over here.
I never meant to impugn your experience in the computer industry, just your experience with an obscure operating system. (:
Hm, that's actually not a bad reason. Not that NATing is much harder than HTTP proxying, IMHO, but hey, it's all about choices.
Ah, but that audio file was made back in '92 or so. Since then Linus moved to California and lost much/most of his accent. "Leee-noos" has become "Lie-nus" and "Lee-noox" has become "Linnux".
Swedish, actually. (: But look at it this way, as a native speaker of American English: suppose you're talking about a baseball player with a .320 batting average. You say this as "zero point three two" while everyone around you says "three twenty". You can argue all you want that "zero point three two" is more correct and logical, but you still sound like a guy who doesn't follow baseball. (Not that there's anything wrong with that.)
Of course it is. It's also, as I said, a very efficient way to telegraph the fact that you're out of touch.
I suppose you're one of those who pronounces km as "kill-o-meter" too, eh? I know this is hard to grasp, but etymology does not always dictate the preferred pronunciation. In this case we're talking about a registered trademark, and the trademark holder calls it "Linnux" - despite also calling himself "Lienus". By remarkable coincidence, this convention is shared by everyone I've met whose knowledge and skill of Linux I could respect.
But this is silly. Pronounce it any way you want. Realise, though, that whether you like it or not, your accent conveys information about you. Hard fact o' life. And to me, your stance labels you as either non-technical or a Linux newbie. (Not that there's anything wrong with that.)
Little credit here? Duh, I know what Perl (once known as "Pearl", by the way) stood for. But no, abbreviations are not always spelled with all caps, and they are not always treated nunc et semper as abbreviations. In this particular case, nobody in authority - from the legions of Perl hackers out there to Larry Wall himself - refers to it as PERL any more. I believe that practice died out well before the release of Perl 5, say '93 or '94. Indeed, referring to it in all caps, like prounouncing Linux Lienux, is a very efficient way to telegraph the fact that you are out of touch.
As I thought.
I do, as do many people I know, but that's not really the point. The point is, you have not yet proven or demonstrated that X is bloated to begin with - or, if it is, that its bloat is even measurable on current desktop setups - or, even if it is, that the client/server design is to blame.
Nice set of assertions you got there, backed up with some lovely handwaving.
My counter-assertion is that while X is old (and "archaic", whatever that means here), it was designed so well to begin with that it has aged gracefully and is not at all in need of replacement. I further assert that your miserably slow experience with Linux on your Athlon has little or nothing to do with X per se and should be blamed on something else.
Then, pardon my bluntness, but you're not really qualified to comment on whether an existing graphics system is even good or bad, much less whether its design and implementation are so horrible as to warrant a complete redesign. I happen to think that X's shortcomings (yes, it has some) are for the most part fairly easy to fix or work around, thanks to its excellent original design.
And hey, aren't you the one who thinks all abbreviations should be in caps? What's with "atm"? (:
Yes. The best-known would be Fresco, which (though I have no first-hand knowledge of this) looks to be a lot more feature-rich / bloated than X. (I believe Fresco uses CORBA throughout, for one thing. If you thought network transparency was an unnecessary layer of abstraction, aka "bloat", check out CORBA. And yes, it's spelled in all-caps.)
Uhhhh. What is "PERL"? Closest match I found is "Perl", a scripting language heavily used in system maintenance procedures. Kind of important if you want to, say, install packages and stuff. (Actually I don't know about RH8, which is what we're presumably talking about here, but a lot of Debian packages require a minimal Perl install to support the packaging scripts.)
Oh - for future reference, saying "PERL" rather than "Perl" is a lot more damaging to your credibility than any mere spelling mistake I can think of. (:
What, praytell, do you propose to replace it with?
Then you should listen less to people who don't know what they're talking about. (Yes, that means reading less Slashdot.) On my box X takes about 3 seconds to start. This is so dwarfed by the startup time for GNOME, it's not even funny. If I logged in and out often enough for it to matter (hmmm, looks like my last login was 1 Dec), I think I'd switch back to vanilla fvwm2.
Now I know that it is fashionable in certain circles to assume that since X is 15 years old and has "unnecessary" features like network transparency and is still binary compatible after all these years, that it must be the cause of all of life's bloat problems. Sorry, but it just ain't so. Not that X couldn't be improved - it's being improved all the time. But it's not the pig you think it is.
They could - but it's not worth it. This may sound heartless, but there are tradeoffs involved. To fix Bug Foo, you can either (a) apply a band-aid fix that maintains full backward compatibility, but looks ugly, sacrifices a tiny amount of performance, and possibly hides other bugs ... or (b) rethink the design and update the various bits in the kernel that use the old design - thereby breaking any external module that happens to rely on the same old design. (Scenario exaggerated a bit.) So which do you do?
If you're a Windows kernel programmer, you almost always do (a). There is a large customer base that rely on the ability to use third-party drivers seamlessly and cannot be depended on to even have a C compiler available (since you didn't bundle one with your OS!) and backward compatibility is paramount.
If you're working on AIX or Solaris, you usually to (a), but probably not always. Once again, customers are depending on this, and the culture is that black-box kernel modules are OK, because the kernel itself is a black box so who cares anyway. Device drivers aren't a biggie because the hardware is vertically integrated, typically - but Oracle for example ships a couple of AIX kernel modules that provide facilities for application-specific optimisations.
On Linux, it depends on the development cycle. Between stable series, they almost always go with (b), because great importance is attached to clean code, clean design, and minimal baggage. Within a stable series, sometimes option (a) is better in that it is often a less invasive change with less short-term potential for causing other bugs. However, unlike AIX, Solaris or Windows, Linux has a userbase accustomed to having a C compiler installed, and accustomed to having kernel source available. Thus, since we all treat the kernel as the open book it is, we are much less tolerant of other core components being binary-only than are users of other platforms. Besides, the driver support that ships directly with the Linux kernel is second only to Microsoft's - the commercial Unix vendors don't even come close - and in many cases Linux ships with a driver for something Windows doesn't. (Microsoft can get away with this because for anything they don't directly support, they can count on the hardware vendor providing a driver.)
In any case, since almost all of the core of a typical Linux installation is free software, there is little need to be overly concerned with the needs of those hardware and software vendors unwilling to play the game. In other words, the fact that source is almost all freely available gives the developers the freedom to fix things correctly rather than concentrating on minimal ABI disruption.
Contrary to popular Slashdot opinion, this attitude quite often actually helps the Linux driver scene: vendors who try providing closed-source drivers for their hardware often see that this is a losing and pointless game, and open up their specs and/or their in-house drivers. For each hardware vendor you name that has been driven away from Linux by the hassle of binary module support, I can name several that either provide and support open source drivers on their own dime, or at least give out spec sheets and answer questions in a semi-cooperative manner.
It is a curious fact of life that many companies, given the choice, will keep their driver (and other) source locked away as tightly as possible ... but if you hold a hard line and say "open source or else suffer various support headaches with closed source" they figure out a way to make it happen. Even the reviled NVidia did this once upon a time, back in '96 or so - after much wrangling they donated a Riva TNT driver to XFree86. (That was a fiasco at first. They initially released obfuscated source code - that is, partially preprocessed code that was intentionally difficult to read in certain places - but later rectified this by posting their "real" source. Speculation at the time was that the obfuscation was done to hide evidence: a major competitor (3Dfx? I can't remember now) had sued them for theft of IP and the suit was still in progress.)
Creative use of existing tools.
It sounds like you're a little confused about what preempt mode is and isn't. So here goes - HTH. It isn't the ability to preempt a running job in favor of scheduling a new job. That's called "preemptive multitasking", and Linux has had it since Day 1. It also isn't multiprocessing - running multiple jobs simultaneously via multiple CPUs. Linux has had that since, oh, 1995, I think (kernel 2.0).
Preemption, in this context, means interrupting one job to schedule another while the first job is busy running something within the kernel itself. You see, most processes ("jobs") run part of the time in user space where they are executing their own instruction streams, and part of the time in kernel space where the kernel is working on their behalf - reading disk files, sending messages to other processes, etc. Now, while the process is in user space, it can be preempted at any time, whenever the scheduler decides it has used its fair share of CPU and it's someone else's turn. (This is preemptive multitasking. MS-DOS and MacOS 9 didn't have it - on those systems, a single process can run as long as it wants, and is only stopped when it voluntarily gives up the CPU.)
Kernel space is another matter. If you ask the kernel to, say, read a disk file, it will usually put your process to sleep until the file comes back from the disk, and will schedule other processes in the meantime - but for various other work the kernel does on your behalf, it does not normally interrupt itself periodically to make sure you still have time left on the clock, as it were. Thus, if a process makes heavy use of kernel facilities, there may be (relatively) long periods of time where the process should "in fairness" relinquish the CPU but it won't because it's "in kernel mode".
The reason for this rule - the reason the kernel scheduler never jumps in and preempts other kernel code - is that by doing so it would be quite easy to corrupt the state of kernel variables. This one is hard to explain if you haven't learned about locking primitives in programming courses, and unnecessary to explain if you have. Suffice it to say that arbitrarily grabbing the CPU and switching to another task is prone to basically the same failure modes as having multiple CPUs running different tasks simulatneously - i.e. SMP mode.
So, what's the problem with not preempting kernel code? Say you have another process doing highly interactive things, like a game, or an MP3 player, or even the X server tracking your mouse movements. Ideally you want it to react to new events (keyboard and mouse input, for example) as quickly as possible, so your system feels "snappy". Which is a problem if another process happens to be taking its own sweet time in kernel mode while you impatiently wiggle your mouse for half a second, wondering if the system is frozen.
Note that if you have multiple CPUs and use an SMP kernel, this "latency problem" is not nearly so bad. Since any one of your multiple CPUs may be available to service your all-important "main snappy application", the chance of seeing unacceptible delays is greatly reduced.
With me so far?
So here's what the preempt patch does. It changes the above-mentioned rule so that the scheduler is allowed to interrupt other kernel code without explicit permission, just as it does with user-mode code. If the kernel happens to be in a critical section (another technical term hard to explain to those who don't already know it), it should already have taken a lock in the SMP-mode case, so preempt-mode just redefines the lock/unlock operation as "disable preempt mode" / "reenable preempt mode". Thus, the kernel can sit and do all the work it wants to, and as long as it isn't holding any locks, the scheduler can pause it and run something more important (like letting your MP3 player trickle a bit more music into your sound card so the sound card won't run out, at which time you'd hear a skip).
I guess the terminology is really up to the reader, but in my opinion, while this is a "hack" in the sense of "clever program snippet", I think "creative use of existing facilities" is a good description. The key here is the realisation that the problem of how to preempt the kernel in arbitrary places is very similar to the problem of letting multiple copies of the kernel run at once on different CPUs, and since the latter is basically a solved problem (it was, in fact, probably the biggest difference between the 2.0 and 2.2 kernels), Robert Love was able to reuse this infrastructure to solve the vast majority of the problems with the former, in one fell swoop. Of course, preempt mode had other problems which had to be solved other ways, but SMP support was the major thing that paved the way.
(By the way, this wasn't Robert Love's idea originally. Linus Torvalds expressed it some time around the 2.4.0 era, but didn't feel like doing the work himself. I don't know if it was his original thought or if all this has been done before. I suspect Solaris, at least, uses a similar trick.)
Completely different. Intel's HyperThreading mode uses cooperative (not preemptive) multitasking implemented within the chip itself. At least that's my guess. Each virtual CPU runs until it hits whatever Intel deems a good stopping point, then changes hats and lets the other virtual CPU have a go. It works because a lot of facilities in the CPU can go underutilised because of bottlenecks elsewhere (fetching memory into L1 cache, for example), so by simulating two CPUs you can often keep these resources busier.
So why, oh why, are you doing it on Slashdot? You never paid me for the privilege you speak of, and I think I speak for most if not all of us here.
So get on the phone with your Red Hat customer service rep already. They're paid to listen to your bellyaching. You gave them your "business" and they take their "customer service issues" seriously.
In this environment, though, you're wrong. To me, to many of us on Slashdot, Linux is still a hobby (dude). I read the 50-page changelogs for fun. I read linux-kernel for fun. I occasionally hack on Linux for fun. Who are you to say I should treat Linux as a business?
(Before you say you weren't talking to me specifically - note that my statements apply to a good many kernel hackers.)
Wow, that's weird - here's a driver written by engineers on paid company time, with full access to spec sheets and with the hardware guys on speed-dial. And they actually work better than drivers reverse-engineered out of thin air because nobody at NVidia was willing to give them so much as a lousy PDF? Who woulda thought?
And this has to do with GPL being a poor development model how?
Where have you been living for the past four years, that you think Linux is "just taking off"? Oh, and how exactly did the kernel developers shoot Linux in the face? I assume you're no longer talking about NVidia here, since the kernel change mentioned in the article wouldn't affect the nv binary module at all, or 99% of other modules for that matter. How is the kernel developers' motivations to be considered philosophical nonsense? (I guess this would be similar to the philosophical nonsense that might motivate book publishers to forbid Barnes & Noble to sell books with a replacement dust jacket emblazoned with "www.bn.com" across the bottom of the front cover?)
What? Is someone trying to prevent me from using the 3DLabs Wildcat 7210? Do tell - I must have missed that headline.
Precisely.
And one that a surprisingly small percentage of wonks involved in GPL flamw^Wdiscussions seem to understand. Sometimes I almost get the feeling that many such people actually haven't read the GPL at all, where this point is spelled out quite clearly.
Look, it's pretty simple.
Where on earth did you get the ideas that either binary-only drivers or any other binary-only software have been disallowed?
Sheesh, RTFA already. Do you even know what the syscall table is? Hint, 99% or more of the modules out there don't need to touch it. (By "need" I mean it would be a reasonable approach to the problems a given module is designed to solve.)
Ummm, yeah, you do that. Perhaps you can spend a few sleepless nights curled up in a shivering ball on your bed wondering when the Kernel Gestapo will kick in your door, boot up your l33t XP/Mandrake dual boot and forcibly upgrade it to some unholy GNU/Palladium. Or maybe you can imagine some dark day when Linus sends you The Announcement: your kernel is vulnerable to a horrible hack, you must upgrade with this hotfix NOW, and oh by the way here's a 15-page EULA you have to click through, don't worry it's all fine print except the bit where they disable all heathen, politically incorrect software such as BitKeeper, which Linus uses for source management.
Have you ever read anything, by the way, that would indicate that even one kernel hacker would support disabling non-free software? I certainly haven't, and I like to think I keep up on these things.