Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon



Hi Robert Watson!

On Sun, 19 Sep 2010 19:33:14 +0100 (BST); Robert Watson wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon':

The reason is performance for overall network stack, not ideology.

For a practical reasons, "it works but slow" is better than "doesn't work at
all (due to absence of code in the src tree)".

"Make it work. Make it right. Make it fast. In that order", know this?
Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is
it?..
Doug has already clarified, but just to follow up with some detail:
[...]
Towards the end of the project, it was clear that a few components in the
stack had attracted no interest from the community,
^^^^^^^^^ (1)
As such, we went through a public deprecation and
^^^^^^ (2)
In the end, any significant code base in the kernel requires ownership -- it
can continue through many minor changes without an owner, but major retrofits,
such as moving to fine-grained locking, need the attention of someone who
understands the code, is able to test the code, and has the time to invest in
(3) ^^^^^^^^^^^^^^
the code. We do a pretty good job at arranging this with a multi-million line
code base, all told.

As I clarified in my reply to Doug today, the community (1) is not just
developers, but users also, some of them, relying on FreeBSD in their business,
have the potential to convert money to (3) and thus help the Project (BTW, is
it possible for Foundation to ease this possibility for such users?). Of
course, that is only one variant, there are may be other posiibilities, but all
of them require announce - and (2) was not really public deprecation, in sense
that it was known to a subset of community only. E.g., a programmer living on
STABLE (thus not reading current@) and hacking other open-source - in case of
public announce he could switch from those others to help FreeBSD in a feature
he needs.

BTW, the committers-guide states:

===
11.4 Deprecating Features

When it is necessary to remove functionality from software in the base system
the following guidelines should be followed whenever possible:

1. Mention is made in the manual page and possibly the release notes that the
option, utility, or interface is deprecated. Use of the deprecated feature
generates a warning.

2. The option, utility, or interface is preserved until the next major (point
zero) release.

3. The option, utility, or interface is removed and no longer documented. It is
now obsolete. It is also generally a good idea to note its removal in the
release notes.
===

But I don't see such metions for i4b/isdnd man pages on 6.4.

this decade-long project was highly successful, and relied on members of the
community stepping forward to adapt a very large code base by adding
fine-grained locking to each component. the results have been extremely
impressive, allowing our network stack to scale to 8+ cpus (i'm actually
testing with 32-thread systems as part of some network stack work i'm doing
right now).

The Project is ultimately about the users, right? There are early signs that
some old FreeBSD users get tired from those changes, those removals, lesser
POLA adherence, marketing-not-technical-stuff for time-not-feature-based
releases, not so stable -STABLE as it used to be, and so on, migrating to
other systems. And older users are more valuable to project than newer ones.
May be it's time to revert to some of thet Old Good Things, if decade-long
project is mostly ended, while those signs are still early and not a strong
tendency?.. Given this thread, I've mentioned earlier about 12 messages in
announce@ from 2002 with such public calls for volunteers - there are several
years already without these.

--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@xxxxxxx
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: A quality operating system
    ... Ron is completely pro-Linux and pro-Windows, and against FreeBSD. ... They reduce a community to hobbyists only. ... It seems pro-forma, as in, "it's in the documentation, ... Even when you get big parts of the operating system correct, ...
    (freebsd-questions)
  • Re: A quality operating system
    ... done to concentrate documentation, e. ... I told him I was considering FreeBSD because of greater stability and security. ... In his view, and now mine, a quality operating system is reliable, ... They reduce a community to hobbyists only. ...
    (freebsd-questions)
  • Re: Thanks.
    ... Your community is independent from the FreeBSD ... That is just a list of the mailing lists in languages other than ... I thankful if you guide me. ...
    (freebsd-questions)
  • Re: FreeBSD Kernel Internals Documentation
    ... supporting FreeBSD is not in the scope of hardware ... That is the chicken and egg problem, an OS with bad hardware support people ... community and then receive what they need from the community, ...
    (freebsd-questions)
  • Re: A quality operating system
    ... Ron is completely pro-Linux and pro-Windows, and against FreeBSD. ... They reduce a community to hobbyists only. ... Disorganized website. ... Then just use Windows, please. ...
    (freebsd-questions)