FreeBSD: Scott Long und seine Project Wunschliste

asg

push it, don´t hype
Auf current@ hat Scott Long seine "project wishlist for the next 12 month" mitgeteilt.
Diese umfasst sechs Punkte die ich hier ungekürzt wiedergeben möchte:

[...]
1. Keyboard multiplexer. We are running into problems with making
ps/2 and USB/bluetooth keyboards work together and work with KVMs.
Having a virtual keyboard device that multiplexes the various real
keyboard devices and handles hotplug can solve this mess pretty
effectively. I know that there has been a lot of talk about this on
mailing lists recently but I don't know how much progress is being made
so I'm listing it here.

2. New installer. I know some people still consider this a joke, but
the reality is that sysinstall is no longer state of the art. It's
fairly good at the simple task that it does, but it's becoming harder
and harder to fix bugs and extend functionality in it. It's also
fairly unfriendly to those of us who haven't been using it since 1995.
The DFly folks have some very interesting work in this area
(www.bsdinstaller.com) and it would be very good to see if we can
collaborate with them on it.

3. Native PCI Express support. I keep on hoping to take care of this,
but I never seem to have the time to get past designing it. This task
includes 3 parts that are mostly independent. The first is support for
the extended PCI config space and memio access method, the second is
MSI, and the third is link QOS management. If anyone is interested
here, please let me know.

4. Journaled filesystem. While we can debate the merits of speed and
data integrety of journalling vs. softupdates, the simple fact remains
that softupdates still requires a fsck run on recovery, and the
multi-terabyte filesystems that are possible these days make fsck a very
long and unpleasant experience, even with bg-fsck. There was work at
some point at RPI to add journaling to UFS, but there hasn't been much
status on that in a long time. There have also been proposals and
works-in-progress to port JFS, ReiserFS, and XFS. Some of these efforts
are still alive, but they need to be seen through to completion. But at
the risk of opening a can of worms here, I'll say that it's also
important to explore non-GPL alternatives.

5. Clustered FS support. SANs are all the rage these days, and
clustered filesystems that allow data to be distributed across many
storage enpoints and accessed concurrently through the SAN are very
powerful. RedHat recently bought Sistina and re-opened the GFS source
code, so exploring this would be very interesting.

6. Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric right
now. I have some work-in-progress in Perforce to address this, but it's
pretty minimal. The parallel SCSI knowledge needs to be separated out
and the stack need to be able to cleanly deal with iSCSI, SCSI, SAS, and
maybe even ATA transports. There is a Lucent implementation of iSCSI
for FreeBSD 4.x that could be a useful reference, though it's a
monolithic stack that doesn't really address the shortcomings of CAM.
Having iSCSI infrastructure that supported both hardware and software
implementations would be ideal.


Insbesondere die Punkte 2 und 4 dürften die meisten User interessieren und auch für die grössten "Reibereien" sorgen.
Gerade was journaling FS angeht so überlassen das *BSD User gerne der Linux Fraktion und halten dabei "softupdates" entgegen. Probleme dürfte aber softupdates (bzw. UFS2) bei einem FS bekommen welches mehrere TB gross ist da ein fsck (weenglich dieser als bgfsck im Hintergrund stattfindet) nach einem Crash immer noch nötig ist.
Beim "Installer" schaut man auf den bsdinstaller vom DFbsd Project, überlegt aber auch einen grafischen Installer in Zukunft zu nutzen.

Jason C. Wells schreibt zu Punkt 5:
Code:
This sounds very close to OpenAFS.  I don't know what distinguishes a SAN
from other types of NAS.  OpenAFS does everything you mentioned in the
above paragraph.  OpenAFS _almost_ works on FreeBSD right now.

Scott Long antwortet ihm darauf:
Code:
Well, AFS requires an intelligent node in front of each disk.  True SAN
clustering means that you have a web of disks directly connected to the
SAN (iSCSI, FibreChannel, etc), and two or more servers on the SAN that
see those disks as a single filesystem (actually a bit more complicated
than this, but you get the point).  If one server goes down, no access
to data is lost since the disks can be reached from any other server on
the SAN that is participating in the clustered FS.

Mike Edenfield schreibt zum Punkt 2:
Code:
Plan9 managed to do some very lightweight installation (that fit on a
*floppy*) and was still graphical.  I liked their install very much --
it was no-frills console windows, but it provided mouse support and a
couple of "informative" extra windows.  But this brings up exactly the
problem with GUI installers -- the plan9 install didn't support the
"graphics adapter" that Virtual PC emulates, and so it just didn't work.
  For a nice OS like plan9, this isn't a big deal.  For an OS like
FreeBSD I don't think that would be acceptable.

Overall, I installed 10 different OS's, and FreeBSD was probably my
second favorite (I did like DFly, as mentioned before).  It's
straightforward, it guides you through the process fairly well, it does
most of the grunt work, it's flexible, it loads and responds fast, and
it's got a lot of on-screen assistance.  I picked it up and used it,
with no documentation, the very first time I installed FBSD anywhere.
(Contract to Gentoo, a geek-favorite, which I had to keep their
installation handbook open in a browser the entire time).  My only real
complaint (not minior nit-picks like about the auto-labelling etc) is
that it's too easy to move around inside the installation and go the
wrong place.  I routinely find myself trying to change a simple setting
post-install, and somehow triggering the entire extraction process
again.  DFly's installer is more wizard-like, in that you can't really
do things out of order.  Otherwise, I would like to see the install stay
similar to what it is.

jon Drews schreibt zu Punkt 2:
Code:
I agree with Eric. As a FreeBSD desktop user, I think (IMHO) that a
gui installer is a high cost low yield item. It would take a lot of
effort to make it work right. My experience with both YaST and
Mandrakes installer was that it took several releases for the bugs to
get worked out. IIRC SuSE introduced the GUI YaST2 in 7.0 and I think
it was working pretty well by 8.0 but that was over the period of a
year.

Auch wird überlegt von syscons Abstand zu gewinnen und stattdessen wscons von NetBSD zu nutzen.
Dazu schreibt Peter Wemm:
Code:
Only if it has 100% identical look/feel to syscons.  ie: same key maps,
same ioctl's, same Xserver interface, same escape codes, etc.  If not,
then over my dead body!

Und Scot Long antwortet ihm darauf:
Code:
What if it's 100% identical except for the [Space] key, which becomes
the console pause key?
=-)

Poul-Hennig Kamp erweitert die Liste von Scott Long noch um die folgenden Punkte:
Code:
7. More people writing FreeBSD related articles for online and
   traditional media.

   If you have never written a piece about FreeBSD, how about sending
   something to your local IT trade rag ?   Heck, even your local
   paper will probably run it if you send them a piece.


8. More people stomping for FreeBSD in universities and schools.

   Have you actually offered the science/IT teachers at the local
   hi-school to pop around and give a lesson on this open source
   phenomena to their pupils ?

   Or call your local college and ask if they need a teaching
   assistant for their evening courses in IT ?


9. A band of happy 1st line reponders dealing with PRs etc.

   We're getting better at this, but one way to really gain users
   is to help them when they need it most: right when they begin.


10. A more dynamic and interesting www.freebsd.org frontpage.

    Come on, at least we should be able to beat the "Congressional
    Record" when it comes to being interesting.


11. More people attending BSDcon conferences.

    Come to BSDcan2005! come to the next EuroBSDcon or AsiaBSDcon.

    Or make your own mini conference!

    Many Linux User groups would welcome you if you offered to give
    a talk about FreeBSD on one of their evenings.

12. Research/Coding grants (3/6/12 months) from the FreeBSD Foundation
    and other deep(er) pockets to help some of the heavy lifting happen.

    We're not only in it for the money, but money surely helps.

Dies war nur ein kleiner Auszug aus der mailingliste current@.
Wie man sieht lohnt es sich bei Interesse diese mailingliste zu abonieren und nur etwas mitzulesen.

Online auch zu finden unter:
http://news.gmane.org/gmane.os.freebsd.current/cutoff=63165
 
Last edited by a moderator:
Hmmm, auch wenn ich zu einigen Punkten nichts sagen kann, finde ich doch, daß freebsd.org zwar spartanisch aussieht, aber imho sehr gut zu dem OS paßt: Klar, schnell, benutzbar und ohne sinnloses Eye Candy.

Ich empfinde gerade die Abwesenheit von dynamischen Elementen (DHTML oder - root bewahre - Flash) als sehr angenehm.
 
Naja, um die Punkte von scottl kurz zu kommentieren:

zu 1. nun, die bittere Erfahrung habe ich mit einem noname KVM Switch gemacht, es wäre schön, wenn KVM's unterstützt werden würden :|

2. Neuer Installer: imho nicht unbedingt notwendig. Ich stimme Jon Drews zu, graphische Installer sind ziemlich sperrig, enthalten im schlimmsten Falle bugs und je nach Design stimmt die Fehlerausgabe nicht... Sysinstall ist zwar "alt" aber dafür gut bewährt, schlank und bugfrei. Wenn man unbedingt einen GUI Installer haben will, dann sollte der User die Möglichkeit haben, zwischen Textbasierenden und Grafischen zu wählen...

3. PCI Express ist schon im kommen, drum herum wird sich kein OS drücken können

4. JFS, hat Mac OS X (HFS+) - finde ist ein "nettes Feature" (z.B. beim herunterfahren in den Ruhezustand) aber als Normaluser komme ich mit dem UFS2 im Moment gut zurecht... (Am besten eigenes ÜberFS entwickeln, welches die anderen FS in den Schatten stellt) :D

Zum Glück sagte Scott Long nicht, dass wir auch einen nativen DirectX Support brauchen.. :D *scnr*

6.0-CURRENT wird echt spannend :D
 
hi,

naja, KVMs sind so durch die Bank alle "slightly" broken.
Das geht dann so in die Richtung wie nen ne(4) Treiber.. :-(

Journalling.. nun, wie waer's schlicht mit snapshots und bg-fsck? War
da nicht mal was (zumindest) announced?
Least effort -> mckusick.com

Wirsing,
 
@douple-p
UFS2+snapshots hat ja bgfsck, aber genau darauf wollen wohl einige verzichten, auf das fsck (auch wenn es im hintergrund rennt), welches bei mehreren TB FS doch etwas dauern könnte.
 
Back
Top