[crux-devel] CRUX next

Jose V Beneyto sepen at crux-arm.nu
Wed Jul 11 15:14:10 UTC 2012


Hello,

sorry for the delay, I had a peak work these days and I could not answer before

On 07/10/12 18:57, Juergen Daubert wrote:
> On Sun, Jul 08, 2012 at 04:29:40PM +0200, Fredrik Rinnestam wrote:
>> On Sun, Jul 08, 2012 at 10:28:57AM +0200, Juergen Daubert wrote:
>>> [...]
>>>
>>> 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.

I'm running purelib64 in 2 boxes without any problem, and so far I have not found
any impediment for the daily work, anyways I'm open to multilib and I'd be happy
to work with it long as they have advantages.
>>> 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.

I'm not as familiar as you with multilib, so can someone point a link or
information about the problem with gcc compiler and glibc32 at buildtime?
On the other hand, what would be the impact for a port maintainer? [2]

Well, there's something I have really clear, and I like. If we finally switch
to a 64bit system, it must be transparent to the user and have native libraries
in /lib, /usr/lib, ... as it has always been.
I have another 64-bit systems at office and for what I see the one used in
rhel/fedora/centos and in the FHS is that the /lib/ directory (and /usr/lib/)
is for 32-bit libraries, and 64-bit libraries go in /lib64 (and /usr/lib64/).
Debian uses /lib/ for 64-bit libraries, and puts 32-bit in *lib32.
>> 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.

+1
>>
>>> 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.
>
> Not sure if we both mean the same here. For me the lib32 repo is only
> for additional ports that are build for multilib purpose.
> Or in other words everything that is currently in one of the *-multilib
> repositories and named like *-32.
>
> If you are talking about a overlay repo for i686, we should name it
> differently. But one overlay repo for core/opt/xorg would be fine here
> as well, given that we need one, see c) below.

Well lib32 repo or whatever be called means that we would make our life easier.
That means we should avoid being redundant, right?
Overlays could be an alternative, but what about our current git repos/branches
organization? should we move {core,opt,xorg,contrib}.git to *-32 names too?
or maybe we can start to merge changes from *-x86_64 repos to new 3.x branches?
whats the plan and ideas?
Maybe I'm wrong, but there are many things to do and since we're a small team [2]
we must study well the next steps.
>>
>>> 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.
>
> Yeah, that's all right, but who should do all the work? I got the
> impression that I'm the only maintainer still using i686 for the
> daily work. After a finally switch to x86_64 I'm no longer able to
> work on i686, at least not officially. Don't get me wrong, I'm not
> basically against a all-new 2.8 for i686, but I'm open for suggestion
> who/how we can do it.

I'm still using i686 for the daily work and IMO a new CRUX 2.7.2 would be fine.
Same toolchain + udev 182 sounds like a good inflection point that marks the end
of an era, but I don't wanna close the door to future situations related to i686.
ATM around 70% of the systems I'm running are only i686 capable and I think that
there are still many people like me out there.
>
>> Atleast we should ask around on the mailinglist if people are ready and
>> ok with us "dropping" i686 in favor of x86_64.
>
> Sure, such a intrusive change should be announced as soon as possible.

Also we could make an online poll (doodle.com, etc.) and/or we can recover the idea
of IRC meetings.
>
>>> d) Device management
>>>
>>> [...]
>>   
>> [...]
>
> Yeah, sticking with udev 182 for now would be the most conservative
> but good working solution.
> Btw, Debian and Ubuntu are still using udev 175 ;)

Since it is another major controversial issue, I would leave that discussion for
another time and keep udev 182 for now. However, that does not mean that I like the
future plans for udev/systemd.
>>> What do you think?
>>
>> I think it's time for a new release! :)

+1
>>> [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.

Best regards,

-- 
Jose V Beneyto | http://sepen.it.cx/




More information about the crux-devel mailing list