Tillbaka till svenska Fidonet
English   Information   Debug  
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4275
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   27601
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/1974
DOS_INTERNET   0/196
duplikat   5999
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33773
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   23439
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12841
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4155
FN_SYSOP   41520
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13558
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16041
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22002
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   894
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4779
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1117
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   2632
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13030
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2055
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
Möte UNIX, 1316 texter
 lista första sista föregående nästa
Text 856, 229 rader
Skriven 2006-12-09 02:16:00 av Robert Wolfe (571.dove-nix)
Ärende: The future of NetBSD
============================
Subject: The future of NetBSD
To: None <netbsd-users@netbsd.org>
From: Charles M. Hannum <mycroft@MIT.EDU>
List: netbsd-users
Date: 08/30/2006 19:27:23

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.

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.  Many changes have taken place, and at the same time many 
things have remained the same -- including some of our early mistakes.

I'd like to say that I'm some great visionary, who foresaw the whole OSS 
market, but the fact is that's BS.  When we started the project, Linux and 
386BSD were both little hobbyist systems, both pretty buggy, and both lacking a

lot of important hardware support.  Mostly we were scratching an itch: there 
was no complete package of 386BSD plus the necessary patches to make it run on 
more systems and fix bugs, and there was no sign that Bill Jolitz was going to 
resurface and do anything.

Much of the project structure evolved because of problems we had early on.  
Probably our best choice was to start using central version control right off; 
this has enabled a very wide view of the code history and (eventually) made 
remote collaboration with a large number of developers much easier.  Some other

things we fudged; e.g. Chris got tired of being the point man for everything, 
and was trying to graduate college, so we created an internal "cabal" for 
managing the project, which became known as the "core group".  Although the web

was very new, we set up a web site fairly early, to disseminate information 
about the project and our releases.

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.  This latter part is also a key element; there was no 
sense that anyone else "owned" a piece of Linux (although de facto "ownership" 
has happened in some parts); if you didn't produce, Linus would use someone 
else's code.  If you wanted people to use your stuff, you had to keep moving.

NetBSD did not have this.  Partly due to lack of people, and partly due to a 
more corporate mentality, projects were often "locked".  One person would say 
they were working on a project, and everyone else would be told to refer to 
them.  Often these projects stagnated, or never progressed at all.  If they 
did, the motivators were often very slow. As a result, many important projects 
have moved at a glacial pace, or never materialized at all.

I'm sorry to say that I helped create this problem, and that most of the 
projects which modeled themselves after NetBSD (probably due to its high 
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.

Unfortunately, these problems still exist in the NetBSD project today, and 
nothing is being done to fix them.

--

I won't attempt to pin blame on any specific people for this, except to say 
that some of it is definitely my fault.  It's only in retrospect that I see so 
clearly the need for a very strong leader.  Had I pursued it 10 years ago, 
things might be very different.  Such is life.  But let's talk about the 
situation today.

Today, the project is run by a different cabal.  This is the result of a coup 
that took place in 2000-2001, in which The NetBSD Foundation was taken over by 
a fraudulent change of the board of directors.  (Note: It's probably too late 
for me to pursue any legal remedy for this, unfortunately.)  Although "The 
NetBSD Project" and "The NetBSD Foundation" were intended from the start to be 
separate entities -- the latter supplying support infrastructure for the former

-- this distinction has been actively blurred since, so that the current 
"board" of TNF has rather tight control over many aspects of TNP.

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 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
system.  There is no file system journaling (except for LFS, which is still 
somewhat experimental).  Although there's been some recent work on suspend 
support, it's still mostly broken.  Power management is very primitive.  Etc.  
Even new hardware support is generally not being originated in NetBSD any more;

it's being developed by FreeBSD and OpenBSD, and being picked up later.  (I 
think the only recent exception to this of any significance is Bluetooth 
support.)

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.

--

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:

1) There must be a strong leadership, and it is not the current one.
   The leadership must honestly want NetBSD to be a premier, world class
   system with leading edge features.  The leadership must set
   aggressive goals, and actively recruit people to make them happen.

2) There must be no more "locking" of projects.  Just because one person
   is supposedly working on a problem, that doesn't mean you shouldn't.
   If there ideas are dumb, or even just suboptimal, do it better!  If
   there is no progress, hop on it.  Don't wait for someone else.

3) The project must become an *actual* meritocracy, not what I call a
   "volumetocracy".  Right now, the people who exert the most influence
   are often the people who produce the least useful product.  Indeed,
   they are often people who produce little more than fluff (e.g.
   changing line-ending whitespace!), and often break things.

4) Speaking of which, there must be negative feedback to discourage
   people from breaking stuff.  This has been a continual problem with
   certain "developers" for more than a decade.

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.)

6) The existing NetBSD Foundation must be disbanded, and replaced with
   an organization that fulfills its original purpose: to merely handle
   administrative issues, and not to manage day-to-day affairs.  The
   extra committees, which mostly do nothing, must be disbanded -- they
   serve only to obfuscate things.  Everything else must revert to the
   historically separate entity, the NetBSD Project, to be managed based
   on technical merits.  There must be no perceived glamour in
   participating in the Foundation; it must be composed of people doing
   it because they are dedicated and want to help the project.

   (I will note here that this is not due to bitterness over the coup.
   Keeping the NetBSD Project as an unincorporated association actually
   helps protect it.)

7) The "core" group must be replaced with people who are actually
   competent and dedicated enough to review proposals, accept feedback,
   and make good decisions.  More to the point, though, the "core" group
   must only act when *needed* -- most technical decisions should be
   left to the community to hash out; it must not preempt the community
   from developing better solutions.  (This is how the "core" group
   worked during most of the project's growth period.)

8) There must be a set of commit standards -- e.g. about when it is or
   is not acceptable to commit changes that do not change functionality;
   when multiple changed must be batched in one commit; etc.  Right now
   it is difficult to sort the wheat from the chaff.  In addition, there
   must be standards of review.

I must repeat a point I've made earlier.  The current "management" of the 
project is not going to either fix the project's problems, or lead the project 
to solutions.  They are going to maintain the status quo, and nothing else.  If

the project is to rise from its charred stump, this "management" must be 
disbanded and replaced wholesale.  Anything less is a non-solution.

--

To some of you, I would like to apologize.  There *are* NetBSD developers doing

good work even now.  I'd like to particularly recognize and thank those working

on kernel locking and UVM problems; wireless support (though I'm not sure what 
happened to my extensive set of rtw bug fixes); Bluetooth; G5; and improved ARM

support.  This is all good stuff.  In the bigger picture, though, the project 
needs to do a lot more.

--
- 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.]


--- BBBS/NT v4.00 MP
 * Origin: Omicron Theta * Buffalo NY * net261.com (1:261/1)