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:
Scott Long antwortet ihm darauf:
Mike Edenfield schreibt zum Punkt 2:
jon Drews schreibt zu Punkt 2:
Auch wird überlegt von syscons Abstand zu gewinnen und stattdessen wscons von NetBSD zu nutzen.
Dazu schreibt Peter Wemm:
Und Scot Long antwortet ihm darauf:
Poul-Hennig Kamp erweitert die Liste von Scott Long noch um die folgenden Punkte:
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
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:
