CRUX for all platforms.
Hi, There! I think it's a bit misleading what the Introduction section of http://crux.nu/ says: Introduction ------------ CRUX is a lightweight, i686-optimized Linux distribution targeted at experienced Linux users. ^^^^^^^^^^^^^^ Can we also at least mention that there are ports of CRUX for PowerPC, OpenBSD and ARM? It's also possible to optimize it for i586 or an Athlon XP or whatever because the CRUX ports system / philosophy is just flexible enough to work on all platforms. I would at least mention CRUX for PowerPC and add a Link to http://cruxppc.sunsite.dk. Can somebody please update the page? Thank you, -- Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
On Tue, May 29, 2007 at 02:26:37PM +0200, Clemens Koller wrote:
Introduction ------------ CRUX is a lightweight, i686-optimized Linux distribution targeted at experienced Linux users. ^^^^^^^^^^^^^^
Can we also at least mention that there are ports of CRUX for PowerPC, OpenBSD and ARM? It's also possible to optimize it for i586 or an Athlon XP or whatever because the CRUX ports system / philosophy is just flexible enough to work on all platforms.
It is implied that a user can optimize / configure the base system to their required specifications. The kicker being that the user is responsible for maintaining the system, not the official crux maintainers, at least if the settings differ significantly from what is provided. The devs are only supposed to produce a base system and the most common software, from where the user continues and expands as needed. A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself. This has the potential to cause unnecessary confusion _IF_ they were displayed more prominently. I would consider this to directly fall into place with the user finding what is needed and without relying on something or someone to hold their hand during the process. [1] http://crux.nu/Main/Links
crux64 aims to be multiarch. http://crux64.die.net.au/ One of the release goals of CRUX64 is multiarch support. Many utilities will need to be patched in order to support this, the multiarch implementation is still under development and it's implementation may change at any time. Here are the git repositories: * pkgutils - git://crux64.die.net.au/pkgutils -- Fredrik Rinnestam
Jesse Kokkarinen ha scritto:
It is implied that a user can optimize / configure the base system to their required specifications. The kicker being that the user is responsible for maintaining the system, not the official crux maintainers, at least if the settings differ significantly from what is provided. The devs are only supposed to produce a base system and the most common software, from where the user continues and expands as needed.
A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself. This has the potential to cause unnecessary confusion _IF_ they were displayed more prominently. I would consider this to directly fall into place with the user finding what is needed and without relying on something or someone to hold their hand during the process.
the _real_ question is: why are these unofficial projects yet? we can join the teams and choose a common way to develop distros' ports, a multiarch port system, and so on... feel free to not agree with it, but: crux users are not only i686... Regards -- bisco at cruxppc dot org CRUX PPC Team! [http://cruxppc.sunsite.dk]
Hi Bisco, On Tue, May 29, 2007 at 15:55:14 +0200, bisco wrote:
A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself. [...]
Jesse Kokkarinen ha scritto: [...] the _real_ question is: why are these unofficial projects yet? Probably because these projects are developed completely independent from the CRUX project. Different people, different release schedules, and in some cases different goals.
What do you think would be the benefits of merging the CRUX PPC projects into the CRUX (crux.nu) project, especially for the CRUX x86 side? I ask this especially since I can't remember seeing patches/generic fixes from the PPC developers sent to crux-devel. Also, would you be willing to give up the non-platform dependent differences you made to CRUX PPC (like the different version scheme etc.), or would you want to keep that independence?
we can join the teams and choose a common way to develop distros' ports, a multiarch port system, and so on... We've been there a couple of times before, yet so far there's no model for this multiarch port system which was generally accepted, and it may be hard to find it, considering that the different flavours of CRUX have slightly different goals.
One of the things I'd like to stress here is that previously, the main problem was communication. If you want to be considered as future team members, you'll somehow need to get into a position to make the crux x86 devs want to work together with you, and trust you. That won't happen overnight, and not as long as you think (and publically express) the problems are just with "the others". Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Tue, May 29, 2007 at 03:55:14PM +0200, bisco wrote:
the _real_ question is: why are these unofficial projects yet?
we can join the teams and choose a common way to develop distros' ports, a multiarch port system, and so on...
feel free to not agree with it, but:
crux users are not only i686...
Hi, I believe the main reasons for officially support only the i686 version are both historical and practical. CRUX was born as distribution targeting the Intel platform, and we've not been able so far to cope with the changes needed to make the system a bit more friendly towards other architectures. AFAIR we discussed the issue more than once in the past, it's only we haven't come up with a well defined path towards integration / cooperation, also because we focused on the 2.3 release. In this page - http://crux.nu/Main/DevVision - we planned to work on a multi-arch solution post-2.3, so the right time seems now ;-) Regards, Simone -- Simone Rota Bergamo, Italy - http://www.varlock.com
Hello, Johannes! Johannes Winkelmann schrieb:
On Tue, May 29, 2007 at 15:55:14 +0200, bisco wrote:
Jesse Kokkarinen ha scritto: [...]
A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself.
*smile* Can somebody please explain what the "responsibility of crux" is? I got the impression that it's the user's responsibility only, to get things right. ;-)
[...]
the _real_ question is: why are these unofficial projects yet?
Probably because these projects are developed completely independent from the CRUX project.
Yes. I am wondering about that. I just see no good reason to develop them independently. From my embedded ppc system's point of view it look pretty obvious: Most of the core ports are 100% identical on ix86 and ppc. Only a few ports are obviously platform dependent: binutils, glibc, gcc, (libstc++-compat if necessary). Some ports need minor compatibility patches or an additional ./configure parameter which are already in my ports repository: coreutils, unzip. fdisk/lilo/grub gets replaced by mac-fdisk/yaboot/ofboot So, I would estimate a maximum of 5% of the ports differ from my platform to the ix86 CRUX-2.3. The differences are really trivial, once you've them in. I see no point why we shouldn't share the other 95% of port maintenance. Well, I just override the official ports with mine.
What do you think would be the benefits of merging the CRUX PPC projects into the CRUX (crux.nu) project
I don't think it's necessary to merge both projects. I just want that they point/link together.
, especially for the CRUX x86 side?
Because then you don't talk x86 only anymore.
I ask this especially since I can't remember seeing patches/generic fixes from the PPC developers sent to crux-devel.
Thats simply because there are hardly patches necessary. unzip needs a make linux_noasm to avoid x86 instructions. coreutils needs a patch for uname to get the non x86 platform names right. Well, that's it. The other patches I pushed recently came from my ppc system but they are valid for all platforms (when we move on to gcc-4.2.0).
One of the things I'd like to stress here is that previously, the main problem was communication. If you want to be considered as future team members, you'll somehow need to get into a position to make the crux x86 devs want to work together with you, and trust you. That won't happen overnight, and not as long as you think (and publically express) the problems are just with "the others".
My primary intention of this thread was to have a link right in the "Introduction" at crux.nu at least to the PPC site, to give the puplic an idea, that CRUX is something more than i686-optimized. (I know the Link section...) CRUX is IMHO very attractive for the embedded market, because it's very slim and easily customizable. Over here, it's PowerPC, but it doesn't really matter a lot, what CPU it is, as long as it's CRUX! 8-) Regards, -- Clemens Koller __________________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com
Johannes Winkelmann ha scritto:
Hi Bisco,
On Tue, May 29, 2007 at 15:55:14 +0200, bisco wrote:
A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself. [...]
Jesse Kokkarinen ha scritto: [...] the _real_ question is: why are these unofficial projects yet? Probably because these projects are developed completely independent from the CRUX project. Different people, different release schedules, and in some cases different goals.
if you remember, we tried some times to talk about merging these projects. We had no results because no one wanted to change its own position. So, other teams developed indipendently, but this is the wrong way, imho.
What do you think would be the benefits of merging the CRUX PPC projects into the CRUX (crux.nu) project, especially for the CRUX x86 side? I ask this especially since I can't remember seeing patches/generic fixes from the PPC developers sent to crux-devel.
I think merging related projects to the main one can give more interest into the distro. Most of the popular distros have official porting projects: why CRUX cannot have them?
Also, would you be willing to give up the non-platform dependent differences you made to CRUX PPC (like the different version scheme etc.), or would you want to keep that independence?
The initial idea was to give the same packages' release (when possible) than the x86 one. Then, due to our (both x86 and ppc) hard positions, we've decide to take our choices indipendently. But we still wish and support a common development for Crux for every architecture!
we can join the teams and choose a common way to develop distros' ports, a multiarch port system, and so on... We've been there a couple of times before, yet so far there's no model for this multiarch port system which was generally accepted, and it may be hard to find it, considering that the different flavours of CRUX have slightly different goals.
If my memories aren't wrong, the problem was because the proposed solutions haven't a KISS style.
One of the things I'd like to stress here is that previously, the main problem was communication. If you want to be considered as future team members, you'll somehow need to get into a position to make the crux x86 devs want to work together with you, and trust you. That won't happen overnight, and not as long as you think (and publically express) the problems are just with "the others".
Yes, the problem was communication, but I think that it's interest of both on having a unified (or, if you think it's better, synchronized) team. But as far as I know, the same problem was shared with other teams working with other architecture than x86.
Regards, Johannes
Best Regards, Alfredo -- bisco at cruxppc dot org CRUX PPC Team! [http://cruxppc.sunsite.dk]
Hi Bisco, On Tue, May 29, 2007 at 22:52:38 +0200, bisco wrote:
Johannes Winkelmann ha scritto: [...]
What do you think would be the benefits of merging the CRUX PPC projects into the CRUX (crux.nu) project, especially for the CRUX x86 side? I ask this especially since I can't remember seeing patches/generic fixes from the PPC developers sent to crux-devel.
I think merging related projects to the main one can give more interest into the distro. Well, popularity never really was a goal of the CRUX project, rather a side effect.
Most of the popular distros have official porting projects: why CRUX cannot have them? Most of the popular distros have GUI installers too...
[...] I think that it's interest of both on having a unified (or, if you think it's better, synchronized) team. I agree, there's certainly an interest, but the interest has been there for the past four years. However, as Simone pointed out the topic is on the todo list, so let's see what the future brings.
Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Tue, 29 May 2007 15:33:59 +0200 Fredrik Rinnestam <fredrik@obra.se> wrote:
crux64 aims to be multiarch. http://crux64.die.net.au/
One of the release goals of CRUX64 is multiarch support. Many utilities will need to be patched in order to support this, the multiarch implementation is still under development and it's implementation may change at any time. Here are the git repositories:
* pkgutils - git://crux64.die.net.au/pkgutils
If you want an example of the port structure, git://crux64.die.net.au/core and look at glibc -- Lucas Hazel <lucas@die.net.au> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." =================================================
bisco wrote:
Johannes Winkelmann ha scritto:
Hi Bisco,
On Tue, May 29, 2007 at 15:55:14 +0200, bisco wrote:
Jesse Kokkarinen ha scritto:
[...]
A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself.
[...]
the _real_ question is: why are these unofficial projects yet?
Probably because these projects are developed completely independent from the CRUX project. Different people, different release schedules, and in some cases different goals.
if you remember, we tried some times to talk about merging these projects. We had no results because no one wanted to change its own position. So, other teams developed indipendently, but this is the wrong way, imho.
What do you think would be the benefits of merging the CRUX PPC projects into the CRUX (crux.nu) project, especially for the CRUX x86 side? I ask this especially since I can't remember seeing patches/generic fixes from the PPC developers sent to crux-devel.
I think merging related projects to the main one can give more interest into the distro. Most of the popular distros have official porting projects: why CRUX cannot have them?
Also, would you be willing to give up the non-platform dependent differences you made to CRUX PPC (like the different version scheme etc.), or would you want to keep that independence?
The initial idea was to give the same packages' release (when possible) than the x86 one. Then, due to our (both x86 and ppc) hard positions, we've decide to take our choices indipendently. But we still wish and support a common development for Crux for every architecture!
we can join the teams and choose a common way to develop distros' ports, a multiarch port system, and so on...
We've been there a couple of times before, yet so far there's no model for this multiarch port system which was generally accepted, and it may be hard to find it, considering that the different flavours of CRUX have slightly different goals.
If my memories aren't wrong, the problem was because the proposed solutions haven't a KISS style.
One of the things I'd like to stress here is that previously, the main problem was communication. If you want to be considered as future team members, you'll somehow need to get into a position to make the crux x86 devs want to work together with you, and trust you. That won't happen overnight, and not as long as you think (and publically express) the problems are just with "the others".
Yes, the problem was communication, but I think that it's interest of both on having a unified (or, if you think it's better, synchronized) team. But as far as I know, the same problem was shared with other teams working with other architecture than x86.
Case in point: Crux64 aims at multiarch/multilib. I, however prefer a "Crux-pure64" version, and have been using such for about a year. For me it is much simpler (KISS) and the majority of x86 ports work "as-is". And the rest only need minor patching, (the worst exceptions being the mozilla plug-ins). I had kept quiet mainly to avoid such discussions, as they seem somewhat counter-productive. By having a "unified (x86) team", the system can grow and be maintained more consistently, while leaving open the ease of customizations. I guess my point is that the beauty of crux is its simplicity and flexibility, while facilitating the individuality of users within the community.
On Wed, 2007-05-30 at 17:27 -0400, Mike VanRoy wrote:
bisco wrote:
Johannes Winkelmann ha scritto:
Hi Bisco,
On Tue, May 29, 2007 at 15:55:14 +0200, bisco wrote:
Jesse Kokkarinen ha scritto:
[...]
A few of the crux "ports" you refer to are already linked [1]. They are unofficial and do not fall under the responsibility of crux itself.
[...]
the _real_ question is: why are these unofficial projects yet?
Probably because these projects are developed completely independent from the CRUX project. Different people, different release schedules, and in some cases different goals.
if you remember, we tried some times to talk about merging these projects. We had no results because no one wanted to change its own position. So, other teams developed indipendently, but this is the wrong way, imho.
What do you think would be the benefits of merging the CRUX PPC projects into the CRUX (crux.nu) project, especially for the CRUX x86 side? I ask this especially since I can't remember seeing patches/generic fixes from the PPC developers sent to crux-devel.
I think merging related projects to the main one can give more interest into the distro. Most of the popular distros have official porting projects: why CRUX cannot have them?
Also, would you be willing to give up the non-platform dependent differences you made to CRUX PPC (like the different version scheme etc.), or would you want to keep that independence?
The initial idea was to give the same packages' release (when possible) than the x86 one. Then, due to our (both x86 and ppc) hard positions, we've decide to take our choices indipendently. But we still wish and support a common development for Crux for every architecture!
we can join the teams and choose a common way to develop distros' ports, a multiarch port system, and so on...
We've been there a couple of times before, yet so far there's no model for this multiarch port system which was generally accepted, and it may be hard to find it, considering that the different flavours of CRUX have slightly different goals.
If my memories aren't wrong, the problem was because the proposed solutions haven't a KISS style.
One of the things I'd like to stress here is that previously, the main problem was communication. If you want to be considered as future team members, you'll somehow need to get into a position to make the crux x86 devs want to work together with you, and trust you. That won't happen overnight, and not as long as you think (and publically express) the problems are just with "the others".
Yes, the problem was communication, but I think that it's interest of both on having a unified (or, if you think it's better, synchronized) team. But as far as I know, the same problem was shared with other teams working with other architecture than x86.
Case in point: Crux64 aims at multiarch/multilib. I, however prefer a "Crux-pure64" version, and have been using such for about a year. For me it is much simpler (KISS) and the majority of x86 ports work "as-is". And the rest only need minor patching, (the worst exceptions being the mozilla plug-ins). I had kept quiet mainly to avoid such discussions, as they seem somewhat counter-productive.
By having a "unified (x86) team", the system can grow and be maintained more consistently, while leaving open the ease of customizations. I guess my point is that the beauty of crux is its simplicity and flexibility, while facilitating the individuality of users within the community.
It's not a matter of aiming for multiarch/multilib, more about providing it. I've found many useful features of the multiarch implementation I am playing with. For example, I wanted to add mysql support to lighttpd. To do this I added a mysql directory in the lighttpd port, Copied the build function from the official port to the mysql directory added mysql functionality and rebuilt it with 'pkgmk -a mysql'. This same method could be used to modify existing ports for a pure64 environment. It's at about this time I can hear people howling USE USE USE. But for me it just makes sense to keep all your ports together, and it makes maintaining compat32 ports a hell of a lot easier. A bit of history on the multiarch system. Originally I was just editing the original Pkgfiles but it made merging with git a complete nightmare. So I put arch specific files in their own directory and then it didn't really make sense to keep a complete port for the multiarch port so I decided to just include the information that differs from the original. Some are simply a matter of adding 'export CFLAGS="$CFLAGS -fPIC"' to the x86_64/Pkgfile. Now I'm not saying the way is The Best Way (TM), but it works for me...well mostly, there are some compatability issues with prt-get. But IMHO unifying the efforts of the i686 and other projects is not necessarily a bad thing. If anyone is interested in working on a miltiarch repository please contact me and we can experiment some more. -- Lucas Hazel
participants (8)
-
bisco
-
Clemens Koller
-
Fredrik Rinnestam
-
Jesse Kokkarinen
-
Johannes Winkelmann
-
Lucas Hazel
-
Mike VanRoy
-
Simone Rota