I have thought long and hard about such a tool (like a Tcl/Tk or Java program) that let you do a kernel build from config to installation but I am not quite certain that the *current* format of LINT would lend itself to that. Maybe if someone went through LINT and created a standard and unified format for the nots and documentation, it would work, but not until then.
WRT to "sooo much hotter," a buyout of an established Unix vendor by a free software vendor has never been done. So BSD would be instantly propelled into the limelight and may be able to chip heavily into Linux's presence just from the mere fact it bought out SCO. Additionally, SCO has a lot of really nice proprietary stuff some of the most highly scalable kernel code ever (read the discussion involving why Beowulf clusters suck for real work above). Plus, if they wanted to, they can keep control of the Tranetella technology allowing them to expand into other markets. And damn, SCO has a huge existing user base.
Microsoft sold Xenix (which Gates wanted nothing to do with) to SCO (which then, in 1979, sold a V6 derivative) in return for a 12% stake in SCO. Xenix later became OpenServer.
I am not treating it like it is nothing. I am treating it realistically. There are things which Beowulf clusters are simply useless for. They are all things which require fine-grained multiprocessing. Beowulf (by design) only supports coarse-grained mutliprocessing. This is why you cannot build a database server around Beowulf. This is also why you can build a 3D render farm around it. SMP will have a place for quite some time. As for the 50th place, that revolves around the fact the Top 500 test uses a lot of linpack routines that simply are coarse-grained. This is done so that fine-grained processors are not at a unique advantage. They may sure as hell be fast, but they are useless for somethings. Kind of like running a GUI on a teletype.
I think you should look at the problem realistically instead of eating the shit you would typically be fed around here. Beowulf clusters built on Linux are not the end-all/be-all of computing. There are real needs and uses for hardware and software of all types and Linux simply doesn't cut it for most if them. Nothing does. This is why we have multiple tools.
You obviously didn't read my post. For most problems, Beowulf simply imposes too much overhead to be cost effective. In fact, power and flexibilty come only with SMP. Beowulf works well for large problems with highly independent calculations. But for most problems and mathematical modelling, using Beowulf only imposes overhead and offers no performance gain and usually a performance loss. You should really learn about such an advanced topic before posting comments which do not make sense.
Also, Beowulf would do notthing for website hosting. SMP could help on the back end if a lot of CGI or database access were involved. But most (nearly all?) websites have bandwidth as the bottleneck. This is why it is perfectly acceptable to use Linux on a webserver. But for a serious database server which will be handling many, many simultaneous queries, Linux is out, use SVR4.
I think this is sarcasm, so I will bite. I never said it was financially sound. I just said it would kick ass. Though, the longer I think about it, the better off both corporations would be.
Any OS can Beowulf cluster. The thing is, genuine SVR4 code can scale like nothing else (well, except Unicos, but that is kind of a specialized product). Solaris, SCO, and others will beat Linux in the scaling arena for quite some time still. Only when Linux can scale reasonably well past four processors (with fine grained control, truth be known, Beowulf is crap and usefull for only a small subset of parallel problems) and hit 64 or 128 with nearly linear speed improvement will commercial SVR4 loose the edge it has in scalability.
Dude, you are a bit out of touch with reality. BSD/OS and FreeBSD are merging. Now, I would like to see the new BSD corporation buy SCO just show who really did win the BSD/SYSV war:)
No, I tried to find out who has the original Altos (I had heard it was still in use, possibly as a dumb terminal somewhere). But I never did find out exactly where it is.
Actually, if you think about it, all commercial Unices are either not based on BSD any more or they all are. SYSV contains a lot of BSD code. Otherwise, there is not commerical Unix (except BSD/OS and they just merged with FreeBSD) that is strictly BSD-like.
However, DEC Unix and BSD are not that similar. At least not in my opinion. Please go into more detail, if you would like.
I don't give a damn about fighting the system. I make money off the system. I think the GPL is going to destroy the software industry for years if it is not stopped. As for these musicians, several of the ones I like have CDs available you may purchase through MP3.com and I have purchased them. You should really do your homework before posting.
While 99% do suck dick, I have still found several dozen songs worth listening too (all from the European region too, maybe coincidence, maybe not). The thing is, the rankings system on MP3.com actually works and the best do float up to the top.
It is not that glib is evil (well, okay, it is, but that is not my objection here). The problem is that it is a small program I am working on and having to pack around a standard C library is not exactly cool. Now, creating a library of those functions I use from the FreeBSD C library is possible and much finer grain control. Which is nice. As for Cosm, interesting concept but I do nto think it will help. I am working with a chat clone (http://www.james-howard.com/display.html?page=par ty.html) and just need some native support. Another problem is the overly complicated license to Cosm (which looks like it is about on par with the Artistic license, correct me if I am wrong). I would also prefer dealing only with BSD licensed programs as far as things I need to ship. I am a bit disturbed that the configure script is GPL'd but I think I can handle that. On the other hand, if I could avoid it, I would. I will not go into the details here, but the GPL is simply morally wrong and I do not wish to support it any more than I have to.
Working with anything other than the standard C libraries is unacceptable, so glib is out. But more to the point, how do I make sure that if I use a construction that say, works on FreeBSD but not on SunOS (in this case, pthreads are a problem) works out all around?
This leads me to an interesting problem. I am developing a program. I am using FreeBSD as my development enviroment but my target environments are BSD/OS, OpenBSD, FreeBSD, SunOS, and possibly UnixWare. Obviously, anything else would be great on top of this. But how does one write code that will compile without problems across so many different architectures and platforms? Is autoconf the way to go? Is there a decent manual on autoconf? The standard documentation that comes with it is a bit lacking in how to make it work with a new project. Ideas?
Let me give a specific example: I am working with a piece of chat software. The software may not be sold commercially. In order to make a minor improvement, I changed it's read command to work with libreadline. DOH! Now my whole program is GPL'd. But wait, I don't even own this program. So I cannot change the license on the chat software. I cannot redistribute this. This sucks and this is a flaw in GPL.
No, really! Even though I am not well versed in kernel design, just flipping through the FreeBSD kernel code will teach you quite a bit about how the system works at a user level. The Design and Implementation of the 4.4BSD Operating System is an excellent resource to have handy when learning to program at the user level in Unix. If you use it, you will have a far greater understanding of how the kernel and libraries are handling the calls you make and you will quickly understand programming more.
Slashdot Mirror
I have thought long and hard about such a tool (like a Tcl/Tk or Java program) that let you do a kernel build from config to installation but I am not quite certain that the *current* format of LINT would lend itself to that. Maybe if someone went through LINT and created a standard and unified format for the nots and documentation, it would work, but not until then.
WRT to "sooo much hotter," a buyout of an established Unix vendor by a free software vendor has never been done. So BSD would be instantly propelled into the limelight and may be able to chip heavily into Linux's presence just from the mere fact it bought out SCO. Additionally, SCO has a lot of really nice proprietary stuff some of the most highly scalable kernel code ever (read the discussion involving why Beowulf clusters suck for real work above). Plus, if they wanted to, they can keep control of the Tranetella technology allowing them to expand into other markets. And damn, SCO has a huge existing user base.
Microsoft sold Xenix (which Gates wanted nothing to do with) to SCO (which then, in 1979, sold a V6 derivative) in return for a 12% stake in SCO. Xenix later became OpenServer.
I am not treating it like it is nothing. I am treating it realistically. There are things which Beowulf clusters are simply useless for. They are all things which require fine-grained multiprocessing. Beowulf (by design) only supports coarse-grained mutliprocessing. This is why you cannot build a database server around Beowulf. This is also why you can build a 3D render farm around it. SMP will have a place for quite some time. As for the 50th place, that revolves around the fact the Top 500 test uses a lot of linpack routines that simply are coarse-grained. This is done so that fine-grained processors are not at a unique advantage. They may sure as hell be fast, but they are useless for somethings. Kind of like running a GUI on a teletype.
I think you should look at the problem realistically instead of eating the shit you would typically be fed around here. Beowulf clusters built on Linux are not the end-all/be-all of computing. There are real needs and uses for hardware and software of all types and Linux simply doesn't cut it for most if them. Nothing does. This is why we have multiple tools.
You obviously didn't read my post. For most problems, Beowulf simply imposes too much overhead to be cost effective. In fact, power and flexibilty come only with SMP. Beowulf works well for large problems with highly independent calculations. But for most problems and mathematical modelling, using Beowulf only imposes overhead and offers no performance gain and usually a performance loss. You should really learn about such an advanced topic before posting comments which do not make sense.
Also, Beowulf would do notthing for website hosting. SMP could help on the back end if a lot of CGI or database access were involved. But most (nearly all?) websites have bandwidth as the bottleneck. This is why it is perfectly acceptable to use Linux on a webserver. But for a serious database server which will be handling many, many simultaneous queries, Linux is out, use SVR4.
I think this is sarcasm, so I will bite. I never said it was financially sound. I just said it would kick ass. Though, the longer I think about it, the better off both corporations would be.
Any OS can Beowulf cluster. The thing is, genuine SVR4 code can scale like nothing else (well, except Unicos, but that is kind of a specialized product). Solaris, SCO, and others will beat Linux in the scaling arena for quite some time still. Only when Linux can scale reasonably well past four processors (with fine grained control, truth be known, Beowulf is crap and usefull for only a small subset of parallel problems) and hit 64 or 128 with nearly linear speed improvement will commercial SVR4 loose the edge it has in scalability.
Dude, you are a bit out of touch with reality. BSD/OS and FreeBSD are merging. Now, I would like to see the new BSD corporation buy SCO just show who really did win the BSD/SYSV war :)
I think it is unfair to suggest that M-Net cannot support itself.
James Howard
M-Net staff
If you could post a link to the Advogato story, I would very much appreciate it. I searched their site and came up empty.
No, I tried to find out who has the original Altos (I had heard it was still in use, possibly as a dumb terminal somewhere). But I never did find out exactly where it is.
These things have been around for several years and I think Slashdot has done this story before.
Actually, if you think about it, all commercial Unices are either not based on BSD any more or they all are. SYSV contains a lot of BSD code. Otherwise, there is not commerical Unix (except BSD/OS and they just merged with FreeBSD) that is strictly BSD-like.
However, DEC Unix and BSD are not that similar. At least not in my opinion. Please go into more detail, if you would like.
I don't give a damn about fighting the system. I make money off the system. I think the GPL is going to destroy the software industry for years if it is not stopped. As for these musicians, several of the ones I like have CDs available you may purchase through MP3.com and I have purchased them. You should really do your homework before posting.
While 99% do suck dick, I have still found several dozen songs worth listening too (all from the European region too, maybe coincidence, maybe not). The thing is, the rankings system on MP3.com actually works and the best do float up to the top.
Actually, he was brought on by the Slashdot crew just to handle BSD related stories.
Doh! I made a mistake. I thought the configure scripts were GPL'd. Well, that solves that problem but I still don't know how to use it :)
ACK! That is evil.
It is not that glib is evil (well, okay, it is, but that is not my objection here). The problem is that it is a small program I am working on and having to pack around a standard C library is not exactly cool. Now, creating a library of those functions I use from the FreeBSD C library is possible and much finer grain control. Which is nice.r ty.html) and just need some native support. Another problem is the overly complicated license to Cosm (which looks like it is about on par with the Artistic license, correct me if I am wrong). I would also prefer dealing only with BSD licensed programs as far as things I need to ship. I am a bit disturbed that the configure script is GPL'd but I think I can handle that. On the other hand, if I could avoid it, I would. I will not go into the details here, but the GPL is simply morally wrong and I do not wish to support it any more than I have to.
As for Cosm, interesting concept but I do nto think it will help. I am working with a chat clone (http://www.james-howard.com/display.html?page=pa
Working with anything other than the standard C libraries is unacceptable, so glib is out. But more to the point, how do I make sure that if I use a construction that say, works on FreeBSD but not on SunOS (in this case, pthreads are a problem) works out all around?
This leads me to an interesting problem. I am developing a program. I am using FreeBSD as my development enviroment but my target environments are BSD/OS, OpenBSD, FreeBSD, SunOS, and possibly UnixWare. Obviously, anything else would be great on top of this. But how does one write code that will compile without problems across so many different architectures and platforms? Is autoconf the way to go? Is there a decent manual on autoconf? The standard documentation that comes with it is a bit lacking in how to make it work with a new project. Ideas?
Only if you start a coutnry whose two-letter country code is OS.
Let me give a specific example: I am working with a piece of chat software. The software may not be sold commercially. In order to make a minor improvement, I changed it's read command to work with libreadline. DOH! Now my whole program is GPL'd. But wait, I don't even own this program. So I cannot change the license on the chat software. I cannot redistribute this. This sucks and this is a flaw in GPL.
Actually, their servers run on NetBSD. The Real Weasel itself will run with any OS since it is OS independent.
No, really! Even though I am not well versed in kernel design, just flipping through the FreeBSD kernel code will teach you quite a bit about how the system works at a user level. The Design and Implementation of the 4.4BSD Operating System is an excellent resource to have handy when learning to program at the user level in Unix. If you use it, you will have a far greater understanding of how the kernel and libraries are handling the calls you make and you will quickly understand programming more.