You speak of checking sources in and out of the "core" (I assume you mean a revision control repository), and checking binaries out. You also mention keeping parse trees and similar temporary data structures in the repository as well. We've really got two things here.
No, I am not talking revision control repository here. I am talking moving towards a representation that is a bit further down the road of compilation.
Obviously it is possible to represent a programm on many different stages:
Starting from a collection of text files to
preprocessed intermediate files,
internal parse trees,
other intermediate representations like RTL in case of gcc and possibly
assembler source to
object files to
linked executables.
If we treat each translation step as a mapping between representations, I can draw the compilation process this way:
1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7
In fact not all mappings are one way (loosing information) but are (or could be made) bijective
1 <-> 2 <-> 3 -> 4 -> 5 -> 6 -> 7
I now suggest focussing more on the programm in representation around stage 3. Why?
Because this is the representation in terms of the language, on that for example the compiler works on for code generation.
And I am not thinking just compilation here. I am more thinking turning the collection of sources into a database of things more understood, e.g. program related units, like classes, functions, macros,..
Take Emacs for example. Press Esc-x and then spc and you get a listing of all available functions. The Emacs kernel "knows" of all its functions. Compare that to grepping a deep C/C++ source tree for some function. That grepping should be replaced by a more appropriate query on a more appropriate database. (Like that Esc-x spc sequence is a query on the dumped Emacs kernel).
If the source has changed, you are going to have to rebuild the output anyway. If the original has not changed, you can just use the object file from revision control. What is the point?
Not every change to source would result in a complete rebuilding of the internal structures. Some mechanism like the access optimzation found in relational databases had to decide if the whole has to be rebuild, or if only parts have to be changed. This is certainly one of the hard parts.
Now, I suppose you could argue that you don't always need to recompile an entire source file; you may have changed just one function. But to know that, the compiler is going to have to do a source analysis of it anyway.
If I edit on the text stage you are right. Possibly most changes will result in a new translation. If I edit on the language stage ("add a function", "delete that class") not necessarily.
One way this has been dealt with in the past is to store everything (source, source deltas, compiled objects and linked executables) in a source code management system along similar lines to SCCS or CVS. I cite as an example the CMS tools on OpenVMS.
I am sure there is a lot to learn from those old systems. (Why some of the VMS guys inflicted Windows NT on us is a different thing:)
That we seem to have lost some features as well and did not progress only, shines through in the hacks and rants of great hackers like Richard Stallmann and Jamie Zawinski. Take this quote
Back before the current dark ages began, I hacked on Lisp Machines. (..) Have you ever wondered why we're stuck with crap like Unix and MS-DOS? Read Richard Gabriel's Worse is Better paper for a great explanation of why mediocrity has better survival characteristics than perfection
Yes, with string-based interpreters you can represent programs as strings, and you can interpret them as strings, but you can't parse their syntax very easily as strings. In LISP, programs are represented as data in a way that expresses their structure, and allows you to easily do things to the programs that are based on understanding them.
from a recent RMS interview. Both refer to the LISP machines of MIT, which seem to have operated on a higher level program representation than mere strings.
I interpret these rants that todays machines are stronger but dumber in a sense as well.
Question is if one could combine the strengths of both worlds. The higher level representation found in LISP machines and the performance of our present C compiled systems.
Like I tried to explain above, my feeling is that this could be achieved by shifting the primary representation to something closer to the intermediate structures that arise during compilation. It would have indeed similarities to a configuration management system. Adding a line to a text source would, after check-in, result in an immediate update of an persistent parse tree of the program database core.
OpenVMS compilers and the linker can be invoked to operate on CMS objects without having to pre-fetch anything first.
Do you have any reference where I can read more about CMS? (I would be happy also to have some nice review on the strengths of the LISP machines)
If we were to implement something like this for ourselves I'd say the first thing to do is to find a lightweight, fast and efficient implementation of an object repository. Does anyone know of such?
Sounds to me like what OODBs are promising. The one I had to try so far (POET 3 under Win32 and Solaris) was horrible. No idea how they perform today, as they seem to be two major revisions farther.
If there's a missing requirement in the rules of the contest, it's the lack of a migration path from make. Without that, you just have an interesting toy, because no one will move their existing significant system without it.
I mean, honestly, what is a "filesystem" except a way of organizing chunks of arbitrary data in a tree structure?
If you have a "database" that also can organize chunks of arbitrary data in a tree structure, but is so much faster than ext2 at this that you believe it should be built into programs... why not wrap a filesystem driver around it and build it into every program at once?
Your're right, I was not thinking of arbitrary data when I speak of that "database". I want to exploit features of a certain kind of data, that should be stored efficiently - the intermediate code representation.
We usually store the initial representation of the program (the source) and the final representation (object files, executables, libs..) but throw away the intermediate representations that compilers, assemblers and linkers calculate time and time again.
For a few cases we keep that intermediate representations. Precompiled headers are an example of an intermediate result that is kept near the beginning of the translation chain, template repositories (used in AT&T's cfront derived C++ compilers) are an example near the end.
What I thought of is similiar to one of those relational databases in that the focus shifts from the raw input data to the intermediate representation that would be kept as a whole.
Let's say the running core would consist not of a collection of files of characters but of datastructures that are more suited for compilation, typically of a forest of parse trees and related intermediate information for the whole project.
One could import/export sources from that core, and the compilation process would be a special kind of query that exports binaries from that core.
More global optimization strategies would be possible because the compilation proceeds on the whole project, not only single compilation units as normal compilers do.
The trouble with template instantiation would be gone.
But, yes now comes the but:-), such a system is certainly complicated. I had a lot of fun with precompiled headers and template repositories in the past. So I assume it is not easy to write them in a way that they work flawlessly.
And that's why *BSD stuff will never beat GNU software - they took the time to do it properly; you're "too busy" to bother.
That is a stupid remark, especially the time argument. Both cultures have excellent results, are fruitful to each others and are likely to stay with us for a while.
The lack of a BSD compiler is the result of no one interested enough so far in writing one. Not more not less. No reason why this could not change one day.
Replace autoconf? Replace make????? These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.
I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only.dsp files! HA!), and opens the program up to porting to other platforms.
First, I completely agree with you that project configuration through MS Developers Studio projects is inferior to UNIX style configuration.
I had many fruitless discussions about this with some of my collegues (sigh). For some reason it is seems nearly impossible to convince people with a DOS/Windows background that the complicated make syntax is less a PITA than the fact that a myriad of parameters is hidden behind various corners of the MS Dev Studio graphical user interface.
My theory is that UNIX people love ASCII representations while the Windows crowds loves roaming GUIs. No idea why. But believe it or not there are people who for example can memorize an astounishing list of key/value pairs from the NT registry.
On the other hand one must admit, that it is hard to understand make without being familiar with the way the basic UNIX tools (awk, sed, grep, sh..) interact in the more complex make files.
My objection against make is not it's complicated syntax (which is only complicated because different levels of parsing - make's and sh's - intermix and regular expressions need a bit familiarity), but that it is slow.
This is not a failure of make itself but because of the way we traditionally organize programms into files and directories. In fact we use the filesystem as database, and query this database by giving paths.
I would expect a speed up, if we would move away from that organization into some kind of program database. A database that is very close to the semantics of the used programming language. Like a database of classes, makros, functions, globals etc So I expect that it would be possible to improve the speed of a make dependency aware construction tool in such a environment.
It would also solve some issues with C++ (especially template resolution).
However I have not seen a move away from that traditional C style project break up, compilation and linking to something which more resembles a database with tools on it yet.
Possibly because it would give up many benefits, the most obvious ones the ASCII representation and the flexibility and power of interaction with the UNIX simple-tools-work-together style. Which is a very good style. In fact it is a very clever hierarchical design.
Another reason is that the database thing would also have some other drawbacks. The slowness of make is part to scanning the file hierarchy. On the other hand this allows to add or delete components in an easy way. A database solution would insist of registring new items and eventually be more complicated to use here.
My objection to autoconf is mostly license based. The whole autoconf/automake/libtool toolchain is an impressive one, but it is inheritently bound to the GPL. If we ever want a true free BSD, we have to think of an alternative. But as with the system compiler, we have other, more important work to tackle with limited resources right now.
Ok, they had me up until the bit about having to build the tools in python.
As far as I understand ("scriptable from python") they want to be able to run it from python.
What I am more surprised about is to see Chris DiBona on the referee board.
He worked on the "Open Sources" book and is the leading PR guy of VA Linux (for a bad example of his advocacy style listen to this interview). But there it ends. He is certainly not picked because he is an expert of tool design.
Really ? Well, I sent them an e-mail over 3 weeks ago, but never got anything back. On all the bugreports I wrote them: nothing but their automated response. They are quite incommunicado and I find it impossible to get in.
First, I exactly know how you feel, as I was very pissed about getting no answer a year ago. One tends to think "these dorks rejected me without no explanation" or similiar. However I tried a second time last winter and this time managed to join. Looking from the other side of fence, the situation looks a bit differently.
There is a bunch of people trying to improve the codebase itself. However these are volunteers mostly.
Can't say I cared much about the internal structures yet (like most seem to do I have a day job and thus not too much free time, it is bad enough I am addicted to/.:), so don't take the following as 100% true:
The administrative work, like handling applications is done by probably two people. And those tend to be pretty much overloaded with work.
So it is quite likely that your mail is in the queue still.
Regarding your bugs, I can't tell you definitive wisdom either (as I had not come to watch what happens with incoming bugs), but my guess is that they go into an internal mailing list and are picked up by volunteers as well.
In short: Try again and keep those patches incoming. (Send me private mail and I try to find out what happened to them)
It is rather a case of bad PR than mischief or arrogance.
The tragic thing is, unless you're really good, you'll find yourself flipping burgers at 50 after having worked at a string of temporary trash post-doc jobs. YOu have to got to really love physics in order to put up with that. And the bar that defines "really good" keeps moving higher each year.
Nobody forces people to do PhDs or to pursue even more. Then leave after graduation and go for a job with physics involved and be it in the domain of engineering.
The "really good" mark might be high, but I experienced the case too that being at the right place at the right time with the right people, 4 and more publications a year plus good presentational skills do the job to get knighted er.. professored.
Albert Einstein did such great work, because he managed to recognize important physical principles.
Even his most abstract contribution, general relativity, was led first by physical insight. As legend goes he sent his friend Marcel Grossmann (a mathmatician) to the library to go looking for a theory with this and that property (which were implied by the principles he got in mind), upon where he returned with Riemann's differential geometry, the mathematical theory to formulate general relativity.
What are the important principles today?
What should a friend look out for, if I sent him to the library?
Is it possible that we just have not the luck Einstein and Grossman had with Riemann, Gauss and other great mathematicians who already created the proper powerful framework?
Isn't it amazing, that something far fetched like general relativity has an every day use (GPS)? Do you imagine any application that involves the physics of weak and strong interaction?
However I doubt that anyone I know studied physics because he/she thought he/she could base a career on it. They do because they want to learn physics and hope to get some job somehow.
Thanks mainly to the shortage in information technology, many (me too) manage to get a job outside physics. (What does a real physicist create? More physicists..:)
We should be thankful for this, because too many physicists with no job and too much time on their hands are not good (think russian nuclear scientists here:)
Funny, my company just got new filtering software and I no longer can look at www.l0pht.com or www.2600.com. They are filtered as "criminal activity" sites. But I use to read these sites to get the information on how to secure my systems better. But at least I can see these sites at home.
The PHBs at my company installed such a package too, recently (Elron Internet Manager).
I did a bit of research, mostly because I am annoyed that they notified us about that we get monitored while not telling us what information is gathered and who gets access to it. Anyways, the interesting bit is this technology pretty much looks like derived from underground technology:
The monitoring is done by passivley snooping traffic and analyzing packet content. A large variety of reports/profiles is calculated from it.
The blocking function I believe is realized by using an IP spoofing technique, sending a blocking notice to the user posing as the original host. At least I can't spot any connection between the software and the firewall, so that's my explanation, without wasting more time on analysis.
For everything bad said about Mr. Stallman, at least he has respect for others.
Come on. Let's keep the Linux-BSD competition a friendly sportive one, it should not been carried out at the personal level.
Anyways thanks for that RMS story. By the way, he does not crumble to dust if brought in contact with BSD, as this link from an Australian Unix user group meeting proofs.:-)
Here is the caption: Peter Wemm trying to convince Stallman to adopt the Berkeley Licensing conditions. You'll notice (but not recognize) that Stallman is holding a FreeBSD CD-ROM set in his right hand. It obviously doesn't taste as good as the Australian wine in his left hand.
I think ethernet would have been a better peripheral bus choice. It's already a platform independent standard. Ethernet controllers have already shrunk to single chip solutions (10/100Base-T PCI cards for less than $10! So don't say it's expensive.)
The Java crowd would love it. Finally they could do systems programming without having to grok pointers..:-)
Apparently, the XFree developer fear that people start looking at their development sources.
Nah. I joined the team recently and have not seen anything that won't show up in a release later.
To be honnest I don't really know why the project is run this way. The reason that would make most sense to me is that this is related to meeting certain requirements of graphics board/chip manufacturers to get them to disclose information. There is a mad competition going on in that area and thus lot of paranoia.
A related reason could be that manufacturers fear bad reputation from betas not working well with their cards. I somewhat doubt that, because today in our community only bad specs give really bad reputation.
Of course there might be historic reasons for it as well. I remember vaguely some comments that the project had to put shields up when some external influence became too disturbing. Maybe some vet knows.
I would like XFree86 to open up more, if possible. Related projects like Mesa and glx have had a good result while being open. In fact the new DRI project has been placed on purpose outside of the XFree86 realm to allow more people to participate (I know several folks who don't work on XFree86 because of the closed nature).
The requirements for members are acceptable, so if that closedness is still required for dealing with the industry, another improvement to the present situation would be clear rules who can join and who can not, if such can be formulated. This would take away some arbitrariness from the brotherhood.:)
Who really believes that the success of Linux is due to the GPL? I am not. There is no reason to believe that his kernel project would have grown much different, if he used a BSD/XFree86 style license.
I would really like to see such a Slashdot poll
I bought BSD/Linux because
it is cool
my friends got it
it runs stable
it runs stable and comes with source
it runs stable and comes with source under GPL
it runs stable and comes with source under BSD license
Hemos uses it
My personal guess is that only those who actually program might rank the type of open source license so high that it influenced their decision. And these are a minority, I believe, maybe ranking in the ten thousands but not in the millions.
Interesting, I would have expected both operating systems to perform similiar.
What graphics cards are they equipped with?
In case of Matrox G200/G400 you can try to build a recent glx version from openprojects.net yourself, as it is more advanced in respect to these cards than the version I based the FreeBSD port on. (Lack of a Matrox card and end-of-year-project-craze has prevented me from updating it yet).
Then there seems to be some sort of AGP support added to Linux in the meantime. Don't how know much impact it has there, however.
Slashdot Mirror
We've really got two things here.
No, I am not talking revision control repository here. I am talking moving towards a representation that is a bit further down the road of compilation.
Obviously it is possible to represent a programm on many different stages:
If we treat each translation step as a mapping between representations, I can draw the compilation process this way:
1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7
In fact not all mappings are one way (loosing information) but are (or could be made) bijective
1 <-> 2 <-> 3 -> 4 -> 5 -> 6 -> 7
I now suggest focussing more on the programm in representation around stage 3. Why?
Because this is the representation in terms of the language, on that for example the compiler works on for code generation.
And I am not thinking just compilation here. I am more thinking turning the collection of sources into a database of things more understood, e.g. program related units, like classes, functions, macros, ..
Take Emacs for example. Press Esc-x and then spc and you get a listing of all available functions. The Emacs kernel "knows" of all its functions. Compare that to grepping a deep C/C++ source tree for some function. That grepping should be replaced by a more appropriate query on a more appropriate database. (Like that Esc-x spc sequence is a query on the dumped Emacs kernel).
If the source has changed, you are going to have to rebuild the output anyway. If the original has not changed, you can just use the object file from revision control. What is the point?
Not every change to source would result in a complete rebuilding of the internal structures. Some mechanism like the access optimzation found in relational databases had to decide if the whole has to be rebuild, or if only parts have to be changed. This is certainly one of the hard parts.
Now, I suppose you could argue that you don't always need to recompile an entire source file; you may have changed just one function. But to know that, the compiler is going to have to do a source analysis of it anyway.
If I edit on the text stage you are right. Possibly most changes will result in a new translation. If I edit on the language stage ("add a function", "delete that class") not necessarily.
I am sure there is a lot to learn from those old systems. :)
(Why some of the VMS guys inflicted Windows NT on us is a different thing
That we seem to have lost some features as well and did not progress only, shines through in the hacks and rants of great hackers like Richard Stallmann and Jamie Zawinski. Take this quote
Back before the current dark ages began, I hacked on Lisp Machines. (..)
Have you ever wondered why we're stuck with crap like Unix and MS-DOS? Read Richard Gabriel's Worse is Better paper for a great explanation of why mediocrity has better survival characteristics than perfection
from Jamie's page and this quote from Richard
Yes, with string-based interpreters you can represent programs as strings, and you can interpret them as strings, but you can't parse their syntax very easily as strings. In LISP, programs are represented as data in a way that expresses their structure, and allows you to easily do things to the programs that are based on understanding them.
from a recent RMS interview. Both refer to the LISP machines of MIT, which seem to have operated on a higher level program representation than mere strings.
I interpret these rants that todays machines are stronger but dumber in a sense as well.
Question is if one could combine the strengths of both worlds. The higher level representation found in LISP machines and the performance of our present C compiled systems.
Like I tried to explain above, my feeling is that this could be achieved by shifting the primary representation to something closer to the intermediate structures that arise during compilation. It would have indeed similarities to a configuration management system. Adding a line to a text source would, after check-in, result in an immediate update of an persistent parse tree of the program database core.
OpenVMS compilers and the linker can be invoked to operate on CMS objects without having to pre-fetch anything first.
Do you have any reference where I can read more about CMS? (I would be happy also to have some nice review on the strengths of the LISP machines)
If we were to implement something like this for ourselves I'd say the first thing to do is to find a lightweight, fast and efficient implementation of an object repository. Does anyone know of such?
Sounds to me like what OODBs are promising. The one I had to try so far (POET 3 under Win32 and Solaris) was horrible. No idea how they perform today, as they seem to be two major revisions farther.
Here is the one I meant (HTML, PS, ASCII)
I suggest to have a look at this article on the problems with recursive makefiles.
PMake - A Tutorial
Adam de Boor
If there's a missing requirement in the rules of the contest, it's the lack of a migration path from make. Without that, you just have an interesting toy, because no one will move their existing significant system without it.
Important point!
If you have a "database" that also can organize chunks of arbitrary data in a tree structure, but is so much faster than ext2 at this that you believe it should be built into programs... why not wrap a filesystem driver around it and build it into every program at once?
Your're right, I was not thinking of arbitrary data when I speak of that "database". I want to exploit features of a certain kind of data, that should be stored efficiently - the intermediate code representation.
We usually store the initial representation of the program (the source) and the final representation (object files, executables, libs..) but throw away the intermediate representations that compilers, assemblers and linkers calculate time and time again.
For a few cases we keep that intermediate representations. Precompiled headers are an example of an intermediate result that is kept near the beginning of the translation chain, template repositories (used in AT&T's cfront derived C++ compilers) are an example near the end.
What I thought of is similiar to one of those relational databases in that the focus shifts from the raw input data to the intermediate representation that would be kept as a whole.
Let's say the running core would consist not of a collection of files of characters but of datastructures that are more suited for compilation, typically of a forest of parse trees and related intermediate information for the whole project.
One could import/export sources from that core, and the compilation process would be a special kind of query that exports binaries from that core.
More global optimization strategies would be possible because the compilation proceeds on the whole project, not only single compilation units as normal compilers do.
The trouble with template instantiation would be gone.
But, yes now comes the but :-), such a system is certainly complicated. I had a lot of fun with precompiled headers and template repositories in the past. So I assume it is not easy to write them in a way that they work flawlessly.
That is a stupid remark, especially the time argument. Both cultures have excellent results, are fruitful to each others and are likely to stay with us for a while.
The lack of a BSD compiler is the result of no one interested enough so far in writing one. Not more not less. No reason why this could not change one day.
Thanks a lot!
Replace make?????
These are robust, time-tested tools for creating software. If a better way existed to manage projects we (programmers in general) would probably have it by now.
I was just recently a member of a team that converted a very large project from Microsoft's hideous Visual Studio project (.dsp) files to autoconf, automake, and make. Why was this done? Because it's easier to use, more flexible (try telling MSVC to run lex and yacc and then compile the output files, using only .dsp files! HA!), and opens the program up to porting to other platforms.
First, I completely agree with you that project configuration through MS Developers Studio projects is inferior to UNIX style configuration.
I had many fruitless discussions about this with some of my collegues (sigh). For some reason it is seems nearly impossible to convince people with a DOS/Windows background that the complicated make syntax is less a PITA than the fact that a myriad of parameters is hidden behind various corners of the MS Dev Studio graphical user interface.
My theory is that UNIX people love ASCII representations while the Windows crowds loves roaming GUIs. No idea why. But believe it or not there are people who for example can memorize an astounishing list of key/value pairs from the NT registry.
On the other hand one must admit, that it is hard to understand make without being familiar with the way the basic UNIX tools (awk, sed, grep, sh..) interact in the more complex make files.
My objection against make is not it's complicated syntax (which is only complicated because different levels of parsing - make's and sh's - intermix and regular expressions need a bit familiarity), but that it is slow.
This is not a failure of make itself but because of the way we traditionally organize programms into files and directories. In fact we use the filesystem as database, and query this database by giving paths.
I would expect a speed up, if we would move away from that organization into some kind of program database. A database that is very close to the semantics of the used programming language. Like a database of classes, makros, functions, globals etc So I expect that it would be possible to improve the speed of a make dependency aware construction tool in such a environment.
It would also solve some issues with C++ (especially template resolution).
However I have not seen a move away from that traditional C style project break up, compilation and linking to something which more resembles a database with tools on it yet.
Possibly because it would give up many benefits, the most obvious ones the ASCII representation and the flexibility and power of interaction with the UNIX simple-tools-work-together style. Which is a very good style. In fact it is a very clever hierarchical design.
Another reason is that the database thing would also have some other drawbacks. The slowness of make is part to scanning the file hierarchy. On the other hand this allows to add or delete components in an easy way. A database solution would insist of registring new items and eventually be more complicated to use here.
My objection to autoconf is mostly license based. The whole autoconf/automake/libtool toolchain is an impressive one, but it is inheritently bound to the GPL. If we ever want a true free BSD, we have to think of an alternative. But as with the system compiler, we have other, more important work to tackle with limited resources right now.
As far as I understand ("scriptable from python") they want to be able to run it from python.
What I am more surprised about is to see Chris DiBona on the referee board.
He worked on the "Open Sources" book and is the leading PR guy of VA Linux (for a bad example of his advocacy style listen to this interview). But there it ends. He is certainly not picked because he is an expert of tool design.
Anyone knows about the other referees?
First, I exactly know how you feel, as I was very pissed about getting no answer a year ago. One tends to think "these dorks rejected me without no explanation" or similiar. However I tried a second time last winter and this time managed to join. Looking from the other side of fence, the situation looks a bit differently.
There is a bunch of people trying to improve the codebase itself. However these are volunteers mostly.
Can't say I cared much about the internal structures yet (like most seem to do I have a day job and thus not too much free time, it is bad enough I am addicted to /. :), so don't take the following as 100% true:
The administrative work, like handling applications is done by probably two people. And those tend to be pretty much overloaded with work.
So it is quite likely that your mail is in the queue still.
Regarding your bugs, I can't tell you definitive wisdom either (as I had not come to watch what happens with incoming bugs), but my guess is that they go into an internal mailing list and are picked up by volunteers as well.
In short: Try again and keep those patches incoming. (Send me private mail and I try to find out what happened to them)
It is rather a case of bad PR than mischief or arrogance.
If they could just do with less dimensions..
I'd prefer Richard Feynman's "QED Theory of Light and Matter", which is adding amplitudes for the layman.
Nobody forces people to do PhDs or to pursue even more. Then leave after graduation and go for a job with physics involved and be it in the domain of engineering.
The "really good" mark might be high, but I experienced the case too that being at the right place at the right time with the right people, 4 and more publications a year plus good presentational skills do the job to get knighted er.. professored.
Even his most abstract contribution, general relativity, was led first by physical insight. As legend goes he sent his friend Marcel Grossmann (a mathmatician) to the library to go looking for a theory with this and that property (which were implied by the principles he got in mind), upon where he returned with Riemann's differential geometry, the mathematical theory to formulate general relativity.
Do you imagine any application that involves the physics of weak and strong interaction?
However I doubt that anyone I know studied physics because he/she thought he/she could base a career on it. They do because they want to learn physics and hope to get some job somehow.
Thanks mainly to the shortage in information technology, many (me too) manage to get a job outside physics. (What does a real physicist create? More physicists.. :)
We should be thankful for this, because too many physicists with no job and too much time on their hands are not good (think russian nuclear scientists here :)
Where is the link to the .mp3? :)
I wonder when I will see a Mac styled by Jean Paul Gautier, Donna Karan, Karl Lagefeld or Kenzo. :-)
Maybe one that smells nice too.. :-)
The PHBs at my company installed such a package too, recently (Elron Internet Manager).
I did a bit of research, mostly because I am annoyed that they notified us about that we get monitored while not telling us what information is gathered and who gets access to it. Anyways, the interesting bit is this technology pretty much looks like derived from underground technology:
Come on. Let's keep the Linux-BSD competition a friendly sportive one, it should not been carried out at the personal level.
Anyways thanks for that RMS story. By the way, he does not crumble to dust if brought in contact with BSD, as this link from an Australian Unix user group meeting proofs. :-)
Here is the caption:
Peter Wemm trying to convince Stallman to adopt the Berkeley Licensing conditions. You'll notice (but not recognize) that Stallman is holding a FreeBSD CD-ROM set in his right hand. It obviously doesn't taste as good as the Australian wine in his left hand.
For those who still don't know, read this link.
The Java crowd would love it. Finally they could do systems programming without having to grok pointers .. :-)
Nah. I joined the team recently and have not seen anything that won't show up in a release later.
To be honnest I don't really know why the project is run this way. The reason that would make most sense to me is that this is related to meeting certain requirements of graphics board/chip manufacturers to get them to disclose information. There is a mad competition going on in that area and thus lot of paranoia.
A related reason could be that manufacturers fear bad reputation from betas not working well with their cards. I somewhat doubt that, because today in our community only bad specs give really bad reputation.
Of course there might be historic reasons for it as well. I remember vaguely some comments that the project had to put shields up when some external influence became too disturbing. Maybe some vet knows.
I would like XFree86 to open up more, if possible. Related projects like Mesa and glx have had a good result while being open. In fact the new DRI project has been placed on purpose outside of the XFree86 realm to allow more people to participate (I know several folks who don't work on XFree86 because of the closed nature).
The requirements for members are acceptable, so if that closedness is still required for dealing with the industry, another improvement to the present situation would be clear rules who can join and who can not, if such can be formulated. This would take away some arbitrariness from the brotherhood. :)
I would really like to see such a Slashdot poll
I bought BSD/Linux because
My personal guess is that only those who actually program might rank the type of open source license so high that it influenced their decision. And these are a minority, I believe, maybe ranking in the ten thousands but not in the millions.
What graphics cards are they equipped with?
In case of Matrox G200/G400 you can try to build a recent glx version from openprojects.net yourself, as it is more advanced in respect to these cards than the version I based the FreeBSD port on. (Lack of a Matrox card and end-of-year-project-craze has prevented me from updating it yet).
Then there seems to be some sort of AGP support added to Linux in the meantime. Don't how know much impact it has there, however.