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.
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.
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.
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. Atleast we should ask around on the mailinglist if people are ready and ok with us "dropping" i686 in favor of x86_64.
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?
What do you think?
I think it's time for a new release! :)
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.
-- Fredrik Rinnestam
Hello to developers! I'll talk from a random user perspective here. On Sun, 8 Jul 2012 16:29:40 +0200 Fredrik Rinnestam <fredrik@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
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:
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.
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.
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.
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.
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?
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 ;)
What do you think?
I think it's time for a new release! :)
Indeed :) Thanks for your feedback. Greetings 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.
On Tue, Jul 10, 2012 at 06:57:19PM +0200, Juergen Daubert wrote:
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.
I think we are but maybe my example wasn't clear enough. I just used mesa3d to demonstrate the pain working with "many" repos containing a few ports.
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.
Fair enough :)
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.
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?
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 ;)
rhel is using 147 or something like that :) -- Fredrik Rinnestam
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/
On Wed, Jul 11, 2012 at 05:14:10PM +0200, Jose V Beneyto wrote:
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]
It's simple, if you configure gcc with --enable-multilib you need both versions of glibc, 64- and 32-bit, installed.
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.
That's our layout too, 'normal' stuff goes into /lib resp. /usr/lib and the compatibility libararies into /lib32 and /usr/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?
Sorry, not sure what you mean. If you start using a multilib system you need the one or another library besides the 64- in a 32-bit version too. The ports for the 32-bit versions, e.g. zlib-32 and gtk-32, are both placed into the lib32 or compat32 repository, and not into core-32 and opt-32 if we follow my suggestion.
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?
No, don't mix up different arch versions (i686 and x86_64) and the _additional_ stuff you need for a running multilib system. Keep in mind that the 'normal' not-multilib user will never touch the additional compat repository.
or maybe we can start to merge changes from *-x86_64 repos to new 3.x branches? whats the plan and ideas?
Yep, that's the plan if we switch our official version to x86_64. Everything that's now in the *-86_64 will be merged into our core/opt/xorg repos, the *-x86_64 repos are no longer needed afterwards.
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.
It's not that much if we do it the simple way, as described above.
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.
Well, one idea might be to create and maintain _one_ new overlay repo for the i686 arch for a limited time, let's say 1 year or so. But I'd give that a 'unofficial' status, like x86_64 has currently.
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.
Let's try to clarify the main things within this thread. If we all have a clear picture how everything should go we can do a 'casual' meeting too. best regards Juergen
On 07/08/12 03: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].
a) Switch our main development platform to the x86_64 architecture [2], the first version should be called CRUX 3.0.
I am, unsurprisingly, all for switching to x86_64 as well as multilib. Installing glibc-32 as the only "out of the box" 32-bit package is how the unofficial ISO currently works so that's perfect for me.
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.
Personally I'd prefer to keep the collection separation intact for 32-bit ports, something like 'core-32/opt-32/xorg-32'. With that said I'll go with the majority opinion here, it's just my personal preference. I feel like a single 'lib32' collection could be messy. As an aside I'd suggest a different name than 'lib32' since there's no guarantee that only libs will be installed from it. Perhaps something like 'compat32' or similar?
c) Create a final CRUX 2.7.2 for i686
I have no strong opinion on this but it seems like a nice idea.
d) Device management
Staying with udev 182 seems like the best current option to me. If we cannot separate future versions of udev from systemd then my second preference would be mdev. Regards, Matt
On Wed, Jul 11, 2012 at 08:06:07AM -0500, Matt Housh wrote:
On 07/08/12 03: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].
a) Switch our main development platform to the x86_64 architecture [2], the first version should be called CRUX 3.0.
I am, unsurprisingly, all for switching to x86_64 as well as multilib. Installing glibc-32 as the only "out of the box" 32-bit package is how the unofficial ISO currently works so that's perfect for me.
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.
Personally I'd prefer to keep the collection separation intact for 32-bit ports, something like 'core-32/opt-32/xorg-32'. With that said I'll go with the majority opinion here, it's just my personal preference. I feel like a single 'lib32' collection could be messy.
Why? The reason for the different repos are more a question of access privileges and in case of core what we define as "important, installation required". In fact xorg is something we could easily integrate into opt. The name of a port must be unique over all repos, so actually it dosn't matter in which repo it lives. IMO the main advantage for one 'lib32' or 'compat32' over '{core,opt,xorg}-32' is easy administration and a simpler repo layout.
As an aside I'd suggest a different name than 'lib32' since there's no guarantee that only libs will be installed from it. Perhaps something like 'compat32' or similar?
Yeah, 'compat32' sounds good to me as well.
c) Create a final CRUX 2.7.2 for i686
I have no strong opinion on this but it seems like a nice idea.
Looks like most maintainers are for a final i686 version, without a clear decision either towards a 2.7.2 or to a all-new 2.8.
d) Device management
Staying with udev 182 seems like the best current option to me. If we cannot separate future versions of udev from systemd then my second preference would be mdev.
Nice, everyone has the same opinion here. Let's stick with udev 182 for now. regards Juergen
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.
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
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. 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
On Sat, Jul 14, 2012 at 09:57:14AM +1000, Danny Rawlins wrote:
HI Everyone,
Here is my reply,
thanks for that! [...]
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.
What do you mean with hard? From a technical point of view it's not a big issue to have three repos instead of one, but it's an issue. You have to create the repos, add a user group for each repo, manager user for that group etc. But the main point is a different one: IMO most users will _not_ need the multilib feature, therefore the idea is to keep the impact of it as minimal as possible, or better, to move the stuff that is needed for it mostly out of the way. And in this sense having six repos instead of three is a big issue ;) [...]
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.
Of course, I've nothing against any contributed solutions.
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.
I'm entirely against a solution that splits our efforts. Our little team should work on one and only one CRUX. Greetings Juergen
On Fri, Jul 13, 2012 at 04:46:20PM +0200, Juergen Daubert wrote: [...]
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.
What do you mean with hard? From a technical point of view it's not a big issue to have three repos instead of one, but it's an issue. You have to create the repos, add a user group for each repo, manager user for that group etc. But the main point is a different one: IMO most users will _not_ need the multilib feature, therefore the idea is to keep the impact of it as minimal as possible, or better, to move the stuff that is needed for it mostly out of the way. And in this sense having six repos instead of three is a big issue ;)
s/three/four/
On 14/07/12 00:51, Juergen Daubert wrote:
On Fri, Jul 13, 2012 at 04:46:20PM +0200, Juergen Daubert wrote:
[...]
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. What do you mean with hard? From a technical point of view it's not a big issue to have three repos instead of one, but it's an issue. You have to create the repos, add a user group for each repo, manager user for that group etc. But the main point is a different one: IMO most users will _not_ need the multilib feature, therefore the idea is to keep the impact of it as minimal as possible, or better, to move the stuff that is needed for it mostly out of the way. And in this sense having six repos instead of three is a big issue ;) s/three/four/
_______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
Hard meaning not that difficult, but perhaps it would be simpler to have 1 repo to overlay in prt-get.conf far less effort to include 1 instead of 4.
participants (6)
-
Danny Rawlins -
Fredrik Rinnestam -
Jose V Beneyto -
Juergen Daubert -
Matt Housh -
Mikhail Kolesnik