I do think The World Would Be A Better Place if all software companies released older code so users still interested could work with it or learn from it. (I'm not holding my breath, though)
It is a graceful way to end development.
Imagine they would have done it during Apple ][ times. A whole game culture is only available today as memory images with questionable legal status.
Another culture vanishing is OS/2. Hope IBM will decide to release their sources one day.
The simple answer is, very similar in most ways, but that really doesn't tell you much. I'll instead mention some of the most obvious differences.
Don't forget some important non-technical features:
structure of development
license
support
For Linux you get without doubt much more commercial support (books, magazines, products) right now than for FreeBSD, so it might be better suited for people who just want to escape Windows or simply want to use the system.
This does not mean that you are on your own with FreeBSD, the contrary is the case, the various (international and national) mailing lists offer great support and there are people who offer contracting.
For developers however, FreeBSD has the advantage of a true free license (you can basically do anything with the source except suing or claiming credit - no strings attached) and a very sane development structure, which covers the system as a whole and not just as kernel plus additions.
I agree, the increased load argument seems not valid. The added load of the indexer updating his index is likely to be less than the combined load of the people that use the index who otherwise would look directly at Ebay.
The driver that has been offered on the nvidia site for some time now is based on a pre august snapshot of the openprojects glx. The changes are mostly included in the present version. So it is more or less old stuff now.
The nvidia specific part has not been touched except for some adjustment to later XFree86 changes regarding the card IDs. But the other stuff (and of course the Matrox specific things) have been improved.
XFree86 will have direct rendering (DRI) and indirect rendering (glx). Here I expect the hardware drivers of the free glx to be integrated and the glx protocol stuff to be replaced by the SGI implementation. But who knows for sure.
I was under the impression that glx could also write directly to video memory, bypassing the X server. That's why you can't take screenshots of it using a standard X screen grabber.
It cooperates with the X server.
I was able to make nice screenshots using good old xv on my FreeBSD system. Pulsar shows some fps (K6-300).
Note that glx is the OpenGL over X protocol, meant primarily to allow an OpenGL app running on host A to draw on another host B. X is a network GUI after all!
Thus you have the X protocol overhead. This is called indirect rendering in contrast to direct rendering where a client app is running on the same host as the display server. This is expected to be quite faster, and was demonstrated at SIGGRAPH in an early stage.
This so called DRI is targeted for XFree86 4. See my message above, where I posted a link to a diagramm at p.i., that shows both situations.
Linux just plain outperforms, outscales, and blows SGI IRIX machines out of the water.
I love to emphasis that FreeBSD was used for rendering The Matrix. But let's face it, in both films mentioned, the free operating systems just delivered raw muscle, not the brains (ie acted as rendering farms).
The higher level modeling and control still seems to be a job for SGIs.
Present stuff gets nice and already is sufficient for certain modelling needs, but we are not state of the art.
Given NVIDIA's gradual back pedalling on open source I have my doubts... first the open source opengl without documentation, then the closed source (obfuscated) object oriented low level API.
I am not completely sure what is going on in their minds.
They seem to want to harvest the free developer resources from the net at one hand, but on the other hand seem to fear to give away too much secrets to their competition by opening up completely (it is an incredibly competetive market after all).
It is also possible that they don't supply register level stuff, because they fear us to produce crappy drivers, hurting the brand name.
The material released so far and updated this month is something more high level, that also provides uniform access along several NV chip generations. Could be the reason why the traditional hardware freaks did not pick it up so far.
My TNT2 Ultra has worked nicely for some months now (since this summer), thank you very much. There's a fully open source (GPL iirc) driver built around Mesa and SGI's GLX.
Nope, the glx that is out and works with nvidia cards (and even better with Matrox ones) is not the SGI one but an open effort - albeit a prominent team member is a SGI employee.
However the upcoming DRI stuff for XFree86 4 is based on a newer glx implementation (we are talking OpenGL over X protocol now) by SGI. At present it is expected that only the hardware driver stuff of the openproject.net glx will make it into XF4 - but who knows.
Are they actually developing their own OpenGL implementation for linux? I don't think they're really creating a ICD for Linux since isn't that a windows term?
You are right, the buzzword to watch for in case of X is DRI.
See this diagramm for what to expect. (There is also a less detailed and a poster sized version in the parent directory).
Walnut Creek had a daemon "hostess" in the booth for the first time.
Pictures! Pictures! Pictures!:)
Re:Pascal / Porting between the BSDs
on
FreeBSD at COMDEX
·
· Score: 3
Bloody good idea, Brian!
When I noticed it first, it was aesthetically very pleasing to see that you have managed to dynamically link those two BSD source trees.
I am not sure about the implications of this approach, yet. Made me wonder if that is the way a future united BSD source tree will look like. Not one single organization, but a tree distributed over 3 or more focal sites, that specialize in some aspect of the grand system.
Indeed it is interesting that Java stucks to C++ rather than Pascal. Java shares some aspects with the Pascal successor Oberon.
Re:What ever happened to the Unix Pascal system?
on
FreeBSD at COMDEX
·
· Score: 2
Ayahhh! You have hit upon a story, that is the root of so many. The UCSD pascal/p-system was ported to micros early on, and I learned how to program on an Apple II using it. Wow, it was great.
Those of use who know this, or those who know Emacs know that Java byte code is an old trick. (Possibly there are even older virtual machine systems)
By the way. Behind Apple's UCSD Pascal was Bill Atkinson, a guy who later worked on the QuickDraw stuff on the Mac (that was a Pascal machine in it's early days) and who might have worked on that MacDraw application. What has become of him? I am not sure if I saw him mentioned as someone having a share in Silicon Graphics, lately. Anyone knows more?
Anyway, the UCSD p-system was licensed by a company called Pecan, and my lab at one time (1987?) had a copy to run on our 286. But Borland TurboPascal came out with their IDE around that time and it blew the p-system away in terms of performance, so we never returned to those idyllic days. I don't know what happened to Pecan or the p-system for micros after that. Arguably the first victims of the octopus from Redmond...
Sure, Turbo Pascal impressed with it's speed, when it came out. But for my friends and me, there was another reason why we (hey we were in high school, having not much money) bought it: Turbo Pascal was very cheap (around $100) in relation to its features and came with a nice doumentation. It would have been a disgrace to pirate such an offer.
In fact we stopped buying it, when it become more and more Windows focussed, and reaching a $500 limit. I personally changed to the emx port of gcc for OS/2 and later on university, stuck to the Unix versions.
So you could say, in a sense, that Borland also became a victim of Redmond, when it had to concentrate on Windows, but never had the same chance to offer adequate support for it.
Re:What ever happened to the Unix Pascal system?
on
FreeBSD at COMDEX
·
· Score: 2
FWIW, gpc isn't the same thing as the old Berkeley pi/pc/pix that Tom was talking about. I believe gpc is a totally new development, and it sits on the gcc backend.
You are right, it is a new development that uses gcc as backend. In fact you need a gcc source tree, add the gpc source tree, use a fitting diff from p/diff to integrate or better say patch gpc into gcc and do the usual configure/make incantations. In between you perform some FreeBSD specific patches (I am very happy that it is possible to put all this knowledge into a nice handy FreeBSD port)
The gpc is still alpha and has bugs, but personally it was already useful for me, as I use it to develop the homework for a computer science course on imperative programming, where Pascal is required as language.
The gpc folks work on covering standard Pascal as well as the glorious Turbo Pascal dialect of the past.
Actually, I hate Pascal too, so what I would do was write the assignments in C under BSD
I personally first learned Basic on an Apple ][ then 6502 Assembler with Big Mac/Merlin and then Pascal with UCSD Pascal and later Kyan Pascal. Then came Forth, then Turbo Pascal for CP/M and the for the IBM PC which was good enough for several years until I hit C++ in 1990 and then Java in 1996. With C++ still my favourite language. (Perl is not bad either)
This learning history also represents an increasing order of difficulty. Pascal is certainly easier to grasp and less mighty than C or C++. And therefore suited for teaching programming.
Pascal also suffered from the facts that it has never evolved as nicely as has C into C++ (and Java to some degree). Not to forget the admirable effort by Bjarne Stroustup to forge the ISO C++ Standard. That was certainly sucking work, but he did it.
When Pascal creator Nikolaus Wirth once came from ETH Zurich to give a talk on his Oberon language at the RWTH Aachen, I annoyed him with my opinion, that Pascal had no worthy successor.:-)
Please make sure the openbsd people get it, too. Any idea how much difficulty it is to cross-port between the two? My guess is that it's trivial. Yes if that were true, you'd think we'd see more ports than we do.
Sure, it will be much more easier than porting from Linux. I just installed openssh on my box - the first FreeBSD port I ever saw, that fetches not some tarball somewhere but does an anonymous CVS checkout from OpenBSD.org's tree. Wow.
Indeed I feel great sympathy and admiration for the other BSD projects and would love to make it cross BSD. My problem is tracking the differences and testing.
Example: In theory, I already put in OpenBSD and NetBSD support for another project I work on, the CD Index client. This was attempted by studying the man pages from these systems, that are available on the German FreeBSD web server. But I never tested it out so far, because I simply have no machine running OpenBSD or NetBSD or access to one.
Even if I had a second box running OpenBSD for example, I doubt somewhat, that I would follow development here as closely, as I would for FreeBSD. It is just a matter of personal preference and limited time resources.
So I believe the various projects should hold test accounts ready for volunteers from the other projects who are willing to test and adapt their stuff, but who are not willing or able to keep up a test system themselves. I would be very happy to get such a opportunity, as ported software seems better to me in the sense that it forces one to better program organization. Maybe one of the reasons why usually UNIX software is of good quality.
Re:What ever happened to the Unix Pascal system?
on
FreeBSD at COMDEX
·
· Score: 2
See this?:-)
marc@oranje$ gpc -v Reading specs from/usr/ports/lang/gpc/inst2/lib/gcc-lib/i386-unknown -freebsd4.0/2.8.1/specs gpc version 19991030, based on gcc-2.8.1 marc@oranje$
If you need it badly, send me a mail. Otherwise have a bit of patience until I submit it to the ports people.
Slashdot Mirror
It is a graceful way to end development.
Imagine they would have done it during Apple ][ times. A whole game culture is only available today as memory images with questionable legal status.
Another culture vanishing is OS/2. Hope IBM will decide to release their sources one day.
Don't forget some important non-technical features:
For Linux you get without doubt much more commercial support (books, magazines, products) right now than for FreeBSD, so it might be better suited for people who just want to escape Windows or simply want to use the system.
This does not mean that you are on your own with FreeBSD, the contrary is the case, the various (international and national) mailing lists offer great support and there are people who offer contracting.
For developers however, FreeBSD has the advantage of a true free license (you can basically do anything with the source except suing or claiming credit - no strings attached) and a very sane development structure, which covers the system as a whole and not just as kernel plus additions.
Right now you would have to compare two boxes with the same RIVA or 3dfx card each to test for OS specific differences.
I agree, the increased load argument seems not valid. The added load of the indexer updating his index is likely to be less than the combined load of the people that use the index who otherwise would look directly at Ebay.
Pardon? Both press blurb and HP page use HTTP just as analogon. Hope the pdf file on the HP page has a bit more meat.
marc@oranje$ cd /usr/compat/linux/proc/ ./ ../
marc@oranje$ ll
total 3
dr-xr-xr-x 2 root wheel - 512 Feb 6 1996
drwxr-xr-x 17 root wheel - 512 Dec 2 02:08
-rw-r--r-- 1 root wheel - 318 Aug 17 23:37
meminfo
marc@oranje$ cat meminfo
total: used: free: shared: buffers: cached:
Mem: 131194880 128024576 3170304 32817152 2682880 82337792
Swap: 131567616 6393856 125173760
MemTotal: 128120 kB
MemFree: 3096 kB
MemShared: 32048 kB
Buffers: 2620 kB
Cached: 80408 kB
SwapTotal: 128484 kB
SwapFree: 122240 kB
marc@oranje$
You should have posted with e-mail, so I would have sent you this hint.
The nvidia specific part has not been touched except for some adjustment to later XFree86 changes regarding the card IDs. But the other stuff (and of course the Matrox specific things) have been improved.
XFree86 will have direct rendering (DRI) and indirect rendering (glx). Here I expect the hardware drivers of the free glx to be integrated and the glx protocol stuff to be replaced by the SGI implementation. But who knows for sure.
Locking is addressed in one of the p.i. papers, can't judge their scheme at present however.
It cooperates with the X server.
I was able to make nice screenshots using good old xv on my FreeBSD system. Pulsar shows some fps (K6-300).
It hasn't hurt Matrox, that they released nice specs so that a lot of people, including John Carmack got interested to hack a driver.
It was pre-processed to obfuscate it.
Thus you have the X protocol overhead. This is called indirect rendering in contrast to direct rendering where a client app is running on the same host as the display server. This is expected to be quite faster, and was demonstrated at SIGGRAPH in an early stage.
This so called DRI is targeted for XFree86 4. See my message above, where I posted a link to a diagramm at p.i., that shows both situations.
I love to emphasis that FreeBSD was used for rendering The Matrix. But let's face it, in both films mentioned, the free operating systems just delivered raw muscle, not the brains (ie acted as rendering farms).
The higher level modeling and control still seems to be a job for SGIs.
Present stuff gets nice and already is sufficient for certain modelling needs, but we are not state of the art.
I am not completely sure what is going on in their minds.
They seem to want to harvest the free developer resources from the net at one hand, but on the other hand seem to fear to give away too much secrets to their competition by opening up completely (it is an incredibly competetive market after all).
It is also possible that they don't supply register level stuff, because they fear us to produce crappy drivers, hurting the brand name.
The material released so far and updated this month is something more high level, that also provides uniform access along several NV chip generations. Could be the reason why the traditional hardware freaks did not pick it up so far.
Nope, the glx that is out and works with nvidia cards (and even better with Matrox ones) is not the SGI one but an open effort - albeit a prominent team member is a SGI employee.
However the upcoming DRI stuff for XFree86 4 is based on a newer glx implementation (we are talking OpenGL over X protocol now) by SGI. At present it is expected that only the hardware driver stuff of the openproject.net glx will make it into XF4 - but who knows.
You are right, the buzzword to watch for in case of X is DRI.
See this diagramm for what to expect. (There is also a less detailed and a poster sized version in the parent directory).
Have not read about this on glx-dev or xfree86-dev yet either.
Pictures! Pictures! Pictures! :)
When I noticed it first, it was aesthetically very pleasing to see that you have managed to dynamically link those two BSD source trees.
I am not sure about the implications of this approach, yet. Made me wonder if that is the way a future united BSD source tree will look like. Not one single organization, but a tree distributed over 3 or more focal sites, that specialize in some aspect of the grand system.
Indeed it is interesting that Java stucks to C++ rather than Pascal. Java shares some aspects with the Pascal successor Oberon.
Those of use who know this, or those who know Emacs know that Java byte code is an old trick. (Possibly there are even older virtual machine systems)
By the way. Behind Apple's UCSD Pascal was Bill Atkinson, a guy who later worked on the QuickDraw stuff on the Mac (that was a Pascal machine in it's early days) and who might have worked on that MacDraw application. What has become of him? I am not sure if I saw him mentioned as someone having a share in Silicon Graphics, lately. Anyone knows more?
Anyway, the UCSD p-system was licensed by a company called Pecan, and my lab at one time (1987?) had a copy to run on our 286. But Borland TurboPascal came out with their IDE around that time and it blew the p-system away in terms of performance, so we never returned to those idyllic days. I don't know what happened to Pecan or the p-system for micros after that. Arguably the first victims of the octopus from Redmond...
Sure, Turbo Pascal impressed with it's speed, when it came out. But for my friends and me, there was another reason why we (hey we were in high school, having not much money) bought it:
Turbo Pascal was very cheap (around $100) in relation to its features and came with a nice doumentation. It would have been a disgrace to pirate such an offer.
In fact we stopped buying it, when it become more and more Windows focussed, and reaching a $500 limit. I personally changed to the emx port of gcc for OS/2 and later on university, stuck to the Unix versions.
So you could say, in a sense, that Borland also became a victim of Redmond, when it had to concentrate on Windows, but never had the same chance to offer adequate support for it.
You are right, it is a new development that uses gcc as backend. In fact you need a gcc source tree, add the gpc source tree, use a fitting diff from p/diff to integrate or better say patch gpc into gcc and do the usual configure/make incantations. In between you perform some FreeBSD specific patches (I am very happy that it is possible to put all this knowledge into a nice handy FreeBSD port)
The gpc is still alpha and has bugs, but personally it was already useful for me, as I use it to develop the homework for a computer science course on imperative programming, where Pascal is required as language.
The gpc folks work on covering standard Pascal as well as the glorious Turbo Pascal dialect of the past.
Actually, I hate Pascal too, so what I would do was write the assignments in C under BSD
I personally first learned Basic on an Apple ][ then 6502 Assembler with Big Mac/Merlin and then Pascal with UCSD Pascal and later Kyan Pascal. Then came Forth, then Turbo Pascal for CP/M and the for the IBM PC which was good enough for several years until I hit C++ in 1990 and then Java in 1996. With C++ still my favourite language. (Perl is not bad either)
This learning history also represents an increasing order of difficulty. Pascal is certainly easier to grasp and less mighty than C or C++. And therefore suited for teaching programming.
Pascal also suffered from the facts that it has never evolved as nicely as has C into C++ (and Java to some degree). Not to forget the admirable effort by Bjarne Stroustup to forge the ISO C++ Standard. That was certainly sucking work, but he did it.
When Pascal creator Nikolaus Wirth once came from ETH Zurich to give a talk on his Oberon language at the RWTH Aachen, I annoyed him with my opinion, that Pascal had no worthy successor. :-)
Please make sure the openbsd people get it, too. Any idea how much difficulty it is to cross-port between the two? My guess is that it's trivial. Yes if that were true, you'd think we'd see more ports than we do.
Sure, it will be much more easier than porting from Linux. I just installed openssh on my box - the first FreeBSD port I ever saw, that fetches not some tarball somewhere but does an anonymous CVS checkout from OpenBSD.org's tree. Wow.
Indeed I feel great sympathy and admiration for the other BSD projects and would love to make it cross BSD. My problem is tracking the differences and testing.
Example:
In theory, I already put in OpenBSD and NetBSD support for another project I work on, the CD Index client. This was attempted by studying the man pages from these systems, that are available on the German FreeBSD web server. But I never tested it out so far, because I simply have no machine running OpenBSD or NetBSD or access to one.
Even if I had a second box running OpenBSD for example, I doubt somewhat, that I would follow development here as closely, as I would for FreeBSD. It is just a matter of personal preference and limited time resources.
So I believe the various projects should hold test accounts ready for volunteers from the other projects who are willing to test and adapt their stuff, but who are not willing or able to keep up a test system themselves. I would be very happy to get such a opportunity, as ported software seems better to me in the sense that it forces one to better program organization. Maybe one of the reasons why usually UNIX software is of good quality.
marc@oranje$ gpc -v Reading specs from /usr/ports/lang/gpc/inst2/lib/gcc-lib/i386-unknown -freebsd4.0/2.8.1/specs
gpc version 19991030, based on gcc-2.8.1
marc@oranje$
If you need it badly, send me a mail. Otherwise have a bit of patience until I submit it to the ports people.