There is currently support in FreeBSD (3.1->) for a native port of the LinuxThreads kernel threads package, but the need for kernel threads on FreeBSD is a lot lower than on Linux, because the userland threads (libc_r - which should be POSIX compilant) has a very quick context switch. The performance between the two is pretty much the same, and should perform very similarly to libpthread on Linux.
There has been a lot of talk about a lightweight kernel threads implementation, especially to use SMP effectively accross threads, but there is no code.
Just a little FreeBSD horn blowing... A farm of dual processor FreeBSD boxes was used for the rendering of the the comupter graphics effects, much like the Linux farm used for Titanic. No details for now, but there should be a link somewhere soon.
You seem to have a good grasp of patents, software and their interactions, and I'd like to pass an idea before your eyes:
What if patents expired when someone improved on the idea? You say you spent millions on your ideas, and they required a good understanding of your field. I agree that your research investment requires protection from people stealing those ideas. But what if someone else comes with a product which adds to yours? Should they be denied access to your thinking? If their addition is minor and obvious then surely you should have thought of it? If their ideas require a deep understanding of the field, and they have out thought you, then shouldn't they get recognition?
I've been thinking of this as a means of allowing patent protection to prevent carbon copy software. It protects your research but forces you to stay at the cutting edge in your field, else the competition takes the prize, and what you have falls into the public domain (although it would still be protected by copyright). It also renders silly patents, like microsoft's style sheets patent, useless since a freeware developer, or W3C can improve trivially on the idea, and freely licence the intellectual property. It would then remain in the public domain, but someone else with a really clever idea which builds on it could still get a patent. It also means that the 20 year time period would self adjust to the pace of development in whatever field the patent was taken out in.
The main arguement is for windowless widgets. Basically, a native widget is in it's own window, and can't take part in the Z-ordering on the page, nor can it be given properties like a bitmaped background or set to be 50% transparent...
The idea is to have two code paths, which will give the same widegets at first. One for the forms and another for the chrome and dialog boxes etc. Then you can replace the chrome/dialog widgets with a native widget library (eg based on GTK) if you want. Then the app will look like the platform, and the forms will still maintain their Mozilla look. You could also use native widgets for the forms if you wanted, but they wont look as nice.
In terms of themes, the forms will be controlled by the pages style sheet, and the applicaiton widgets would be controlled by Mozilla's style sheets (which will be downloadable vis the web), or by the native widget implementation.
-Jeremy
PS. These are my conclusions from the mozilla discussions, and may not represent reality, since I not doing the coding...
There is currently support in FreeBSD (3.1->) for a native port of the LinuxThreads kernel threads package, but the need for kernel threads on FreeBSD is a lot lower than on Linux, because the userland threads (libc_r - which should be POSIX compilant) has a very quick context switch. The performance between the two is pretty much the same, and should perform very similarly to libpthread on Linux.
There has been a lot of talk about a lightweight kernel threads implementation, especially to use SMP effectively accross threads, but there is no code.
-Jeremy
Hi,
Just a little FreeBSD horn blowing... A farm of dual processor FreeBSD boxes was used for the rendering of the the comupter graphics effects, much like the Linux farm used for Titanic. No details for now, but there should be a link somewhere soon.
-Jeremy
Our ex network admin at work has an interesting saying:
"The paperless office will become a reality soon after the paperless toilet."
-Jeremy
Hope you're still reading this...
You seem to have a good grasp of patents, software and their interactions, and I'd like to pass an idea before your eyes:
What if patents expired when someone improved on the idea? You say you spent millions on your ideas, and they required a good understanding of your field. I agree that your research investment requires protection from people stealing those ideas. But what if someone else comes with a product which adds to yours? Should they be denied access to your thinking? If their addition is minor and obvious then surely you should have thought of it? If their ideas require a deep understanding of the field, and they have out thought you, then shouldn't they get recognition?
I've been thinking of this as a means of allowing patent protection to prevent carbon copy software. It protects your research but forces you to stay at the cutting edge in your field, else the competition takes the prize, and what you have falls into the public domain (although it would still be protected by copyright). It also renders silly patents, like microsoft's style sheets patent, useless since a freeware developer, or W3C can improve trivially on the idea, and freely licence the intellectual property. It would then remain in the public domain, but someone else with a really clever idea which builds on it could still get a patent. It also means that the 20 year time period would self adjust to the pace of development in whatever field the patent was taken out in.
-Jeremy
The main arguement is for windowless widgets. Basically, a native widget is in it's own window, and can't take part in the Z-ordering on the page, nor can it be given properties like a bitmaped background or set to be 50% transparent...
The idea is to have two code paths, which will give the same widegets at first. One for the forms and another for the chrome and dialog boxes etc. Then you can replace the chrome/dialog widgets with a native widget library (eg based on GTK) if you want. Then the app will look like the platform, and the forms will still maintain their Mozilla look. You could also use native widgets for the forms if you wanted, but they wont look as nice.
In terms of themes, the forms will be controlled by the pages style sheet, and the applicaiton widgets would be controlled by Mozilla's style sheets (which will be downloadable vis the web), or by the native widget implementation.
-Jeremy
PS. These are my conclusions from the mozilla discussions, and may not represent reality, since I not doing the coding...