Hi Riccardo,

First, I want to thank you for taking the time to share your
observations. We really need feedback right now. 

> since there is a thread going on about various problems holding NetBSD
> from total world dominaiton, I'll throw in here some of my
> impressions, in order of "experience".

Domination? Nah. We can't force anyone do to anything. We can only
lead...

> 0) the world is biased towards linux and x86
> solution: I don't know one

It's not truly a competition. One of the core strengths of NetBSD is its
ability to teach. Just look how often OpenBSD bases their code on
NetBSD.

> 1) hardware support is limited. My 8200 mac is not supported, my
> pb1400 either. The only viable box I found is my 9500.
> workaround: get another box...
> solution: as far as the ppc601 concerns, someone had success on rs6k
> machines. since the a PCI/601 combination is possible (on x200
> machines and as cpu doughterboard) someone with experience could try
> to see if we as macppc could benefit too

I've got a 7200 here, which is a ppc601. I could probably convince my
wife to let me...borrow... it for a bit, but we also have to ask
ourselves how far back in hardware do we want to support?

> 2. installation troubles. It was really hard to boot that thing! I
> admit that the fact that old 1.0 OF defaults to serial console is a
> drawback...

Yes, the installation process could be smoothed out some. What would be
nice is a MacOS application that did the installing, but that's
difficult to do.

The biggest double edged blade that I see is our user base on macppc.
Many of them, perhaps the majority of them, are former MacOS users (not
OS X). This means they expect a very high quality user experience. The
standards for user experience are different for BSD, with the emphasis
on "different" as opposed to "not as good" or any other judgemental
sentiment.

There are a lot of things in the macppc experience that an i386 or Sparc
user will ignore or workaround that a former MacOS user will find
and say,"it's broken, let's move onto something more polished." I think
it is also true that the macppc user base is changing and becoming more
MacOS users and less BSD users. The reason is that Apple is increasingly
dropping support for older hardware with OS X, and a lot of people,
myself included, said that if I have to learn a new operating system,
then I'm going to learn one that isn't Apple's. 

> 3. Ethernet troubles. Onboard mc0 is essentially unusable
> workaround: get another supported ethernet card (no, don't get a RTK
> that one works bad under  NetBSD too)
> solution: fix the driver of the onboard ethernet (which works on
> 1.6.2/mac68k. At least I think the Q840 has a mc0 card). But it seems
> that not everybody can reproduce this either, so not easy.

I haven't seen mc0 problems. I know that others have. I agree that it
needs to be fixed, but I bought a new Asante card for $20 that works
with sip*. I'm getting about 950KB/s on my seven year old 10 Mps hub
with it. I added the card for reasons other than mc0 problems.

> 4. SCSI troubles. I had problems with Sync/async negotation and sync
> not working and locking up the kernel
> solution: the patches from Michael seem to work fine and I never
> experienced problems again. Others should test them and I think they
> shall find the way to 2.0

I'm running his patch now, as well. I would have liked to have run pre-
and post-patch benchmarks for concrete numbers, but he's gotten feedback
that indicates speed is up as much as 30%. This patch will likely be
committed soon, but the default config options flag for mesh will
probably be to disable sync.

What would be good, though, would be for clear directions on how to use
config interactively to set flags in the kernel, in which case the user
would not need to recompile (I hope...) in order to enable sync.

> 5. X troubles. This is by far the biggest nightmare.
> - server not working
> - Michael gave me a patched server that seems to work fine with my
> Matrox card

Michael is doing good work with X. We are hoping to tackle the problem
with X losing sync on quit soon. It is a high priority, as it should be
consider in the same level of severity as kernel panics. Anything the
requires the user to reboot to continue using their previously
functioning NetBSD box in unacceptable. Unacceptable.

> this is the first bunch of "blocking" complaints.
> 
> A further "feature request" would be the following:
> The OF console is limited. This is true also for the /sparc port. It
> is slow, black/white only and offers no multiple terminals. It has of
> course many advantages: works out of the box and works on serial port,
> etc.

Right now I'd like to see additional resolutions, so at least
we can have more than 640x480 (someone correct me if I'm wrong and this
is already present). There are OF routines to allow this(fb8 calls), but
I haven't had time to explore them.

> This is of course not "everything" that should be fixed, the solutions
> are only suggestions and it is my personal experience. But I think
> more than a user would benefit from fixing these points. Also the
> Tsunami board that my 9500 uses is very widespread among "older" macs
> and their clones umax...)

Feedback is good :-)

tim