HI Everyone, Here is my reply,
On 08/07/12 18:28, Juergen Daubert wrote: > Hello, > > now that glibc 2.16 is available a new version of CRUX seems to be > doable. But before we start working, we should consider some important, > upcoming changes besides the usual small updates and improvements [1]. glibc 2.16 breaks some ports that need to catch up yet so it'll still be some time yet before this will be ready. > > > a) Switch our main development platform to the x86_64 architecture [2], > the first version should be called CRUX 3.0. Totally agree on switching main system to x86_64 > > At the time Per Liden had created CRUX, the i686 processor on base of > the 32-bit Intel IA-32 architecture was state of the art and therefore > chosen by him as the default optimization for CRUX. But nowadays, over > 10 years later [2], the i686 arch is more or less obsolete, at least > for desktop machines. The 64-bit extension to the x86 instruction set, > mostly called x86_64, is the the new standard now. > > We had extensive discussions on IRC about the type of system we want, > a pure 64-bit or a multilib system. > The main consensus is that we ship a "multilib ready" system, but > without the 32-bit compatibility libraries except for glibc-32. The > reason for this exceptions is the gcc compiler, which needs the > glibc-32 at build- but not at run-time. > The problem we are facing is the great debate between a minimal tool chain and glibc-32 in core to a pure 64bit tool chain. > b) Keep our repository layout as simple as possible > > At the moment we have official repos for i686 and overlay repos for > x86_64 and multilib on top of those. That's ok and the best way to do > it at the moment, but not really neat for the final solution. > I'd suggest to merge everything needed by a) into our core/opt/xorg > repos and add only _one_ additional repo, probably called 'lib32', > for the compatibility libraries. If we must have one repo for 32bit compatibility it should be called compat32. But I disagree it's not hard to have coe-32 xorg-32 opt-32 contrib-32 as jaeger has now. > > c) Create a final CRUX 2.7.2 for i686 I don't like the idea of a final x86 ISO, not yet at least, x86 has some life in her yet. I would prefer if a team could still build x86 iso, that track the x86_64 ports and only those that need tweaking provide a x86 overlay, if there is enough demand for x86 still, we would get more users signing up to be maintainers for this older generation in computing history. > > TBH I'm unsure if we should do that, but it would be a nice service > for all people using CRUX on older hardware and might be the basis > for contributed i686 ISOs in the future. IMO updated xorg stuff is > a must-have for such a version, however, as the version number 2.7.2 > suggests, I wouldn't change the toolchain. > The main idea behind is to have a final mostly up-to-date system with > a very solid toolchain for the 'old' architecture. > > > d) Device management > > As outlined in another mail [4], the udev sources has been merged > into systemd and it's no longer possible to build a standalone udev > with minimal dependencies. It is foreseeable that systemd will become > a hard dependency for udev soon. What can we do? > > - stick with udev 182 or try to extract newer versions from systemd > even if we had to add stuff like dbus and intltools to our core > ports. How long will this work? > - switch our init system to systemd > - use devtmpfs together with mdev for device managment > > IMO going with mdev is the most clear and CRUX-ish way [5], but we > might run in greater problems in the future, because more stuff will > depend on udev/systemd. This is especially true for all kind of > "desktop" software and everything that depends on dbus, *kit and the > like. I agree we should stick to udev 182 for now, I really really really dislike systemd, hanging off on updating udev should hopefully provide another option, as mentioned other distros are holding off as well for a better solution. > > > What do you think? Other points to make that x86 (32bit) could be comunity driven so as to not be official but still available for use. Much like Jues i586 was around for a very long time. except more users will hopefully jump on that band wagon. IF we must have a pure 64bit iso then we could have some script to convert it to multilib and add in the additional overlay repo's as required. > > > best regards > Juergen > > > [1] http://crux.nu/Wiki/TODO28 > [2] One may ask why not doing both alongside, but that is too much > work for our little team, at least as a official version. > [3] http://crux.nu/Main/History > [4] http://article.gmane.org/gmane.linux.distributions.crux.devel/2284 > [5] From my personal point of view I was never really happy with > udev. The whole development is unpredictable and udev is doing > all kind of "magic" behind my back. > > _______________________________________________ > crux-devel mailing list > crux-devel@lists.crux.nu > http://lists.crux.nu/mailman/listinfo/crux-devel > > Regards, Danny Rawlins Romster @ Freenode _______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
