> While I admit that time is a determining factor for an individual, you > know > how much (time) a port costs and ...
Painfully well. Especially in having to spend time with lawyers to CMA. > The problem is that it's not the "oh it boots and gets to single user > and...", multiuser, networking, drivers,... but then it's QA, keep it > running, bundle it, adopt apps, mgmt apps, write docs, guides, ..., > support > it. Teams, more people, different temas, PYs PYs PYs. Exactly. > Lot's of consulting > hours to sell to migrate Sparc people to z aeh linux and solaris to BSD on > z;) More like "lots of non-billable hours to spend to convince people to consider doing projects in the first place". Harder than it looks. > > OpenBSD would be fun, ... > > On the other hand another problem I see for going BSD(*) (even for fun) is > the > lack of (public) documentation - I don't mean principle of operations or > the > like but OSA*/HS/crypto/... for example. I guess if getting there, that > would > not be a problem anymore - at least with 3-letters-paper. Having recently done this with OpenSolaris, I can say that, modulo crypto, this is near to being possible without the gory details of how the hardware works. You need to look very closely at APAR VM64466 for the final set of information to get a server-oriented system going; the rest of what you need is in the CP Programming Services manual, which is publically available information. (You can thank the OpenSolaris project later for getting the bit of work in VM64466 made public). Hopefully IBM will keep their promise on publishing documentation for the services therein on schedule. > I always worry what would be > next if one gets there? To keep this relevant to this list - Would the > answer be 'find someone and go for VM'? See above. You can do it much more easily, if you start with the assumption of z/VM being present. After that, it's just learning more than you ever wanted to know about cross-compilation...8-)
