> I'm just a lurker, but 'hi'. Hello ;-)
> > With this post I started the work on Menhir. > > Menhir will distribute the sources of: > > FreeBSD Release 6.1 (base system) > > 6.1 is archaic; the last release of FreeBSD is 6.2. > and 6.2 is six months old. 6.1 was released in may of > 2006 which makes it painfully out of date. So > personally, for the sake of features and security I > would choose 6.2. Thank you very much, for showing me this typo. Because I had in my thoughts "6.2" but I wrote "6.1". > Actually, for the sake of security I'd choose OpenBSD > 4.1; but then you'd be losing features (mostly device > drivers and WINE). No, no OpenBSD for the time being. Because I want also target Xen machines and OpenBSD is not "Xen ready". All the other Menhir included operating systems are Xen ready. > > Slackware 11.0 (all packages which are required > for > > "starting with pkgsrc) > > Slackware is forever frozen, meaning it would be hard > to apply security patches. As much as I hate gentoo, > I think they might be a better alternative simply > because they have a mechanism for applying > source-based security updates into the OS. No, Gentoo is not approriate for my goals. A distro which updates every day glibc is not for my goals. (As this thread should target more OpenSolaris I want to stop this here. We can discuss privately the pros and cons.) As the Slackware "upstream" have already guaranteed a long time for Slack11 support I see no problem here. > The best choice, in my quite uninformed opinion, > would be to build a skeleton LFS framework, and drop > in packages as needed (foo-0.1a has a security hole > so you unpack foo-0.1b into your source tree and tell > people to update via subversion or whatever). Too much work. I want to be able to concentrate on my goals to gather the several free OS projects/devs/users on one site. Your proposal is _maybe_ better technically but it would be "micro-managing". > This might not be as unfeasible as it sounds at > first; the last time I read the LFS site they were > working on an automated LFS, so I'm sure you could > pull out a great deal of ideas and infrastructure > code from that. > > It's something to consider and I think it would be a > better alternative than relying on slackware's > packages. See above. > > NetBSD Release 3.1 (base system) > > Getting old in the tooth, but since 4.0 hasn't > appeared yet, fair enough. > > > OpenSolaris build 65 + two tar balls of closed > > binaries which are required. > > + > > All I can say is that I hope you've had better luck > building meta-pkgs/xorg on solaris than I have... > (disclaimer, my problem may involve a lack of skill > rather than luck). > > > pkgsrc 2007Q1 > > 2007Q2 is on the verge of being released, and 2007Q1 > will no longer be supported. That is no problem, as I then just have to update the guides/docs about Menhir to pkgsrc2007Q2. And to test the packages with the several base systems. > > > > The base systems are _forever_ "frozen" . Only bug > > fixing and security updates will be > > included in the source files. Only the pkgsrc tree > is > > a "moving" part for > > actual and fresh userland. > > > > So, are you saying that you will never update the > base system? If so, I think you'll very quickly end > up with cripplingly out-dated and irrelevant base > systems. A much better idea would be to pick two > arbitary times a year (I would suggest tracking when > pkgsrc makes their releases) and update each base > system then (even if it meant only distributing the > latest cvs versions if they have not made a new > release between the two pkgsrc releases). I really don't know how the people come to the idea of "a two old package, gosh, i have to update to the newwest version from the CVS"!?! I am working here with a Slackware with the 2.4 kernel. And I am a full multi-media person. Watching flash-movies, watching web-casts from several software/hardware vendors, talking with people over VOIP, all these things with a 2.4 kernel. > You're doing no one any favors by distributing > antiquated base systems which lack features and/or > drivers. Please, which features lack FBSD6.2 -again excuse me for my typo in the last mail - , which NetBSD3.1, which OpSol build 65 (the actual build is something like 66 or 67 but Belenix is using 60 and it is "perfectly" to say it in very short manner) "Antiquated" is nothing: Since the chosen operating systems are actual today and they will be usable for a long time coming. > > want to distribute these 4 operating systems side > by > > side > > How? On DVD? On CDs? Through an ftp site? Are you > going to have each base system have its' own boot > DVD/CD with packages, or what, exactly? I want only distribute the sources because that is the "real gate" to free software. But I will - logically - make guides how to get these sources running. And coming back from your ever Linux dependent comments - but nevertheless thank you for them - to OpenSolaris: OpenSolaris is a source based distribution because this, the sources are released. And we the community have to make the best with the sources. The OpenSolaris devs are releasing the sources. But then some "alpha" community members make more with it - Belenix , Martux and so on -. > > or following reasons: > > > > 1) Collaboration: > > I want to make Menhir the meeting point of the > users > > and developers from all > > the four operating systems. They should chat, > develop > > and test together their > > systems for interoperability, security, stability > and > > so on. > > > Sounds good on paper. But it also doesn't sound like > anything that the pkgsrc developers aren't already > doing. Okay, but I want to make that "stronger". And for this site here: I want to bring OpSol into this development. > > With this I want to get rid of the ever ongoing of > > rivalry between the users and > > developers of the (free) Unix-like operating > > systems. > > > That goal is impractical. The rivalry is based on > differences of opinion > which include both technical matters and > philosophical matters (BSD license vs GPL > vs CDDL). It is rivalry, but I want more "standing together" of the Free OS devs. So make the rivalry stop. Maybe I will have success or not -we will see-. > > 2) Teaching: > > I want to make Menhir a distribution for training > the > > administration and development > > skills for all the four operating systems. > > You know that people are driving heterogeneous > > systems at their workplace and also > > in some cases at home. I also don't have to > explain > > to you that heterogeneous systems > > are more stable and secure. > > With Menhir you will get the basis for building up > > skills for such a multi-operating system > > environment. > > > Heterogeneous systems are a good thing; in fact that > is the entire selling > point of pkgsrc. > > I think you have to be careful with this, however. > Someone who learns how to administer "Menhir" won't > be at any advantage when their work places them in > front of a redhat console. If all they know is > "Menhir" they'll be lost if they are ever faced with > trying to do techniques using sun's GUI tools. Oh, I do think that the future users of Menhir will be at an advantage: Because they will have learned the real basics and the ideas about the Unix-like systems. In the most cases until today the GUIs for admin tasks in the Unix land are visuals of the console tools. > > I witness that if today someone learns about some > > Unix-like operating system then it is > > mostly Linux. I want to change that with Menhir. I > > want to bring the broad knowledge > > about all four operating systems to the users. > > > +1, rock on. > > > 3) Experimenting: > > With Menhir you can start your own experiments > > (system building and also development) without > > fear because the stable base systems give you a > point > > to where you can return if your experiments > > were not successful. > > > > But your users wouldn't really building a system, > from what you're saying. If I install Menhir/FreeBSD > I *have* the base system; what I can experiment with > is > what combination of *additional packages* I add on to > it. > > "system building experiments" -to me, at least- > implies things such as trying to get > ulibc to work with the OpenSolaris kernel and porting > the BSD userland to it. But if you're provided with a > "frozen" base system there is no changing the libc, > or the rc.d/smf system. > > With this I want to encourage users to build their > > systems not only with Linux but also > > with FreeBSD or NetBSD or OpenSolaris using the > best > > combination for the appropriate "use-case". > > > > The principles of Menhir are: > > I) Strength : You, as a user, get four > distributions > > with one medium. > > What medium? Or do you mean from one place (ie, one > internet location)? > > > You, as a user, get one united > > documentation for every system. > > Are you saying that you'll be choosing ONE set of man > pages to explain ALL FOUR systems? > > That sounds like a recipie for disaster (eg what > happens when someone reads the linux manpage for > killall and then runs killall under Menhir/Solaris) No, that was maybe not clear enough: You get guides/docs side by side so that you have the four manpages for killall page after page for every system. > > II) Vigour : You get a maximum flexible system. > From > > the kernel up to the graphical userland you can > > choose every part of your system. As the base > system > > is constant the userland will be always developing > > forward. > How are you defining base system and how are you > defining userland? > > What you're describing: including netbsd/base, > freebsd/base and opensolaris implies > that you would *already be* distributing individual > userlands. Each one of those comes with fully stocked > /bin:/sbin:/usr/bin:/usr/sbin, etc. > > You appear to be confusing add-on packages (pkgsrc) > with userland. Okay, ACK, My English is not the best and sometimes i have some difficulties describing facts(finding words for it). > > III) Security : As the base system will be > constant, > > after training yourself or your employees your > skills > > never get old. As the base system will be > constant, > > the testing and bug fixing will make the most > > possible stable system. With the overall quality > > management of the constant base system the most > > possible secure interaction between every > operating > > system will be ensured. > > Until your various base systems become unsupported > and security advisories and patches cease to be > released for them. Which is what will happen if you > -as you say- intend on keeping your base systems > frozen. > Debian considers themselves to be a > kernel-independent Operating System. It would be > incredibly awesome to have operating system releases > which feature the minimum from the host os (apart > from kernel, libc and OS-specific features such as > solaris zones) and have the rest made up from pkgsrc, > (eg pkgsrc/opensolaris, pkgsrc/freebsd, pkgsrc/linux. > and so on) > The advantages I see to this are that you download > your sources *once* and then you are able to create > packages for each OS, and pkgsrc does a great job of > keeping up with current application and desktop > versions (a little better than OpenSolaris and MUCH > better than Slackware). > > I am by no means a CS person (in fact, I'm posting > this from Windows XP), but earlier this year I spent > a few months playing with pkgsrc and minimal installs > of opensolaris, openbsd and slackware (and annoying > pkgsrc-users in the process) with the intent of doing > something similar to what you're proposing. So I > *like* your general idea; but I think you need to > reassess some goals, clarify some points and > completely scrap the idea of having a permanently > "Frozen" base for each OS. > > Good luck, I'll be watching with much interest! Thank you This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
