Hi all,
first a big thanks for all the replies we got for the initial 'CRUX
next' thread [1]. We like to summarize the results a bit and do the
following proposal:
- we switch our main development platform to the x86_64 architecture.
This will be called CRUX 3.0 and will be the only version with
official support. We go for the "multilib ready" approach, meaning
that our toolchain is capable to produce 32-bit binaries. Besides
glibc-32 we will not ship any 32-bit compat library on our ISO.
We will merge everything needed for the above into our main repos
and add _one_ additional repo, called compat-32, for the 32-bit
compatibility libraries. After all we will have 4 official repos:
core, opt, xorg and compat-32.
- to give our users a smooth option to switch to x86_64 we create
a final i686 version, called CRUX 2.8. It includes the latest
toolchain and roughly all the stuff listed on [2].
If we find volunteers for it, we might create another repo, probably
called i686, as _one_ i686 overlay for the main repositories.
A summary timeline for the above should look something like this:
1. create a branch 2.8 based on 2.7 for the core/opt/xorg repos
2. update the toolchain and do verything described in [2]
3. release CRUX 2.8 for the i686 architecture
4. create a branch 3.0 based on 2.8 for the core/opt/xorg repos
and add the compat-32 repository
5. merge everything from *-x86_64.git and *-multilib.git into our
{core,opt,xorg,compat-32}.git repositories
6. release CRUX 3.0 for the x86_64 architecture
best regards
Matt + Juergen
[1] http://thread.gmane.org/gmane.linux.distributions.crux.devel/2291
[2] http://crux.nu/Wiki/TODO28
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.
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.
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.
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.
What do you think?
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.
