Hello to developers! I'll talk from a random user perspective here.
On Sun, 8 Jul 2012 16:29:40 +0200 Fredrik Rinnestam <fred...@rinnestam.se> wrote: > On Sun, Jul 08, 2012 at 10:28:57AM +0200, 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]. > > > > > > a) Switch our main development platform to the x86_64 architecture [2], > > the first version should be called CRUX 3.0. > > > > 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. > > Unsurprising I fully support a change in direction towards x86_64. I > also would prefer to ship a stripped down x86_64 only version on the ISO > but with the option to simply add multilib binaries if one chooses to do > so. shipping glibc-32 is a good compromise. It sounds like a relatively safe and minimalistic plan. Should suit most users needs. > > 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. > > Yes. Keeping only one "compatibility overlay" repo would simplify things > a lot. Currently mesa3d is the only xorg port that needs a specific > x86_64 .footprint. I've been reluctant to do anything about this since > it would require a new repo for just one port, with the current setup. Should be pretty easy to use and work on too. > > c) Create a final CRUX 2.7.2 for i686 > > > > 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. > > Hmm. I do think i686 deserves a new and up to date release (2.8 or 3.0, > whatever). I'm not sure it's fair to all the i686 users to just drop a > "sorry, no longer supported" bombshell without prior warning. As it has > been for a couple of years now, x86_64 has been "unofficial" and > "experimental", possibly scaring people away from x86_64 and to i686. Yes, it was scaring me all this time. And all the different versions floating around over past few years complicated the decision even further. However, even with the possibly official x86_64 version release the need in recent i686 would not gone away immediately. For example, I am still running CRUX on an old PC as a router, on legacy laptop and on a few VPS at Linode (as it have somewhat smaller memory footprint). A fairly fresh desktop PC would welcome native architecture for sure! > Atleast we should ask around on the mailinglist if people are ready and > ok with us "dropping" i686 in favor of x86_64. Not sure if a great part of CRUX users are really following the ML... although, can't imagine real usage without doing that. Maybe, a few of us can manage to test/update i686 specific repos from time to time. Should it be fairly easy? > > 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 think the future of udev is a bit uncertain at the moment. We are not > the only ones that dislike systemd. Staying with a "stable" (182?) udev > version > might be the best bet for now. If major issues would appear (security > etc.) it should be not too hard finding patches since few distros are as > up to date with upstream as we are. > > Switch to systemd? over my dead body! :) > > mdev could work. But you do lose features that one's gotten used to over > the years (autoload of modules, xorg, etc). I currently use mdev on my desktop > and, although it does the job it's supposed to do, it did feel like > stepping backwards in time. It is also possible packages might break > during the lifetime of 2.8 (or 3.0). xorg-xf86-input-evdev breaks in > recent versions without udev. Perhaps being a bit conservative here and > stick with a working udev version is the safest bet? Using some exotic (CRUX-specific) solution would hurt someone sooner or later. (Not really sure what it means in aspect of systemd.) I'd like to see most recent udev as far as it works with most other upstream releases. Have you considered posponing any udev/systemd changes for CRUX 3.1? There might be other distros developing possible solutions over time... which we can borrow/learn from. Thanks for the great work and such a clear summary of possible upcoming changes. -- JID: fake.mike.k at gmail dot com IRC: mike_k at freenode/#crux _______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
