Re: [9fans] porting from vs. porting to Plan 9

Re: [9fans] porting from vs. porting to Plan 9

[Richard C Bilson]

> Opinions?

I don't really disagree with anything you say, although you seem to be
taking the most pessimistic view of things.  For me, the bottom line is
utility -- sure, I may be living in a hovel, but I can at least have
some nice tools to make life a little less brutish.  Not everyone gets
to decide what OS they use, and not everyone has "advocate plan 9" at
the top of their list of priorities.

I think people resist the idea of porting software to plan 9 because
there's a certain idealism to the system -- it would be silly to port
Mozilla, for instance, because the design of Mozilla is in opposition
to the principles of 9.  On the other hand, modern Unix seems to be
without any such principles, so why not humor those who rely on it for
their livelihood.

- Richard

Re: [9fans] porting from vs. porting to Plan 9

[steve-simon]

Mmmm, I tend to agree.

I lived with sam on HPUX under X, then sam under
windows/cygwin, until just this year I managed to
get real plan9 on my work desktop (hurray!).

For me, running plan9 apps under *nix again would be
a depressing retrogade step.

However being able to write code for and on plan 9 and
then just re-compile it with a library for Windows and
X11 would be wonderfull.

If we could do that using a plan9 hosted gcc
cross compiler so much the better (and no I'am not offering :-).

That would only leave the web-browser...

-Steve

[9fans] porting from vs. porting to Plan 9

[mirtchov]

I remember how thrilled I was when I first saw /usr/ports/plan9 on a
FreeBSD system -- my first reaction was "woo-hoo, I don't need an
extra machine to run Plan 9 on!"...  Later on I came to realize that
they weren't what I thought they were, and that if I want the real
thing I should just get the real thing and use it, not look for a
replacement.

Now that it seems everybody is happy with porting Plan 9's libs to
other operating systems, I'm reminded of these ports again, but not in
a good way.  You see, I hold the opinion that if Plan 9 becomes a
'niche' OS, one that people run in VMWare or otherwise hosted on top
of other systems, it will gradually loose its appeal, and
disappear.  I believe the same will happen if its libraries were
ported elsewhere.

Whether Plan 9 libs on lunix are beneficial (to lunix) is also
questionable -- it's nice to have libdraw for example, but if not
widely adopted it is just a (very small, admittedly) drop of code in
the huge sea that is X.  Besides, non-9fans have gotten used to
looking for familiar things in lunix, and it will be harder to educate
them of the _proper_ Plan 9 way in their world, on their turf, than to
bring them in ours -- they all end up liking Plan 9 at the end, but
that's because they are able to tear off the lunix-built habits by
being forced to live in a Plan 9 environment.

There is a great deal of opposition to bringing/porting other apps to
Plan 9, and I admit I was expecting to see the same opposition to
porting Plan 9's libs to other systems: "why would they want it there
anyway?  throwing pearls before swine!" was going through my head.

You see, without the reason to run Plan 9 it'll just become yet
another dead operating system, just like Oberon recently discussed --
the ideas from it live here to an extent, but the system itself has
long gone...

Opinions?

Andrey

Re: [9fans] porting from vs. porting to Plan 9

[Skip Tavakkolian]

> Whether Plan 9 libs on lunix are beneficial (to lunix) is also
> questionable -- it's nice to have libdraw for example, but if not
> widely adopted it is just a (very small, admittedly) drop of code in
> the huge sea that is X.  Besides, non-9fans have gotten used to
> looking for familiar things in lunix, and it will be harder to educate
> them of the _proper_ Plan 9 way in their world, on their turf, than to
> bring them in ours -- they all end up liking Plan 9 at the end, but
> that's because they are able to tear off the lunix-built habits by
> being forced to live in a Plan 9 environment.
> 

I think that the cunning idea from Plan9 that one hopes would rub off
on other OS'es is the filesystem protocol.  I think turning other OSes
into servers for various namespaces and then tying them together with
something like a 9grids, is the way to go.  Drawterm is a good example.

> There is a great deal of opposition to bringing/porting other apps to
> Plan 9, and I admit I was expecting to see the same opposition to
> porting Plan 9's libs to other systems: "why would they want it there
> anyway?  throwing pearls before swine!" was going through my head.
> 

I think there could be other reasons for this.  I would rather program
graphics using libdraw because it would be save me time and effort
just in dealing with various OS's graphic subsystem complexities.
Doing things in libdraw, I would guess, not win the "flashy-eye-candy"
contest; but if that is not what you're aiming at, it is okay.

> You see, without the reason to run Plan 9 it'll just become yet
> another dead operating system, just like Oberon recently discussed --
> the ideas from it live here to an extent, but the system itself has
> long gone...

Plan9 wont die.  That is why it has the bunny.  The bunny
reproduces fast and can get under fences.
So, go forth and multiply ☺

Seriously, I believe that if you could get other OSs to handle 9P,
then having a 9grid would enable you to provide a namespace switching
mechanism that gives you tighter integration than "visiting web pages"
and email.

Re: [9fans] porting from vs. porting to Plan 9

[Joel Salomon]

Steve said:
> However being able to write code for and on plan 9 and
> then just re-compile it with a library for Windows and
> X11 would be wonderfull.

Skip Tavakkolian said:
> I think there could be other reasons for this.  I would rather program
> graphics using libdraw because it would be save me time and effort
> just in dealing with various OS's graphic subsystem complexities.
> Doing things in libdraw, I would guess, not win the "flashy-eye-candy"
> contest; but if that is not what you're aiming at, it is okay.

Offer people clean, fast libraries and code in general will be improved.

"Saving" or "rescuing" Plan 9? The basic benefits of Plan 9 seem to be for
the programmer, or for specialized purposes like distributed (flames to
/dev/null). The guy who uses my program probably likes WinXP because it
"handles multimedia better than previous versions". *I* want to use Plan 9
because it "lets me do what I want to without getting in my way". Hence,
the ports.

--Joel

Re: [9fans] porting from vs. porting to Plan 9

[Brantley Coile]

In the early 1980's, you folks in the labs trashed the VAX
kernel and replaced it with 4.1a (or c or something).  You
poked around in the kernel, trowing away some stuff, adding
new stuff like streams and netb and stuff.  On top you
ran very clean stuff.  This was done because you saw
that for that hardware the BSD kernel was more useful.
Can we do that with Linux and the plan9 stuff?  Can we
replace X windows altogether with a libdraw interface?  Can the
binding that Linux currently does me bent into shape?
Can we have a Linux kernel base system that doesn't have
commands with so many options that each command has built
in man pages in the form of --help?  Can we have a real
Unix system and not a GNU one?

Just a thought.

  Brantley

Re: [9fans] porting from vs. porting to Plan 9

[matt]

> Can we have a real Unix system and not a GNU one?

we have one : plan9

Re: [9fans] porting from vs. porting to Plan 9

[ron minnich]

On Fri, 17 Oct 2003, Brantley Coile wrote:

> In the early 1980's, you folks in the labs trashed the VAX
> kernel and replaced it with 4.1a (or c or something).  You
> poked around in the kernel, trowing away some stuff, adding
> new stuff like streams and netb and stuff.  On top you
> ran very clean stuff.  This was done because you saw
> that for that hardware the BSD kernel was more useful.

If you look in v9fs there is a toy thing I had in there called 9sys, which
was a first cut at a system call interface in linux to plan 9 system
calls. It was going to look like Plan 9 outside, but ride on top of linux
kernel internals, and use v9fs for 9p transport.  Step 1 was to get the
Plan 9 system calls in. Step two was to remove the Linux system calls.

I started this before Plan 9 license got fixed, and stopped it at that
time.

I'd still rather work with a real plan 9 kernel. There's so much baggage
in Linux I don't want to deal with. I would rather put my efforts into
making plan 9 a bigger deal.

ron

Re: [9fans] porting from vs. porting to Plan 9

[Christopher Nielsen]

On Fri, Oct 17, 2003 at 02:17:32PM -0600, ron minnich wrote:
>
> I'd still rather work with a real plan 9 kernel. There's so much baggage
> in Linux I don't want to deal with. I would rather put my efforts into
> making plan 9 a bigger deal.

Pretty much the point of my most recent post worded better. :)

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] porting from vs. porting to Plan 9

[Brantley Coile]

On Fri, 17 Oct 2003 14:17:32 -0600 (MDT), ron minnich <rminnich@lanl.gov> wrote:
> I'd still rather work with a real plan 9 kernel. There's so much baggage in Linux I don't want to deal with. I would rather put my efforts into making plan 9 a bigger deal.

Can this be done without having to make a branch of the Linux kernel?
The Linux baggage is just the cost of having most hardware supported.
Can most of the Linux kernel be look--don't touch?

 Brantley

Re: [9fans] porting from vs. porting to Plan 9

[Charles Forsyth]

>>The Linux baggage is just the cost of having most hardware supported.

not really: it's fundamentally flawed.
to be fair, i haven't looked at 2.6 yet, though i've got it on DVD (!)
but for the five (different) versions i've got,
even the #include files are barely finite,
you need to wade through chains of #ifn?def to work
out what applies in your case, x86 is deeply embedded(!)
in surprising ways, and all in all it's depressing when it's not awful.

the aim of implementing an operating system
(or graphics subsystem) is to try to help control complexity,
not create it.

The difference between a computer scientist and a hacker is that the
computer scientist knows what an exponential is.  -MD McIlroy

Re: [9fans] porting from vs. porting to Plan 9

[Brantley Coile]

On Fri, 17 Oct 2003 21:41:12 +0100, Charles Forsyth <forsyth@caldo.demon.co.uk> wrote:

>>> The Linux baggage is just the cost of having most hardware supported.
>
> not really: it's fundamentally flawed.

I just meant that putting up with the Linux mess is the
cost of not having to write all the drivers for
everything.  I didn't mean that the kernel's
state was `natural.'  I agree with everything
you said.  Can't we fix the include files and
still not be trapped supporting the 2M+lines of
kernel code?

 Brantley

Re: [9fans] porting from vs. porting to Plan 9

[Douglas A. Gwyn]

What the whole industry really, really needs is for all
resources to be accessed through a clean but adequate
interface that has exactly the same access methods no
matter what the nature of the resource.  In other words,
devices all need to come from the manufacturers speaking
something like 9P.  This will never be achieved by hiding
in a corner hacking away at a niche OS, but could perhaps
be achieved eventually by more activism in the standards
realm, both de facto (e.g. Linux) and de jure (e.g. POSIX).
By letting other people determine the properties of such
interfaces you basically doom the most significant good
idea of Plan 9 to historical oblivion.

Inferno was an attempt at beginning to establish something
like what I have in mind, but it didn't have enough
impetus sustained on enough fronts over a long enough time
to have the desired effect.

Maybe the thing to do is seek out several of the smart
minds in Microsoft R&D, who are bound to see the problems
but might not have seen the solution, and engage them in
dialogues.  If you make enough impact, perhaps it would
begin moving the dominant OS line in the right direction,
eventually enabling protocol-compatible OSes with different
higher-level interfaces to compete.

Re: [9fans] porting from vs. porting to Plan 9

[Skip Tavakkolian]

> Maybe the thing to do is seek out several of the smart
> minds in Microsoft R&D, who are bound to see the problems
> but might not have seen the solution, and engage them in
> dialogues.  If you make enough impact, perhaps it would
> begin moving the dominant OS line in the right direction,
> eventually enabling protocol-compatible OSes with different
> higher-level interfaces to compete.

It appears they've already (re)invented it.  It is called WinFS and as
is usual practice it will probably have something like 9P but
different; There is very little information about it, but it is presumably
part of Longhorn and they're saying look for it around 2005-06.

Re: [9fans] porting from vs. porting to Plan 9

[Adrian Tritschler]

Skip Tavakkolian wrote:

>>Maybe the thing to do is seek out several of the smart
>>minds in Microsoft R&D, who are bound to see the problems
>>but might not have seen the solution, and engage them in
>>dialogues.  If you make enough impact, perhaps it would
>>begin moving the dominant OS line in the right direction,
>>eventually enabling protocol-compatible OSes with different
>>higher-level interfaces to compete.

> It appears they've already (re)invented it.  It is called WinFS and as
> is usual practice it will probably have something like 9P but
> different; There is very little information about it, but it is presumably
> part of Longhorn and they're saying look for it around 2005-06.

As far as I can tell, WinFS is more the addition of vast amounts of 
meta-data to the file system.  Nothing about the underlying protocol to 
talk back and forth between things.

 From http://www.winsupersite.com/faq/longhorn.asp

"Longhorn will include a database-like file system add-on called Windows 
Future Storage (WinFS), which is based on technology from SQL Server 
2003 (code-named Yukon). This file system add-on will abstract physical 
file locations from the user and allow for the sorts of complex data 
searching that are impossible today. For example, today, your email 
messages, contacts, Word documents, and music files are all completely 
separate. That won't be the case in Longhorn. WinFS requires NTFS."

	Adrian

---------------------------------------------------------------
Adrian Tritschler                          mailto:ajft@ajft.org
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] porting from vs. porting to Plan 9

[ron minnich]

On Fri, 17 Oct 2003, Brantley Coile wrote:

> <rminnich@lanl.gov> wrote:
> > I'd still rather work with a real plan 9 kernel. There's so much
> > baggage in Linux I don't want to deal with. I would rather put my
> > efforts into making plan 9 a bigger deal.
>
> Can this be done without having to make a branch of the Linux kernel?

I was not doing it as a branch, but as a module. Part of the fun was it
really made me think more about how Plan 9 has to do things -- so it was
educational. I had trivial instances of bind etc. trivially working for
trivial things, but then I was able to stop ...

I only did this when I despaired of seeing the license change. That's been
fixed.

The goal was to at some point remove all the standard Linux system calls.
I had no interest in co-existence.

> The Linux baggage is just the cost of having most hardware supported.
> Can most of the Linux kernel be look--don't touch?

Now that inferno has opened up why not just use inferno on linux?

One thing that would be a step forward would be to have a plan 9 distro
that included all the inferno stuff too. Mainly a packaging thing I guess.
But the plan 9/inferno split seems unnecessary (to me anyway).

The main reactions I see to Plan 9 are
- "I don't get the window manager"
- "Where's emacs"
- "Where's the browser"
- "How do I handle PCMCIA and USB"

I still think the last is the biggest deal. Hot-plug is really needed. It
would be nice to do it somehow better than the zillions of kernel modules
I see in linux:

Module                  Size  Used by    Tainted: PF
eepro100               19824   1
supermon_proc          12416   0
symdm                   1876   0  [supermon_proc]
vmnet                  24704   7
vmmon                  23636   4
prism2_pci             99656   1  (autoclean)
p80211                 25460   1  (autoclean) [prism2_pci]
radeon                 95736   1
agpgart                39168   3
binfmt_misc             6916   1
autofs                 10980   0  (autoclean) (unused)
ds                      8256   2
yenta_socket           11968   2
pcmcia_core            47008   0  [ds yenta_socket]
usb-uhci               24292   0  (unused)
usbcore                68576   1  [usb-uhci]

ron

Re: [9fans] porting from vs. porting to Plan 9

[okamoto]

> - "How do I handle PCMCIA and USB"
>
> I still think the last is the biggest deal. Hot-plug is really needed.

When I connected my usb HP printer, I do followings:

1) run usbd
2) wakeup the usb port
3) print anything to that printer.

In practice, I use following scripts for my work:

(1) and (2)  /rc/bin/psc2110lp
===========================================
#!/bin/rc

if(! ~ `{ps |grep usbd} *usbd)
	usb/usbd
for(i in `{seq 20}){
	if (grep -s '3 0x020107' '#U'/usb0/$i/status >[2]/dev/null){
		echo -n 'ep 3 bulk w 64 32' >'#U'/usb0/$i/ctl
		bind '#U'/usb0/$i/ep3data /n/lp
		exit ''
	}
}
exit 'no printer'
================================

(2) /sys/lib/lp/devices
have a line of
==================================
# Hewlett-Packard All-in-One usb printer psc 2110
psc2110	Kenji-Home	-	/n/lp	-	gsijs!PSC+2100	generic	nospool	-	-	-	-
==================================

(3) change the /sys/lib/lp/process/generic to
============================================
#!/bin/rc
# Tries to determine what type of file you are printing and do the correct
# thing with it.
# It currently knows about images, troff intermediate, and ascii files.
TMPFILE=/tmp/lp$pid
fn sigexit { rm -f $TMPFILE; }
if (! ~ $DEBUG '') flag x +
if (~ $LPCLASS *nohead*) NOHEAD=1
if (~ $LPCLASS *duplex*) DUPLEX=1
cat >$TMPFILE
FILETYPE=`{file $TMPFILE}
switch ($FILETYPE(2)) {
case troff;
	switch ($LPCLASS) {
	case *Latin1* *post* *opost*;	switch ($FILETYPE(5)) {
					# Latin1 is for compatibility with old research UNIX systems, doesn't work on Plan 9
					case Latin1 post; tcs -s -f utf -t latin1 < $TMPFILE |$LPLIB/process/dpost

					case UTF; $LPLIB/process/tr2post < $TMPFILE
					}

	case *gs!* *gsijs!*;	switch ($FILETYPE(5)) {
					# Latin1 is for compatibility with old research UNIX systems, doesn't work on Plan 9
					case Latin1 post; tcs -s -f utf -t latin1 < $TMPFILE |$LPLIB/process/dpost |$LPLIB/process/gspipe

					case UTF; $LPLIB/process/tr2post < $TMPFILE |$LPLIB/process/gspipe
					}

	case *;		echo $FILETYPE(2) -T$FILETYPE(5) output is improper for $LPDEST >[1=2]
	}
case special;
	switch ($FILETYPE(4)) {
	case '#b';		switch ($LPCLASS) {
				case *post*;	$LPLIB/process/p9bitpost < $TMPFILE
				case *gs!*;	$LPLIB/process/p9bitpost < $TMPFILE |$LPLIB/process/gspipe
				case *gsijs!*;	$LPLIB/process/p9bitpost < $TMPFILE |$LPLIB/process/gspipeijs
				}

	case *;		echo $FILETYPE file is improper for $LPDEST >[1=2]
	}
case Compressed plan old;	# type is really 'Compressed image' or 'plan 9 image'
				# or 'old plan 9 image'
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/p9bitpost < $TMPFILE
	case *gs!*;	$LPLIB/process/p9bitpost < $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/p9bitpost < $TMPFILE |$LPLIB/process/gspipeijs
	}
case jpeg;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/jpgpost < $TMPFILE
	case *gs!*;	$LPLIB/process/jpgpost < $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/jpgpost < $TMPFILE |$LPLIB/process/gspipeijs
	}

case GIF;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/gifpost < $TMPFILE
	case *gs!*;	$LPLIB/process/gifpost < $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/gifpost < $TMPFILE |$LPLIB/process/gspipeijs
	}

case ccitt-g31;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/g3post < $TMPFILE
	case *gs!*;	$LPLIB/process/g3post < $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/g3post < $TMPFILE |$LPLIB/process/gspipeijs
	}

# bitmap for research UNIX compatibility, does not work on Plan 9.
case bitmap;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/bpost < $TMPFILE
	case *mhcc*;	$LPLIB/process/bpost < $TMPFILE | $LPLIB/process/mhcc
	case *;		echo $FILETYPE(2) file is improper for $LPDEST >[1=2]
	}
case tex;
	mv $TMPFILE $TMPFILE.dvi
	TMPFILE=$TMPFILE.dvi
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/dvipost $TMPFILE
	case *gs!*;	$LPLIB/process/dvipost $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/dvipost $TMPFILE |$LPLIB/process/gspipeijs
	case *;		echo $FILETYPE(2) file is improper for $LPDEST >[1=2]
	}
case postscript;
	switch ($LPCLASS) {
	case *post*;		$LPLIB/process/post < $TMPFILE
	case *gs!*;		$LPLIB/process/post < $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;		$LPLIB/process/post < $TMPFILE |$LPLIB/process/gspipeijs
	case *;			echo $FILETYPE(2) file is improper for $LPDEST >[1=2]
	}
case HPJCL;
	switch ($LPCLASS) {
	case *HPJCL*;		$LPLIB/process/noproc < $TMPFILE
	case *;			echo $FILETYPE(2) file is improper for $LPDEST >[1=2]
	}
case daisy;
	switch ($LPDEST) {
	case *;		echo $FILETYPE(2) file is improper for $LPDEST >[1=2]
	}
case English short extended alef limbo [Aa]scii assembler c latin rc sh as mail email message/rfc822;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/ppost < $TMPFILE
	case *gs!*;	$LPLIB/process/ppost < $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/ppost < $TMPFILE |$LPLIB/process/gspipeijs
	case *canon*;	$LPLIB/process/can $* < $TMPFILE
	case *;		echo Unrecognized class of line printer for $LPDEST >[1=2]
	}

case tiff;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/tiffpost $TMPFILE
	case *gs!*;	$LPLIB/process/tiffpost $TMPFILE |$LPLIB/process/gspipe
	case *gsijs!*;	$LPLIB/process/tiffpost $TMPFILE |$LPLIB/process/gspipeijs
	case *;		echo Unrecognized class of line printer for $LPDEST >[1=2]
	}
case PDF;
	switch ($LPCLASS) {
	case *post*;	$LPLIB/process/pdfpost $TMPFILE
	case *gs!*;	$LPLIB/process/pdfgs $TMPFILE
	case *gsijs!*;	$LPLIB/process/pdfgsijs $TMPFILE
	case *;		echo Unrecognized class of line printer for $LPDEST >[1=2]
	}
case empty;
	echo file is empty >[1=2]
case cannot;
	echo cannot open file >[1=2]
case *;
	echo $FILETYPE(2) file is improper for $LPDEST >[1=2]
}
wait
rv=$status
rm -f $TMPFILE
#exit $status
exit
======================================

(4) add a file as /sys/lib/lp/process/gspipeijs as#!/bin/rc
======================================
# extended to IJS driver by K.Okamoto
if (! ~ $DEBUG '') flag x +

# usage: gspipeijs [dev]
# assumes postscript on stdin

switch($#*) {
case 0
	MANUF=`{echo $LPCLASS | sed 's/(.*\+)?gsijs!([^+]*)(\+.*)?/\2/'}
	PRODCT=`{echo $LPCLASS | sed 's/(.*\+)?gsijs!([^+]*)\+(.*)?/\3/'}
case 1
	IJS=$1
case *
	echo 'usage: gspipeijs [dev]' >[1=2]
	exit gspipeijs
}

GSTMPFILE=/tmp/gsp$pid

GSOPT=(-q '-sDEVICE=ijs' '-sIjsServer='hpijs '-sDeviceModel='"$MANUF^' '^$PRODCT" '-sOutputFile='^$GSTMPFILE  '-sPAPERSIZE='a4 -dIjsUseOutputFD -dSAFER -dNOPAUSE )

gs $GSOPT  -

cat $GSTMPFILE
rm $GSTMPFILE

exit
======================================

(5) then, lp -dpsc2110 foo.ps

Lastly, I hate lp system of Plan 9!!!

Kenji

Re: [9fans] porting from vs. porting to Plan 9

[Roman Shaposhnick]

On Fri, Oct 17, 2003 at 02:17:32PM -0600, ron minnich wrote:
> On Fri, 17 Oct 2003, Brantley Coile wrote:
>
> > In the early 1980's, you folks in the labs trashed the VAX
> > kernel and replaced it with 4.1a (or c or something).  You
> > poked around in the kernel, trowing away some stuff, adding
> > new stuff like streams and netb and stuff.  On top you
> > ran very clean stuff.  This was done because you saw
> > that for that hardware the BSD kernel was more useful.
>
> I'd still rather work with a real plan 9 kernel. There's so much baggage
> in Linux I don't want to deal with. I would rather put my efforts into
> making plan 9 a bigger deal.

  I always wanted to see how many applications would break if I were to,
  lets say, disable shared memory from SysV API. It could be a nice
  experiment to do on a live contemporary distro -- just pick a set of
  obscure interfaces and see how many applications are really using
  any of it.

Thanks,
Roman.

Re: [9fans] porting from vs. porting to Plan 9

[Douglas A. Gwyn]

Roman Shaposhnick wrote:
>   I always wanted to see how many applications would break if I were to,
>   lets say, disable shared memory from SysV API. It could be a nice
>   experiment to do on a live contemporary distro -- just pick a set of
>   obscure interfaces and see how many applications are really using
>   any of it.

Just because something isn't much used doesn't prove that
it isn't essential to have for a few cases where it is used.
In the case of shared memory, more recent apps use threads
instead of separate processes sharing memory.  Threads
weren't available when shared memory was added.

Re: [9fans] porting from vs. porting to Plan 9

[Geoff Collyer]

But 4.1BSD was much closer to V7 and 32V than Linux is to Plan 9.
Berkeley had added some optimisations (real and imagined) and `poked
dirty fingers all over previously clean code' (I believe that's a
quote from Ken).

I think the Linux kernel is hopeless and I don't want to run it:
ignoring its size, complexity and ugliness, it's just too buggy and
poorly designed.  The thought of storing files that I value in a file
system implemented on top of that kernel makes me queasy.

It might be possible to construct a cage such that Linux drivers could
be compiled and run in Plan 9 kernels without causing too much damage
to the running system.

I'd like to have a full-time person keeping up with new hardware
(processors and peripherals mainly), but I don't know how to fund such
a person.  Much of the code could be shared with Inferno, so that
might help.

More later.

Re: [9fans] porting from vs. porting to Plan 9

[bs]

Geoff Collyer wrote:

> I'd like to have a full-time person keeping up with new hardware
> (processors and peripherals mainly), but I don't know how to fund such
> a person.  Much of the code could be shared with Inferno, so that
> might help.
Probably do it all in India??? Just kidding :-)

Re: [9fans] porting from vs. porting to Plan 9

[Martin C.Atkins]

On Fri, 17 Oct 2003 21:21:19 -0400 bs <bs@nospam.com> wrote:
>..
> > a person.  Much of the code could be shared with Inferno, so that
> > might help.
> Probably do it all in India??? Just kidding :-)

Why kidding? I'm sitting in India - you send the money, and I'll
hire the army... :-)

Martin

--
Martin C. Atkins				martin@parvat.com
Parvat Infotech (Private) Limited		http://www.parvat.com

Re: [9fans] porting from vs. porting to Plan 9

[Charles Forsyth]

>>It might be possible to construct a cage such that Linux drivers could
>>be compiled and run in Plan 9 kernels without causing too much damage
>>to the running system.

i'd have thought it would be harder to encapsulate the drivers
than user-level code, but since no one has tried, we don't really
know.  one result of attempting it would be a possibly useful
comparison between Linux and Plan 9 kernel internals and interfaces.
(currently, my favourite examples are drivers for non-x86
platforms that must produce x86-defined values for higher levels.)

the Linux driver interfaces are supposed to have changed significantly in 2.6
according to the Linux glossy magazine i bought recently.  i haven't yet
looked at the code.  the catch in using 2.6 as a basis is that i suspect many drivers
haven't been converted.  either that, or there's nothing to
convert because it hasn't really changed.

for useful drivers, is xBSD really well behind Linux?
i'd have thought encapsulating a BSD one would be easier,
if it's possible at all,
if only because BSD started with a Unix model so the pitfalls
are fairly obvious to start with.

perhaps more to the point, which missing drivers in particular
have provoked the crisis?  has it just built up?

Linux itself is having trouble with hot plugging things, if my recent
experience with Redhat is any guide.  actually, it was cold plugging
things: i had to take one card out because it couldn't drive it at all
and put in a card that i thought it could drive (sound familiar?).
admittedly i got it to work in the end but only because i
kept thumping it and correcting it each time it
went wrong.  (``which ethernet was that again?''
i don't know: you've got the PCI vendor/device ID database! look it up!)
it was worse than Windows.  Windows seems to
specialises in drivers that must (or must not) be installed
before (or after) installing the device.  read the bits of paper
carefully!  don't panic!  don't hit the computer!
``i've already given you the bloody driver disk!  THERE IS THE DRIVER!''
(my 2000 hasn't really recovered from the Bluetooth experience.
i myself have barely recovered.)   i can only assume there are nasty
things to sort out that are hard to get right that we've avoided only
because we haven't done this sort of thing.  either that or there
are surprisingly many twits writing code.

Re: [9fans] porting from vs. porting to Plan 9

[Richard Miller]

> either that or there
> are surprisingly many twits writing code.

Why surprisingly?  Sturgeon's Law applies to software too.

Re: [9fans] porting from vs. porting to Plan 9

[Geoff Collyer]

There are obvious driver interface mismatches between Linux and Plan
9.  Linux has ioctl, mmap and select entry points; Plan 9 drivers
present a file system interface.  I think we can ignore mmap and
select, and probably some sort of class drivers can provide the glue
between a file system interface and the Linux drivers, including
turning I/O on ctl files into calls on the ioctl entry points, though
I don't know if they are sufficiently standardised across drivers for
that to work with tweaks for each Linux driver.

My impression is that Linux has more drivers because it has more
contributors.  Here are some numbers from systems I have access to.

	RedHat 7.3:
	; pwd 
	/usr/src/linux-2.4/drivers
	; du -sk
	98820	.
	; du -a | wc -l
	   4149

	OpenBSD 3.3:
	; pwd
	/usr/src/sys
	; du -sk scsi arch/i386/isa arch/i386/eisa arch/i386/pci | addup 1
	946
	; du -a  scsi arch/i386/isa arch/i386/eisa arch/i386/pci | wc -l
	     106 

The Linux numbers look incredible (and they exclude object files), but
they've got busy little typists working for them:

	-rw-r--r--    1 root     root       632394 Sep  7  2001 qlogicfc_asm.c
	-rw-r--r--    1 root     root       741668 Aug 18 11:33 advansys.c

I drew up a list of obvious drivers that one could write: Adaptec PCI
SCSI; various gigabit Ethernet cards; USB, Bluetooth and Firewire
generic (protocol), device class and controller drivers; flash memory
widgets; random sound chipsets; random VGA chipsets; and perhaps
serial ATA.  I must admit that I'm not currently in need of any of
these, though that could change if I bought a laptop.  Some of these
may just be checklist items that would make people feel warm and
fuzzy, but also probably some people could make use of others (notably
VGA and ether).


As for C++, X and configure, my sense is that implementing X (even
from scratch) will add a lot of bulk to the system and I wonder how
much use it would get other than web browsing (about which, see
below).  C++ is another source of bulk.  Is there a cfront-like
C++-to-C translator extant for the current version of C++?

I've been pretty happy with vnc to Unix machines that also run u9fs
for web browsing (I use a private 100Gb/s Ethernet for this).
Likewise, when I need to use some GNUware, it's much simpler to just
install it on a Unix system and access it remotely.  I think trying to
make GNUware runnable out of the box will contort the system until it
looks like a GNUish lunix system (e.g.  Linux).  I installed the
latest Bochs emulator last night; this is the size of its configure
script:

	; wc bochs/configure
	   23851   84792  701647 bochs/configure

The sheer size of configure scripts is bad enough, but they are
stuffed full of bad AI and knowledge of lunix path names and other
intimate details.  Some examples: if your C compiler is named pcc,
configure won't find it and will quit; if your C compiler generates .8
files instead of .o files, configure will quit; if your include files
aren't in /usr/include, configure won't find them.  configure does all
this sniffing and probing to determine things that are largely
irrelevant to its real job, which seems to be converting prototype
makefiles into usable makefiles and guessing at the local OS
configuration, but if any of a long list of tests fail, it just quits
and leaves you unable to even try to run make.  For simple programs,
"cc -I. *.c" usually works, but sometimes the authors have provided
complicated trees of include files that have to be searched in a
particular order.  (Speaking of which, here are numbers from RedHat
7.3:

	: new; cd /usr/include
	: new; du -sk
	81396	.
	: new; du -a | wc -l
	   9672

And these include files are full of #if, #ifdef and games with #define.)


The problem that I believe configure was designed to solve (divergence
of Unices during the Unix Wars) is going away and all the Unix vendors
are making their systems compliant with POSIX and SUS and the like, so
configure's raison d'etre is vanishing, yet configure scripts are
getting bigger and more ludicrous.  Maybe it's getting bad enough that
lots of people need to start telling the GNU project to just aim for
POSIX/SUS/whatever and get rid of configure and its associated
religious machinery (autoconf, automake, etc.).  The alternative, for
us, seems to be to make Plan 9 look enough like Linux that ¾MB
configure scripts can poke, prod, sniff and make false deductions
based on bogus assumptions, and yet happily build GNUware.

And once started down that road, it just gets worse.  More and more
GNUware now wants perl just to build, never mind run.  And you may
need GNU's special make too, and on and on.

Re: [9fans] porting from vs. porting to Plan 9

[Tristan Seligmann]

On Sat, Oct 18, 2003 at 04:09:18 -0700, Geoff Collyer wrote:
> As for C++, X and configure, my sense is that implementing X (even
> from scratch) will add a lot of bulk to the system and I wonder how
> much use it would get other than web browsing (about which, see

What about OpenGL etc.?

Re: [9fans] porting from vs. porting to Plan 9

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 100 bytes --]

i don't see why that couldn't drive draw directly.
(i thought tinygl would do for my own purposes.)

[-- Attachment #2: Type: message/rfc822, Size: 2484 bytes --]

From: Tristan Seligmann <mithrandi-9fans@mithrandi.za.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] porting from vs. porting to Plan 9
Date: Sat, 18 Oct 2003 15:09:08 +0200
Message-ID: <20031018130908.GA30767@mithrandi.za.net>

On Sat, Oct 18, 2003 at 04:09:18 -0700, Geoff Collyer wrote:
> As for C++, X and configure, my sense is that implementing X (even
> from scratch) will add a lot of bulk to the system and I wonder how
> much use it would get other than web browsing (about which, see

What about OpenGL etc.?

Re: [9fans] porting from vs. porting to Plan 9

[mirtchov]

> i don't see why that couldn't drive draw directly.
> (i thought tinygl would do for my own purposes.)

tinygl is a mess that doesn't even look right...

MesaGL 5.0.1 has been sitting largely compiled in $home since June
15th..  It needs a driver for the software renderer and for glut,
which I believe is the harder of the two.

it also needs time, which nobody seems to have.

as fo rrewriting X apps for libdraw, it is relatively straightforward
to translate the simple X primitives into libdraw ones.  the
xscreensaver hacks are an example.

i think Geoff is right -- without somebody being able to work
full-time on those things nothing will get done.  the bubble burst and
the code that depended on developers' spare time is moving ahead
slower and slower -- see how long it took for FBSD 5.0 to come out.

Linux, on the other hand, has at least one full-time developer at
every major corporation working for it.  it's the one with the
momentum behind it.

Re: [9fans] porting from vs. porting to Plan 9

[Tristan Seligmann]

On Sun, Oct 19, 2003 at 21:28:03 -0600, mirtchov@cpsc.ucalgary.ca wrote:
> MesaGL 5.0.1 has been sitting largely compiled in $home since June
> 15th..  It needs a driver for the software renderer and for glut,
> which I believe is the harder of the two.

How would hardware support be handled?

Re: [9fans] porting from vs. porting to Plan 9

[mirtchov]

> On Sun, Oct 19, 2003 at 21:28:03 -0600, mirtchov@cpsc.ucalgary.ca wrote:
>> MesaGL 5.0.1 has been sitting largely compiled in $home since June
>> 15th..  It needs a driver for the software renderer and for glut,
>> which I believe is the harder of the two.
>
> How would hardware support be handled?

it won't...  even if Plan 9 knew hardware optimizations for anything
beyond rectangle fills, scrolling and hardware cursors there would be
too much code required to get mesa to use it.

ideally one would be hiding optimizations behind something like
/dev/opengl, but a reimplementation of the opengl library as a file
server is, I believe, beyond the amount of free time anyone on this
list has available :)

I don't think we can catch up with 2.0, even if we never look at the
1.x stuff...  makes for a nice student project though, doesn't it?
pity nobody would let me do it back when mesa was in its relative
infancy.

andrey

Re: [9fans] porting from vs. porting to Plan 9

[Patrick R. Wade]

In article <43bc6b835731c3c823fdd658cb28775e@plan9.ucalgary.ca>,
mirtchov@cpsc.ucalgary.ca wrote:
>
>i think Geoff is right -- without somebody being able to work
>full-time on those things nothing will get done.  the bubble burst and
>the code that depended on developers' spare time is moving ahead
>slower and slower -- see how long it took for FBSD 5.0 to come out.
>

Which seems kind of backwards; one would expect the bubble bursting to
leave lots of developers with *more* spare time than before...

--
:wq!
?
^X^C
?

Re: [9fans] porting from vs. porting to Plan 9

[david parsons]

In article <slrnbp6q8f.b5f.pat_e@garcia.efn.org>,
Patrick R. Wade <pat_e@efn.org> wrote:
>In article <43bc6b835731c3c823fdd658cb28775e@plan9.ucalgary.ca>,
>mirtchov@cpsc.ucalgary.ca wrote:
>>
>>i think Geoff is right -- without somebody being able to work
>>full-time on those things nothing will get done.  the bubble burst and
>>the code that depended on developers' spare time is moving ahead
>>slower and slower -- see how long it took for FBSD 5.0 to come out.
>>
>
>Which seems kind of backwards; one would expect the bubble bursting to
>leave lots of developers with *more* spare time than before...


   Not necessarily.  Being unemployed takes you away from your nice
   remote office where you can work on your open source(r)(tm)(c)
   project after hours and during lunch and puts you at home, where,
   aside from the exciting job of writing PLEASE HIRE ME letters,
   sending resumes, and looking for more victims to send resumes to, you
   become available to the rest of your family.

   I'm guessing that in the two years of recovery that I've enjoyed I've
   done less open source(r)(tm)(c) coding than I've ever done since
   before I was a college student, and the largest chunk of that coding
   has been sneaking off to do 5-6 hour keep-my-fingers-dirty exercises.


                 ____
   david parsons \bi/ Grrr.
                  \/

Re: [9fans] porting from vs. porting to Plan 9

[Charles Forsyth]

>>My impression is that Linux has more drivers because it has more

i get the impression there are also a good few drivers for
old things you wouldn't use anymore, including some
for which plan 9 had drivers but which have been declared
obsolete and aren't there any more.  (i looked at the driver for one device
that i knew quite well.  it was grim.)  plan 9 eliminates
whole platforms from time to time.

Re: [9fans] porting from vs. porting to Plan 9

[bs]

Here are my thoughts:

To interoperate with other OS's out there one should port 9P2000 and
the 9fs (u9fs) to those OS's at a minimum, and support CIFS and NFS at
a minimum.
Slamming the namespace into the other OS's might pose a problem, or
almost close to impossible.
With this, one can get into co-existing everywhere.

With the port of the libraries from p9, one can, if they want, start
writing portable code going forward. This way we can build up the base.

The bigger challenge now is how to work with all the h/w bits out there:
If one can only understand the clear differences between a
plan9 device driver and a linux/bsd driver, even twits like me can
contribute to converting them. Hey, run through a translator, compile
a few times and get it standing up.

This IMO can atleast help getting p9 closer to the masses. (This will
still not get us a browser, but if the python port is complete, one
can try porting Grail over. May be we need Tk too.).

-bs

Re: [9fans] porting from vs. porting to Plan 9

[Richard Miller]

>>>It might be possible to construct a cage such that Linux drivers could
>>>be compiled and run in Plan 9 kernels without causing too much damage
>>>to the running system.

Coincidentally, QNX Software Systems have just produced a white paper
on a case study of converting a Linux driver (for the SMC9452TX
ethernet adapter) to use with QNX.  They report a successful result,
largely because that particular Linux driver is "well-structured" with
a clean division between hardware-specific code (which could be reused
without changes) and OS-specific code (which was mostly rewritten).

The hardware-specific and OS-specific parts were 7400 lines and 2030
lines of code respectively.

The largest Plan 9 ethernet driver has 2117 lines of code in total.

-- Richard

Re: [9fans] porting from vs. porting to Plan 9

[I RATTAN]

On Sat, 18 Oct 2003, Richard Miller wrote:

> Coincidentally, QNX Software Systems have just produced a white paper
> on a case study of converting a Linux driver (for the SMC9452TX
Where can I find this paper?

-ishwar

Re: [9fans] porting from vs. porting to Plan 9

[Richard Miller]

>> Coincidentally, QNX Software Systems have just produced a white paper
>> on a case study of converting a Linux driver (for the SMC9452TX
> Where can I find this paper?

http://seminar2.techonline.com/~qnx22/sep2903/index.shtml

You will be asked to "register" with assorted personal information before
they let you download it.

-- Richard

Re: [9fans] porting from vs. porting to Plan 9

[ron minnich]

On Sat, 18 Oct 2003, Richard Miller wrote:

> The largest Plan 9 ethernet driver has 2117 lines of code in total.

not a completely fair comparison. A lot of those linux drivers have cases
for all the buggy various implementations. See the Tulip driver as a
worst-case (but it's not; see the tg3 driver ...)

ron

Re: [9fans] porting from vs. porting to Plan 9

[jmk]

On Mon Oct 20 10:05:41 EDT 2003, rminnich@lanl.gov wrote:
> On Sat, 18 Oct 2003, Richard Miller wrote:
>
> > The largest Plan 9 ethernet driver has 2117 lines of code in total.
>
> not a completely fair comparison. A lot of those linux drivers have cases
> for all the buggy various implementations. See the Tulip driver as a
> worst-case (but it's not; see the tg3 driver ...)
>
> ron

Which Linux tulip driver? The one that only handles the 21041 or the one that
says it has had all 21041 support stripped out but hasn't (linux-2.5.69)?

Of course I can't really disagree with your main point, that it's not a fair
comparison and that the drivers purport to handle many buggy chips. Indeed,
many of them do. I'm reminded of when I wrote the Realtek 8139 driver and
I looked at a number of the *nix drivers. They all had reams of code dealing
with chip bugs, but the bugs described in one driver were not the same as
those in another.

Re: [9fans] porting from vs. porting to Plan 9

[splite]

On Fri, Oct 17, 2003 at 04:38:41PM -0700, Geoff Collyer wrote:
>
> I think the Linux kernel is hopeless and I don't want to run it:
> ignoring its size, complexity and ugliness, it's just too buggy and
> poorly designed.  The thought of storing files that I value in a file
> system implemented on top of that kernel makes me queasy.

Then try not to think about all the poorly-designed, buggy hardware between
the kernel and your bits.  You'll lose your lunch.

Yeah, Linux sucks, but it works well enough.  I've had more trouble with my
car, water softener, garage door opener, etc. than I've ever had with Linux
filesystems.

> It might be possible to construct a cage such that Linux drivers could
> be compiled and run in Plan 9 kernels without causing too much damage
> to the running system.

I'd guess that each driver would require its own custom-made cage.  Maybe
that would be less work that re-implementing the entire driver, but I dunno.

> I'd like to have a full-time person keeping up with new hardware
> (processors and peripherals mainly), but I don't know how to fund such
> a person.  Much of the code could be shared with Inferno, so that
> might help.

The problem is finding someone with sufficient taste to write decent
Plan 9-style drivers but low enough self-esteem to inflict monstrosities
like USB on themselves daily.  Good luck.

Re: [9fans] porting from vs. porting to Plan 9

[Ronald G. Minnich]

On Fri, 17 Oct 2003 mirtchov@cpsc.ucalgary.ca wrote:

> You see, without the reason to run Plan 9 it'll just become yet
> another dead operating system, just like Oberon recently discussed --
> the ideas from it live here to an extent, but the system itself has
> long gone...
>
> Opinions?

I'm with you. Plan 9 apps on Unix will suffer from all the things that are
wrong with Unix. It's kind of like Eunice, for all you fogies out there.

ron

Re: [9fans] porting from vs. porting to Plan 9

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

I think the system will stay alive as long as some of us use it.
Regarding drivers and the like, it's likely that we get them done as some of us
need them.

I'll try to help by proposing student projects along the lines suggested by
presotto. But wouldn't count on that too much, and right now I dont have the
time to pick up those tasks myself, sic.

[-- Attachment #2: Type: message/rfc822, Size: 2811 bytes --]

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] porting from vs. porting to Plan 9
Date: Fri, 17 Oct 2003 10:43:57 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0310171042050.12273-100000@pink.lanl.gov>

On Fri, 17 Oct 2003 mirtchov@cpsc.ucalgary.ca wrote:

> You see, without the reason to run Plan 9 it'll just become yet
> another dead operating system, just like Oberon recently discussed --
> the ideas from it live here to an extent, but the system itself has
> long gone...
>
> Opinions?

I'm with you. Plan 9 apps on Unix will suffer from all the things that are
wrong with Unix. It's kind of like Eunice, for all you fogies out there.

ron

Re: [9fans] porting from vs. porting to Plan 9

[Christopher Nielsen]

On Fri, Oct 17, 2003 at 07:01:19PM +0200, Fco.J.Ballesteros wrote:
...
> Regarding drivers and the like, it's likely that we get them done as some of us
> need them.
...

How else do drivers get written? :)
That's exactly why I wrote the 48-bit LBA support for
the ATA driver. I needed it.

I would like a better multimedia subsystem so I don't
have to use a MacOS or Windows to produce music, so I'm
trying to work on that. I would like better SCSI controller
support, so when I have the time (and no one beats me
to it) I'll work on that.

My point is that Plan 9 isn't dead as long as we keep
developing it, which some of us are doing.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] porting from vs. porting to Plan 9

[Douglas A. Gwyn]

Christopher Nielsen wrote:
> How else do drivers get written? :)

The hardware vendors write them (or contract to have them
written) for the OSes that are dominant in the marketplace.

It might not be a bad idea to study the WDM to see if its
drivers can be interfaced to some generic Plan 9 device
driver; while crufty at least it would help solve the
problem of not getting enough information from hardware
vendors to write Plan 9 drivers.

Or if Linux has a better driver interface for this
purpose, use that.  At least Linux has *some* vendor
support.