Hey,

> First, I want to thank you for taking the time to share your
> observations. We really need feedback right now.
I thought so. While I said "world domination" as a joke, I still think
2.0 should come out polished and good.
At the end we often "get attached" to Linux (during linux days, in the
LUGs, in Linux magazines) and that is also reasonable since our userbase
it small. So we should learn where linux made progress, especially if it
is easily doable in NetBSD too.

If on one side we compare to MacOS-X and it is true that many users have
a Macos-classic background like myself, Darwin can spur interest in BSD
too.
That is what I experienced with myself. Once I used heavily MacOS and
booted NetBSD sometimes just to have "the unix feeling". With the time I
got more unix experienced, I develop under unix and I have Os-X on a G3,
on a 9600, I use Irix and Solaris. So I prefer to run NetBSD, linux or
OpenBSD on my old Mac boxen (68k and ppc) since MacOS "is tight" for me
now. I use it only for some tasks where it is better suited or for stuff
like I have software that runs only on MacOS. Still it is amazing how
polished it is, how fast and respoonding the user interface is.
 
> > 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.
Well, this is true in both senses and I praise this, I use both OSs and
I appreciate some aspects of both (and have cirtics towards both)
 
> 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?
On one side it would be nice to support "everything". But at the current
status it would be better to support more conisstently what we have.
Not only for personal reasons, but it yould be goot to support all PCI
machines, a 7200/8200 and a 7500 are still nice machines. Also if ppc601
support is "almost there" it would make even more sense (and think also
how clean our support table would be: "everything with OF is supported"
without little cpu exceptions...)
 
> 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.
That is one way, but think also about how many people want to get "rid"
of macos or don't even have macos.
Several mac/netbsd users both in 68k and ppc are non-mac users that jsut
rescued a non-x86 box and want to slam unix on it.

I like the current install process, light and easy. I would better the
boot process and this is a macppc problem only. The other trouble is
partitioning...

 
> 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.
This is a problem for all "second choice" operating systems. That is
when you compare to an OS that laready exists, may it be MacOS, Windows
or Solaris.
 
> 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.
That makes also an increasingly bigegr number of non-macosx macs
available that people may want to reuse as a second workstation, as a
file server, gateway, test platform for other browsers or whatever.
 
> 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.
I said that not everybody has it. But my 9500 has and I once tried a
9600/Kansas and it had too. It can be worked around, but still, onboard
stuff should be supported. And it is again a "user experience" thing.
 
> 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.
I did benchmarking with both bonnie and bonnie++ and sent the resuls to
michael. They were encouarging for the sync drivers.

 
> 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.
Yes, maybe some sysctl stuff. Or provide a sync/async kernel version.
Although I think if sync proves to be robust it should be standard.
 
> 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.
I agree. But still, having X is already a move forward

 
> 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.
some newer openfirmwares settle to the monitor setting or last macos
boot. Unfortunately old versions stick always to 640x480.
 

Ah, now that I am here I make another complaint, possibly not Macppc
specific.

One thing I learned to appreciate about some linux distributions (but in
some senses OpenBSD too) is that the stuff "comes ready out of the box".

I find it unacceptable that I can't get XDM running. "XDM=yes" in
rc.conf should be more than enough to start the thing with any
reasonable defaults. That is the goal of having "ports".

I enabled it and had no luck, xdm starts but every login fails, both
root and users. (Black sceen and then back to XDM)

I looked around for past posts, tried create .xsessions no help. I am
surely missing something easy, but I am not finding it. The point is tht
all defaults should be reasonable enough to make things work. This is
part of a "polished user experience"

exaclty like ye should provide some Keyboard maps to work with xfree.

-Riccardo