Slashdot Mirror
Domain: geocrawler.com
Stories and comments across the archive that link to geocrawler.com.
Comments · 140
-
Re:*BSD is dying
Not. You just can't see them because they happen to be firewalls.
The Geocrawler mail-list archive of OpenBSD misc has nothing but doubled from 1996~2000.
Speaking of which, is Geocrawler out of business? there are no messages showing up for September... -
Re:This Crowd is Disappointing
I just read a Todd Fries post on misc@ re: this issue. He says that OpenBSD will likely switch to ipfw. So it really isn't a big deal anyway. I guess projections are in the several months range. You can find the discussion on Geocrawler
-
Re:Bagh humbug...
You mean PDP-11s have a network capability? Shit, we have an ancient PDP-11 in the lab and I was thinking about hooking it into the net, but couldn't find any info if it could do it...
AFAIK they couldn't network in the normal sense (beyond terminals, etc), but you could plug several of them together and have them share the workload. Look here for some small confirmation of this, I'm sure other evidence of it can be found.
Though it could only be the later and/or high-end models - we've got an old product announcemnt package for the PDP-11/24 here in the lab, and there's no mention of clustering.
If you could somehow convice a PDP-11 that it was talking with a serial terminal or another PDP-11, when in fact it was talking to something more modern, I guess you could set up some form of networking on it. Heh, TCP/IP over an VT100/RS-232. -
Mozilla 0.9 and Java SupportOkay, i took a little time to setup Java support with Mozilla 0.9 and came up with this page.
I downloaded j2re 1.3 for Linux, and installed the RPM. Setting up the symbolic link in
Overall, Mozilla 0.9 seems to be as functional as Netscape 4.7. Very impressive!
-
Re:Double Barrel
The funny thing is, this was a story which leaked in a big way from the Themes group:
and they're not too happy about it. -
Re:X marks the spot
Yeah, I think the 2D stuff is generalized, but there are a lot of ways to do it, and that's driver related. See this post to dri-devel about what's been accelerated using AGP and DRM accel, and this post on performance with the new r128 driver. Still very very new code, and other posts indicate the numbers may not be totally accurate, but if it is, then it's a good start for much better 2d performance from X.
"I may not have morals, but I have standards." -
Re:X marks the spot
Yeah, I think the 2D stuff is generalized, but there are a lot of ways to do it, and that's driver related. See this post to dri-devel about what's been accelerated using AGP and DRM accel, and this post on performance with the new r128 driver. Still very very new code, and other posts indicate the numbers may not be totally accurate, but if it is, then it's a good start for much better 2d performance from X.
"I may not have morals, but I have standards." -
Re:Another framework: dmSDK
Erik has writen the followng reply to that question, which I thought I link to here for completion. GStreamer mail archive
-
Re:Beastie??? Aaaarrrrrggggghhhhh!!!!!!!
No, no, no. His name is not Chuck. Why don't you look at what Kirk McKusick, the creator of the daemon image has to say.
-
Re:What hardware?
Sure You can run it on your G400. Just check out the E-develop mailing list archives Lots of people have the same problem and some of them even found the solution
-
Re:GPL is not a virus, non-linking is allright byHowdy, Lion,
The GPL is not like a virus.
I don't claim it's an exact metaphor, and I certainly don't claim to have invented it. Here (1,2) are a couple of discussions of the topic; you can find plenty more by searching in Google for "gpl virus."Often times, people pin RMS as a "lone" worker, who somehow makes terrible things happen.
My beef is with his very unethical behavior toward the Nupedia folks. I couldn't care less whether he's a loner, or whether he's popular or unpopular. Unethical behavior is unethical behavior.
The Assayer - free-information book reviews -
Re:Sad, really...You should have informed yourself before you started ranting: This has nothing to do with pride.
They just have found a faster, cleaner, more flexible (in short: better) solution than OpenSSH.
You can read more about it in the mailinglist archives, e.g. here:
"It was originally written for an embedded realtime OS, but also works on Solaris and NetBSD. It has independent reader/writer threads, for MUCH better performance than other Secure Shell implementations, has better Kerberos support, and is just written in a much cleaner way.
It is already being used inside at least one very popular commercial product."
-
Re:Linux and the iBook FireWire SEPretty much all my Linux experience is on PPC and it is a wonderful platform to work on. There are a number of things that still need work (that StarOffice port being one of them) but it is very quickly making significant progress.
You probably want to search the linuxppc-user list archives from here and check out penguinppc.org for other useful resources and info.
As for the iBook, the archives indicate that it does work quite well. There doesn't appear to be support for Firewire though (or at least not good support).
The cube also seems to run LinuxPPC just fine as does those new dual processor G4s (drool). Though the multiprocessor support is in early stages. Did this just not port well from Intel or does multiprocessor support generally suck in Linux?
Aside from LinuxPPC, you may also want to check out YellowDog which is a very similar distro to LinuxPPC but apparently has an auto-update feature similar to apt-get as well as rpm support. Then of course there's SUSE.
Personally, I'd strongly recommend buying a PPC for Linux - the computers are substantially faster than Intels (despite the Mhz ratings, look at the benchmarks). I'm also looking at buying an iBook to go with my G3 desktop so I'd like to hear your experiences with it. Oh, and yes you can buy multi-button mice for Macs. Get one.
Adrian Sutton.
-
Re:I'm sorry...
Everything you say there is true, but I have to say that the Microsoft compiler they used for Visual J++ was the best java compiler I ever used.
I'm reasonably certain that the MS JVM was one of the faster ones available for a long time.
See the one Java Compiler bug I found
Steve
--- -
Emperor Has No ClothesI'd like to know why people aren't interested in 2.4. Is it that it's been delayed so long it's like vaporware?
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians- set realistic goals for a release
- defer any further feature creep until the next release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good documentation to make upgrades and new feature addition easier and the learning curve less steep
- provide robust methods for troubleshooting the system to make development and debugging easier.
The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________ -
Emperor Has No ClothesI'd like to know why people aren't interested in 2.4. Is it that it's been delayed so long it's like vaporware?
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians- set realistic goals for a release
- defer any further feature creep until the next release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good documentation to make upgrades and new feature addition easier and the learning curve less steep
- provide robust methods for troubleshooting the system to make development and debugging easier.
The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________ -
Emperor Has No ClothesI'd like to know why people aren't interested in 2.4. Is it that it's been delayed so long it's like vaporware?
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians- set realistic goals for a release
- defer any further feature creep until the next release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good documentation to make upgrades and new feature addition easier and the learning curve less steep
- provide robust methods for troubleshooting the system to make development and debugging easier.
The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________ -
Emperor Has No ClothesI'd like to know why people aren't interested in 2.4. Is it that it's been delayed so long it's like vaporware?
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians- set realistic goals for a release
- defer any further feature creep until the next release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good documentation to make upgrades and new feature addition easier and the learning curve less steep
- provide robust methods for troubleshooting the system to make development and debugging easier.
The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________ -
Emperor Has No ClothesI'd like to know why people aren't interested in 2.4. Is it that it's been delayed so long it's like vaporware?
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians- set realistic goals for a release
- defer any further feature creep until the next release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good documentation to make upgrades and new feature addition easier and the learning curve less steep
- provide robust methods for troubleshooting the system to make development and debugging easier.
The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________ -
Patience...
Whether or not he was going about it the right way, it looks like he has been plenty patient.
http://www.geocrawler.com/arch ives/3/35/2000/6/0/3875772/
This is from June, and the post indicates he posted the bugfix in December of 1999. -
Re:And we're supposed to believe this because... ?I direct your attention to the words of Dean Gaudet, long-time Apache developer and HTTP expert:
-
Re:The good and bad of this
There is a binary-only *.a library in there which actually drives the new features their driver actually adds. So this driver looks not to be open source to me.
Look at the DRI project's developer mailing list archives. There's a message from Jeff Hartmann hinting that the source for the HAL will be relesed eventually, too. (Wait for the archive to be updated, the message is fairly recent, that's the reason I can't provide a direct link to it)
-
Re:Drivers
So, do we think the driver will be open source or not?
Please look at the CVS tree of the DRI project, Matrox had worked together with Precision Insight to develop this drivers and the source is there. This particular release seems to be mising one bit (the HAL), but it looks like that will be released, too. Look at the DRI mailing list archives if you want more info about the current status of the DRI.
-
Keep up the good work... matrox?
Keep up the good work Precision Insight! These drivers are developed by Presicion Insight, and other than the HAL, what Matrox released is more or less what's already available at DRI's CVS.
Nevertheless, Matrox is to praise for releasing specifications that allowed people to write drivers for their hardware, including but not limited to the Utah GLX drivers, as well as for releasing source code (not all of it, mind you, but information comming reliable sources suggests it will be there eventually) along with this "beta" driver. So, go, Matrox, go!
-
Re:Components at install levelThere was a recent thread on the Freenet developer's mailing list which may be of interest to you, Cory. Freenet involves transmitting information in a way that may elicit some opposition in certain circumstances. The issue arose that users may want to be able to install, use, then uninstall Freenet in a big fat hurry. Pushing as many Freenet-related files as possible into a single directory would make that process somewhat easier, though considerable doubts were raised that such a scheme was workable or even advisable.
I agree, however, with much of what Cory said about
FWIW, the idea of using XML as a config-file format was also briefly discussed. IIRC, the response seemed to be that the developers preferred to stick with a vi-editable text file in the old "keyword=value" format. Oh, well.
--Will
-
Re:Competition
I think the reason that things are progressing so slowly is because what we're doing is REALLY HARD.
Well, that *sounds* convincing, but a quick check of the mailing list shows that there is roughly zero discussion going on at the moment about the crucial issues I mentioned (updating and searching). And roughly the same amount of development. Why do think that is? Sure my post was controversial, but I stand by what I said. I think the real problem is that a lot of developers who have the right stuff to attack and solve these problems are not being well-received by some developers already entrenched in the project. Try it yourself and you'll see what I mean.
Open source developers tend to exhibit well-known cat-like behavior: they do what comes naturally and move on to some other project that can make better use of their talents. If you go back, *way back* through the list archives you'll see exactly what I'm talking about happening over and over again. Don't be distracted by the volume of posts - you have to look closely at the quality to see what I mean. Whatever, I wish you the best of luck.
-- -
More Freenet advantages
In addition to unlimited file size, and no AT&T censorship, Freenet will be fully searchable.
-
Re:Well, looks like the film industry is done withC) If Intergraph supports the WildCat on Linux within 6 months, I'll print out an entire
Put some salt on your printer papers - Wildcat driver will be our RSN (hopefully when XFree 4.0.2 is out). I'm talking about few weeks - up to 2 months
Want some ketchup with it? Oh, if you want a proof - take a look here -
Zoid's Comment
This is indeed nothing new, and stuff is available right now. Just not very wide spread. Here's Zoid bit on it also which you may find interesting:
-Steve Gibson -
Re:Here's the (driver) scoop:
This message pretty much sums it up, I think.
-
One more note...Check the mailing list archives for the latest status; the actual project pages mention numerous wishlist items (like support for non-Epson printers) that are actually implemented and working.
BTW, does anyone know a better archive than the one at geocrawler? The index only shows about 25 messages at a time, and the messages themselves don't have prev and next links, and in general there's way too much window dressing "noise" per unit of signal. (I wonder if there are also banner ads. At least I don't waste time downloading them.)
-
Re:Linux moving in the right direction?
How about the performace problems in 2.4?
Riel x ClassZone (late) results -
Re:two words..
actually freebsd and linux are roughly comparable at speed...bsd is slightly faster on loaded systems while linux is faster on unloaded systems.
what makes me currently more interested is stability - and freebsd seems to be winning this one for now..specially with the VM problems and screwups taking place with the kernel. -
Re:Gnutella Like System?
Actualy, there was some disscussion of DNS over Freenet sometime back. Check the Freenet-chat archives.
The idea got passed around a lot. Eventualy, we just decided that it was a good idea but there was no reason to implement it now, but maybe in the future. Freenet would also have to get a lot faster at doing requests (hey, its only in 0.2 beta!)
------
-
Re:Wrong
I am surprised to see the 3Dfx drivers do so poorly, though. Isn't anyone helping out Daryll Strauss now that we've got source code available?
I believe this answers your question.
Basically, no.
-
Re:Inherent performance limitations for 3D?
Here is a good article showing why we can expect some differences in the 3d rendering between Linux and Windows. Basically it states that 3d in Linux is geared more towards compliancy with OpenGL vs Fastest Damn Frame Rate we can get. This results in a stable driver that still performs reasonably well. I am extremely happy with the results I have seen using the DRI mga driver.
I think that the Linux implementation of these drivers will be more feature rich (meaning prettier) and more stable than the Windows equivalent at the sacrifice of a few FPS. -
Joe Greco and news...When they blurb talks about large news servers, they mean it. Recently, Joe posted an email to freebsd-hackers because he tried, and failed, to newfs a 1.9 terabyte filesystem. Since it failed, he went back to allocating it as a bunch of different filesystems, but it was interesting to try...
-
Ex-coauthor on QuakeLives
There's a post from one of the ex-coauthors of the QuakeLives project up on the QuakeForce mailing list archives about this situation. He resigned when the 2.53 binary patch was released. He's got an exchange with Slade about the issue as well.
-
Re:I hope this goes down again one day.1.) Zope is based on Apache
2.) Apache 2.0 (aka new-httpd) is a major step WRT Apache's technique (i.e. it's multithreaded, runs on OS/390).
See the list archive: http://www.geocrawler.com/lists/3/Web/ 417/0/
-
Here's the post...
Found it in the archive, here