You give him scorn, he kicks you in the scrotum. That's what's going to eventually happen, you do realize.
Forced labour is not the open source way.
on
State of the Onion 9
·
· Score: 4, Insightful
Forcing people to work is not the open source way. If he wants to work on Perl 6, then he'll do so. If he'd rather play around with Photoshop, then he'll do that, too. To suggest that he should be forced into working on his open source project, a project that has been a godsend for hundreds of thousands of programmers over the last decade and a half, is just plain ignorant. That's just not how things work in the open source community. Contributions are valued and appreciated, but nobody is forced to contribute.
Of course functional programming is ancient.
on
State of the Onion 9
·
· Score: 2, Interesting
Nobody was suggesting that Haskell is the first functional programming language. Of course not! But it has brought pure functional programming to the masses. Haskell's strong typing is a real plus.
Why is it taking over now? It's because we hit the limits of imperative languages years ago, and we're at the point of hitting the limits of object-oriented programming. That's why we're seeing applications that were traditionally implemented in C (such as a Perl implementation) being implemented using Haskell.
A language like Haskell allows more complex programs to be developed in less time, with fewer lines of code, and with enhanced stability and maintainability. While Perl was known for such things as well, Haskell offers native code compilation and the benefits of functional programming.
Indeed, we see that functional programming has had a massive impact on languages like Ruby and Python as of late. That's because the trend is moving towards techniques pioneered by languages like SML, and now made widely usable by Haskell.
I have looked at Curry, but I am not a fan of logical programming. I much prefer pure functional, or at worst an imperative, OO functional language such as O'Caml.
Don't forget that COBOL is still used today. It doesn't have the momentum it once had, of course. Perhaps you're right. The very same thing might happen to Perl. It won't be as widely used as it once was, but it will still be very useful to a lot of people. And it will be maintained, and there will be updates.
Pugs is a Perl 6 implementation. It is written in Haskell. I recently fooled around with it. What did I learn? Haskell is powerful. Perhaps even more powerful than Perl. Indeed, as a long time Perl programmer I think that I will soon be abandoning Perl in favor of Haskell. Its functional capabilities are extremely useful when writing software that needs to work (think automated verification and such). And that's just the beginning. If the performance of the compiled code of GHC can be improved somewhat, then we might see Haskell revolutionize programming. It will do what Perl did in the early 1990s: open up a whole new set of development opportunities that just plain did not exist.
Indeed, I'm British, but I use metric because it is the superior system of measure.
We're comparing the time needed to compile OpenOffice with that needed to compile some other app (perhaps vi, bash, or some other relatively small piece of software). The earlier poster was complaining about it taking several hours to build on their machine. Indeed, the vast time difference between compiling OOo and bash is due to the relative sizes of the two pieces of software.
Bash could be considered the 10 metre (30 foot, if you prefer) stream. It takes very little time to compile bash, just as a bridge could be built across a small stream with minimal effort using today's technology.
OpenOffice, on the other hand, is the vast English Channel. It takes hours on today's machines to compile OOo, just as it would take a very long time to construct a bridge across the English Channel, again using today's technology.
OpenOffice is by far the more advanced of the two. While KOffice is comparable for the most basic tasks, it is usually unsuitable when you really push the software to the limit. Many of our secretaries found OOWriter to be far more useful than KWord. But eventually we decided on using LaTeX, as it trumped them both for document formatting. KCalc would crash mysteriously, while OOCalc would work work fine.
KOffice is a good effort, but to suggest that it is equal in some way to OpenOffice is absurd.
If they started today, perahps. But remember, OpenOffice is hardly new software. It's roots go back to the end of 1994. Qt and wxWidgets/wxWindows were in their infancy then. Motif, MFC, Athena, etc., were/are either expensive, ugly, and/or non-portable. Indeed, the infrastructure they needed was just not available a decade ago, but is quite prevalent now. The effort needed to transition over now may be many times greater than the benefit they'd actually receive.
Qt is nowhere near as large nor as complex as OpenOffice. Recall that OpenOffice includes its own GUI toolkit and app framework, in addition to the OpenOffice software itself.
X.org is written in C, rather than C++. C often compiles, especially with GCC, far faster than C++. Even then, X.org is miniscule in comparison to OpenOffice in terms of codebase size.
That's not a problem with the build system. That sounds like a problem with OpenOffice itself. Which, of course, is not what this particular thread is about.
Re:The build system of OpenOffice is fantastic.
on
OpenOffice 1.1.5 Released
·
· Score: 3, Interesting
It's a massive piece of software. Of course it's going to take hours, literally, to build. It's just a matter of OpenOffice being so massive.
It'd be like building a bridge across the English Channel. It will take longer to build such a bridge than it would to build a bridge across a 10 m wide stream.
The build system of OpenOffice is truly a fantastic beast to study. Indeed, when one looks deeply at it you see the sort of work that needs to be done to support the building of a massive C++ application with many different compilers on many different platforms. It's truly a feat of engineering what they accomplish in the build system alone, completely ignoring OpenOffice itself.
I have relatives who, unfortunately, live in Alabama. Several years back I visited them, and watched a football (soccer, in America) game my nephew was participating in. In any case, one of the other tots sustained a rather horrid injury. He was kicked in his manhood, and basically his scrotum was split wide open, with one testicle even lying on the ground. As would be expected, he was on the ground in extreme pain, basically yelling "Oh fuck! Fuck! Fuck! Oh fuck!" over and over again.
Now, a teenaged football player screaming at the destruction of his genitals was not what surprised me. It was his mother who surprised me. She appeared far more concerned by her son's use of "fuck", rather than his obliterated scrotum. She kept telling him not to swear, because "Jesus would not approve". I found that absurd, considering English did not even begin to form as a language until well after the death of Jesus.
In any case, I find it quite amusing how far some people will take not swearing. Even to the point of chiding a suffering child over their use of such words.
To join in on the pedantry, "is now becoming" suggests a definite transformation which is already underway.
Indeed, the process has already started. But the final result, DFBSD trumping FreeBSD absolutely, will come in the future. Seeing as I'm correct on this issue, I feel no need to read the rest of your post. Good day, sir!
The phrase "is now becoming" obviously suggests that DFBSD is not, as of now, the premiere BSD. But in time (ie. the future!) it will take the place of FreeBSD as the general purpose BSD of choice.
Doubt me all you want. The fact remains that the quality, usability, reliability and overall development of FreeBSD is seriously lacking these days. That is because the project no longer has the talents of an individual like Matt Dillon. Consequently, there is strong reason to believe that a project lead by Matt Dillon is sure to succeed. And that is what we are seeing: DFBSD is quickly becoming the leading general purpose BSD, soon to take over completely from FreeBSD.
Indeed, the development strategies of Firefox and Mozilla Suite do differ.
I'd say that Firefox is more like the Linux development process. It's not as well engineered, but there's the community impetus behind it that keeps the work going. Sometimes the quality is a bit lacking, but such problems are dealt with soon enough.
Mozilla Suite/SeaMonkey is more like the *BSD development process. Things move more slowly, but the product is quite solid and well designed.
In the end, it's difficult to say which is a better method: rapid development with rapidly fixed problems, or slower development without significant problems. Either way, the software produced trumps anything put out by many commercial vendors.
I think your inability to read English is causing you some problems here. Reread what I wrote. Notice that I used terms like "is now becoming" and "is bound to". The very nature of those phrases suggest that the event will occur in the future. You know, the "future" as in not now, but sometime soon.
FreeBSD 5 had better be more scalable than FreeBSD 4. I mean, come on. New releases are supposed to improve upon old releases! But DragonFlyBSD is being architectured to trump them all. Literally, to trump them all.
And regarding the study you mentioned, it looks like it was valid as of November, 2003. That was two years ago! Things have changed significantly since then. Besides, the machine used was a uniprocessor system. DragonFlyBSD will be capable of scaling on systems with a massive number of processors or multicore CPUs. Even FreeBSD 6 may struggle to offer suitable performance on such systems.
Indeed. With the loss of Matt Dillon, Mike Smith and Jordan Hubbard, FreeBSD lost its essence. There are indeed good programmers like PHK still around, but nobody to truly lead the system into the future, as you have said. Perhaps FreeBSD will find replacements for those they have lost, but I fear by that time FreeBSD will be technically inept.
How is the quality of these boards? Will they still be working in two or three years? Or will they have leaking capacitors by that time?
The loss of Matt Dillon hurt FreeBSD 5.
on
BSD Usage Survey
·
· Score: 1
The loss of Matt Dillon truly hurt the FreeBSD 5 development efforts. That's why it has taken up until FreeBSD 5.4 before many people can even begin to get a system up and running, let alone stable enough for production work.
However, FreeBSD's loss has thankfully turned into DragonFlyBSD. Once the initial work of rearchitecturing DragonFlyBSD is complete, it is quite certain that we might have a platform to replace FreeBSD for server and workstation tasks. DFBSD will be able to handle the massively multicored CPUs that are about to become prevalent. FreeBSD will not. But the virtue of technological superiority, DFBSD will trump FreeBSD.
While I do not have any MySQL benchmarks to provide you (I prefer to use the far more mature PostgreSQL myself), I do agree with you that Matt Dillon is by far one of the premiere BSD developers today.
It isn't surprising to consider that his project is bound to become the server/workstation BSD of choice in the near future. After all, it is built upon his decades of operating system development experience, in addition to his raw natural talent. From the perspective of the FreeBSD project, it is a shame for them that they no longer can boast his talent as their own.
But don't forget that the core DFBSD developers were a few years back amongst the core FreeBSD developers. They include guys like Matt Dillon, who basically was FreeBSD before the split. It's no wonder that DragonFlyBSD is now becoming the premiere production BSD: all of the developers who once made FreeBSD great are now working on it! Meanwhile we see FreeBSD still struggling to produce a stable branch. It was only with the latest FreeBSD 5.4 release that many people actually considered switching over.
Like it or not, DragonFlyBSD is bound to take the role FreeBSD has. DragonFlyBSD will soon be the BSD you use on your production server or workstation. Its revolutionary rearchitecturing will no doubt be quite beneficial when it comes to the multicore and multiprocessor systems which will soon become widespread. Meanwhile, systems like FreeBSD which have failed to make the transition to a far more threaded kernel design will lose the performance race.
Of course the microchip inside a computer matters. It matters very much. Chances are you're not using a 1980's PC with an 8 MHz processor. Why is that? Because such a CPU isn't suitable for most of today's tasks. So contrary to your beliefs, the type of processor(s) in a system do matter.
Slashdot Mirror
You give him scorn, he kicks you in the scrotum. That's what's going to eventually happen, you do realize.
Forcing people to work is not the open source way. If he wants to work on Perl 6, then he'll do so. If he'd rather play around with Photoshop, then he'll do that, too. To suggest that he should be forced into working on his open source project, a project that has been a godsend for hundreds of thousands of programmers over the last decade and a half, is just plain ignorant. That's just not how things work in the open source community. Contributions are valued and appreciated, but nobody is forced to contribute.
Nobody was suggesting that Haskell is the first functional programming language. Of course not! But it has brought pure functional programming to the masses. Haskell's strong typing is a real plus.
Why is it taking over now? It's because we hit the limits of imperative languages years ago, and we're at the point of hitting the limits of object-oriented programming. That's why we're seeing applications that were traditionally implemented in C (such as a Perl implementation) being implemented using Haskell.
A language like Haskell allows more complex programs to be developed in less time, with fewer lines of code, and with enhanced stability and maintainability. While Perl was known for such things as well, Haskell offers native code compilation and the benefits of functional programming.
Indeed, we see that functional programming has had a massive impact on languages like Ruby and Python as of late. That's because the trend is moving towards techniques pioneered by languages like SML, and now made widely usable by Haskell.
I have looked at Curry, but I am not a fan of logical programming. I much prefer pure functional, or at worst an imperative, OO functional language such as O'Caml.
Don't forget that COBOL is still used today. It doesn't have the momentum it once had, of course. Perhaps you're right. The very same thing might happen to Perl. It won't be as widely used as it once was, but it will still be very useful to a lot of people. And it will be maintained, and there will be updates.
Pugs is a Perl 6 implementation. It is written in Haskell. I recently fooled around with it. What did I learn? Haskell is powerful. Perhaps even more powerful than Perl. Indeed, as a long time Perl programmer I think that I will soon be abandoning Perl in favor of Haskell. Its functional capabilities are extremely useful when writing software that needs to work (think automated verification and such). And that's just the beginning. If the performance of the compiled code of GHC can be improved somewhat, then we might see Haskell revolutionize programming. It will do what Perl did in the early 1990s: open up a whole new set of development opportunities that just plain did not exist.
Indeed, I'm British, but I use metric because it is the superior system of measure.
We're comparing the time needed to compile OpenOffice with that needed to compile some other app (perhaps vi, bash, or some other relatively small piece of software). The earlier poster was complaining about it taking several hours to build on their machine. Indeed, the vast time difference between compiling OOo and bash is due to the relative sizes of the two pieces of software.
Bash could be considered the 10 metre (30 foot, if you prefer) stream. It takes very little time to compile bash, just as a bridge could be built across a small stream with minimal effort using today's technology.
OpenOffice, on the other hand, is the vast English Channel. It takes hours on today's machines to compile OOo, just as it would take a very long time to construct a bridge across the English Channel, again using today's technology.
OpenOffice is by far the more advanced of the two. While KOffice is comparable for the most basic tasks, it is usually unsuitable when you really push the software to the limit. Many of our secretaries found OOWriter to be far more useful than KWord. But eventually we decided on using LaTeX, as it trumped them both for document formatting. KCalc would crash mysteriously, while OOCalc would work work fine.
KOffice is a good effort, but to suggest that it is equal in some way to OpenOffice is absurd.
If they started today, perahps. But remember, OpenOffice is hardly new software. It's roots go back to the end of 1994. Qt and wxWidgets/wxWindows were in their infancy then. Motif, MFC, Athena, etc., were/are either expensive, ugly, and/or non-portable. Indeed, the infrastructure they needed was just not available a decade ago, but is quite prevalent now. The effort needed to transition over now may be many times greater than the benefit they'd actually receive.
Qt is nowhere near as large nor as complex as OpenOffice. Recall that OpenOffice includes its own GUI toolkit and app framework, in addition to the OpenOffice software itself.
X.org is written in C, rather than C++. C often compiles, especially with GCC, far faster than C++. Even then, X.org is miniscule in comparison to OpenOffice in terms of codebase size.
That's not a problem with the build system. That sounds like a problem with OpenOffice itself. Which, of course, is not what this particular thread is about.
It's a massive piece of software. Of course it's going to take hours, literally, to build. It's just a matter of OpenOffice being so massive.
It'd be like building a bridge across the English Channel. It will take longer to build such a bridge than it would to build a bridge across a 10 m wide stream.
I believe the player who kicked him was wearing shoes with metal cleats, rather than football shoes. They may have been baseball shoes.
The build system of OpenOffice is truly a fantastic beast to study. Indeed, when one looks deeply at it you see the sort of work that needs to be done to support the building of a massive C++ application with many different compilers on many different platforms. It's truly a feat of engineering what they accomplish in the build system alone, completely ignoring OpenOffice itself.
I have relatives who, unfortunately, live in Alabama. Several years back I visited them, and watched a football (soccer, in America) game my nephew was participating in. In any case, one of the other tots sustained a rather horrid injury. He was kicked in his manhood, and basically his scrotum was split wide open, with one testicle even lying on the ground. As would be expected, he was on the ground in extreme pain, basically yelling "Oh fuck! Fuck! Fuck! Oh fuck!" over and over again.
Now, a teenaged football player screaming at the destruction of his genitals was not what surprised me. It was his mother who surprised me. She appeared far more concerned by her son's use of "fuck", rather than his obliterated scrotum. She kept telling him not to swear, because "Jesus would not approve". I found that absurd, considering English did not even begin to form as a language until well after the death of Jesus.
In any case, I find it quite amusing how far some people will take not swearing. Even to the point of chiding a suffering child over their use of such words.
To join in on the pedantry, "is now becoming" suggests a definite transformation which is already underway.
Indeed, the process has already started. But the final result, DFBSD trumping FreeBSD absolutely, will come in the future. Seeing as I'm correct on this issue, I feel no need to read the rest of your post. Good day, sir!
The phrase "is now becoming" obviously suggests that DFBSD is not, as of now, the premiere BSD. But in time (ie. the future!) it will take the place of FreeBSD as the general purpose BSD of choice.
Doubt me all you want. The fact remains that the quality, usability, reliability and overall development of FreeBSD is seriously lacking these days. That is because the project no longer has the talents of an individual like Matt Dillon. Consequently, there is strong reason to believe that a project lead by Matt Dillon is sure to succeed. And that is what we are seeing: DFBSD is quickly becoming the leading general purpose BSD, soon to take over completely from FreeBSD.
What's the image shown in the installer supposed to be? Is it a sheep on a yacht? I fail to see how that is a "SeaMonkey".
Indeed, the development strategies of Firefox and Mozilla Suite do differ.
I'd say that Firefox is more like the Linux development process. It's not as well engineered, but there's the community impetus behind it that keeps the work going. Sometimes the quality is a bit lacking, but such problems are dealt with soon enough.
Mozilla Suite/SeaMonkey is more like the *BSD development process. Things move more slowly, but the product is quite solid and well designed.
In the end, it's difficult to say which is a better method: rapid development with rapidly fixed problems, or slower development without significant problems. Either way, the software produced trumps anything put out by many commercial vendors.
I think your inability to read English is causing you some problems here. Reread what I wrote. Notice that I used terms like "is now becoming" and "is bound to". The very nature of those phrases suggest that the event will occur in the future. You know, the "future" as in not now, but sometime soon.
FreeBSD 5 had better be more scalable than FreeBSD 4. I mean, come on. New releases are supposed to improve upon old releases! But DragonFlyBSD is being architectured to trump them all. Literally, to trump them all.
And regarding the study you mentioned, it looks like it was valid as of November, 2003. That was two years ago! Things have changed significantly since then. Besides, the machine used was a uniprocessor system. DragonFlyBSD will be capable of scaling on systems with a massive number of processors or multicore CPUs. Even FreeBSD 6 may struggle to offer suitable performance on such systems.
Indeed. With the loss of Matt Dillon, Mike Smith and Jordan Hubbard, FreeBSD lost its essence. There are indeed good programmers like PHK still around, but nobody to truly lead the system into the future, as you have said. Perhaps FreeBSD will find replacements for those they have lost, but I fear by that time FreeBSD will be technically inept.
How is the quality of these boards? Will they still be working in two or three years? Or will they have leaking capacitors by that time?
The loss of Matt Dillon truly hurt the FreeBSD 5 development efforts. That's why it has taken up until FreeBSD 5.4 before many people can even begin to get a system up and running, let alone stable enough for production work.
However, FreeBSD's loss has thankfully turned into DragonFlyBSD. Once the initial work of rearchitecturing DragonFlyBSD is complete, it is quite certain that we might have a platform to replace FreeBSD for server and workstation tasks. DFBSD will be able to handle the massively multicored CPUs that are about to become prevalent. FreeBSD will not. But the virtue of technological superiority, DFBSD will trump FreeBSD.
'Thank you' would be sufficient.
While I do not have any MySQL benchmarks to provide you (I prefer to use the far more mature PostgreSQL myself), I do agree with you that Matt Dillon is by far one of the premiere BSD developers today.
It isn't surprising to consider that his project is bound to become the server/workstation BSD of choice in the near future. After all, it is built upon his decades of operating system development experience, in addition to his raw natural talent. From the perspective of the FreeBSD project, it is a shame for them that they no longer can boast his talent as their own.
But don't forget that the core DFBSD developers were a few years back amongst the core FreeBSD developers. They include guys like Matt Dillon, who basically was FreeBSD before the split. It's no wonder that DragonFlyBSD is now becoming the premiere production BSD: all of the developers who once made FreeBSD great are now working on it! Meanwhile we see FreeBSD still struggling to produce a stable branch. It was only with the latest FreeBSD 5.4 release that many people actually considered switching over.
Like it or not, DragonFlyBSD is bound to take the role FreeBSD has. DragonFlyBSD will soon be the BSD you use on your production server or workstation. Its revolutionary rearchitecturing will no doubt be quite beneficial when it comes to the multicore and multiprocessor systems which will soon become widespread. Meanwhile, systems like FreeBSD which have failed to make the transition to a far more threaded kernel design will lose the performance race.
Of course the microchip inside a computer matters. It matters very much. Chances are you're not using a 1980's PC with an 8 MHz processor. Why is that? Because such a CPU isn't suitable for most of today's tasks. So contrary to your beliefs, the type of processor(s) in a system do matter.