> GPL protects against EEE How does it do that? By forcing commercial vendors to come up with totally proprietary solutions this rendering GPL code completely irrelewant in the long run? GPL is good for _killing_ standards with its Magical Powers.
No, the point was that if BSD-licensed prototype didn't exist, Microsoft would have implemented its own 100% proprietary code. The existence of GPLed code is equal to no code at all for them.
> It doesn't matter, and it's not really accurate. It is accurate enough. If memory serves me right, only six files were removed from the codebase as part of a lawsuit settlement.
> while FreeBSD uses ipfilter in userspace
Absolutely incorrect. Get your facts straight.
Re:Do you care about your kernel?
on
Debian NetBSD
·
· Score: 1
They posted screenlog of the multiprocessor VAX box booting NetBSD some time ago. This is probably the oldest working SMP machine in existence.
Re:the kernel? my god man
on
Debian NetBSD
·
· Score: 1
It makes a world of difference when you are trying to implement something which touches both kernel and userspace at the same time, just as an example. Good luck finding central point of contact to discuss your patches:)
Re:I would prefer the other way around
on
Debian NetBSD
·
· Score: 1
On 2-way SMP machines the performance difference between Linux and FreeBSD in SMP department will be negligible. There were test from Byte magazine published recently, where misconfigured FreeBSD did more than adequate against Linux 2.4 despite the fact that FreeBSD kernel was configured with MAXUSERS value which is way to low for any reasonable use. It is when number of processors is more than two then Linux should start showing advantages. Once you abandon cheap dual-processor market segment, you will find that prices for Intel-based servers are not that different from the same class Sun or IBM boxes.
>neither of your responses highlight any reason
>that SMP on x86 is worthless and shouldn't be
>pursued.
And I never intended to argue that. I was simply stated that the importance of supporting SMP on i386 is quite overrated.
Re:I would prefer the other way around
on
Debian NetBSD
·
· Score: 1
But there is. Since FreeBSD 4.4, if I am not mistaken. And external patches to do just that have existed for at least last two years. No need for sharity-light.
Re:the kernel? my god man
on
Debian NetBSD
·
· Score: 1
Actually, the number of committers in FreeBSD is close to 300. But do not make mistake thinking that the number of committers represents the number of actual developers. FreeBSD has a GNATS system and and a number of developer-oriented mailing lists where everyone is welcome to submit patches. Think about the whole bunch of BSD nomads from Japan, all hiding behind handful of Japanese committers as an example.
Besides, FreeBSD is using a lot of "contributed" software, take 'bind' for example. BSDs only provide a glue to integrate such a software into the base system but try hard to feed all other changes back to original vendor. This allows them to minimize divergence with an 'official' package versions and eliminate associated support problems.
Re:I would prefer the other way around
on
Debian NetBSD
·
· Score: 2, Insightful
IMHO, because if you need high end system in the first place, you will be really better served by buying system from Sun, IBM or HP. Their offerings of enterprise-class systems are much more mature and stable than any of the i386-base alternatives on the market today.
SMPng project is not only about improving SMP performance of FreeBSD. It is also about making kernel fully preemtable, which has its advantages for real-time tasks, responsiveness in desktop and multgimedia environments. Besides, with an upcoming PPC and UltraSPARC ports having better SMP support kinda starts making more sense:)
Just two points:
a) there is a port for DRM kernel module in the
FreeBSD ports tree and last time I checked it worked just fine. WITH_MATROX_GXX_DRIVER was
working fine too. Together two will give fully
functional DRI for Matrox.
c) Sound card - blame Creative for their semi-
binary driver with lack of all and any documantation.
Forgot to mention: I am not working for Rational,
I am just a very loyal customer. If your project
is huge and you have resources and hardware to
spend on powerful ClearCase servers, then by all
means go fo it. You'll never look back at CVS
again.
ClearCase is years ahead of other version control
systems I have used or tried to evaluate. Locking
system in ClearCase is actually superior to the
CVS model once you figure out differenced between
'reserved' and 'unreserved' checkouts. And why two
developers would want to check out files for a
long time (~10min) from the same branch anyway?
Branches are what makes ClearCase exceptional,
just create your own branch, redefine your
config spec and hack away uninterrupted by
anybody. Use cleartool findmerge command to
merge your changes back when done, or to
pull in changes done by others.
Are BSD projects really elitist and closed as you claim? Do you have any shred of evidence to back your story? FreeBSD committers have responded to each and any of PRs I sent to them to date, and good portion of patches I proposed are now in FreeBSD CVS repository, and those, that were rejected, were rejected because a better and more complete patch was either already available or was in the works. I've had much lesser luck with linux-kernel mailing list and with GCC developers, for instance, not because there folks are inherently more egoistic, but because there is no sane way one could propose patches to either Linux or GCC. There is nothing like FreeBSD GNATS database available for Linux kernel, and GNATS database on the GCC website is pretty much unused and submitted patch requests are simply being consistently ignored. In short, the alleged elitism in BSD community is pretty much a fantasy of Linux advocates, invented to draw attention away from their own shortcomings.
Sorry, but that is just plain wrong. Linux does not have formal change request system that is remotely as convenient as all the BSDs have. In fact, Linux has no
approved way yo submit patches - through linux kernel mailing list. Whether or not this patch will get someone's attations is anyones guess. BSD's use more formal process with GNATS, PRs, etc. In fact, the best way to become a committer is to submit as most good quality PRs as possible so that other FreeBSD committers will get bored committing your patches and simply will let you to commit them yourself.
I would say it is extremely hard to get poorly designed code into BSD CVS. Good code is always welcome.
Is is as bloated in Plan 9 as it is in Linux? Well no:)
Remote filesystem sharing - does it even make sense for
_procfs_? Plan 9 has nice private namespaces consept, but how does that prove anything in this discussion?
Procfs on Linux does things it should not do at all. What the hell 'process fs' has to do with device control? TCP/IP stacks paramaters? That _is_ strange no matter what you are trying to come out to justify Linux' flawed design. Regarding NIH accusation in one of your previous postings let me note that BSD's have procfs for a time longer than Linux but quite successfully managed not to turn it into a kitchen sink it is on Linux.
If text is the 'Unix way', then why syscalls live statfs, stat, etc are all returning binary structures? Pretty non-Unixy:) Let me repeat myself - given the fact, that Linux procfs has no business representing information better exposed by other means, discussion about in what exactly format it is exporting data is moot.
Yes, sysctl.conf will most likely not work as expected across all the BSD's. I never claimed that it is portable. Neither will be linprocfs text interface. What I actually was saying that given the differences between the operating systems, adding unnesessary and hard to syncronise interface just for the sake of Linux compatibility will only double the burden. Sysctl is present and is doing its jobs adequately, so there is no point adding yet another feature which does not provide you any signficicant gain (if any at all). And questionable justification behing Linux procfs implementation very unlikely to inspire BSD developers. Their energy will be better spent somewhere else.
Binary to text conversion is slow. I am not sure I follow your argument where you trying to convince me otherwise. Each open syscall on procfs node will involve text string formatting and possible parsing back into binary form in userland, while corresponding sysctl will not have this overhead at all. Yes, while not touched, procfs does not spend your processor time but each access retrieval from it is order of magnitude slower than binary only syscall.
> It still seems like a case of favouring tradition over a superior design.
That I am ready to agree with, except for that 'superior' word. 'Slow and redundant' might be a better word choice. And yes, you did not state any sigle advantage Linux procfs has over sysctl excpept for some 'Unix way' religious mantras.
Linux procfs usually provides information in plain text
usually. That is evil since making text output similar
between two operating systems is unpractical, especially when these operating systems tend to change
their interfaces often. And why spending valuable processor time converting _binary_ data from text and then back?
Or do you really think that the developer who puts essentially device interfaces like AGP under/proc really knows what he is doing? I hope you do not really advocate the idea that BSD's should follow that strange at best path?
Slashdot Mirror
The plane flies with 'borrowed' engines from Su-37, as ones designed specifically for T-50 are not complete yet.
> GPL protects against EEE
How does it do that? By forcing commercial vendors to come up with totally proprietary solutions this rendering GPL code completely irrelewant in the long run? GPL is good for _killing_ standards with its Magical Powers.
No, the point was that if BSD-licensed prototype didn't exist, Microsoft would have implemented its own 100% proprietary code. The existence of GPLed code is equal to no code at all for them.
> It doesn't matter, and it's not really accurate.
It is accurate enough. If memory serves me right, only six files were removed from the codebase as part of a lawsuit settlement.
It just happened. Re-cvsup your ports again.
It is ongoing process and it happens as we speak.
> while FreeBSD uses ipfilter in userspace
Absolutely incorrect. Get your facts straight.
They posted screenlog of the multiprocessor VAX box booting NetBSD some time ago. This is probably the oldest working SMP machine in existence.
It makes a world of difference when you are trying to implement something which touches both kernel and userspace at the same time, just as an example. Good luck finding central point of contact to discuss your patches :)
On 2-way SMP machines the performance difference between Linux and FreeBSD in SMP department will be negligible. There were test from Byte magazine published recently, where misconfigured FreeBSD did more than adequate against Linux 2.4 despite the fact that FreeBSD kernel was configured with MAXUSERS value which is way to low for any reasonable use. It is when number of processors is more than two then Linux should start showing advantages. Once you abandon cheap dual-processor market segment, you will find that prices for Intel-based servers are not that different from the same class Sun or IBM boxes.
>neither of your responses highlight any reason
>that SMP on x86 is worthless and shouldn't be
>pursued.
And I never intended to argue that. I was simply stated that the importance of supporting SMP on i386 is quite overrated.
But there is. Since FreeBSD 4.4, if I am not mistaken. And external patches to do just that have existed for at least last two years. No need for sharity-light.
Actually, the number of committers in FreeBSD is close to 300. But do not make mistake thinking that the number of committers represents the number of actual developers. FreeBSD has a GNATS system and and a number of developer-oriented mailing lists where everyone is welcome to submit patches. Think about the whole bunch of BSD nomads from Japan, all hiding behind handful of Japanese committers as an example.
Besides, FreeBSD is using a lot of "contributed" software, take 'bind' for example. BSDs only provide a glue to integrate such a software into the base system but try hard to feed all other changes back to original vendor. This allows them to minimize divergence with an 'official' package versions and eliminate associated support problems.
IMHO, because if you need high end system in the first place, you will be really better served by buying system from Sun, IBM or HP. Their offerings of enterprise-class systems are much more mature and stable than any of the i386-base alternatives on the market today.
:)
SMPng project is not only about improving SMP performance of FreeBSD. It is also about making kernel fully preemtable, which has its advantages for real-time tasks, responsiveness in desktop and multgimedia environments. Besides, with an upcoming PPC and UltraSPARC ports having better SMP support kinda starts making more sense
Just two points:
a) there is a port for DRM kernel module in the
FreeBSD ports tree and last time I checked it worked just fine. WITH_MATROX_GXX_DRIVER was
working fine too. Together two will give fully
functional DRI for Matrox.
c) Sound card - blame Creative for their semi-
binary driver with lack of all and any documantation.
Forgot to mention: I am not working for Rational,
I am just a very loyal customer. If your project
is huge and you have resources and hardware to
spend on powerful ClearCase servers, then by all
means go fo it. You'll never look back at CVS
again.
ClearCase is years ahead of other version control
systems I have used or tried to evaluate. Locking
system in ClearCase is actually superior to the
CVS model once you figure out differenced between
'reserved' and 'unreserved' checkouts. And why two
developers would want to check out files for a
long time (~10min) from the same branch anyway?
Branches are what makes ClearCase exceptional,
just create your own branch, redefine your
config spec and hack away uninterrupted by
anybody. Use cleartool findmerge command to
merge your changes back when done, or to
pull in changes done by others.
Are BSD projects really elitist and closed as you claim? Do you have any shred of evidence to back your story? FreeBSD committers have responded to each and any of PRs I sent to them to date, and good portion of patches I proposed are now in FreeBSD CVS repository, and those, that were rejected, were rejected because a better and more complete patch was either already available or was in the works. I've had much lesser luck with linux-kernel mailing list and with GCC developers, for instance, not because there folks are inherently more egoistic, but because there is no sane way one could propose patches to either Linux or GCC. There is nothing like FreeBSD GNATS database available for Linux kernel, and GNATS database on the GCC website is pretty much unused and submitted patch requests are simply being consistently ignored. In short, the alleged elitism in BSD community is pretty much a fantasy of Linux advocates, invented to draw attention away from their own shortcomings.
I understand Jordan was speaking about his MacOS X work, not FreeBSD.
Get your facts straight, please. Since when BSD projects have used Linux for their mail server?
Well, Apache license is BSD-like license.
Sorry, but that is just plain wrong. Linux does not have formal change request system that is remotely as convenient as all the BSDs have. In fact, Linux has no approved way yo submit patches - through linux kernel mailing list. Whether or not this patch will get someone's attations is anyones guess. BSD's use more formal process with GNATS, PRs, etc. In fact, the best way to become a committer is to submit as most good quality PRs as possible so that other FreeBSD committers will get bored committing your patches and simply will let you to commit them yourself. I would say it is extremely hard to get poorly designed code into BSD CVS. Good code is always welcome.
Is is as bloated in Plan 9 as it is in Linux? Well no :)
Remote filesystem sharing - does it even make sense for
_procfs_? Plan 9 has nice private namespaces consept, but how does that prove anything in this discussion?
Sorry, that was /proc/mtrr
Procfs on Linux does things it should not do at all. What the hell 'process fs' has to do with device control? TCP/IP stacks paramaters? That _is_ strange no matter what you are trying to come out to justify Linux' flawed design. Regarding NIH accusation in one of your previous postings let me note that BSD's have procfs for a time longer than Linux but quite successfully managed not to turn it into a kitchen sink it is on Linux. If text is the 'Unix way', then why syscalls live statfs, stat, etc are all returning binary structures? Pretty non-Unixy :) Let me repeat myself - given the fact, that Linux procfs has no business representing information better exposed by other means, discussion about in what exactly format it is exporting data is moot.
Yes, sysctl.conf will most likely not work as expected across all the BSD's. I never claimed that it is portable. Neither will be linprocfs text interface. What I actually was saying that given the differences between the operating systems, adding unnesessary and hard to syncronise interface just for the sake of Linux compatibility will only double the burden. Sysctl is present and is doing its jobs adequately, so there is no point adding yet another feature which does not provide you any signficicant gain (if any at all). And questionable justification behing Linux procfs implementation very unlikely to inspire BSD developers. Their energy will be better spent somewhere else.
Binary to text conversion is slow. I am not sure I follow your argument where you trying to convince me otherwise. Each open syscall on procfs node will involve text string formatting and possible parsing back into binary form in userland, while corresponding sysctl will not have this overhead at all. Yes, while not touched, procfs does not spend your processor time but each access retrieval from it is order of magnitude slower than binary only syscall.
> It still seems like a case of favouring tradition over a superior design.
That I am ready to agree with, except for that 'superior' word. 'Slow and redundant' might be a better word choice. And yes, you did not state any sigle advantage Linux procfs has over sysctl excpept for some 'Unix way' religious mantras.
Linux procfs usually provides information in plain text usually. That is evil since making text output similar between two operating systems is unpractical, especially when these operating systems tend to change their interfaces often. And why spending valuable processor time converting _binary_ data from text and then back? Or do you really think that the developer who puts essentially device interfaces like AGP under /proc really knows what he is doing? I hope you do not really advocate the idea that BSD's should follow that strange at best path?