The concept of counting is not for personal comparison of collections of things, but rather to describe a group of things to a second party so that *he/she/it* may perform a comparison with another collection without being able to appreciate the first himself/herself/itself.
If this tribe needed to communicate the value of collections beyond "There are *this* many " (while indicating the height of a pile of the items), they would work out a way - that way may be numerical if that satisfied their needs. As an example, if they have words "one", "two", "many", "smallest", then they may have three by refering to it as "smallest many", and four as "smallest many one", and five as "smallest many two", etc. it doesn't take long and they'll start making up words for larger quantities to avoid "smallest many smallest many smallest many smallest many two. They might start saying "smamamama-two" as 14.
I have seen this in English somewhere in (I think) "Church and State" from the Cerebus comic where Cerebus is trying to write a letter to his love, Jaka, and can't say what he wants to. Every other frame you see "Rip Rip" and "Tear Tear" written in wavy lines eminating from the hunched form of Cerebus as he decides each letter is not good enough. Although this uses the verb to represent the sound it makes, you can often see people exclaim in IRC channels on freenode "w00t!" which, if you attempt to say it, is a bit like the Gerry Springer audience trademark exclamation - it indicates the feeling you get when you are very pleased with some good news.
Are you proposing that the windowing system should not provide straightforward access to plain drawable windows unless it also provides an easier to use interface for a widget set?
I'm not suggesting limiting functionality -- of course it should be _possible_ for applications to directly draw on their windows if they want to. Any function that is unique to an individual application should be performed this way.
But any common functions should be implemented as part of a standard widget set.
oes that mean that the windowing part of the project *must* *not* be released for testing before the widget part?
No. In fact, it would likely be impossible to develop the widget implementations before the window management side was complete.
As soon as you have a window system, people can start creating multiple widget sets that have a different programming API, different lines drawn between similar widgets (eg, combo/list/text boxes), and different look and feel. And since there are tens of widget sets already available and Open Source, any new window system is likely to have them ported very quickly to get applications ported over. So you immediately have the polydigm problem.
If GTK+ included an X server, would that satisfy your requirements so that QT developers "specifically override [your] choices".
Probably not. I'll admit I don't know much about GTK+ at a technical level, but I believe it only supports overriding the drawing mechanisms as part of its theme mechanism. What I'm proposing is an interface where the application is unaware of the specific implementation of the widget, which is chosen by the user. So, for example, I could replace multi-line edit boxes with either a vi or an emacs implementation if I so chose.
If you have a window system that can be talked to from outside it's process, there is an IPC mechanism with a protocol. You can *always* use that protocol without even having the standard widget set installed on the system. For a window system that is designed to work over the network, this is forced to be even easier to do since the protocol must be very well specified.
I suspect it would be fairly easy to modify GTK+ and QT to use the widget sets provided by the server, and once this had been done any applications using either of those toolkits would function adequately. Any other system designed for cross platform portability is likely to be portable to the new functions of the server, also.
I assume you are not familiar with computer programming. Each GTK function has a specified behaviour, it will cause a certain widget to appear with a certain relationship to other widgets, in a certain state - if the new standard widget set does not have the same available widgets (or the GTK widgets can not be described by a combination of the new widgets), or the same expressiveness of relations, and the widgets don't have at least the same states with any extra states being merely logical "substates" (for want of a better word) of the GTK states, then making GTK use the widget set from the window system will be hard. Furthermore any change in future versions of the widget set will probably screw GTK up right royal unless extreme care is taken. That means that unless you *enforce* a no GLUT/canvas policy, existing widget sets will be ported as is, with all the user interface oddities.
In short, it ain't gonna happen so start trying to persuade existing widget developers to harmonise, and application developers to hurry up and move to the new harmonised versions. *That* is the only reason there is a consistent look and feel on Windows and MAC OS. As an example, The GIMP was ported over to Windows, and it looks like a GTK application even though Windows has a standard widget set.
Have I just infringed on MS's patent 'cos now gnome-terminal infringes on my system.
The question is whether anybody has done chmod u+s bash before and whether it can be proved. Or alternatively if it is particularly inventive or simply hasn't been done because it is a dangerous thing to do?
Are you proposing that the windowing system should not provide straightforward access to plain drawable windows unless it also provides an easier to use interface for a widget set?
Does that mean that the windowing part of the project *must* *not* be released for testing before the widget part?
If GTK+ included an X server, would that satisfy your requirements so that QT developers "specifically override [your] choices".
You know that the GTK+ library and the QT library could be made to draw on any window system that provides OpenGL/GLUT or a canvas from which events can be obtained, so the mere existence of GTK+ and QT makes it trivial to produce applications that conflict with any "standard" widget look and feel for a window system.
If they shipped even one binary without source, they must make the source available to all comers, in order to make it available to anyone to whom a copy of the binary-only release was transferred. This has the side-effect of making it availalable to people who did not get the object from them - but it IS still required.
That is incorrect, the GPL requires that you offer to and do (on request) supply the source to anybody to whom you distributed the binary. You do not have to distribute the source to everybody in the world, since then if you gave your best mate an installable CD, you would then have to supply the source to anybody in the world that asks you. They provide the source to those to whom they provided the binaries, and if those people provide the binaries to somebody else, they must provide the source on request - probably with a notice that some code has been removed as it was not permitted in the original release.
And I don't believe that they would have an obligation to even distribute their own IP to those they've already supplied binaries to. They would still have an obligation to distribute the source *minus* their IP to those people.
If someone knowingly distributes something they wrote under the GPL, then they have done just that. No waiting for an indefinite period and saying "April fools!" or "Gosh, we knew our code was in the stuff we were distributing under the GPL, but we didn't intend it" or shouting "Psyche!" at the world.
But if they UNKNOWINGLY distributed it, and as a result were now obligated to distribute the source even after they discovered the matter?
If they don't know that it contains their IP, then they cannot be obliged to honour the license they have given you for that part.
But they *do* know. They've known for over a year and now that they know, they are offering the Linux Kernel under the terms of the GPL. If they are not offering the whole under the terms of the GPL then under the terms of the license they have for any legitimate parts, they must stop distributing the whole thing, or remove those parts that they do not offer under the terms of the GPL.
They have not done that. They are currently offering the whole Linux Kernel under the terms of the GPL, so anybody that gets that code off of them can do anything with it that the GPL allows.
They also claim to have thoroughly reveiwed all the code, so they *must* know either that it contains their code and that anybody who gets it off of them has a license under the terms of the GPL, or that it doesn't contain their code.
This is probably why they changed their lawsuit from a copyright infringment case to a breach of contract case...
The OP asked if this Linux kernel version fixes the problem, the reply was that it did not involve the kernel.
The question is answered: No, this does not fix your bootloader. Not Grub nor Partition Magic; Neither Lilo, "the bootloader that has no name", nor any other bootloader are in any way altered by this software.
Peer To Peer software is software that transfers information between two or more peers (that is either one is capable of both sending information and receiving information if given permission by the operators). If P2P software is banned, or the artists that produce it face huge suits, then TCP/IP and similar legitimate technology will be affected.
If you mean software that trivially transfers downloaded information to a repository that is exported by server software along with an index that is easy to find, you face a similar problem (Internet Explorer, IIS, MSN Search). I think you must explicitly narrow your definition to something like "... that is trivially easy to configure and abuse to breach a copyright license".
If you just say P2P software, you will ban/criminalise boatloads of stuff that is P2P but which is not wrongful. Much of this whole discussion is about poorly defined terms that a applied by politicians who think they only refer to a tiny set of wrongful domains - as in other posts that refer to the PATRIOT act of the USA applying to things it never should have.
> 5. No..not gmc..Nooooo! Why would you like to browse the Internet and your local computer with the same software?
With *my* unreliable ide controller, there is very little different between the local disk and a remote disk. Latency and reliability seem to be about the only difference, normally.
I suppose you really meant browse the web, but even the web is made up of many concepts, there is the document, the image, the animation, the video, the song, the interview, the chat room/channel, the bulletin board.
There should really be a separate "app" for each of those. I use the double-quotes since the word has been very poorly defined for the last 10 years. You can have one app that spans multiple processes, and even multiple countries, and several apps all in one process. You can now even have several apps in one process across several continents.
However, the "common" theme is that of browsing, there is a history, back/forward buttons, index/contents. There should be a common theme to the UIs for that part, but that could be in the form of shared libraries or embedded display (running a specific "app" with an instruction to draw to a window in the "browser" task). That way, you can disembed an app when you want to treat it separately to the browsing you were doing.
Because the LED is in series with the capacitor, the voltage drops, ensuring that there is a differential in the EMFs from the supply and the capacitor, and a current always flows.
But the supply must be rectified and smoothed first, I suppose. Also solving the flicker.
I don't think it was a particularly childish comment, the LSB has done nothing but document how the Redhat and SuSE (now Novell) distributions do things.
> [multiarch is] not backwards compatible... and it's not compliant with the LSB. For instance it's not hard to create an new x86 ABI that's faster (technically superior) than the current one, but the fact that it's not compatible with the one everyone else is using would be a pretty big reason to ignore it, if someone did one.
The libc5 to libc6 transition was done to improve the technical position, and it was not backwards compatible either, some software had to be recompiled just to co-exist, packaging methods had to be rethought. Similarly for gcc 3.2 and C++.
If you did the same loader magic as was done for libc5 support, only a few peices of software would need altering; and uniarch -> biarch is a far more significant change than libc -> libc6.
> AMD explicitly wanted the layout so you could just use the AMD64 as a faster x86 for a while
AMD can want sugarlumps supplied in boxed Debian sets, but AMD design Microprocessors - they have never even attempted to demonstrate their O/S design abilities.
Debian is not very compatible with other Distros anyway, the packages have to be transformed via alien, and I see no reason why Debian can't translate file operations to/lib depending on arch anyway. It may be a bit more work writing the kernel modules or libc/loader changes, but (and here's the great thing about Debian) they don't have to make money, so they don't have to release crap software just to release in time to get your money.
But what Microsoft *should* have done is simply provided a through and through 32 bit system with sensible directory names and supplied 32 bit versions of the legacy windows programs to people, like Debian will do.
The problem is all those third party commercial people that are slow and incompetent and shouldn't be supplying software in the first place.
LSB (Linux Standard Base) is a misnomer, it should be RNSB (Redhat and Novell Standard Base).
It is lead by its members wallets, the AMD64 Pure64 port does not run 32bit binaries (except in a chroot), it has no need for a 32 bit lib directory, same as IA64 and Alpha.
The multiarch solution is the technically superior one, the LSB should be push that design rather than a broken (lets make some MONEY!!) design.
Actually, it's not self contradictory since I didn't claim that Linux does not now withdraw a CPU quantum... It was just wrong. However, the process will only lose its CPU slot if there is something else that needs the CPU, so the current Linux scheduler is not wholly crap, just a bit crap.
> So at least one class of user is forced to be aware of the scheduler, to refer to another poster's assertion that users shouldn't even need to know...
For some info on sched_yield:
Sched_yield is intended to allow a non-preemtive system to give other processes a go. You call it when you are using the cpu in a long running calculation. You *ought* to use it in every such case. A smart pre-emptive scheduler will ignore it, and a dumb non-pre-emptive one will round robin to another process.
While it should not be used to simply spin with a 0-overhead delay inserted, there is little difference between spinning and simply being very conscientious.
A spinning process that's checking the completion status of a parallel task should preferably be recognised as such and given CPU like any CPU bound task (since it should have just blocked instead). A CPU bound task that is being concientious for the sake of non-pre-emptive systems should be treated, similarly, just like any other CPU bound task. OpenOffice.org and Ocaml have to wait too long for their next CPU quantum, but that's because they are CPU bound tasks and it's their own fault.
The bug was in past versions of Linux where, although it was pre-emptive, sched_yield was allowed some power - it should have been ignored in user-space and the scheduler decided what gets CPU and when. Depending on that bug is also a bug and the mis-users deserve everything they get.
> A really distributable system would include only the scheduler in the kernel
No, a kernel doesn't even need to have a scheduler in it. It needs to be able to take instructions to transfer control to another cpu context, and be able to create the necessary page tables, and that's about it.
The driver would be mapped into the X11 server process since that's how the Xfree implementation works with drivers (Xfree is in userspace).
One part of my post was about that alternative:
There *can* be a performance hit, though it comes somewhere else. When the driver is mapped into kernel space it can be executed while the application is still mapped, that means no TLB flushes to draw. If the driver is in a second process [the X server], then the user-context must be changed and this is more expensive. To alleviate this, you need buffering, which can increase latency and make a game feel less responsive.
The above is what the GLX extension to the X server does.
However, if the user-space driver code and data is mapped into the same user-space process as the game, it is not a problem. There are other issues with that...
This is the new alternative of which DRI is the kernel driver version. The X clients have the code to program the card, and the card protects itself from malicious user-space (or there is a small Open Source kernel component to protect it). There is then extremely high userspace performance, at the expense of more complex resource management issues.
If the driver is mapped into the process, what if it is running in a window, and another 3d program is running in another window. You can have the windows be textures on surfaces, but the hardware *must* be able to distinugish which context is drawing, and also must somehow fairly assign resources to the two. This can be done, especially since resource management does not have to be done terribly often it can be in a third process [the X server] a lot of the time (though some tasks may require a lot of changes to resource assignment I'm sure).
> You exercise YOUR rights by choosing what products/licenses you want to accept. Your rights don't include telling other companies how to license their legal products.
You WHAT?! When did I say nVIDIA should change their licensing? In fact you didn't even bother to read the second sentence of my post:
"A closed source video card driver is fine..."
The *only* thing I said is that if they're doing it closed source, it shouldn't be inserted in the kernel.
You said "My concern is not if the kernel module is open or closed, as long as they comply with the GPL."
I don't have any copyrighted work in the kernel, so I have no interest in whether they comply with the GPL in that respect, my concern is for the same reason as I use Linux. I don't trust commercial code (in general) to not make me lose data. It is true that there are bugs in the standard kernel, but they have a reasonable guarantee of being fixed when they get found since linux developers care about code quality - commercial developers have to do what their managers care about... release the next version and make it faster!
While *I* have a choice since I am a software engineer and understand this, video cards and their drivers are a consumer device, and companies are supposed to provide consumers with what they should have in a device without the consumer having to study a scientific discipline. In the case of a hardware driver *in* *the* *kernel* it can't be bug free, so it should be provided such that it is reasonably likely that it will be made good when the bugs are discovered. This then reduces the chance over time of data loss, and the way to do it is "in the kernel" -> "Open Source", "Closed Source" -> "out of the kernel".
Obviously there are things that *must* go in the kernel (either in principle, or due to temporary design limitations in the kernel), it gets a bit hairy then, since a corporation has no fundamental right to risk injury to a consumer just to provide a choice (though I beleive it *can* risk injury to another corporation to provide a choice).
You said "That is capalism [sic], you vote with your dollars, you DON'T have the right to force legally compliant companies to do your will in any other way."
This is Britain (where I am), decisions on right and wrong are not (yet) based purely on who is willing to pay how much. A company cannot sell a CD player (and get away with it) that wipes your CDs occassionaly just because people are still buying it. Consumers do not have to research what lasers are supposed to be used and which devices use the correct ones.
But closed source code does not have a place in a consumer kernel.
A closed source video card driver is fine... Who gives a shit since you have to pay for the hardware and the quality of the driver determines the cost of the hardware.
> I believe you need to invest in a calculator. 10000 switches, divided by 1000 switches per frame = 10 frames per second. A performance problem.
10000 switches / 1000 switches per frame = 10 frames
You've got your units wrong. Many a Mars mission has wasted tens of millions of dollar because of that. It should be:
10000 switches PER MONITOR REFRESH / 1000 switches per frame = 10 frames per monitor refresh
Since you only need 1-3 frames per monitor refresh depending on what jitter you are aiming for, the OP is quite right (assuming 1000 switches per frame is a good estimate - I think it is).
Slashdot Mirror
The concept of counting is not for personal comparison of collections of things, but rather to describe a group of things to a second party so that *he/she/it* may perform a comparison with another collection without being able to appreciate the first himself/herself/itself.
If this tribe needed to communicate the value of collections beyond "There are *this* many " (while indicating the height of a pile of the items), they would work out a way - that way may be numerical if that satisfied their needs. As an example, if they have words "one", "two", "many", "smallest", then they may have three by refering to it as "smallest many", and four as "smallest many one", and five as "smallest many two", etc. it doesn't take long and they'll start making up words for larger quantities to avoid "smallest many smallest many smallest many smallest many two. They might start saying "smamamama-two" as 14.
I have seen this in English somewhere in (I think) "Church and State" from the Cerebus comic where Cerebus is trying to write a letter to his love, Jaka, and can't say what he wants to. Every other frame you see "Rip Rip" and "Tear Tear" written in wavy lines eminating from the hunched form of Cerebus as he decides each letter is not good enough. Although this uses the verb to represent the sound it makes, you can often see people exclaim in IRC channels on freenode "w00t!" which, if you attempt to say it, is a bit like the Gerry Springer audience trademark exclamation - it indicates the feeling you get when you are very pleased with some good news.
I am currently undergoing hypnotic therapy to make me forget the word "pain", so that I can be a superhero!
In short, it ain't gonna happen so start trying to persuade existing widget developers to harmonise, and application developers to hurry up and move to the new harmonised versions. *That* is the only reason there is a consistent look and feel on Windows and MAC OS. As an example, The GIMP was ported over to Windows, and it looks like a GTK application even though Windows has a standard widget set.
how about chmod u+s bash ?
Have I just infringed on MS's patent 'cos now gnome-terminal infringes on my system.
The question is whether anybody has done chmod u+s bash before and whether it can be proved. Or alternatively if it is particularly inventive or simply hasn't been done because it is a dangerous thing to do?
Are you proposing that the windowing system should not provide straightforward access to plain drawable windows unless it also provides an easier to use interface for a widget set? Does that mean that the windowing part of the project *must* *not* be released for testing before the widget part? If GTK+ included an X server, would that satisfy your requirements so that QT developers "specifically override [your] choices". You know that the GTK+ library and the QT library could be made to draw on any window system that provides OpenGL/GLUT or a canvas from which events can be obtained, so the mere existence of GTK+ and QT makes it trivial to produce applications that conflict with any "standard" widget look and feel for a window system.
That is incorrect, the GPL requires that you offer to and do (on request) supply the source to anybody to whom you distributed the binary. You do not have to distribute the source to everybody in the world, since then if you gave your best mate an installable CD, you would then have to supply the source to anybody in the world that asks you. They provide the source to those to whom they provided the binaries, and if those people provide the binaries to somebody else, they must provide the source on request - probably with a notice that some code has been removed as it was not permitted in the original release.
And I don't believe that they would have an obligation to even distribute their own IP to those they've already supplied binaries to. They would still have an obligation to distribute the source *minus* their IP to those people.
If they don't know that it contains their IP, then they cannot be obliged to honour the license they have given you for that part.
But they *do* know. They've known for over a year and now that they know, they are offering the Linux Kernel under the terms of the GPL. If they are not offering the whole under the terms of the GPL then under the terms of the license they have for any legitimate parts, they must stop distributing the whole thing, or remove those parts that they do not offer under the terms of the GPL.
They have not done that. They are currently offering the whole Linux Kernel under the terms of the GPL, so anybody that gets that code off of them can do anything with it that the GPL allows.
They also claim to have thoroughly reveiwed all the code, so they *must* know either that it contains their code and that anybody who gets it off of them has a license under the terms of the GPL, or that it doesn't contain their code.
This is probably why they changed their lawsuit from a copyright infringment case to a breach of contract case...
Linux is safe.
The OP asked if this Linux kernel version fixes the problem, the reply was that it did not involve the kernel.
The question is answered: No, this does not fix your bootloader. Not Grub nor Partition Magic; Neither Lilo, "the bootloader that has no name", nor any other bootloader are in any way altered by this software.
Peer To Peer software is software that transfers information between two or more peers (that is either one is capable of both sending information and receiving information if given permission by the operators). If P2P software is banned, or the artists that produce it face huge suits, then TCP/IP and similar legitimate technology will be affected.
If you mean software that trivially transfers downloaded information to a repository that is exported by server software along with an index that is easy to find, you face a similar problem (Internet Explorer, IIS, MSN Search). I think you must explicitly narrow your definition to something like "... that is trivially easy to configure and abuse to breach a copyright license".
If you just say P2P software, you will ban/criminalise boatloads of stuff that is P2P but which is not wrongful. Much of this whole discussion is about poorly defined terms that a applied by politicians who think they only refer to a tiny set of wrongful domains - as in other posts that refer to the PATRIOT act of the USA applying to things it never should have.
I have P2P software, and I use it for downloading legitimate material. The P2P software is called bittornado.
I also have some P2P software in the O/S, it is called TCP/IP.
> 5. No..not gmc..Nooooo! Why would you like to browse the Internet and your local computer with the same software?
With *my* unreliable ide controller, there is very little different between the local disk and a remote disk. Latency and reliability seem to be about the only difference, normally.
I suppose you really meant browse the web, but even the web is made up of many concepts, there is the document, the image, the animation, the video, the song, the interview, the chat room/channel, the bulletin board.
There should really be a separate "app" for each of those. I use the double-quotes since the word has been very poorly defined for the last 10 years. You can have one app that spans multiple processes, and even multiple countries, and several apps all in one process. You can now even have several apps in one process across several continents.
However, the "common" theme is that of browsing, there is a history, back/forward buttons, index/contents. There should be a common theme to the UIs for that part, but that could be in the form of shared libraries or embedded display (running a specific "app" with an instruction to draw to a window in the "browser" task). That way, you can disembed an app when you want to treat it separately to the browsing you were doing.
oooh, oooh, I get it!
Because the LED is in series with the capacitor, the voltage drops, ensuring that there is a differential in the EMFs from the supply and the capacitor, and a current always flows.
But the supply must be rectified and smoothed first, I suppose. Also solving the flicker.
Do I get any soup?
That's really interesting. Can you elaborate on how the series capacitor works because my school physics education is becoming hazy now?
Is there any problem using that also on 230V A/C?
What about reducing flicker?
> Grow up.
... and it's not compliant with the LSB. For instance it's not hard to create an new x86 ABI that's faster (technically superior) than the current one, but the fact that it's not compatible with the one everyone else is using would be a pretty big reason to ignore it, if someone did one.
/lib depending on arch anyway. It may be a bit more work writing the kernel modules or libc/loader changes, but (and here's the great thing about Debian) they don't have to make money, so they don't have to release crap software just to release in time to get your money.
I don't think it was a particularly childish comment, the LSB has done nothing but document how the Redhat and SuSE (now Novell) distributions do things.
> [multiarch is] not backwards compatible
The libc5 to libc6 transition was done to improve the technical position, and it was not backwards compatible either, some software had to be recompiled just to co-exist, packaging methods had to be rethought. Similarly for gcc 3.2 and C++.
If you did the same loader magic as was done for libc5 support, only a few peices of software would need altering; and uniarch -> biarch is a far more significant change than libc -> libc6.
> AMD explicitly wanted the layout so you could just use the AMD64 as a faster x86 for a while
AMD can want sugarlumps supplied in boxed Debian sets, but AMD design Microprocessors - they have never even attempted to demonstrate their O/S design abilities.
Debian is not very compatible with other Distros anyway, the packages have to be transformed via alien, and I see no reason why Debian can't translate file operations to
But what Microsoft *should* have done is simply provided a through and through 32 bit system with sensible directory names and supplied 32 bit versions of the legacy windows programs to people, like Debian will do.
The problem is all those third party commercial people that are slow and incompetent and shouldn't be supplying software in the first place.
LSB (Linux Standard Base) is a misnomer, it should be RNSB (Redhat and Novell Standard Base).
It is lead by its members wallets, the AMD64 Pure64 port does not run 32bit binaries (except in a chroot), it has no need for a 32 bit lib directory, same as IA64 and Alpha.
The multiarch solution is the technically superior one, the LSB should be push that design rather than a broken (lets make some MONEY!!) design.
My post is self contradictory :)
Actually, it's not self contradictory since I didn't claim that Linux does not now withdraw a CPU quantum... It was just wrong. However, the process will only lose its CPU slot if there is something else that needs the CPU, so the current Linux scheduler is not wholly crap, just a bit crap.
> So at least one class of user is forced to be aware of the scheduler, to refer to another poster's assertion that users shouldn't even need to know...
For some info on sched_yield:
Sched_yield is intended to allow a non-preemtive system to give other processes a go. You call it when you are using the cpu in a long running calculation. You *ought* to use it in every such case. A smart pre-emptive scheduler will ignore it, and a dumb non-pre-emptive one will round robin to another process.
While it should not be used to simply spin with a 0-overhead delay inserted, there is little difference between spinning and simply being very conscientious.
A spinning process that's checking the completion status of a parallel task should preferably be recognised as such and given CPU like any CPU bound task (since it should have just blocked instead). A CPU bound task that is being concientious for the sake of non-pre-emptive systems should be treated, similarly, just like any other CPU bound task. OpenOffice.org and Ocaml have to wait too long for their next CPU quantum, but that's because they are CPU bound tasks and it's their own fault.
The bug was in past versions of Linux where, although it was pre-emptive, sched_yield was allowed some power - it should have been ignored in user-space and the scheduler decided what gets CPU and when. Depending on that bug is also a bug and the mis-users deserve everything they get.
heh, I've still got TWO of them, one of them can even play *four* notes at a time, making a scheduler completely unnecessary.
Wake me up before you go, go......
> A really distributable system would include only the scheduler in the kernel
No, a kernel doesn't even need to have a scheduler in it. It needs to be able to take instructions to transfer control to another cpu context, and be able to create the necessary page tables, and that's about it.
One part of my post was about that alternative:
The above is what the GLX extension to the X server does.
This is the new alternative of which DRI is the kernel driver version. The X clients have the code to program the card, and the card protects itself from malicious user-space (or there is a small Open Source kernel component to protect it). There is then extremely high userspace performance, at the expense of more complex resource management issues.
> You exercise YOUR rights by choosing what products/licenses you want to accept. Your rights don't include telling other companies how to license their legal products.
You WHAT?! When did I say nVIDIA should change their licensing? In fact you didn't even bother to read the second sentence of my post:
"A closed source video card driver is fine..."
The *only* thing I said is that if they're doing it closed source, it shouldn't be inserted in the kernel.
You said "My concern is not if the kernel module is open or closed, as long as they comply with the GPL."
I don't have any copyrighted work in the kernel, so I have no interest in whether they comply with the GPL in that respect, my concern is for the same reason as I use Linux. I don't trust commercial code (in general) to not make me lose data. It is true that there are bugs in the standard kernel, but they have a reasonable guarantee of being fixed when they get found since linux developers care about code quality - commercial developers have to do what their managers care about... release the next version and make it faster!
While *I* have a choice since I am a software engineer and understand this, video cards and their drivers are a consumer device, and companies are supposed to provide consumers with what they should have in a device without the consumer having to study a scientific discipline. In the case of a hardware driver *in* *the* *kernel* it can't be bug free, so it should be provided such that it is reasonably likely that it will be made good when the bugs are discovered. This then reduces the chance over time of data loss, and the way to do it is "in the kernel" -> "Open Source", "Closed Source" -> "out of the kernel".
Obviously there are things that *must* go in the kernel (either in principle, or due to temporary design limitations in the kernel), it gets a bit hairy then, since a corporation has no fundamental right to risk injury to a consumer just to provide a choice (though I beleive it *can* risk injury to another corporation to provide a choice).
You said "That is capalism [sic], you vote with your dollars, you DON'T have the right to force legally compliant companies to do your will in any other way."
This is Britain (where I am), decisions on right and wrong are not (yet) based purely on who is willing to pay how much. A company cannot sell a CD player (and get away with it) that wipes your CDs occassionaly just because people are still buying it. Consumers do not have to research what lasers are supposed to be used and which devices use the correct ones.
But closed source code does not have a place in a consumer kernel.
A closed source video card driver is fine... Who gives a shit since you have to pay for the hardware and the quality of the driver determines the cost of the hardware.
Just, for the love of god, not in the kernel!
> I believe you need to invest in a calculator. 10000 switches, divided by 1000 switches per frame = 10 frames per second. A performance problem.
10000 switches / 1000 switches per frame = 10 frames
You've got your units wrong. Many a Mars mission has wasted tens of millions of dollar because of that. It should be:
10000 switches PER MONITOR REFRESH / 1000 switches per frame = 10 frames per monitor refresh
Since you only need 1-3 frames per monitor refresh depending on what jitter you are aiming for, the OP is quite right (assuming 1000 switches per frame is a good estimate - I think it is).