> About the "obsolescence": There I have no great > problems, > because I read, hear and "know" that the free > operating systems > today can handle the actual hardware and also much > older > hardware. Many businesses have chosen Linux because > they could > then use some older PC for "new" use cases without > buying new > HW. > > Maybe, Sir, I don't understand your obsolescence > problem. > Then explain it to me with some examples, please.
These OSs _now_ support the hardware that their maintainers choose to support, including to varying degrees, older hardware. But within 10 years, today's new hardware will be old indeed, both in terms of performance, and in terms of poor energy efficiency for a given performance level. Some used hardware that's very well built will still be around, but even if the price is low-to-free, with rising electricity prices, it might not even be worth having. Further, there will always be new peripherals (that people will want to use), requiring new drivers. It wouldn't be so bad with Solaris (unless it moves mostly to a different CPU architecture, like 4+GHz PowerPC or some such) inasmuch as Solaris's interface between drivers and the rest of the kernel is _relatively_ stable. But even that can't stay still forever. And on Linux, where they believe that source code means they don't need stable driver interfaces, they make wide-ranging changes fairly often, which means that everything in-tree gets updated, and new drivers have changed interfaces and different kernel facilities to call on; thus, on Linux, backporting new drivers to an older kernel could be relatively difficult. Not sure what the situation would be with the *BSDs. And then there's CPU support. CPUs within a family stay fairly compatible at the unprivileged (user space) level, but less so in privileged mode; then there's newer CPUs that have a hypervisor mode as well. Just about every CPU has _some_ bugs, that the kernel needs workarounds added for. The above distinction between unprivileged and privileged compatibility is probably even stronger for SPARC, which gives itself more freedom by only defining unprivileged behavior as standard; the privileged mode OS behavior has a lot more latitude to evolve. So eventually, you need to start backporting CPU-specific support, or you can't run on new hardware anymore. So, over time, you frozen (except for bug/security fixes) kernels would _only_ be able to run on hardware no longer in production, and on some of the OSs, would need more effort to have any new drivers one wanted to add backported to them. The effort would increase over time, and the support problem for the old hardware would also increase, until spare parts were no longer available, and people would have to try to scrounge 3 or 4 old systems to cannibalize for parts to keep one of them running. Of course, just as an exercise, one could always run this stuff forever on an emulator. Heck, I've run Windows 3.1.1 on qemu, MVS 3.8j on Hercules, CP/M on another emulator, v7 Unix on a PDP-11 emulator, etc. Fun for nostalgia, or if there was some particular app on one of them that was closed source but did whatever it did really well. But not particularly useful eventually. Then there's the course aspect. Over the last few years, we've had considerable growth in virtualization, advanced filesystems and debugging technology, etc. Something "must have" with design principles that students would need to know about, is bound to come along in the next few years, and you won't have it. I give this 6 months to 2 years to get set up, and no more than a 10 year lifespan before it's of little further use, unless you allow for at least occasional (and perhaps synchronized) updates of the kernels. > > The cooperation sounds interesting and possibly > very > > worthwhile, although given the possibility of > > what amount to planned obsolescence (2nd point > > above), I wonder if there would be enough > > interest to achieve much there. Similar point on > the > > promotion of heterogenous environments. > > The cooperation part is really new. The Unix guys > have > real problems with working together. > > I see it as my biggest challenge to bring together > the > OpenSolaris devs with the *BSD devs with the Linux > devs. > > But I want accomplish that. And I will be successful, > I promise. > Just now, I don't know how to overcome the "hatred" > in the > hearts of the users and devs alike for the other > Unix-like OSes. I don't think there's so much hatred as all that; the worst of them, whichever that may be, still has much more potential than Windows. I do think there's arrogance all around, plus some real anger at the fanboys in certain circles that just _have_ to believe that they'll rule the world one day. _Nobody_ should end up ruling the world, nor should there be just one community and one culture; we'd all be the worse off for the lack of competing ideas. The competition however needs to be nonviolent (assuming the others oblige - nothing says you have to let yourself get killed!), and civil enough to keep the door open for cooperation whenever there's some benefit to be gained from it, and keeping in mind that the objective is _not_ to merge into one mind inhabiting multiple bodies. > > A long, slow kernel update cycle (with snapshots > of > > the then current kernels being used as a > > starting point only once the first multi-kernel > > distro is out and stable) might address the > > obsolescence issue, while still honoring the other > > concerns. It would also ensure that the > > opportunity for improving cooperation would be in > > depth and open-ended. > > I want to start a "backporting" of actual drivers to > the > "kernels" existent in Menhir. > With a "frozen" base system the testing will be easy > I think > AND > The real interests in (home) users and developers are > in > application land today I think. > So with this I can create maybe a stable development > platform > for actual applications. All that still holds if you're willing to update the kernels every four or five years, say; at which time you can still do minimum essential maintenance on the old ones. In other words, update just often enough to maintain interest, relevance and usefulness. It may turn out that could be never, but I really don't think it will. > > I think that if you could engage as many Austin > Group > > (http://www.opengroup.org/austin/) > > participants as possible, you could at once work > for > > more uniform standards compliance among > > heterogenous implementations, and yet also for > more > > dynamism (albeit the responsible sort) in > > the standards process itself. I do think that relating this all to formal standards is reasonably important too. Interoperability should promote cooperation, especially if the application space is the main place for new development. There are some difference between for example Linux and Solaris as to how important their individual communities are likely to consider formal standards. But the standards tend to allow enough latitude that compliance shouldn't be unduly burdensome for any one OS implementation, since after all, they are arrived at by participation of multiple vendors. So far, most of the participants in formal standards have been commercial; but this might be an opportunity to bring community based development into the standards process in a big way. The meeting of the disciplined process folks with those that primarily believe in challenging every assumption could be very interesting and beneficial. Although to give some credit, both are in the long run necessary, and those camps originally favoring one and neglecting the other have both moved more towards recognizing the value of both; witness the development of the LSB, hardware vendors writing two-part drivers to isolate the closed or model-specific parts from the OS interface, and so on; and on the other side, Solaris incorporating features such as zfs and dtrace, both of which (and especially the latter IMO) challenge earlier assumptions of how things are done. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
