Wait. He said it wasn't ready for 2.2, yet still missed 2.4?????
Yup. Late 2.3 was really weird. Actually it was a lot like other kernel cycles, come to think of it. Linus did the usual feature-freeze-no-wait-let's-put-in-LVM-ok-now-fea ture-freeze thing, and eventually replaced the whole memory manager in the 2.3.99 series somewhere (later replacing that in 2.4.10, as is now common knowledge)... but really everyone was in a holding pattern figuring Linus would release the real 2.4 Any Day Now, for quite some time. It was an easy boat to miss. Reiserfs missed it, actually - Hans Reiser was up in arms about that - but then Linus let it in in 2.4.1 or 2.4.2 since it was pretty much self-contained.
Did anyone notice that Linus also integrated x86-64? Now AMD's vapor 64-bit offering is on an equal footing with Intel's vapid 64-bit offering.
(OT: According to a local SGI sales rep, a lot of the big Unix vendors got burned by the whole Itanium fiasco. I said I was curious a couple years ago why the vendors were all so quick to drop their own chips in favor of ia64, and he said "because we were stupid".)
I'm not sure I agree with creating a whole new arch for x86-64 rather than making it conditional stuff within i386. Yes, I realise, this was already done by sparc64, mips64 and ppc64, but that doesn't make it right. I think I would prefer the approach used by arm and superh - having sub-architectures within the main arch framework. Oh well, I guess that's why I'm not Linus.
I still have one of the old Aureal Vortex2 cards, which has (in part) a binary-only driver module. Could this be modified to work inside the ALSA framework in 2.6?
Depends - what do you mean by "in part"? I'm assuming the binary-only part is combined with a shim layer which is compiled from source?
If that's the case, it may be possible to rework the shim layer to support the ALSA API, but you might have some trouble getting hackers to do it for you. Many of them are more interested in supporting open hardware, after all. On the other hand, several people worked on winmodem drivers long before anyone provided much documentation for those chips, so perhaps someone will port it for you.
Alternatively, try your hand at porting it yourself, or pay someone to hack on it....
Or you could ask the company to develop ALSA drivers... oops, I forgot, there is no company. ):
however i wonder why this is big news because there are so many important things which are getting merged.
It is a big deal - ALSA has been "on the horizon" with many happy users ever since the late 2.1 days. Jaroslav didn't feel it was ready for prime time by 2.2 and missed the boat with 2.4, so I'm glad ALSA finally made it.
Now if Linus will just accept Keith Owens's new Makefile structure, I'll be a happy man. (Same goes, to a lesser extent, for Eric Raymond's new configuration infrastructure.) He said a year ago it would happen in the 2.5.1 - 2.5.2 timeframe, now it looks like he may be backpedaling... oh well.
Can someone explain to me what this means? I've never had trouble with the sound modules that came with the kernel before.
range of hardware - ALSA supports more cards than the existing OSS-based stuff
features - the first "A" in ALSA is "Advanced". The original OSS API is rather limited as to what it allows an application to do. Doesn't affect me much, because I have a motherboard OPL3SA chip with its crappy FM synthesizer (so MIDI sounds really lousy) - but if you have newer hardware with its leet DSP effects including 3D simulation, etc, the old drivers will never allow an app (read: game) to take full advantage of it. ALSA may not be as advanced as DirectX - I have no idea - but it's a sight better than OSS.
new infrastructure - ALSA is a sort of "clean slate" and gets rid of many of the annoying limitations of the current architecture, like only letting one app use the card at a time (some current drivers have this limitation even though the hardware supports multiple input channels - sure you can get around this with a sound daemon such as aRts or esd, but still).
Pratchett uses a lot of footnotes, and iSilo handled it really well. (I simply put a "mark" at the end where the footnotes were). Two arrows appeared. One to go to where I set it, the other to return to where I was. It is great.
Let me get this straight. They have a fancy file format to represent the text of a book, yet this fancy file format doesn't support any sort of hyperlinks to/from the footnotes? *boggle* Come on, even Windows.HLP files support this! Who designed the ebook format, anyway?
Re:No need for NAT router for open socket migratio
on
OpenMosix
·
· Score: 1
when a process is migrated, it would send a broadcast message to change ARP tables, so the same IP address would be sent to a different MAC address
Think of the effect on switched networks. Switches have finite-sized ARP caches, so by artificially inflating them you increase the number of misses (where each miss equates to a broadcast since the switch doesn't know where to send the packet).
Not a serious problem, if your number of hosts (on your network, not just in your cluster) << number of MAC addresses supported by your switches (a few thousand, often). I suppose it does depend on how many "away-from-home" processes start per unit time.
Also, each ARP packet will itself be broadcast, causing more traffic up front. Again, this may or may not be significant. And each host has to process and cache the ARP.
If you are assuming that the MOSIX cluster will be on a dedicated network - probably reasonable - none of this is much of a problem.
If it's digital data, there's no way you can make a copy and lose quality. Any freshman computer engineering student can tell you that.
"In theory, theory and practice are the same. In practice, they are different." --Larry McVoy, {Solaris,IRIX,Linux} kernel hacker
It is quite possible to get errors ripping CDs, even with no visible scratches. Usually the imperfections are minor enough to be inaudible. But try ripping the same track of a favorite CD five times, and checksumming the five CDDA files. If they all match, you have a better CD-ROM than I do.
Data CDs have a much better error correction scheme than audio CDs - they would be impractical for data storage otherwise. A sector of a data CD is 2048 bytes; an audio sector is 2352 bytes (do the math: 2 channels, 16 bits, 44100 Hz, 1/75 second). I'm no expert, but I believe the size difference is due to the different error correction mechanism.
you can be thankful you are supporting the no-talent hacks ad "Midbar technologies".
It takes a complete friggin moron to think they can make bits uncopyiable.
Hey - they don't think they can make bits uncopyable. They think they can convince the record companies that they can make bits uncopyable.
Big difference. I don't think Midbar are morons at all. They sold a large load of snake oil to some very big customers for (probably) a lot of money. Not bad.
I believe that Fantastic Lad could hook you up with one. Some assembly required.
That could work. "Hand-crafted! Twice!"
BTW, you're not going to give me the satisfaction of luring you into a GPL/BSD flamewar in the other story?:-(
Aha! Proof that AC is really only one person after all. Nah, go find an advocacy group or... oh wait... this is slashdot... um, never mind, but you'll have to argue with someone else.
Especially when it comes to jokes about how genitalia contribute to logic or any such nonsense.
Good point, poor example. How many lines about brains vs genitalia have you heard about women? The only ones in that category I ever hear are about the two warring nerve centers of the male. (:
I would laugh if I didn't have to put up with this in the real world-thinly veiled jokes expressing attitudes toward women.
Hey, I feel your pain. I hear jokes all the time about how stupid men are relationship-wise. I laugh anyway, since they're mostly true.
So save yourself some real world grief and pick up some tactfulness now in a relatively anonymous place like Slashdot.
I've got tact. I like to pull it out and spring it on people right when they think I'm gonna be all gauche and stuff. You've got problems with condescension. (Not that I mind - as demonstrated by the retaliatory condescension in that very sentence. (: )
Finally, it's not a:), it's a (:. In my world, to read things, I have to pitch to the right a lot more often than to the left - you know, book spines, CD spines, etc. (Sure, French books and a very few CD jackets are the opposite - but that's a small minority in my world.)
Those licenses don't attempt to extricate source code from copyright holders' hands, but simply open what those developers feel they should.
Congratulations, you have described every software license ever written.
Think about it. This isn't a glib point - it is the point. A software license is the copyright holder's expression of his own desires. Not the desires of RMS, or Larry Wall, or the Regents of the University of California.
You're not going to bait me into a GPL vs BSD flamewar here. Just don't tell me I have a warped sense of reality by using an RMS license and I won't tell you you are on a permanent LSD trip for using a Berkeley license. (:
Hey! What website? I'd gladly pay a dime for just one. (:
Now destroy a Steinway... That's sacrilege.
So say you. Call me a snob, but I don't care for Steinways at all. Never have. The keys are too mushy, the quiet end of the dynamic range is hard to get right. I'll take the crisp sound & feel of a Yamaha over a Steinway any day of the week.
If you just want to sell me software, you should have to sell me a copy. I get all the normal rights available to other intangible goods, but you can't impose additional restrictions.
Sounds good.
The GPL might have some difficulties under this system though...
Others have said it better - but it bears repeating, because so many people seem to miss this point: The GPL has the opposite function to a typical EULA: it gives additional rights, rather than purporting to take rights away.
The GPL does not restrict your rights under copyright law. It gives you certain rights you do not have under copyright law -- namely, the right to distribute copies of the work, and to distribute modified copies ("derivative works"), subject to certain conditions.
Without a license such as the GPL, you do not have the right to redistribute copyrighted software at all. With or without modifications. That's the whole point of copyright law.
Your typical EULA, on the other hand, doesn't give you any rights you didn't already have. Instead, it claims to take away some of the rights you have -- namely, the right to use your software for whatever you wish (excluding redistribution - that's where copyright law steps in).
(Note of course I say an EULA "purports to" and "claims to" do such and such. I refuse to agree with those who say that my cutting open a box or clicking on an icon, in the privacy of my own home, bears any resemblance to so much as a handshake with an authorized vendor rep, much less a seal or signature. How would you notarize a click?)
A friend of mine described how a government tax agent and several company officers had to witness the destruction of a perfectly working, hand-crafted, grand piano.
Gee, thanks, I'm about to cry now. That's just wrong. No Yamaha grand piano should have to suffer that fate. Where was PETP?
No one knows why and no one can offer any explanation other than his ONE working eye can do depth perception _by itself_.
I find this quite interesting, but not hard to believe. His brain is probably using either change-of-perception (his own head moving around) or focus lengths of objects - or, more likely, combining the two.
Back on topic - one way for a digital camera to get a Z coordinate is focal length. Cameras have had auto-focus features for years - why not run all the way through the focal range, and with a decent embedded DSP you should be able to pull together at least an estimated Z buffer for the whole frame. I figure the whole focal range should take less than a second, but what do I know?
This joke seems to assume that since human females in general have slightly smaller brains than males, then females are thus less intelligent than males. How unfortunate to have such a thought, because in this society women will have more control over what happens to their pregnancy then they do. It is not a good idea to imply that they cannot make logical decisions that will benefit their welfare.
In the book "The universe in a nutshell" by Stephen Hawking, he notes that humans developing inside an artificial womb would be able to develop larger brains.
Haven't read it - is he referring to the restriction of going through the birth canal? Because millions of us never experienced it. Including Shakespeare's Macduff, who was "from his mother's womb / Untimely ripped" several hundred years ago.
Of course none of us yet look like the Guild members from Dune, so perhaps there is some potential there.
(of course, larger brains != more intelligence..)
So how do you explain the female version of logical thought process? (:
Second, a process doesn't preempt another process unless it has a lower priority. As long as each of the 2000 users' apps have the same priority level, they'll all get the same response times.
I just thought it was worth pointing out here that Linux already preempts user processes so other processes can run! It has done this since 1991 - that's what "preemptive multitasking" means, and all modern OSes support it. The only distinction with the preempt patch is a rather academic (to most) question of "being in kernel mode" when the preemption happens.
So, as you say, this is completely orthogonal to scalability.
Not quite true - some Linux patches give unilateral improvement. But I do see your point.
What is the tradeoff that occurs when you integrate this patch?
None of the other responses to this thread (that I've noticed) addressed one tradeoff: complexity and bugs. Ever since Linux started to support SMP systems, SMP kernels have been somewhat buggier than UP kernels. This is because there are a lot of potential mistakes to be made - getting and releasing spinlocks and semaphores at the right places is not trivial stuff. Of course bugs have been fixed over the past several years, and SMP is now considered a standard Linux feature (in 2.0 it was "experimental"), but there are still no doubt lots of SMP bugs in some of the more obscure device drivers.
The problem with the preempt patch is that it introduces all these potential bugs into a standard non-SMP kernel, since preempt uses much the same basic mechanism as SMP. Most people only have one CPU, but now these people will be exposed to the same "increased level of risk" as SMP systems.
In a way, that could be considered a benefit - this may serve to flush out some of those last remaining SMP bugs. The SMP code paths will be exercised by a lot of people now.
Slashdot Mirror
Yup. Late 2.3 was really weird. Actually it was a lot like other kernel cycles, come to think of it. Linus did the usual feature-freeze-no-wait-let's-put-in-LVM-ok-now-fea ture-freeze thing, and eventually replaced the whole memory manager in the 2.3.99 series somewhere (later replacing that in 2.4.10, as is now common knowledge) ... but really everyone was in a holding pattern figuring Linus would release the real 2.4 Any Day Now, for quite some time. It was an easy boat to miss. Reiserfs missed it, actually - Hans Reiser was up in arms about that - but then Linus let it in in 2.4.1 or 2.4.2 since it was pretty much self-contained.
Did anyone notice that Linus also integrated x86-64? Now AMD's vapor 64-bit offering is on an equal footing with Intel's vapid 64-bit offering.
(OT: According to a local SGI sales rep, a lot of the big Unix vendors got burned by the whole Itanium fiasco. I said I was curious a couple years ago why the vendors were all so quick to drop their own chips in favor of ia64, and he said "because we were stupid".)
I'm not sure I agree with creating a whole new arch for x86-64 rather than making it conditional stuff within i386. Yes, I realise, this was already done by sparc64, mips64 and ppc64, but that doesn't make it right. I think I would prefer the approach used by arm and superh - having sub-architectures within the main arch framework. Oh well, I guess that's why I'm not Linus.
The mistake was probably due to the BK changelog, which quotes Jaroslav's email message:
(@*#&$^(*& llllaaaammmmeeeennnneeeessssssss ffffiiiilllltttteeeerrrr)
Depends - what do you mean by "in part"? I'm assuming the binary-only part is combined with a shim layer which is compiled from source?
If that's the case, it may be possible to rework the shim layer to support the ALSA API, but you might have some trouble getting hackers to do it for you. Many of them are more interested in supporting open hardware, after all. On the other hand, several people worked on winmodem drivers long before anyone provided much documentation for those chips, so perhaps someone will port it for you.
Alternatively, try your hand at porting it yourself, or pay someone to hack on it....
Or you could ask the company to develop ALSA drivers ... oops, I forgot, there is no company. ):
It is a big deal - ALSA has been "on the horizon" with many happy users ever since the late 2.1 days. Jaroslav didn't feel it was ready for prime time by 2.2 and missed the boat with 2.4, so I'm glad ALSA finally made it.
Now if Linus will just accept Keith Owens's new Makefile structure, I'll be a happy man. (Same goes, to a lesser extent, for Eric Raymond's new configuration infrastructure.) He said a year ago it would happen in the 2.5.1 - 2.5.2 timeframe, now it looks like he may be backpedaling ... oh well.
Hope this helps..
Actually I believe it was originally known as Micro Soft.
Let me get this straight. They have a fancy file format to represent the text of a book, yet this fancy file format doesn't support any sort of hyperlinks to/from the footnotes? *boggle* Come on, even Windows .HLP files support this! Who designed the ebook format, anyway?
Think of the effect on switched networks. Switches have finite-sized ARP caches, so by artificially inflating them you increase the number of misses (where each miss equates to a broadcast since the switch doesn't know where to send the packet).
Not a serious problem, if your number of hosts (on your network, not just in your cluster) << number of MAC addresses supported by your switches (a few thousand, often). I suppose it does depend on how many "away-from-home" processes start per unit time.
Also, each ARP packet will itself be broadcast, causing more traffic up front. Again, this may or may not be significant. And each host has to process and cache the ARP.
If you are assuming that the MOSIX cluster will be on a dedicated network - probably reasonable - none of this is much of a problem.
"In theory, theory and practice are the same. In practice, they are different." --Larry McVoy, {Solaris,IRIX,Linux} kernel hacker
It is quite possible to get errors ripping CDs, even with no visible scratches. Usually the imperfections are minor enough to be inaudible. But try ripping the same track of a favorite CD five times, and checksumming the five CDDA files. If they all match, you have a better CD-ROM than I do.
Data CDs have a much better error correction scheme than audio CDs - they would be impractical for data storage otherwise. A sector of a data CD is 2048 bytes; an audio sector is 2352 bytes (do the math: 2 channels, 16 bits, 44100 Hz, 1/75 second). I'm no expert, but I believe the size difference is due to the different error correction mechanism.
Hey - they don't think they can make bits uncopyable. They think they can convince the record companies that they can make bits uncopyable.
Big difference. I don't think Midbar are morons at all. They sold a large load of snake oil to some very big customers for (probably) a lot of money. Not bad.
That could work. "Hand-crafted! Twice!"
Aha! Proof that AC is really only one person after all. Nah, go find an advocacy group or ... oh wait ... this is slashdot ... um, never mind, but you'll have to argue with someone else.
Good point, poor example. How many lines about brains vs genitalia have you heard about women? The only ones in that category I ever hear are about the two warring nerve centers of the male. (:
Hey, thanks for the hospitality, gotta go..
Hey, I feel your pain. I hear jokes all the time about how stupid men are relationship-wise. I laugh anyway, since they're mostly true.
I've got tact. I like to pull it out and spring it on people right when they think I'm gonna be all gauche and stuff. You've got problems with condescension. (Not that I mind - as demonstrated by the retaliatory condescension in that very sentence. (: )
Finally, it's not a :), it's a (:. In my world, to read things, I have to pitch to the right a lot more often than to the left - you know, book spines, CD spines, etc. (Sure, French books and a very few CD jackets are the opposite - but that's a small minority in my world.)
Congratulations, you have described every software license ever written.
Think about it. This isn't a glib point - it is the point. A software license is the copyright holder's expression of his own desires. Not the desires of RMS, or Larry Wall, or the Regents of the University of California.
You're not going to bait me into a GPL vs BSD flamewar here. Just don't tell me I have a warped sense of reality by using an RMS license and I won't tell you you are on a permanent LSD trip for using a Berkeley license. (:
(Dagnabbit, I love feeding trolls.)
Hey! What website? I'd gladly pay a dime for just one. (:
So say you. Call me a snob, but I don't care for Steinways at all. Never have. The keys are too mushy, the quiet end of the dynamic range is hard to get right. I'll take the crisp sound & feel of a Yamaha over a Steinway any day of the week.
Sounds good.
Others have said it better - but it bears repeating, because so many people seem to miss this point: The GPL has the opposite function to a typical EULA: it gives additional rights, rather than purporting to take rights away.
The GPL does not restrict your rights under copyright law. It gives you certain rights you do not have under copyright law -- namely, the right to distribute copies of the work, and to distribute modified copies ("derivative works"), subject to certain conditions.
Without a license such as the GPL, you do not have the right to redistribute copyrighted software at all. With or without modifications. That's the whole point of copyright law.
Your typical EULA, on the other hand, doesn't give you any rights you didn't already have. Instead, it claims to take away some of the rights you have -- namely, the right to use your software for whatever you wish (excluding redistribution - that's where copyright law steps in).
(Note of course I say an EULA "purports to" and "claims to" do such and such. I refuse to agree with those who say that my cutting open a box or clicking on an icon, in the privacy of my own home, bears any resemblance to so much as a handshake with an authorized vendor rep, much less a seal or signature. How would you notarize a click?)
Gee, thanks, I'm about to cry now. That's just wrong. No Yamaha grand piano should have to suffer that fate. Where was PETP?
No, not on purpose - it's been too long since I read 'em. (:
I find this quite interesting, but not hard to believe. His brain is probably using either change-of-perception (his own head moving around) or focus lengths of objects - or, more likely, combining the two.
Back on topic - one way for a digital camera to get a Z coordinate is focal length. Cameras have had auto-focus features for years - why not run all the way through the focal range, and with a decent embedded DSP you should be able to pull together at least an estimated Z buffer for the whole frame. I figure the whole focal range should take less than a second, but what do I know?
Yo. Lighten up.
Haven't read it - is he referring to the restriction of going through the birth canal? Because millions of us never experienced it. Including Shakespeare's Macduff, who was "from his mother's womb / Untimely ripped" several hundred years ago.
Of course none of us yet look like the Guild members from Dune, so perhaps there is some potential there.
So how do you explain the female version of logical thought process? (:
<aol>Nice to know I'm not the only one whose first thought was of the innovative settlers of Ix.</aol>
To those who said "but they used real wombs" - yes, but I still think of axlotl tanks as artificial.
I just thought it was worth pointing out here that Linux already preempts user processes so other processes can run! It has done this since 1991 - that's what "preemptive multitasking" means, and all modern OSes support it. The only distinction with the preempt patch is a rather academic (to most) question of "being in kernel mode" when the preemption happens.
So, as you say, this is completely orthogonal to scalability.
Not quite true - some Linux patches give unilateral improvement. But I do see your point.
None of the other responses to this thread (that I've noticed) addressed one tradeoff: complexity and bugs. Ever since Linux started to support SMP systems, SMP kernels have been somewhat buggier than UP kernels. This is because there are a lot of potential mistakes to be made - getting and releasing spinlocks and semaphores at the right places is not trivial stuff. Of course bugs have been fixed over the past several years, and SMP is now considered a standard Linux feature (in 2.0 it was "experimental"), but there are still no doubt lots of SMP bugs in some of the more obscure device drivers.
The problem with the preempt patch is that it introduces all these potential bugs into a standard non-SMP kernel, since preempt uses much the same basic mechanism as SMP. Most people only have one CPU, but now these people will be exposed to the same "increased level of risk" as SMP systems.
In a way, that could be considered a benefit - this may serve to flush out some of those last remaining SMP bugs. The SMP code paths will be exercised by a lot of people now.