Re: The future of NetBSD
Thorsten Glaser wrote: Marc G. Fournier dixit: And what I'm learning with bsdstats.org is that there are more then just those four ... GNU/kFreeBSD is reporting Now _that_'s funny ;) Yes, indeed. Some people are really wasting their time. are there any others? DragonFly Is already included on bsdstats.org. DesktopBSD PC-BSD Those two aren't separate operating systems, but rather FreeBSD with a custom GUI on top (live-FS / installer). They shouldn't be counted separately. [...] picoBSD nanoBSD The latter three are probably just stripped-down versions of the bigger ones. True. It could be argued whether they should be counted separately. Personally I don't think they should. The big ones are clearly DragonFly, Free-, Net- and OpenBSD. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. cat man du : where Unix geeks go when they die
Re: The future of NetBSD
Marc G. Fournier dixit: And what I'm learning with bsdstats.org is that there are more then just those four ... GNU/kFreeBSD is reporting Now _that_'s funny ;) are there any others? DragonFly DesktopBSD PC-BSD 4.3BSD-Quasijarus ekkoBSD (dead) MidnightBSD (nascent) MicroBSD (once dead, but apparently undead...) emBSD picoBSD nanoBSD The latter three are probably just stripped-down versions of the bigger ones. I think there are even more than these I listed above. The five big ones are DF/Free/Mir/Net/Open though. Daniel Seuffert (from AllBSD.de) today said he intends that your script to be installed AND ENABLED BY DEFAULT in every BSD release/snapshot, and he will definitively enable it in DesktopBSD 2.0. I will probably do the same for MirOS, as I currently don't have a way to even estimate the user base, other than bittorrent downloads, and it does not transmit any data qualifying as 'sensitive', uses almost no resources and is low-bandwidth. (We'll have to add some jitter to the execution time, though.) bye, //mirabile -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999
Re: The future of NetBSD
If you're going to keep chatting about the bsdstats thing would you please stop cross posting to so many lists? It's very irritating. -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: The future of NetBSD
Thorsten Glaser [EMAIL PROTECTED] wrote: Marc G. Fournier dixit: And what I'm learning with bsdstats.org is that there are more then just those four ... GNU/kFreeBSD is reporting Now _that_'s funny ;) -snip- The five big ones are DF/Free/Mir/Net/Open though. Not as funny as that^^^ Adam
Re: The future of NetBSD
On 9/1/06, Gilbert Fernandes [EMAIL PROTECTED] wrote: I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. But when you tell yourself that it cannot be done, you don't even try it. It would require people to not only do it for the sake of their projects, but for the whole BSD people. Even those who really piss you off in other projects. Because someday, those projects will live on without us. We'll pass on like everyone. Am I alone thinking this ? I would disagree with that. Is not unification we need, it is unity. Instead of speaking about the [Net, Open, Free, DragonFly]BSD community, we should be talking about the BSD community as a whole. I'm using Free, but when Open asks vendors to give driver docs, and when Net is spiralling down, it should be a problem for all the BSDs. Like bsdstats.org is considering, they are all bsd.
Re: The future of NetBSD
On Sat, 9 Sep 2006, rouk ounas wrote: On 9/1/06, Gilbert Fernandes [EMAIL PROTECTED] wrote: I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. But when you tell yourself that it cannot be done, you don't even try it. It would require people to not only do it for the sake of their projects, but for the whole BSD people. Even those who really piss you off in other projects. Because someday, those projects will live on without us. We'll pass on like everyone. Am I alone thinking this ? I would disagree with that. Is not unification we need, it is unity. Instead of speaking about the [Net, Open, Free, DragonFly]BSD community, we should be talking about the BSD community as a whole. I'm using Free, but when Open asks vendors to give driver docs, and when Net is spiralling down, it should be a problem for all the BSDs. I couldn't have said it better! And what I'm learning with bsdstats.org is that there are more then just those four ... GNU/kFreeBSD is reporting, as is MirBSD ... main index page hasn't been updated yet ... are there any others? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664
Re: The future of NetBSD
On 05/09/06, Marco Peereboom [EMAIL PROTECTED] wrote: I don't think that binary only drivers are well enough. Surely better than nothing but ... No fucking way. No support is FAR FAR better than a blob. Yes, really! Indeed! When something brakes, do you want it to continue to work as if nothing has happened and lose your data silently, or do you want it to give you some indication that it needs attention? * With binary drivers, it's always broken (and if it's not, it's guaranteed to be broken in the future), but some people tend to [foolishly] think that it's working. * With drivers written from proper documentation by developers who know their OS, it just works. BTW, I'd argue that the same principle applies to the manufacturer-supplied drivers for closed-source operating systems like Windows -- it's better to have the drivers written by people who know the OS it's written under, not by some random people hired by the company that produced the hardware (which would never be the same people who designed the hardware anyway, because people who design hardware don't usually write software for it, and vice-versa). Cheers, Constantine.
Re: The future of NetBSD
On Sun, 10 Sep 2006, Thorsten Glaser wrote: Daniel Seuffert (from AllBSD.de) today said he intends that your script to be installed AND ENABLED BY DEFAULT in every BSD release/snapshot, and he will definitively enable it in DesktopBSD 2.0. I will probably do the same for MirOS, as I currently don't have a way to even estimate the user base, other than bittorrent downloads, and it does not transmit any data qualifying as 'sensitive', uses almost no resources and is low-bandwidth. (We'll have to add some jitter to the execution time, though.) Check out the newest version, which adds 'jitter' ... :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664
Re: The future of NetBSD
I don't think that binary only drivers are well enough. Surely better than nothing but ... No fucking way. No support is FAR FAR better than a blob. Yes, really! Don't forget that an open source team sometimes makes api changes that might break a binary only driver. And companies sometimes are slow in fixing. A.K.A. Never. And when they try it usually doesn't work right. Worst of all *you* have no clue how they kludged a so called fix together. Vendor code is usually pretty darn bad and I wonder why people never revolt against that. Or the vendor did some mistakes in his own driver. First the paying customers are served. All the other folks (open source ..) surely will come last. Open source users paid for the hardware didn't they? Or because they use an alternative OS now they stole the hardware? This argument is retarded. For some smaller corps supporting open source developers is simply a burden that costs time and so money. Docs are part of the development process. If they are not than you don't want that hardware. I know this from a medium sized german company producing nice audio recording cards. It was impossible to get a card and documentation from them for a FreeBSD developers. And after weeks and months of asking via e-mail they decided finally to tell the truth that they don't want to support open source developers anymore, it makes too much work. They are unable to spend so much time answering open source developers questions although they got documentation. This experience they made with Linux developers. I call horseshit on this one too. Vendors do not have to support shit if they free their docs. NOTHING because the OS developers will do it for FREE for them. This argument is a steaming pile of shit with peanuts in it. It is this attitude that is killing Linux and FreeBSD. They will allow anyone to shit and piss in their sandbox and say GREAT THANKS! You people need to get through your heads that blobs are killing your operating system that you pretend to care so much about. Allowing blobs is the equivalent of eating fast food; it is convenient now but 10 years from now your ass wont fit through the door. A man will fight harder for his interests than for his rights. -- Napoleon Bonaparte Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ Hi All! I agree totally with Mr. Peereboom. IMHO, BLOBS are not sustainable in the long run. If a manufacturer decides to retire a particular model (driver support included) while OS keeps on releasing newer versions (which include changes in the design and/or how things are implemented) one will be facing two scenarios: stasis or an unstable system. Both I believe is distasteful. I'd rather purchase hardware that will enable me to (ab)use it until it no longer works (MBTF deadend) using either NetBSD or OpenBSD :). Joseph A. Dacuma
Re: The future of NetBSD
thus Joseph A. Dacuma spake: I don't think that binary only drivers are well enough. Surely better than nothing but ... No fucking way. No support is FAR FAR better than a blob. Yes, really! Don't forget that an open source team sometimes makes api changes that might break a binary only driver. And companies sometimes are slow in fixing. A.K.A. Never. And when they try it usually doesn't work right. Worst of all *you* have no clue how they kludged a so called fix together. Vendor code is usually pretty darn bad and I wonder why people never revolt against that. Or the vendor did some mistakes in his own driver. First the paying customers are served. All the other folks (open source ..) surely will come last. Open source users paid for the hardware didn't they? Or because they use an alternative OS now they stole the hardware? This argument is retarded. For some smaller corps supporting open source developers is simply a burden that costs time and so money. Docs are part of the development process. If they are not than you don't want that hardware. I know this from a medium sized german company producing nice audio recording cards. It was impossible to get a card and documentation from them for a FreeBSD developers. And after weeks and months of asking via e-mail they decided finally to tell the truth that they don't want to support open source developers anymore, it makes too much work. They are unable to spend so much time answering open source developers questions although they got documentation. This experience they made with Linux developers. I call horseshit on this one too. Vendors do not have to support shit if they free their docs. NOTHING because the OS developers will do it for FREE for them. This argument is a steaming pile of shit with peanuts in it. It is this attitude that is killing Linux and FreeBSD. They will allow anyone to shit and piss in their sandbox and say GREAT THANKS! You people need to get through your heads that blobs are killing your operating system that you pretend to care so much about. Allowing blobs is the equivalent of eating fast food; it is convenient now but 10 years from now your ass wont fit through the door. A man will fight harder for his interests than for his rights. -- Napoleon Bonaparte Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ Hi All! I agree totally with Mr. Peereboom. IMHO, BLOBS are not sustainable in the long run. If a manufacturer decides to retire a particular model (driver support included) while OS keeps on releasing newer versions (which include changes in the design and/or how things are implemented) one will be facing two scenarios: stasis or an unstable system. Both I believe is distasteful. definitely. but on the other hand there's 15 minutes of fame if you support a device (using a blob) today -- as others won't support it. I'd rather purchase hardware that will enable me to (ab)use it until it no longer works (MBTF deadend) using either NetBSD or OpenBSD :). true, but NetBSD allows blobs. Joseph A. Dacuma timo
Re: The future of NetBSD
On Wed, 06 Sep 2006 09:47:32 +0200 Timo Schoeler [EMAIL PROTECTED] wrote: : Hi All! : : I agree totally with Mr. Peereboom. IMHO, BLOBS are not sustainable : in the long run. If a manufacturer decides to retire a particular : model (driver support included) while OS keeps on releasing newer : versions (which include changes in the design and/or how things are : implemented) one will be facing two scenarios: stasis or an : unstable system. Both I believe is distasteful. : : definitely. but on the other hand there's 15 minutes of fame if you : support a device (using a blob) today -- as others won't support it. If you want 15 minutes of fame, go rob a liquor store. -- One thing the inventors can't seem to get the bugs out of is fresh paint.
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 11:59:57AM +0200, Gilbert Fernandes wrote: I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. But when you tell yourself that it cannot be done, you don't even try it. It would require people to not only do it for the sake of their projects, but for the whole BSD people. Even those who really piss you off in other projects. Because someday, those projects will live on without us. We'll pass on like everyone. Am I alone thinking this ? Sure would be kind of nice, but in practice its nearly like saying, I want that the world gets one car. Please unify Mercedes, BMW, Ferrari, VW and all of their models ;-) With design goal: Modularize car in a way, that the different customer demands can be achieved as options. You'll get problems in many ways ... - too many different - partly contradictory - design goals. One car is more a racing car, the other tries to be kind to mother nature - too different customers demands - different company cultures ... - many leaders that have to give up their own goals and synchronize with each other - say good-bye to own companies history and habits and be open to be only part of a new team For a volunteer project it sounds nearly impossible to synchronize all the different people with different goals and culture to the project targets _and_ be productive and write good code ! If the situation of NetBSD is the way like Charles Hannum describes - I'm no insider therefore I formulate it carefully this way - then a possible way could be a fork of NetBSD. But does the world really needs one more BSD ? Maybe the discussion itself is useful for making a cut and trying to reorganize the team by avoiding all that turns out to be a misconception. If this is not possible and people are convinced a fork with a strong leader would bring more merits and productivity, then a fork still could be done later. A fork off alone from NetBSD by keeping all the CPU and architecture support might be very tricky and difficult. Its questionable if one person is able to draw good design decisions that are well for all different NetBSD ports (here I mean the different architectures). Maybe a fork would need to specialize on one or some CPU types that a small team is able to handle. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote: On Thu, 31 Aug 2006, Constantine A. Murenin wrote: On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: Just a stupid comment, but ... Linux is one kernel, multiple distributions ... BSD is, what, 4 kernels now? If we worked more together instead of as seperate camps, it might make things a bit easier, no? Isn't there still fewer differences between *BSD operating systems than between different GNU/Linux distributions and kernel releases? :) Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? Are you really sure ? I see it more this way: For Linux on kernel (or device driver) level they only have to support 2 main trains: 2.4.x and 2.6.x. The 50 distributions are only a burden if it comes to the point what different shared library / Java / TCL / etc ... versions are packaged with the OS. A friend of mine doing Java development had severe issues with all that different Linux versions. But a simple kernel driver only has to honour different CPU types and the 2.4 and 2.6 tree and maybe now a development tree but am not sure on the latter ... Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 08:14:31PM -0300, Marc G. Fournier wrote: On Thu, 31 Aug 2006, Miod Vallat wrote: If the vendor is supporting the driver, and working with the community, then one would hope that they would also fix the driver as bug reports come in about it ... That's too many ifs to be realworld-compatible. And actually the only vendors I can think of which are working with the community actually provide documentation, if only because it is simpler for them to spend time on documentation than on code for N different systems. ICP Vortex (aka Adaptec) were providing drivers on their web site for FreeBSD 4.x and 5.x that are included in both source trees ... it was a binary driver, as far as I'm aware, but source code ... and Adaptec doesn't provide documentation ... I don't think that binary only drivers are well enough. Surely better than nothing but ... Don't forget that an open source team sometimes makes api changes that might break a binary only driver. And companies sometimes are slow in fixing. Or the vendor did some mistakes in his own driver. First the paying customers are served. All the other folks (open source ..) surely will come last. For some smaller corps supporting open source developers is simply a burden that costs time and so money. I know this from a medium sized german company producing nice audio recording cards. It was impossible to get a card and documentation from them for a FreeBSD developers. And after weeks and months of asking via e-mail they decided finally to tell the truth that they don't want to support open source developers anymore, it makes too much work. They are unable to spend so much time answering open source developers questions although they got documentation. This experience they made with Linux developers. Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/
Re: The future of NetBSD
I don't think that binary only drivers are well enough. Surely better than nothing but ... No fucking way. No support is FAR FAR better than a blob. Yes, really! Don't forget that an open source team sometimes makes api changes that might break a binary only driver. And companies sometimes are slow in fixing. A.K.A. Never. And when they try it usually doesn't work right. Worst of all *you* have no clue how they kludged a so called fix together. Vendor code is usually pretty darn bad and I wonder why people never revolt against that. Or the vendor did some mistakes in his own driver. First the paying customers are served. All the other folks (open source ..) surely will come last. Open source users paid for the hardware didn't they? Or because they use an alternative OS now they stole the hardware? This argument is retarded. For some smaller corps supporting open source developers is simply a burden that costs time and so money. Docs are part of the development process. If they are not than you don't want that hardware. I know this from a medium sized german company producing nice audio recording cards. It was impossible to get a card and documentation from them for a FreeBSD developers. And after weeks and months of asking via e-mail they decided finally to tell the truth that they don't want to support open source developers anymore, it makes too much work. They are unable to spend so much time answering open source developers questions although they got documentation. This experience they made with Linux developers. I call horseshit on this one too. Vendors do not have to support shit if they free their docs. NOTHING because the OS developers will do it for FREE for them. This argument is a steaming pile of shit with peanuts in it. It is this attitude that is killing Linux and FreeBSD. They will allow anyone to shit and piss in their sandbox and say GREAT THANKS! You people need to get through your heads that blobs are killing your operating system that you pretend to care so much about. Allowing blobs is the equivalent of eating fast food; it is convenient now but 10 years from now your ass wont fit through the door. A man will fight harder for his interests than for his rights. -- Napoleon Bonaparte Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/
Re: The future of NetBSD
On Tue, 5 Sep 2006 08:55:42 +0200, Andreas Klemm [EMAIL PROTECTED] said: On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote: On Thu, 31 Aug 2006, Constantine A. Murenin wrote: On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: Just a stupid comment, but ... Linux is one kernel, multiple distributions ... BSD is, what, 4 kernels now? If we worked more together instead of as seperate camps, it might make things a bit easier, no? Isn't there still fewer differences between *BSD operating systems than between different GNU/Linux distributions and kernel releases? :) Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? Are you really sure ? I see it more this way: For Linux on kernel (or device driver) level they only have to support 2 main trains: 2.4.x and 2.6.x. The 50 distributions are only a burden if it comes to the point what different shared library / Java / TCL / etc ... versions are packaged with the OS. A friend of mine doing Java development had severe issues with all that different Linux versions. But a simple kernel driver only has to honour different CPU types and the 2.4 and 2.6 tree and maybe now a development tree but am not sure on the latter ... Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? - http://www.apsfilter.org/ For what it's worth: Linux kernel interfaces change every day - I mean every minor release. Linux makes it very hard to support drivers for it. Just look inside a module DEVELOPED OUTSIDE THE KERNEL TREE, you will see an incredible mess of #if KERNEL_VERSION... Virtualy everyone that started some module gave up supporting it. If it is not picked up by the kernel or by some Debian developer, the module dissapears.The internet is littered with orphaned Linux modules. Best Regards -- Stefan Bojilov [EMAIL PROTECTED] -- http://www.fastmail.fm - A no graphics, no pop-ups email service
Re: The future of NetBSD
On 9/2/06, Marc Espie [EMAIL PROTECTED] wrote: The BSDs have always been about the code, not the organization. quoted for truth.
Re: The future of NetBSD
On Sat, Sep 02, 2006 at 05:30:23PM +0200, Timo Schoeler wrote: please stop this thread. you're like a whining child that didn't... Weinen? Ich hast weinen nicht, aber du, du hast weinen ins eine Deutsche liste schreibt. Danke, du hast mir lachen gemachen. there is black and white. you can promote open source and demand open documentation, or even open hardware (which would be best; projects of this character do exist). Timo, if you just would shut up and hack you would fit in even better. -- Brett Lymn
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 01:15:09PM -0700, Jon R H wrote: There is no way anybody can win from any of this! That's the worst part of it all! all BSD's will are suffering! Nope. I don't see OpenBSD suffering from this, not for real. The BSDs have always been about the code, not the organization. As long as there are people writing good code with a reasonable licence, who cares where they live ? Certainly not I.
Re: The future of NetBSD
thus Marc Espie spake: On Fri, Sep 01, 2006 at 01:15:09PM -0700, Jon R H wrote: There is no way anybody can win from any of this! That's the worst part of it all! all BSD's will are suffering! Nope. I don't see OpenBSD suffering from this, not for real. i back this :) The BSDs have always been about the code, not the organization. yes, and that's why (IMHO) NetBSD has really a problem; since a few days there's 'discussion' about whether or not use or accept blobs. i fully comply to OpenBSDs philosophy here. it's not only a technical thing, it's about (the projects) politics, metaphysics and more. it's one of the most important issues that ever came up in the recent months on NetBSD MLs, and it's being ignored. as a long year user of the three 'major' BSDs myself, i am now realizing (especially after Charles M. Hannums post) that there will be only two BSDs left in our portfolio from the week to come. that means switching a few dozen (!) servers at customers as well as our development of appliances. fortunately, our internal servers were switched some time ago to one of the two remaining BSDs, or commercial UNIX (non-x86/amd64). As long as there are people writing good code with a reasonable licence, who cares where they live ? Certainly not I. neither do i. two last sentences: every OS (or project building, maintaining, running an open source OS) deserves it's developers' politics. if NetBSD suffers that much from it's developers that it 'dies', well, then it be so. i appreciate the OpenBSDs community efforts in building and maintaining a *real* open source OS very much. thank you! cheers, -- Timo Schoeler | http://riscworks.net/~tis | [EMAIL PROTECTED] RISCworks -- Perfection is a powerful message ISP | POWER PowerPC afficinados | Networking, Security, BSD services GPG Key fingerprint = B5F6 68A4 EC45 C309 6770 38C4 50E8 2740 9E0C F20A Frankie says: Relax
Re: The future of NetBSD
On Sat, Sep 02, 2006 at 01:47:59PM +0200, Timo Schoeler wrote: it's one of the most important issues that ever came up in the recent months on NetBSD MLs, and it's being ignored. No, Timo, it's not being ignored. You just cannot accept the answer is something different to what you want. You'll probably be happier here. -- Brett Lymn
Re: The future of NetBSD
thus Brett Lymn spake:
On Sat, Sep 02, 2006 at 01:47:59PM +0200, Timo Schoeler wrote:
it's one of the most important issues that ever came up in the recent
months on NetBSD MLs, and it's being ignored.
No, Timo, it's not being ignored.
not any longer, yes, as there come replies that back my opinion that
blobs are evil and do not comply with NetBSDs (former?) 'portability and
clean architecture listed as its goals' (quote).
but you do behave as if you as an individuum represent not only NetBSDs
core teams' opinion(s), but that of the whole developer community, and
claim your 'if my gaming station which runs Linux can take blobs without
exploding, NetBSD can do this, too'.
You just cannot accept the answer
is something different to what you want.
you certainly have not the smallest idea of 'what i want'. i am just
pointing to the above statement ('portability and clean architecture
listed as its goals', to remind you).
you are very presumptuous.
You'll probably be happier here.
as i told you, the company i work for and i myself used to run all
'three major BSDs' *as well as* a bunch of proprietary Unices on
professional hardware (read: non-PeeCee hardware; yes, even if you don't
know of such, it still exists).
the obvious death of NetBSD and the screaming of its degenerated
developers as soon as one reminds them of their 'project goals' show the
way to go: drop it.
please stop this thread. you're like a whining child that didn't win a
discussion because it has had only false and rotten arguments and now
complains it lost.
there is black and white. you can promote open source and demand open
documentation, or even open hardware (which would be best; projects of
this character do exist).
or you can start accepting blobs, closed this and that, and finally sell
you soul. it's up to you and i couldn't mind less about it. but the
question then is why did NetBSD ever exist? you can promote Linux or
even Windows with your opinion.
--
Timo Schoeler | http://riscworks.net/~tis | [EMAIL PROTECTED]
RISCworks -- Perfection is a powerful message
ISP | POWER PowerPC afficinados | Networking, Security, BSD services
GPG Key fingerprint = B5F6 68A4 EC45 C309 6770 38C4 50E8 2740 9E0C F20A
Frankie says: Relax
Re: The future of NetBSD
On 9/1/06 9:38 PM, [EMAIL PROTECTED] wrote: Unfortunately, looking at it from the vendors' side, I can at least see their point: what is the business case in creating and maintaining good documentation? They basically need *financial* motivation for taking an engineer off a project to write the documentation (or hire a technical writer, but either way, it's intellectual capital that they perceive as not making money). I'm sure a business case could be made, but I'm sure these big vendors have pretty conservative cultures that discourages out-of-box thinking. In this industry parts and products without good documentation are completely clueless. OpenBSD for example is still alive largely because of the miraculous documentation. Companies can hold documentation for themselves but they cannot maintain software for hardware without good documentation. +++chefren
Re: The future of NetBSD
Gilbert Fernandes wrote on Fri, Sep 01, 2006 at 11:59:57AM +0200: I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. Horrors! Options are mostly against the goals of OpenBSD. I, for one, want as little of them as possible. The less complicated something is, the easier it is to maintain. Correctness is too often sacrificed to complexity. That's exactly the main reason why i hate Debian GNU/Linux so much. Options abound, and at least 95% of them are completely useless. You can hardly imagine how much time i already lost digging through literally thousands of lines of completely useless script files, scripts that are advertised for option management - desperately trying to track down some problem in Debian that would have been completely trivial to solve when encountered while using OpenBSD. Some of the worst examples that come to mind look like /etc/cron.* /etc/logrotate.d /etc/alternatives /etc/init.d /etc/rc?.d, runlevels in general and the grub boot manager - and last not least that whole dpkg-query/dpkg-deb/dpkg/apt-cache/apt-get/dselect/aptitude jungle. Zillions of options - and you can not even decide to not use most of them, but are usually forced to learn at least a bit about nearly all of them. Besides, i don't want an option to compile a blob-free kernel, but i want a completely free operating system. Besides, i don't want security options but security by default. It is nice NetBSD, FreeBSD and OpenBSD developers have the option to freely copy code from each other whenever it fits the need at hand. It is also nice to have the option to run either. But stay away from me with any additional options... By the way, there are also a few corners in OpenBSD where options are overdone - if i understand correctly, mostly for historical reasons. The standard example of course is mailwrapper(8) - well, even the man page says so. But i would gladly trash securelevel(7), too, just to give one additional example.
Re: The future of NetBSD
Theo de Raadt wrote: [snip] We know one reason why we never got documentation. Bit by bit more information has come out to show that the hardware design is an embarrasment and there are countless bugs and shortcomings. Surprising? Not really. Affects ONLY OpenBSD? Not a chance. That's why I follow [EMAIL PROTECTED] I don't think I'm alone.
Re: The future of NetBSD
I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. But when you tell yourself that it cannot be done, you don't even try it. It would require people to not only do it for the sake of their projects, but for the whole BSD people. Even those who really piss you off in other projects. Because someday, those projects will live on without us. We'll pass on like everyone. Am I alone thinking this ? -- unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep
Re: The future of NetBSD
On 01/09/06, Gilbert Fernandes [EMAIL PROTECTED] wrote: I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. But when you tell yourself that it cannot be done, you don't even try it. It would require people to not only do it for the sake of their projects, but for the whole BSD people. Even those who really piss you off in other projects. Because someday, those projects will live on without us. We'll pass on like everyone. Am I alone thinking this ? -- BSD isn't Germany. It's more like Korea ;-) Jeff.
Re: The future of NetBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It would require people to not only do it for the sake of their projects, but for the whole BSD people. Even those who really piss you off in other projects. Because someday, those projects will live on without us. We'll pass on like everyone. Am I alone thinking this ? You're completely right, diversity always hurts an ecosystem *rolls eyes* Let's be serious here, each of the mainstream BSDs have their places, and I'm glad they're separate. I'd run OpenBSD on a soekris box on the fringe of my network, FreeBSD on my 4-way Opteron interactive server, and NetBSD on my Tamagotchi (http://en.wikipedia.org/wiki/ Tamagotchi). They all have their places, by merging them you lose a lot of the focus of keeping them separate. Besides some largely impractical good feeling that we'd derive from unifying the projects, there's absolutely no reason to unify them. And to be frank, some people you don't want to work together, there's a reason DragonFlyBSD forked from FreeBSD, and there's a reason OpenBSD forked from NetBSD; not to say this is a bad thing at all, but trying to make people get along to volunteer their time on a project is outright retarded. Developers who like the goals and team of the FreeBSD project will gravitate that way, same with OpenBSD, NetBSD and DragonFlyBSD. NetBSD isn't having trouble because of OpenBSD forking from it, or from FreeBSD's recent innovations, NetBSD is having trouble because of actions taken by those within the project, unification accomplishes nothing in the realm of practicality. Cheers, - -R. Tyler Ballance iD4DBQFE+A6PqO6nEJfroRsRArKFAJjgWGbVS3w1BmmYPThRTRoTWxLvAJsEpzpK 4ZUDjBGTprGcNsOgYYrszw== =SMpu -END PGP SIGNATURE-
Re: The future of NetBSD
2006/9/1, Gilbert Fernandes [EMAIL PROTECTED]: I have a dream. A dream of unification. Having one BSD. Merging the three projects and, why not, keeping incompatible stuff as options that would be either one or another. Opensource is about choice. If you don't like something, when fork it and do it as you wish. That's why we have 3 open BSDs (not OpenBSDs ;)). Period.
Re: The future of NetBSD
From: Charles M. Hannum On Fri, Sep 01, 2006 at 01:08:13AM +0200, Matthias Kilian wrote: They don't have to write device drivers at all, they just should write good documentation. What we really want is not just documentation, but support from their engineers. The Linux community is starting to get this in some places. Fine, great, and the liklihood of vendors concerned about their bottom line contributing much time and energy to something that won't contribute *directly* to their bottom line... Good luck. We know that happens _all the time_. I'm sure in no time at all the Linux devs will be waist deep in vendor engineers. Why does it need to be spelled out? Of course bad documentation isn't what anyone wants. Duh. Like, what docs does a vendor engineering division give to the developers who write the drivers internally? They don't give them bad docs. They give them functional, useful docs. Does it need to be stated that any project wanting to compose useful support for the same hardware shouldn't get the same level of docs? I would sooner have access to good hardware docs than a vendor engineer paid by a closed-minded BoD who is there to attempt to silver-tongue the developer into just adopting some OSS driver crap (or steering them towards a blob.) DS
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 10:40:01AM -0700, Spruell, Darren-Perot wrote: Like, what docs does a vendor engineering division give to the developers who write the drivers internally? They don't give them bad docs. They give them functional, useful docs. Does it need to be stated that any project wanting to compose useful support for the same hardware shouldn't get the same level of docs? Sorry, but that's the core fallacy in your argument. In many cases, there are no functional, useful docs. They just don't exist. Certainly this is a problem in itself.
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 01:08:13AM +0200, Matthias Kilian wrote: They don't have to write device drivers at all, they just should write good documentation. Unfortunately, the documentation often isn't so hot either. I'll give you an example. Even with both code and documentation from Realtek, we still had to reverse engineer how some parts of the RTL8180 work. And though it works now, our understanding is still incomplete. It is far easier for a manufacturer to spew out a Windows driver in-house, where they have direct access to the people who designed the hardware, so this is what they do. The Windows driver model is pretty much designed around this approach. What we really want is not just documentation, but support from their engineers. The Linux community is starting to get this in some places.
Re: The future of NetBSD
I was happy to continue lurking and not trolling, but it appears some Open Source users still don't get it, and I figured perhaps by saying it again might enlighten a few more. On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: what my point is, though, is if we aren't willing to accept 'vendor written drivers', then it is *we* that are limiting our growth but limiting what hardware we can run stably on ... Sadly, you've twisted the point in the wrong direction. Since we aren't willing to accept 'vendor written drivers', those vendors don't deserve our advocacy or our dollars. *We* did not limit our growth, the vendors limit theirs: by not being able to sell to our market. Time and Again I've seen the OpenBSD team make a request documentation in order to make drivers, time and again I've seen that request denied. Simply put, the vendor is closing their door on a chance to make more revenue and thus increase profits for their company by not providing the correct documentation to open source developers. I'll go back to lurking now. Peter Verhagen PS: Vote with your $$$ people. It works! /* status: just an OpenBSD [l]user */
Re: The future of NetBSD
Whyzzi wrote: On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: what my point is, though, is if we aren't willing to accept 'vendor written drivers', then it is *we* that are limiting our growth but limiting what hardware we can run stably on ... Sadly, you've twisted the point in the wrong direction. Since we aren't willing to accept 'vendor written drivers', those vendors don't deserve our advocacy or our dollars. *We* did not limit our growth, the vendors limit theirs: by not being able to sell to our market. Time and Again I've seen the OpenBSD team make a request documentation in order to make drivers, time and again I've seen that request denied. Simply put, the vendor is closing their door on a chance to make more revenue and thus increase profits for their company by not providing the correct documentation to open source developers. Not only that, but since when is it part of OpenBSD's goals to meet some sort of growth projection? In particular, it is stated on the Project Goals page of OpenBSD.org: Pay attention to security problems and fix them before anyone else does. This cannot be achieved by allowing closed source / closed documentation into the project. It's Open BSD. It only makes sense that the project supports hardware vendors which support the project goals. We don't need every vendor to recognize that it is in their best interests to support the project goals, but we definitely DO NOT want to imply to vendors that we will compromise those goals. We are the customers - and when the vendor loses sight of what customers want, they lose sales and another vendor moves in to fill the void. If we don't make it clear that we want open documentation then no one will provide it. The market is dynamic - just look at any stock exchange! Use that to your advantage and don't support closed vendors. I don't know why so many projects appear to be centered on the idea that they need to outstrip the user bases of other OSes. If it works for you then use it (and support it, financially if you cannot support it any other way!). If it doesn't work for you then go find something that does. Who cares how many other people are using it? Worry about the goals of the project and the results (vendors getting on board, a larger user base, etc.) will follow. I think it is likely that the user bases of certain projects don't want to take responsibility for their hardware purchases, and as a result have hoodwinked the developers into making poor decisions about project goals. The users want to go out and buy any part and have it just work. They don't want to do any research first to make sure it is the right purchase. They want to close their eyes to reality and instead hope that the companies selling hardware will do the right thing, when it flies in the face of common sense for an entity whose entire purpose is maximize shareholder profit to do the right thing. It is a typical case of consumer apathy, and the projects that cater to this apathy will only hurt themselves in the long run. They will grow unmanageable projects which constantly break, and that breakage will be outside of the control of the developers and in the hands of hardware vendors trying to push new products. Dozens of messages on this topic and it is merely doing what I predicted it would do - wasting the resources of the OpenBSD mailing list. Nothing is being solved by this discussion, and the very little of it that deals with OpenBSD only does so in a roundabout way. Breeno PS - KILL THIS THREAD. Stop replying to it and it will go away. There never was any point to it which affected OpenBSD. The woes of a subset of NetBSD devs / users do not affect OpenBSD. If NetBSD ever did die as a project then the user base would move on, the devs would move on, and new developers would move in to tackle new projects and pick up slack. Open Source is a dynamic environment and change will not kill it. Change is unavoidable but people adapt to it.
Re: The future of NetBSD
On Friday 01 September 2006 11:27, Charles M. Hannum wrote: On Fri, Sep 01, 2006 at 01:08:13AM +0200, Matthias Kilian wrote: They don't have to write device drivers at all, they just should write good documentation. Unfortunately, the documentation often isn't so hot either. I'll give you an example. Even with both code and documentation from Realtek, we still had to reverse engineer how some parts of the RTL8180 work. And though it works now, our understanding is still incomplete. It is far easier for a manufacturer to spew out a Windows driver in-house, where they have direct access to the people who designed the hardware, so this is what they do. The Windows driver model is pretty much designed around this approach. What we really want is not just documentation, but support from their engineers. The Linux community is starting to get this in some places. Yes. In many cases, the reason a company doesn't want to release documentation is because it doesn't really exist, except in phone calls or e-mails between the Windows driver writer and the hardware guys. Software folks are notorious for poor documentation. It would be unrealistic for us to expect hardware folks to do a substantially better job. -- John Baldwin
Re: The future of NetBSD
On Friday 01 September 2006 19:40, Spruell, Darren-Perot wrote: Like, what docs does a vendor engineering division give to the developers who write the drivers internally? They don't give them bad docs. They give them functional, useful docs. Does it need to be stated that any project wanting to compose useful support for the same hardware shouldn't get the same level of docs? MUAAAAHAHHAHAHAHHAHAH they don't give them bad docs!?!?!?? Have you seen the quality level of docs given out from the engineering divisions at most chip manufacturers? Usually it is in edit state and hacked up from the previous version in the chip family. Graphic chip vendors are the worse. The manuals usually doesn't even reflect the actual functionality but what the designer whished for at planning stage. So even if docs *were* given out they would be incomplete and full of bugs! Why? Because they were never intended for public use! The GOOD docs does not usually exist.
Re: The future of NetBSD
From: Charles M. Hannum [mailto:[EMAIL PROTECTED] On Fri, Sep 01, 2006 at 10:40:01AM -0700, Spruell, Darren-Perot wrote: Like, what docs does a vendor engineering division give to the developers who write the drivers internally? They don't give them bad docs. They give them functional, useful docs. Does it need to be stated that any project wanting to compose useful support for the same hardware shouldn't get the same level of docs? Sorry, but that's the core fallacy in your argument. In many cases, there are no functional, useful docs. They just don't exist. Certainly this is a problem in itself. Certainly it is. So why bother resorting to vendor-supplied drivers (OSS or blob) derived from originally piss-poor docs in the first place? If the docs are bad, then the results of those docs are derivatively worse as a result. Users don't want this, and developers don't want this either. DS
Re: The future of NetBSD
On Fri, Sep 01, 2006 at 12:16:59PM -0700, Spruell, Darren-Perot wrote: From: Charles M. Hannum [mailto:[EMAIL PROTECTED] On Fri, Sep 01, 2006 at 10:40:01AM -0700, Spruell, Darren-Perot wrote: Like, what docs does a vendor engineering division give to the developers who write the drivers internally? They don't give them bad docs. They give them functional, useful docs. Does it need to be stated that any project wanting to compose useful support for the same hardware shouldn't get the same level of docs? Sorry, but that's the core fallacy in your argument. In many cases, there are no functional, useful docs. They just don't exist. Certainly this is a problem in itself. Certainly it is. So why bother resorting to vendor-supplied drivers (OSS or blob) derived from originally piss-poor docs in the first place? If the docs are bad, then the results of those docs are derivatively worse as a result. That's not actually true. You're still using the fallacy that the vendor driver is written based on the documentation -- but in fact there are other inputs, like discussion with the hardware engineers. Sometimes there are pieces you just can't get from the documentation, because they're not there, but they are present in the driver. In the current climate, having both is almost always better than having only one -- and certainly having the code is better than having nothing. I'm not against harassing the hardware vendors to do better.
Re: The future of NetBSD
There is no way anybody can win from any of this! That's the worst part of it all! all BSD's will are suffering! The future is always looking back to see what it has to work with! There is no future with out a past! The software its self ( BSD's) is smarter them the ones making it. Thats the point of failure (humans), the weak link in all of it ! Just having safe by defalt rule proves nothing! The software is only as safe as the minds who made it The point of failure is to think it is safe! - Original Message - From: Nick Guenther [EMAIL PROTECTED] To: OpenBSD-Misc misc@openbsd.org Sent: Wednesday, August 30, 2006 5:31 PM Subject: Re: The future of NetBSD On 8/30/06, Charles M. Hannum [EMAIL PROTECTED] wrote: The NetBSD Project has stagnated to the point of irrelevance. It has gotten to the point that being associated with the project is often more of a liability than an asset. I will attempt to explain how this happened, what the current state of affairs is, and what needs to be done to attempt to fix the situation. [snip] Much of this early structure (CVS, web site, cabal, etc.) was copied verbatim by other open source (this term not being in wide use yet) projects -- even the form of the project name and the term core. This later became a kind of standard template for starting up an open source project. That's very interesting history, if true (and I don't see why it wouldn't be)! Don't feel bad then, if you have accomplished that. [snip] -- At this point most readers are probably wondering whether I'm just writing a eulogy for the NetBSD project. In some ways, I am -- it's clear that the project, as it currently exists, has no future. It will continue to fall further behind, and to become even less relevant. This is a sad conclusion to a project that had such bright prospects when it started. I admit that I may be wrong about this, but I assume that most people who have contributed to NetBSD, and/or continue to do so, do not desire to see the project wallow away like this. So I will outline what I think is the only way out: [snip] *cough*Most of these ideas have been in the OpenBSD culture from the beginning*cough* - Charles Hannum - past founder, developer, president and director of The NetBSD Project and The NetBSD Foundation; sole proprietor of The NetBSD Mission; proprietor of The NetBSD CD Project. [I'm CCing this to FreeBSD and OpenBSD lists in order to share it with the wider *BSD community, not to start a flame war. I hope that people reading it have the tact to be respectful of their peers, and consider how some of these issues may apply to them as well.] Um. Wow. I think Theo wins. -Nick
Re: The future of NetBSD
On 08/31/06 01:27, Charles M. Hannum wrote: The NetBSD Project has stagnated to the point of irrelevance. Stop whining and spamming to get interest for your broken project and start doing something interesting, this future of... has clearly nothing to do with that. Shut up and code! instead of spreading stupid politics. ---chefren
Re: The future of NetBSD
Andy Ruhl wrote: On 8/30/06, Charles M. Hannum [EMAIL PROTECTED] wrote: The NetBSD Project has stagnated to the point of irrelevance. It has Let me start by saying I'm probably not qualified to reply to this thread, but I was never worried about making a fool out of myself before so here goes... I am a former user of FreeBSD and occasional user of OpenBSD. Haven't had much experience with either in the last year or so. So... Stagnant? Yes. Irrelevance? Possibly. But, BUT, can anyone tell me where I can get an OS that I can build easily from the same place to run on my NEC PDA as well as an old IBM PowerPC box I just happened to have sitting around and doing nothing else? And I'm typing this now on an AMD64 box that ran stably long before FreeBSD did (yes, I tested both). Nobody else can say that. Is it relevant? It's funny how much more relevant NetBSD's philosophy becomes as i386 becomes irrelevant. While the others (FreeBSD in particular) seemed to be scrambling for another architecture, NetBSD just quietly supported them without any fanfare (IA-64 excluded, but it's more irrelevant than NetBSD!). There are strengths that go right down to the core of the project. They are still there. They won't ever be irrelevant. They just need to be built upon. The cleanliness, portability, and ease of use is there. So you're probably right. A strong leader is needed to recruit people to complete new projects and generally keep things relevant. If it's a people problem, I hope someone can fix it. Too bad the guy who used to say I probably don't know what I'm talking about isn't here to comment. Andy With a straight line like that, I cannot resist: Seems like somebody is complaining that stability is the same thing as stagnating to the point of irrelevance. A chicken running around sans head is quite active. Not really the same thing as productive. Microsoft Windows goes patch-happy, and the rate for compromised machines goes to five cents each. I don't know what I'm talking about (no probably about it) but there's stuff running around considerably worse.
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 12:01:07AM -0500, [EMAIL PROTECTED] wrote: A chicken running around sans head is quite active. Not really the same thing as productive. What you don't see is that NetBSD is the chicken in your analogy.
Re: The future of NetBSD
Marc G. Fournier wrote: Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... Because committees are famous for creating great designs --- Lars Hansson
Re: The future of NetBSD
Thorsten Glaser wrote: Nick Guenther dixit: Um. Wow. I think Theo wins. OpenBSD has had MicroBSD forked off twice, MirOS and ekkoBSD too. Ok I'll bite, since I can speak quite well (not definitively however) for ekkoBSD. I can't speak for the exact reason the fork happened (since I didn't start it), but I can speak for a couple of us who got involved very early and ended up playing major roles (relatively speaking, this was a small project where not much progress was ever made) almost entirely by accident. ekkoBSD was not forked (in my understanding) because of any perceived stagnation in OpenBSD, nor any lack of leadership, nor long term viability. It was forked because there were very clear goals for OpenBSD and we thought the code-base could be taken in another direction. OpenBSD was used because we had (and have) a tremendous respect for OpenBSD, Theo, and the entire core of active developers. I suspect a lack of respect for Theo may have played a role in the founder's motives, but not for those of us who got involved and kept it going as long as it did. What we discovered during that time was in line with Nick's analysis, Theo has the right project organization for OpenBSD. We had a core group which largely consisted of people interesting in tinkering but without a strong drive for the project itself. I (and I suspect the others I purport to speak for) would have stuck around as long as the project was being driven forward along its goals, but achieving those goals always seemed like someone else's problem. As for NetBSD, for as long as I've been interested (a little more than 5 years now, not back to the old-days of NetBSD) it's always seemed to be the kind of system driven by tinkering. I would expect that to lead to the of lack of progress Charles talks about, but I don't see a reason to be that alarmist for a system that I've always considered to be moving along in exactly the way being described. -- Stephen Paskaluk
Re: The future of NetBSD
On 31/08/06, Gilles Gravier [EMAIL PROTECTED] wrote: Andy Ruhl wrote: The reason why apache and perl shouldn't be included is because they are moving, 3rd party targets. They are better suited to pkgsrc. And of course, GCC isn't... a moving 3rd party target? Gilles. Good point. It's also licensed under that bad boy of the we're-proprietary-but-we-want-to-appear-friendly-to-open-source world, the General Public Licence. Jeff.
Re: The future of NetBSD
I read in some business management book somewhere that took a Machiavelli approach that said: If you want to kill a project, send it to a committee. On Thu, 31 Aug 2006 23:01:11 +0800, Lars Hansson wrote Marc G. Fournier wrote: Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... Because committees are famous for creating great designs --- Lars Hansson
Re: The future of NetBSD
On 8/31/06, Marc G. Fournier [EMAIL PROTECTED] wrote: Just a stupid comment, but ... Linux is one kernel, multiple distributions ... BSD is, what, 4 kernels now? If we worked more together instead of as seperate camps, it might make things a bit easier, no? Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... Yes, because we all want Scott Long defending binary blobs in the kernel (*cough* adaptec *cough*). Pigs will fly long before OpenBSD imports a NDIS wrapper into the tree. A more common BSD? for what? what I want to run runs on OpenBSD and DragonflyBSD. when FreeBSD or NetBSD does something I care about, I'll care about them then and only then. Sorry, FreeBSD seems to want Linux's fame and fortune and is gladly giving away its history of a stable, clean codebase to get it. The winning logo was honestly the last straw for me, though, so maybe that says something about me... Anyway, all this jibber jabber is off topic and I already feel stupid for replying to it.
Re: The future of NetBSD
Sorry, FreeBSD seems to want Linux's fame and fortune and is gladly giving away its history of a stable, clean codebase to get it. The winning logo was honestly the last straw for me, though, so maybe that says something about me... Yes, it means you are mixing purely technical points with completely irrelevant stuff. In other words: your reasoning is flawed. Find a better excuse not to use FreeBSD than its logo change. Miod
Re: The future of NetBSD
On 31/08/06, Miod Vallat [EMAIL PROTECTED] wrote: Sorry, FreeBSD seems to want Linux's fame and fortune and is gladly giving away its history of a stable, clean codebase to get it. The winning logo was honestly the last straw for me, though, so maybe that says something about me... Yes, it means you are mixing purely technical points with completely irrelevant stuff. In other words: your reasoning is flawed. Find a better excuse not to use FreeBSD than its logo change. Does their redesigned-to-be-fancy-and-*unusable* web-site sound like a better and more technical excuse? :)
Re: The future of NetBSD
On Thu, 31 Aug 2006 19:28:29 -0300 (ADT), Marc G. Fournier wrote: I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? Please take this back to freeBSD only or bother netBSD if you must. It is irrelevant to OpenBSD which does NOT want drivers, binary or source. Just docs. Drivers written by OpenBSD developers tend to be less buggy and any bugs seem to get rapid attention. It depends on the docs. Nothing more. (un)Free can do whatever it wishes. From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server. Your IP address will also be greytrapped for 24 hours after any attempt. I am continually amazed by the people who run OpenBSD who don't take this advice. I always expected a smarter class. I guess not.
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 05:44:00PM +0200, Johnny Billquist wrote: Andy Ruhl wrote: On 8/31/06, Thorsten Glaser [EMAIL PROTECTED] wrote: BSD is about an operating system, not about a kernel. Bingo. Good point. This point is lost sometimes. I believe NetBSD has the proper philosophy in regards to the entire OS as well. I don't want apache built in, for instance. This is a silly definition (imho) which I first heard Stallman use, but seems to be spreading. Every book on operating systems that I own, or have read, defines an operating system as the kernel. Different applications, including even shells, are not the operating system. But that's just my opinion, of course. But most of all, I don't see the relevance of bringing the discussion down to a hair-splitting of what an operating system is. Actually, defining (poorly) the OS to include so much else has been a liability for NetBSD in many ways. It has massively slowed the adoption of new software versions (e.g. GCC), for one. It also contributed to the perception that a better package system and automatic updates were not a serious issue.
Re: The future of NetBSD
Ahem... so no Apache... but why games, X11, compiler? After all, an OS isn't necessarily a development platform either. Or a graphics workstation environment either. Or a game platform either. As time goes by, the definition of what is part of an OS and what is a separate application evolves. We aren't living in 1960 anymore. We are in 2006. NetBSD definitely needs to stay up-to-date with what a fantastic operating system should be. Gilles. Andy Ruhl wrote: On 8/31/06, Thorsten Glaser [EMAIL PROTECTED] wrote: BSD is about an operating system, not about a kernel. Bingo. Good point. This point is lost sometimes. I believe NetBSD has the proper philosophy in regards to the entire OS as well. I don't want apache built in, for instance. Andy
Re: The future of NetBSD
Benny Siegert dixit: A very pessimistic article but well worth a read: http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html You could've just replied to it so that the References: header can be perused. I've changed this mail to reply to it for threading. Charles M. Hannum dixit: Much of this early structure (CVS, web site, cabal, etc.) was copied verbatim by other open source (this term not being in wide use yet) projects -- even the form of the project name and the term core. This later became a kind of standard template for starting up an open source project. Unfortunately, we made some mistakes here. As we've seen over the years, one of the great successes of Linux was that it had a strong leader, who set goals and directions, and was able to get people to do what he wanted -- or find someone else to do it. On the other hand, the bazaar model of Linux leads to bad code and no well-defined APIs. While it's true that the core-team model _might_ benefit from a strong leadership, care should be taken to avoid Linux' success because it'll be its failure soon enough. (I mean, hey, 5 new kernels in 2 days, wtf?) Nick Guenther dixit: Um. Wow. I think Theo wins. OpenBSD has had MicroBSD forked off twice, MirOS and ekkoBSD too. Travers Buda dixit: As for Charles M. Hannum: fork! I don't think so, as long as he can improve the inner status of the NetBSD project. Forking is the solution if you're outside, want to improve and are ignored, or, if you're inside but don't see your interesting new ideas being accepted well or fitting within the project's overall policy (DragonFly). Andy Ball dixit: suspend and resume work on my laptop. I know that work is being done on PowerNow! for AMD K6-2+, Athlon etc. Incidentally, Martin Vigiard's PowerNow work showed up in OpenBSD and FreeBSD. first, in NetBSD. last. @OpenBSD people: I did leave this mailing list, I'm just keeping the Cc: list. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
I'm just a lurker on the OpenBSD list, but I think Charles is right about Linux. The code is better then people give it credit for, and considering it's vast popularity and what all it's accomplished, the bazaar model has worked wonders. I'm not advocating Linux, I'm just pointing out that considering where Linux is, where it's headed, who all is backing it, I really don't see it stagnating or dying anytime soon. If I'm correct, that's also what Charles thinks NetBSD needs among other things, to look at their model for inspiration. I agree. As Ingo said: I'm not a developer. Back to lurking. On 8/31/06, Thorsten Glaser [EMAIL PROTECTED] wrote: Benny Siegert dixit: A very pessimistic article but well worth a read: http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html You could've just replied to it so that the References: header can be perused. I've changed this mail to reply to it for threading. Charles M. Hannum dixit: Much of this early structure (CVS, web site, cabal, etc.) was copied verbatim by other open source (this term not being in wide use yet) projects -- even the form of the project name and the term core. This later became a kind of standard template for starting up an open source project. Unfortunately, we made some mistakes here. As we've seen over the years, one of the great successes of Linux was that it had a strong leader, who set goals and directions, and was able to get people to do what he wanted -- or find someone else to do it. On the other hand, the bazaar model of Linux leads to bad code and no well-defined APIs. While it's true that the core-team model _might_ benefit from a strong leadership, care should be taken to avoid Linux' success because it'll be its failure soon enough. (I mean, hey, 5 new kernels in 2 days, wtf?) Nick Guenther dixit: Um. Wow. I think Theo wins. OpenBSD has had MicroBSD forked off twice, MirOS and ekkoBSD too. Travers Buda dixit: As for Charles M. Hannum: fork! I don't think so, as long as he can improve the inner status of the NetBSD project. Forking is the solution if you're outside, want to improve and are ignored, or, if you're inside but don't see your interesting new ideas being accepted well or fitting within the project's overall policy (DragonFly). Andy Ball dixit: suspend and resume work on my laptop. I know that work is being done on PowerNow! for AMD K6-2+, Athlon etc. Incidentally, Martin Vigiard's PowerNow work showed up in OpenBSD and FreeBSD. first, in NetBSD. last. @OpenBSD people: I did leave this mailing list, I'm just keeping the Cc: list. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
On Aug 30, 2006, at 5:27 PM, Charles M. Hannum wrote: The NetBSD Project has stagnated to the point of irrelevance. As one of the 4 originators of NetBSD, I am in a fairly unique position. [I'm CCing this to FreeBSD and OpenBSD lists in order to share it with the wider *BSD community, not to start a flame war. I hope that people reading it have the tact to be respectful of their peers, and consider how some of these issues may apply to them as well.] Charles, obviously the Fates intend you to bring all that expertise over to OpenBSD and enrich the community which produces that Best of the BSD's with your experience, counsel and coding skills! --- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: The future of NetBSD
On 8/31/06, Thorsten Glaser [EMAIL PROTECTED] wrote: BSD is about an operating system, not about a kernel. Bingo. Good point. This point is lost sometimes. I believe NetBSD has the proper philosophy in regards to the entire OS as well. I don't want apache built in, for instance. Andy
Re: The future of NetBSD
I'm just a lurker on the OpenBSD list, but I think Charles is right about Linux. The code is better then people give it credit for, and considering it's vast popularity and what all it's accomplished, the bazaar model has worked wonders. Well, the hype certainly put the zap on your head. Wonders? So, if I take a picture of a van Gogh painting, copy it as poorly as a three-year-old child, put an OSI license on it and call it open van Gogh that would be wonderous? They are copying known work, shooting for a target that has already been hit. Ignore IBM's and ESR's hype. Linux is a rather poor re-implementation. The BS is the only thing that is accomplished, unless you count the illusions of grandeur as well. What I'd _really_ like to hear is the status of the total move-over to Linux that IBM announced (what was it?) 3 freakin years ago? How is that coming, old Big Bloser?
Re: The future of NetBSD
Marc G. Fournier dixit: (Please don't keep individual persons in the Cc, only the lists, otherwise people will get the mails several times.) Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... BSD is about an operating system, not about a kernel. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... BSD is about an operating system, not about a kernel. This is a common misconception. BSD is about people pissing each other, because they don't want to admit that other people can have different needs, goals, or ways of designing code, than themselves. This is why all this talking about BSD projects needing to merge is complete bullshit. Miod
Re: The future of NetBSD
On 8/31/06, Gilles Gravier [EMAIL PROTECTED] wrote: Ahem... so no Apache... but why games, X11, compiler? So don't install the games set, the X set, or the comp set if you don't want that stuff. I think the point I'm trying to make is, apache is certainly not something *most* people will use. There is argument in another thread about perl being included in the base distro, which is someting people will use more than apache probably. The reason why apache and perl shouldn't be included is because they are moving, 3rd party targets. They are better suited to pkgsrc. Andy
Re: The future of NetBSD
On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: On Thu, 31 Aug 2006, Harpalus a Como wrote: I'm just a lurker on the OpenBSD list, but I think Charles is right about Linux. The code is better then people give it credit for, and considering it's vast popularity and what all it's accomplished, the bazaar model has worked wonders. I'm not advocating Linux, I'm just pointing out that considering where Linux is, where it's headed, who all is backing it, I really don't see it stagnating or dying anytime soon. If I'm correct, that's also what Charles thinks NetBSD needs among other things, to look at their model for inspiration. I agree. Just a stupid comment, but ... Linux is one kernel, multiple distributions ... BSD is, what, 4 kernels now? If we worked more together instead of as seperate camps, it might make things a bit easier, no? Isn't there still fewer differences between *BSD operating systems than between different GNU/Linux distributions and kernel releases? :) Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals...
Re: The future of NetBSD
On Aug 31, 2006, at 6:06 PM, Miod Vallat wrote: BSD is about an operating system, not about a kernel. This is a common misconception. BSD is about people pissing each other, because they don't want to admit that other people can have different needs, goals, or ways of designing code, than themselves. I'm noone to talk about this, but this is *one* of the problems that seem to emerge in every project I've heard of, and surely it affects lots of projects more than the BSDs. Everywhere there are people pissing each other because they don't understand that the Truth is never on the same side, if something called truth even exists. According to my experience as dumb user, I've never found such a helpful community as the NetBSD one, so I think that what stated is excessive and unfair. This is why all this talking about BSD projects needing to merge is complete bullshit. The reason why merging is impossible or stupid has been said some million times... Different goals. It's only a positive thing that there is more than one project, also because of what you said above, although exaggerating. Do you think it would be better if everyone pursued the same things, knowing that users won't ever be a faceless mass of identical robots? Miod davide zanon www.redmist.altervista.org
Re: The future of NetBSD
Andy Ruhl wrote: The reason why apache and perl shouldn't be included is because they are moving, 3rd party targets. They are better suited to pkgsrc. And of course, GCC isn't... a moving 3rd party target? Gilles. -- /*Gilles Gravier*/ *=* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *=* *http://www.gravier.org/* ICQ : *77488526* http://www.icq.com/whitepages/about_me.php?Uin=77488526 * || *MSN Messenger : [EMAIL PROTECTED] http://members.msn.com/[EMAIL PROTECTED]* *Skype : ggravier callto://ggravier* || *Y! : ggravier http://profiles.yahoo.com/ggravier || AOL : gillesgravier aim:goim?screenname=gillesgravier PGP Key ID : *0x8DE6D026* http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026op=index Chastity is its own punishment. (/Solomon Short/) [/David Gerrold/] De toutes les aberrations sexuelles, la chasteti est la plus aberrante. [Anatole France]
Re: The future of NetBSD
Andy Ruhl wrote: On 8/31/06, Thorsten Glaser [EMAIL PROTECTED] wrote: BSD is about an operating system, not about a kernel. Bingo. Good point. This point is lost sometimes. I believe NetBSD has the proper philosophy in regards to the entire OS as well. I don't want apache built in, for instance. This is a silly definition (imho) which I first heard Stallman use, but seems to be spreading. Every book on operating systems that I own, or have read, defines an operating system as the kernel. Different applications, including even shells, are not the operating system. But that's just my opinion, of course. But most of all, I don't see the relevance of bringing the discussion down to a hair-splitting of what an operating system is. Johnny
Re: The future of NetBSD
On 8/31/06, Charles M. Hannum [EMAIL PROTECTED] wrote: Actually, defining (poorly) the OS to include so much else has been a liability for NetBSD in many ways. It has massively slowed the adoption of new software versions (e.g. GCC), for one. It also contributed to the perception that a better package system and automatic updates were not a serious issue. It would be interesting to hear more discussion on this. If there is a continuum that is what the definition of an OS is, with a bare kernel on the left and something like SuSE with multiple gigs of junk on the right, NetBSD is toward the left. I think consensus is among NetBSD people is that this is a good thing. If you want something, put it in pkgsrc. I think NetBSD deals with the compiler issue quite well. If a compiler must be part of the base OS, ship it with some fairly stable version. Then there are more recent versions in pkgsrc. And if you really want to do your own thing, download and compile your own. What's the big deal? Andy
Re: The future of NetBSD
On 31/08/06, Andy Ruhl [EMAIL PROTECTED] wrote: On 8/31/06, Charles M. Hannum [EMAIL PROTECTED] wrote: Actually, defining (poorly) the OS to include so much else has been a liability for NetBSD in many ways. It has massively slowed the adoption of new software versions (e.g. GCC), for one. It also contributed to the perception that a better package system and automatic updates were not a serious issue. It would be interesting to hear more discussion on this. If there is a continuum that is what the definition of an OS is, with a bare kernel on the left and something like SuSE with multiple gigs of junk on the right, NetBSD is toward the left. I think consensus is among NetBSD people is that this is a good thing. If you want something, put it in pkgsrc. To be fair, it's easy to remove 'junk' from SuSE, and not much harder to pile junk into a working Gentoo, Slackware or NetBSD installation. Ironically one complaint that's often voiced at SuSE is that its selection of rpm junk isn't as extensive as other distros'. Jeff.
Re: The future of NetBSD
On Thu, 31 Aug 2006, Constantine A. Murenin wrote: On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: Just a stupid comment, but ... Linux is one kernel, multiple distributions ... BSD is, what, 4 kernels now? If we worked more together instead of as seperate camps, it might make things a bit easier, no? Isn't there still fewer differences between *BSD operating systems than between different GNU/Linux distributions and kernel releases? :) Put together a *BSD core ... representative from each camp and try and steer the *kernel* itself towards a more common BSD ... I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no?
Re: The future of NetBSD
Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? Sure, support as a .o file, ready to link against a unique API. Just what Atheros delivers already. That's not something all BSD projects are willing to accept. Miod
Re: The future of NetBSD
Marc G. Fournier wrote: I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? How would a common API provide more support from the vendor ? What does the API have to do with releasing documentation ?
Re: The future of NetBSD
Please don't Cc: people when you respond to mailing lists *sigh* Marc G. Fournier dixit: for us, they need to write 1. Companies don't write drivers for BSD 2. Companies don't even release specs so that people can write drivers for BSD //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote: Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? Vendors should release documentation, not write drivers. -p.
Re: The future of NetBSD
On Fri, 1 Sep 2006, Gilles Chehade wrote: Marc G. Fournier wrote: I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? How would a common API provide more support from the vendor ? What does the API have to do with releasing documentation ? I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for?
Re: The future of NetBSD
I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? To fix the driver. A given piece of source code can only been believed correct until it is proven to be broken (unless you're Knuth, but he did not write device drivers). Even if the driver API is static, the hardware you'll want to use your particular card on isn't. New hardware may (and will) need tweaks to work on your new Uberathlon128 system in two years. If the driver happens to be working by chance on x86 because of, say, some cache behaviour future (read: legacy-free) hardware won't guarantee, what are you going to do? Beg the vendor to fix the driver for this card while it wants you to buy the new, expensive, device flavour which sports 128-bit bellswhistles? Fixing a subtly broken piece of code might not be as simple as adding bus_dmamap_sync() calls here and there. Miod
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote: Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD They don't have to write device drivers at all, they just should write good documentation. Some ten or twenty years ago, if you bought arbitrary hardware -- be it a radio, an audio tape drive, a television or even a computer -- you always got thorough documentation for the device, often including schematics, description of used integrated circuits etc. If your tape drive was broken, you could contact your local HiFi engineer, handle him the drive and the schematics, and got it repaired within a few days, even if he (the engineer) never got his hands on a device of the same brand. Even if the manufacturer of the device had vanished. Today, people happily accept and even *encourage* the use and inclusion of black boxes[1] that only the vendors can fix (if they want to, and if they still exist when problems occur). Even worse, people involved in free and open source operating systems encourage this habit. This is incredible. And for Adaptec, please remember the big aac(4) debacle popping up at the OpenBSD lists about a year ago. Ciao, Kili [1] Sometimes, the black boxes aren't black but white and have fruit printed or engraved on them. Ever tried to repair a broken iPod or let someone fix a bug in MacOS X?
Re: The future of NetBSD
On Aug 31, 2006, at 7:01 PM, Marc G. Fournier wrote: On Thu, 31 Aug 2006, Pedro Martelletto wrote: On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote: Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? Vendors should release documentation, not write drivers. In a perfect world, they all would ... this is not a perfect world, it is one dominated by Linux or Microsoft ... I use Adaptec drivers on 3 of my servers, because, in 4.x, they were rock solid ... in 6.x, they have a problem ... I'd like to be able to go out and upgrade those servers to a vendor that provides documentation, but its a cost I can't afford at this time ... so, should I then switch to Linux because they do welcome 'vendor written drivers'? Rhetorical question, since I do not consider switching to Linux an option ... instead, I'm trying to do something to help *BSD advocates promote *BSD to those vendors (see http://www.bsdstats.org) by showing them that we aren't just a 'hobbiest operating system' ... what my point is, though, is if we aren't willing to accept 'vendor written drivers', then it is *we* that are limiting our growth but limiting what hardware we can run stably on ... If everyone had your attitude, there would be no *BSD. Settling for good enough means never making progress. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: The future of NetBSD
Marc G. Fournier dixit: If the vendor is bought up, bankrupt, out of business, dead (like that person who ported g++ to Plan 9, whose window managers' copyright is now set in stone), etc... you're SOL9. //mirabile 9) wtf knows it -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
This is the most retarded thing I heard in weeks. On Thu, Aug 31, 2006 at 07:28:29PM -0300, Marc G. Fournier wrote: On Fri, 1 Sep 2006, Gilles Chehade wrote: Marc G. Fournier wrote: I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? How would a common API provide more support from the vendor ? What does the API have to do with releasing documentation ? I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for?
Re: The future of NetBSD
On Thu, 31 Aug 2006, Miod Vallat wrote: If the vendor is supporting the driver, and working with the community, then one would hope that they would also fix the driver as bug reports come in about it ... That's too many ifs to be realworld-compatible. And actually the only vendors I can think of which are working with the community actually provide documentation, if only because it is simpler for them to spend time on documentation than on code for N different systems. ICP Vortex (aka Adaptec) were providing drivers on their web site for FreeBSD 4.x and 5.x that are included in both source trees ... it was a binary driver, as far as I'm aware, but source code ... and Adaptec doesn't provide documentation ...
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 08:01:49PM -0300, Marc G. Fournier wrote: In a perfect world, they all would ... this is not a perfect world, it is one dominated by Linux or Microsoft ... I use Adaptec drivers on 3 of my servers, because, in 4.x, they were rock solid ... in 6.x, they have a problem ... I'd like to be able to go out and upgrade those servers to a vendor that provides documentation, but its a cost I can't afford at this time ... so, should I then switch to Linux because they do welcome 'vendor written drivers'? Rhetorical question, since I do not consider switching to Linux an option ... instead, I'm trying to do something to help *BSD advocates promote *BSD to those vendors (see http://www.bsdstats.org) by showing them that we aren't just a 'hobbiest operating system' ... what my point is, though, is if we aren't willing to accept 'vendor written drivers', then it is *we* that are limiting our growth but limiting what hardware we can run stably on ... A 'hobbiest' operating system is one which makes no demands, accepting whatever the vendors want it to. And it's not a matter of promoting *BSD to the vendors. It's a matter of vendors promoting their products by providing clear, concise documentation, demonstrating the quality and correctness of their products. We should not wait for a perfect world to make correct decisions. -p.
Re: The future of NetBSD
On 01/09/06, Marc G. Fournier [EMAIL PROTECTED] wrote: so, should I then switch to Linux because they do welcome 'vendor written drivers'? If by 'vendor-written drivers' you mean binary-only drivers, then no, the linux kernel developers emphatically do not accept them. They would much prefer that all vendors release open source drivers, since (amongst other things) if they do, that means they (the LKD's) will be responsible for making sure that when the device driver ABI changes, all open-source drivers are rewritten and recompiled to work with that version of the kernel. Jeff.
Re: The future of NetBSD
Marc G. Fournier wrote: On Fri, 1 Sep 2006, Gilles Chehade wrote: Marc G. Fournier wrote: I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? How would a common API provide more support from the vendor ? What does the API have to do with releasing documentation ? I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? mmmh ... you've got a point ... you just opened my eyes ... documentation is pointless when I have a blackbox doing the work. I assumed a BSD system was supposed to provide access to all of the source tree with no restriction so that one could study, fix or improve any part of the system; but you are right and BSD should follow Linux path and focus on quantity, not quality. My eyes are opened, I do trust random vendors to provide fixes and not force me into buying new hardware. I do trust their code to be bug-free and of high-quality. I trust them so much actually, that I don't consider incorporating their code into any of the BSD projects as prostituting their goals: From OpenBSD's goal page: Integrate good code from any source with acceptable copyright (ISC or Berkeley style preferred, GPL acceptable as a last recourse but not in the kernel, NDA never acceptable) http://www.openbsd.org/policy.html. We want to make available source code that anyone can use for ANY PURPOSE, with no restrictions. *We strive to make our software robust and secure, and encourage companies to use whichever pieces they want to.* There are commercial spin-offs http://www.openbsd.org/products.html of OpenBSD. From NetBSD's goal page: avoids encumbering licenses http://www.netbsd.org/Goals/redistribution.html, From FreeBSD's goal page: The goal of the FreeBSD Project is to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we definitely do not insist on it. We believe that our first and foremost mission is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, we believe, one of the most fundamental goals of Free Software and one that we enthusiastically support. That code in our source tree which falls under the GNU General Public License (GPL) http://www.FreeBSD.org/copyright/COPYING or GNU Library General Public License (LGPL) http://www.FreeBSD.org/copyright/COPYING.LIB comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed FreeBSD license http://www.FreeBSD.org/copyright/freebsd-license.html whenever possible. Then, next step would be a rewrite of ``Design and Implementation of the FreeBSD Operating System to remove some of the descriptions concerning structures and code, and incorporation of a chapter on how to load opaque objects to add support for adaptec hardware. Actually ... each edition should have an additionnal chapter for new vendors following adaptec's path and being supportive by providing more opaque objects. After all, that's what BSD is about ... bending to vendors.
Re: The future of NetBSD
On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote: On Thu, 31 Aug 2006, Pedro Martelletto wrote: On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote: Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? Vendors should release documentation, not write drivers. In a perfect world, they all would ... this is not a perfect world, it is one dominated by Linux or Microsoft ... I use Adaptec drivers on 3 of my servers, because, in 4.x, they were rock solid ... in 6.x, they have a problem ... Did you ever wonder WHY they don't work in the first place? Does your fxp(4)-based Ethernet no longer works with 6.x, too? The driver thing is really simple -- vendors either provide documentation, and their stuff works forever and everywhere; or they provide you some rubbish they often name support, which basically means that you can only use the purchased hardware for X-number of years, until some progress in your OS is made, and then you are EXPECTED to buy a new device. Complaining that Adaptec doesn't support 6.x is stupid. Didn't they advertise to you that they support FreeBSD 4.x? So what is the problem? Either ask them for documentation, or go buy another controller!
Re: The future of NetBSD
On Thu, 31 Aug 2006, Jason Dixon wrote: If everyone had your attitude, there would be no *BSD. Settling for good enough means never making progress. Who ever said settling for good enough? I know I didn't ... if I settled for good enough, I would have stuck it out with Linux years ago instead of switching to BSD ...
Re: The future of NetBSD
Marc G. Fournier [EMAIL PROTECTED] wrote: On Thu, 31 Aug 2006, Miod Vallat wrote: I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? To fix the driver. If the vendor is supporting the driver, and working with the community, then one would hope that they would also fix the driver as bug reports come in about it ... That is beyond naive. Many companies don't even do this for their windows drivers. There's lots of perfectly good hardware out there that doesn't work in recent windows releases because the company making it wants you to buy more hardware, so they refuse to update their drivers. You can keep your vendor lock in thanks, I don't want it. Adam
Re: The future of NetBSD
On Fri, 1 Sep 2006, Gilles Chehade wrote: mmmh ... you've got a point ... you just opened my eyes ... documentation is pointless when I have a blackbox doing the work. Maybe I'm missing something, and if so, I do apologize to those on these lists that I may have offended ... but ... having clean source code to a driver is not equal to a black box ... is it? I don't believe I've once advocatged 'binary drivers' ...
Re: The future of NetBSD
On 01/09/06, Jeff Rollin [EMAIL PROTECTED] wrote: On 01/09/06, Marc G. Fournier [EMAIL PROTECTED] wrote: so, should I then switch to Linux because they do welcome 'vendor written drivers'? If by 'vendor-written drivers' you mean binary-only drivers, then no, the linux kernel developers emphatically do not accept them. They would much prefer that all vendors release open source drivers, since (amongst other things) if they do, that means they (the LKD's) will be responsible for making sure that when the device driver ABI changes, all open-source drivers are rewritten and recompiled to work with that version of the kernel. Of course, that should be API Jeff.
Re: The future of NetBSD
On Fri, 1 Sep 2006, Jeff Rollin wrote: On 01/09/06, Marc G. Fournier [EMAIL PROTECTED] wrote: so, should I then switch to Linux because they do welcome 'vendor written drivers'? If by 'vendor-written drivers' you mean binary-only drivers, then no, the linux kernel developers emphatically do not accept them. They would much prefer that all vendors release open source drivers, since (amongst other things) if they do, that means they (the LKD's) will be responsible for making sure that when the device driver ABI changes, all open-source drivers are rewritten and recompiled to work with that version of the kernel. Nope, definitely not binary-only ... I meant source code drivers provided by a vendor, and supported by them ... apologies if I gave the impression that binary-only drivers where acceptable :(
Re: The future of NetBSD
Marc G. Fournier wrote: On Fri, 1 Sep 2006, Gilles Chehade wrote: mmmh ... you've got a point ... you just opened my eyes ... documentation is pointless when I have a blackbox doing the work. Maybe I'm missing something, and if so, I do apologize to those on these lists that I may have offended ... but ... having clean source code to a driver is not equal to a black box ... is it? I don't believe I've once advocatged 'binary drivers' ... a blackbox is not necessarily a binary driver, based on source code filled with magic values you know nothing about, would you be able to fix a bug ?
Re: The future of NetBSD
Marc G. Fournier dixit: I'm curious here, but why did the *kernel* diverge for each project? Because kernel, userland, ports and attitude come as a package, they cannot be separated, for together they are the operating system. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
(When do you stop putting people into Cc instead of just the lists?) Marc G. Fournier dixit: source code drivers provided by a vendor, and supported by them Yeah, and what if the vendor goes out of business, is bought or simply bankrupt? You're pretty much SOL then. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: The future of NetBSD
Marc G. Fournier wrote: On Thu, 1 Jan 1970, Gilles Chehade wrote: Marc G. Fournier wrote: On Fri, 1 Sep 2006, Gilles Chehade wrote: mmmh ... you've got a point ... you just opened my eyes ... documentation is pointless when I have a blackbox doing the work. Maybe I'm missing something, and if so, I do apologize to those on these lists that I may have offended ... but ... having clean source code to a driver is not equal to a black box ... is it? I don't believe I've once advocatged 'binary drivers' ... a blackbox is not necessarily a binary driver, based on source code filled with magic values you know nothing about, would you be able to fix a bug ? 'k, put that way, I retract my original statement and apologize to those that I obviously offended ... I wasn't thinking it through, and can understand that adversion that those on these lists had to my comments :( I, for one, was not offended by your statements, I don't get offended by people behind screens. The fact is, it saddens me. I'd continue this discussion, but it is a waste of time, it has been discussed already a lot and to sum things up, the fact that some people are willing to sacrifice the goals of their project and willing to accept anything to grow a larger user base and make vendors happy is scary. I am an OpenBSD, NetBSD and FreeBSD user, my opinion is not biased as I like them all, but to be honest the fact that some of them accept blobs or obfuscate source drivers is at the opposite of what BSD used to mean (at least for me). no matter the reason, bending to a vendor sets up an example for others and harms everyone in the end. For each adaptec hardware supported by blackboxes, how many hardware support have we lost because vendors feel they can distribute NDA's ? Anyway, i'm over with this discussion, i got more productive things to do ;)
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 08:03:04PM -0300, Marc G. Fournier wrote: On Thu, 31 Aug 2006, Miod Vallat wrote: I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? To fix the driver. If the vendor is supporting the driver, and working with the community, then one would hope that they would also fix the driver as bug reports come in about it ... You're living in a dreamland. You should get over your prejudice against Linux, because it's already where you want to be. -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: The future of NetBSD
On Thu, Aug 31, 2006 at 10:57:20PM +, Miod Vallat wrote: I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? To fix the driver. A given piece of source code can only been believed correct until it is proven to be broken (unless you're Knuth, but he did not write device drivers). Even Knuth: Beware of bugs in the above code; I have only proved it correct, not tried it. -DEK -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: The future of NetBSD
On Thu, 31 Aug 2006 20:03:04 -0300 (ADT), Marc G. Fournier [EMAIL PROTECTED] said: On Thu, 31 Aug 2006, Miod Vallat wrote: I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? To fix the driver. If the vendor is supporting the driver, and working with the community, then one would hope that they would also fix the driver as bug reports come in about it ... BWHHAAHAHAAHAHAHAHAHAHAHAHAH OHHOHOHOHOHOHH, MY GOD WAS THAT FUNNY MY SIDES ARE SPLITTING Wait... You weren't serious, were you? You couldn't be serious. Nobody is *THAT* f*g ignorant of what has transpired between vendors and the open source community over the last decade...
Re: The future of NetBSD
On 9/1/06, Marc G. Fournier [EMAIL PROTECTED] wrote: On Fri, 1 Sep 2006, Gilles Chehade wrote: Marc G. Fournier wrote: I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all different goals... Even at the kernel level? Look at device drivers and vendors as one example ... companies like adaptec have to write *one* device driver, for, what, 50+ distributions of linux ... for us, they need to write one for FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD ... if we had *at least* a common API for that sort of stuff, it might be asier to get support at the vendor level, no? How would a common API provide more support from the vendor ? What does the API have to do with releasing documentation ? I'd rather have Adaptec provide a source code driver for their cards directly, then have Scott Long have to fight with unavailability of documentation itself ... if the driver works, what do we need documentation for? Marc, Some time back we ( OpenBSD community and some others in other BSD/Linux communities ) had mailed Adaptec to release the Documentation for their RAID Chipsets. One of the mail's from the adaptec personnel said. We have a disclaimer because there may be corner cases Which adaptec would not have encountered before releasing the drivers. A *working* driver doesnot mean much when you bring to the picture things like these. Forget Corner cases if you want to use your card on newer hardwre that comes out everyday you will find that the driver needs to be worked on. And it is very important if you are interested in the Stability and Security of your System. Forget about the vendor giving you a fix for every problem you face. The would most probably tell you to upgrade your hardware. But if you had the documentation available for all if not you some one who knows to Code could fix it for you. The vendor loses nothing by freeing the docmentation of their hardware. On the contrary by doing so they ensure their is supported on wider OS platforms and work together well with other hardware. This helps in selling more of their hardware and also since it is used by more people the corner cases will be less because there is a chance that people would encounter them more quiclky and since the documentation is free it will be fixed more quickly. And there is no real reason ( in my opinion ) in exerting some pressure on vendors to release the documentation. Actually it is for their benefit :-) Hope this Helps Kind Regards Siju
Re: The future of NetBSD
On 8/30/06, Charles M. Hannum [EMAIL PROTECTED] wrote: The NetBSD Project has stagnated to the point of irrelevance. It has gotten to the point that being associated with the project is often more of a liability than an asset. I will attempt to explain how this happened, what the current state of affairs is, and what needs to be done to attempt to fix the situation. [snip] Much of this early structure (CVS, web site, cabal, etc.) was copied verbatim by other open source (this term not being in wide use yet) projects -- even the form of the project name and the term core. This later became a kind of standard template for starting up an open source project. That's very interesting history, if true (and I don't see why it wouldn't be)! Don't feel bad then, if you have accomplished that. [snip] -- At this point most readers are probably wondering whether I'm just writing a eulogy for the NetBSD project. In some ways, I am -- it's clear that the project, as it currently exists, has no future. It will continue to fall further behind, and to become even less relevant. This is a sad conclusion to a project that had such bright prospects when it started. I admit that I may be wrong about this, but I assume that most people who have contributed to NetBSD, and/or continue to do so, do not desire to see the project wallow away like this. So I will outline what I think is the only way out: [snip] *cough*Most of these ideas have been in the OpenBSD culture from the beginning*cough* - Charles Hannum - past founder, developer, president and director of The NetBSD Project and The NetBSD Foundation; sole proprietor of The NetBSD Mission; proprietor of The NetBSD CD Project. [I'm CCing this to FreeBSD and OpenBSD lists in order to share it with the wider *BSD community, not to start a flame war. I hope that people reading it have the tact to be respectful of their peers, and consider how some of these issues may apply to them as well.] Um. Wow. I think Theo wins. -Nick
Re: The future of NetBSD
On 31/08/06, Charles M. Hannum [EMAIL PROTECTED] wrote: The NetBSD Project has stagnated to the point of irrelevance. If true, unfortunate. A sad day. Jeff.
Re: The future of NetBSD
Hello Charles, Some parts of your message seemed to be flames resulting from some past personality conflict that I know nothing about, so I won't comment further on those. Clearly you are more familiar with BSD internals than I am. I imagine others will pickup various technical points such as LFS and threading. I can only write from my own personal perspective as just one ordinary user of NetBSD. CMH The NetBSD Project has stagnated to the point of irrelevance. Relevance to whom? It's relevant to me because I use it every day. CMH As one of the 4 originators of NetBSD, I am in a fairly unique position. I am the only one who has continuously participated and/or watched the project over its entire history. Sincere thanks for the contributions you have made to my favorite operating system. CMH Power management is very primitive. Etc. I'm not sure what this means. All I can say is that it works for me: suspend and resume work on my laptop. I know that work is being done on PowerNow! for AMD K6-2+, Athlon etc. I don't presently use Intel chips, so I don't know about SpeedStep. Hopefully someone who knows will clarify this point. You make several references to a flash-friendly file system, which I assume means one that somehow spreads out data to avoid wearing the carpet too thin. NetBSD works well with my flash cards and JumpDrive, but I would not want to use either for something heavy like swap because the nature of the technology (its finite number of write/erase cycles) does not suit that. That's not NetBSD's fault and does not pose a problem for me in any case. CMH terrible support for kernel modules; I understand that other operating systems have loadable kernel modules. Perhaps NetBSD has them too. I don't know because I have never needed one. If I need a special device driver, I compile a new custom kernel. It's quick, easy (once you know how) and in my experience both painless and beneficial. NetBSD works very well for my modest server-side needs: it's fast, light, absolutely rock solid, consistent and does not make assumptions about the work that I need to do or the software that I will choose to install. As a desktop operating system it's not quite there yet (depending on the application). I understand that support for hardware accelleration of things like MPEG decode and 3D graphics are not yet working. I will be happy if someone corrects me on this point. One very underestimated assett of NetBSD is its user and developer community. The mailing lists and #netbsd on the freenode.net IRC network have provided me with far superior support than I have received from any proprietary software vendor and also better than other open-source products that I use. I have found the people there friendly, patient and very, very helpful. This is just my inital reaction to your post, which I fealt like sharing. - Andy Ball
Re: The future of NetBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Charles, Charles M. Hannum wrote: popularity in 1993 and 1994) have suffered similar problems. FreeBSD and XFree86, for example, have both forked successor projects (Dragonfly and X.org) for very similar reasons. I don't agree that Dragonfly is a successor of FreeBSD. Not yet. Dragonfly is nowhere near the state of FreeBSD 6.x Will it get there? Time will tell... Were TNF comprised of a good set of leaders, this situation might be somewhat acceptable -- though certainly not ideal. The problem is, there are really no leaders at this point. Goals for releases are not based on customer feedback or looking forward to future needs, but solely on the basis of what looks like it's bubbled up enough that it might be possible to finish in time. There is no high-level direction; if you ask what about the problems with threads or will there be a flash-friendly file system, the best you'll get is we'd love to have both -- but no work is done to recruit people to code these things, or encourage existing developers to work on them. This would be the very same with Linux, if there would be the same amount of developers as in NetBSD. I promise that. I do know this attidute from reading FreeBSD mailing lists. However, this is pretty natural for OSS projects. If you don't have a guy/girl who's doing the job, the wishlist gets long and the manpower gets short. It is like that... and it's hard to change. Myself, I would like to have an easy to setup fully automated, serial console controlled, installation system of FreeBSD and OpenBSD. This doesn't exists. So it's in the end up to me to make up my mind, if nobody else does. This vacuum has contributed materially to the project's current stagnation. Indeed, NetBSD is very far behind on a plethora of very important projects. Threading doesn't really work across multiple CPUs -- and is even somewhat buggy on one CPU. There is no good flash file It is like that in Linux too, more or less. So don't worry ;-) For these reasons and others, the project has fallen almost to the point of irrelevance. (Some people will probably argue that it's beyond that point, but I'm trying to be generous.) This is unfortunate, especially since NetBSD usage -- especially in the embedded space -- was growing at a good rate in 2000 and 2001, prior to the aforementioned coup. Avocent's KVM over IP boards are based on NetBSD for instance :) 5) There are a number of aspects of the NetBSD architecture that are flat out broken, and need serious rehabilitation. Again, the leadership needs to recruit people to do these things. Some of them include: * serious problems with the threading architecture (including the user-kernel interface), as mentioned earlier; * terrible support for kernel modules; * the horrible mess that is 32/64-bit compatibility, resulting in 32-bit apps often not working right on 64-bit kernels; and * unbounded maintenance work due to inappropriate and rampant use of quirk tables and chip-specific tables; e.g. in SCSI, ATAPI, IDE, ACPI and SpeedStep support. (I actually did much of this work for SCSI, but am not currently able to commit it.) You really don't want to compare these facts against Linux. I promise you, despite how popular Linux is, they have the very same problems, and IMHO it's even worse. Much worse. The only luck the Linux project has, is a whole lot of more developers than any of the BSD's projects have. Does this produce better code? No! Does this produce more features? Yes. Does this produce a faster OS? Probably Yes. But under the hood, Linux is completely screwed. Ever tried to set up bonding (aka trunk(4)) ? You don't want to! It works, okay, but it's a rocky road... [I'm CCing this to FreeBSD and OpenBSD lists in order to share it with the wider *BSD community, not to start a flame war. I hope that people reading it have the tact to be respectful of their peers, and consider how some of these issues may apply to them as well.] I hope people did. Although I doubt that much read that far. You said true words, and false, and sometimes it looked like a flame war. But all in all, it was very sad to read. Go back to your work, and start changing things. Don't stop.. Keep on! best regards, Marian, FreeBSD and OpenBSD user/advocate (but payed at work to use Debian GNU/Linux...) iD8DBQFE9jJPgAq87Uq5FMsRAlSrAJ9ZTsNd8bh/szNUFooKe7EHugvDEQCgjs5w c3g8J3xKio5/zRnKkE1bjdA= =0PPc -END PGP SIGNATURE-
Re: The future of NetBSD
On Thursday 31 August 2006 07:27, Charles M. Hannum wrote: At this point most readers are probably wondering whether I'm just writing a eulogy for the NetBSD project. At this point i was wondering why I was reading this on [EMAIL PROTECTED] --- Lars Hansson
