Hi, I started using CRUX GNU/Linux in October 2006. I was fascinated by its simplicity and decided to continue using it. I especially liked pkgutils and the ports system. I am exacting regarding package management, because I think it is the main aspect that makes a distribution unique (all distribution provide roughly the same software, but have a different package manager and design philosophy). My first contribution to CRUX was the libarchive support for pkgutils (FS#121). I took a month to get this feature into the git repository. There were some trivial problems with libarchive, but it became apparent to me that CRUX had maintenance problems. I was not really happy about this fact, but I pretended myself that this was not a real problem. At the same time I started maintaining my own ports collection which consists (after a cleanup) over 30 ports. I tried to merge some patches for ports in the opt repository and sent them to the port maintainers, but I never got a reply. Therefore I maintain them now in my own repository. But all these incidents never discouraged me from using and liking CRUX. I was not happy about the situation, but I neither wanted to fork yet another distribution nor I wanted to switch to another. In May 2007 tried to integrate libtre in pkgutils without any success. This was not a matter of great importance to me, but I had real doubts about the organisation of CRUX from that on. I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore. That was all in the past. Today I think CRUX has reached its zenith. It will die a slow and silent death. Perhaps this will take months or years; it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing. When I recognised that the C++ version of pkgutils was going to be replaced by a C version, I knew that this would have far reaching consequences for the design and philosophy of CRUX. I think it is not longer the great design philosophy of Per Lidén; it is not longer the thing I liked about CRUX. But generally speaking we (the community) bear the guilt for its death. We did not stop the death, we agreed with the decisions and decided to support this development. Nevertheless it is not to late to stop this process and revitalise CRUX. Everything depends on us! I thought about the future of CRUX and conceived some ideas and demands: * restructuring of the development process (patch queues, better issue tracker, more transparent development and release process, public discussions, development teams, ...) * open ports system (easier updating, submission and maintenance, open to anyone) * entirely public wiki * (perhaps) merge with CRUX-PPC * automatic version, standards and integration tests for Pkgfiles * more precise and stricter packaging standards * no more footprint mismatches (isolated builds, USE flags like system) * complete localisation (no --disable-nls, ...) * (simple) Pkgfile standard library (common mirrors, functions) * multiple architectures * improvement of pkgutils (attribute, hooks/events, pkgutils library) * redesign of prt-get * git repository cleanups * ... Let us (the community) take over the development of CRUX! We are the people, we can change our distribution! The future of CRUX is up to you! You can decide on your own! -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-05 17:51]: Hi,
My first contribution to CRUX was the libarchive support for pkgutils (FS#121). I took a month to get this feature into the git repository. There were some trivial problems with libarchive, but it became apparent to me that CRUX had maintenance problems. I was not really happy about this fact, but I pretended myself that this was not a real problem.
I don't really see the issue with a non-critical patch taking a month to get merged.
At the same time I started maintaining my own ports collection which consists (after a cleanup) over 30 ports. I tried to merge some patches for ports in the opt repository and sent them to the port maintainers, but I never got a reply. Therefore I maintain them now in my own repository.
Can't comment much here; ignoring patches sucks :/
But all these incidents never discouraged me from using and liking CRUX. I was not happy about the situation, but I neither wanted to fork yet another distribution nor I wanted to switch to another.
In May 2007 tried to integrate libtre in pkgutils without any success. This was not a matter of great importance to me, but I had real doubts about the organisation of CRUX from that on.
Did you see my comment on the bug tracker? I don't see the regex handling as performance critical, that's why I didn't apply your patch back then. Why didn't you provide profiles to convince me how much faster pkgutils/prt-get can go in typical use cases with libtre?
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Right. Who did you write to? I've never heard about those mails. The next logical step would have been to write to the crux-devel mailing list, btw.
it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing.
It always was, I don't see the regression here. In fact it's much easier to contribute these days than it was "back then".
When I recognised that the C++ version of pkgutils was going to be replaced by a C version, I knew that this would have far reaching consequences for the design and philosophy of CRUX. I think it is not longer the great design philosophy of Per Lidén; it is not longer the thing I liked about CRUX.
Huh? Sorry, I don't understand why the pkgutils move is such a big deal for you. IMO it doesn't affect the philosophy of CRUX at all.
I thought about the future of CRUX and conceived some ideas and demands:
discussions, development teams, ...) * open ports system (easier updating, submission and maintenance, open to anyone) * entirely public wiki * (perhaps) merge with CRUX-PPC
* automatic version, standards and integration tests for Pkgfiles * more precise and stricter packaging standards * no more footprint mismatches (isolated builds, USE flags like system) * complete localisation (no --disable-nls, ...) * (simple) Pkgfile standard library (common mirrors, functions) * multiple architectures
* improvement of pkgutils (attribute, hooks/events, pkgutils library)
I thought you hated the pkgutils work I'm doing?
* redesign of prt-get
You'd have to talk to Johannes to do that, but I guess he's open to suggestions (I believe he's only fixing evil bugs in prt-get these days). Some points on your list are totally NOT compatible with Per's idea of CRUX, I think (like NLS, USE flags, ...). And I'm sure there's lots of users who _like_ not having NLS and no USE flags. Really :) Seems you want Gentoo with ports/pkgutils :)
Let us (the community) take over the development of CRUX! We are the people, we can change our distribution! The future of CRUX is up to you! You can decide on your own!
That's kind of rude considering we're still active. Feel free to fork if you hate CRUX though. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
Hi,
My first contribution to CRUX was the libarchive support for pkgutils (FS#121). I took a month to get this feature into the git repository. There were some trivial problems with libarchive, but it became apparent to me that CRUX had maintenance problems. I was not really happy about this fact, but I pretended myself that this was not a real problem.
I don't really see the issue with a non-critical patch taking a month to get merged.
I think patches should be merged as soon as possible.
But all these incidents never discouraged me from using and liking CRUX. I was not happy about the situation, but I neither wanted to fork yet another distribution nor I wanted to switch to another.
In May 2007 tried to integrate libtre in pkgutils without any success. This was not a matter of great importance to me, but I had real doubts about the organisation of CRUX from that on.
Did you see my comment on the bug tracker? I don't see the regex handling as performance critical, that's why I didn't apply your patch back then. Why didn't you provide profiles to convince me how much faster pkgutils/prt-get can go in typical use cases with libtre?
I did not provide any profiles, because I did not have any.
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Right. Who did you write to? I've never heard about those mails.
I wrote to crux@ and crux-devel@.
The next logical step would have been to write to the crux-devel mailing list, btw.
I did so, but both messages were bounced, because I was not subscribed to the list. The e-mail to crux@ was reject by the administrator.
it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing.
It always was, I don't see the regression here. In fact it's much easier to contribute these days than it was "back then".
But this does not justify it. Just because it was worse in past it is not a good thing nowadays.
When I recognised that the C++ version of pkgutils was going to be replaced by a C version, I knew that this would have far reaching consequences for the design and philosophy of CRUX. I think it is not longer the great design philosophy of Per Lidén; it is not longer the thing I liked about CRUX.
Huh? Sorry, I don't understand why the pkgutils move is such a big deal for you. IMO it doesn't affect the philosophy of CRUX at all.
Yes, but it affects the way the philosophy is implemented and expressed.
I thought about the future of CRUX and conceived some ideas and demands:
discussions, development teams, ...) * open ports system (easier updating, submission and maintenance, open to anyone) * entirely public wiki * (perhaps) merge with CRUX-PPC
* automatic version, standards and integration tests for Pkgfiles * more precise and stricter packaging standards * no more footprint mismatches (isolated builds, USE flags like system) * complete localisation (no --disable-nls, ...) * (simple) Pkgfile standard library (common mirrors, functions) * multiple architectures
* improvement of pkgutils (attribute, hooks/events, pkgutils library)
I thought you hated the pkgutils work I'm doing?
"Hate" is something different, but I did not like it very much. You changed something that was already good in favour of something that is not better.
Some points on your list are totally NOT compatible with Per's idea of CRUX, I think (like NLS, USE flags, ...).
Localisation is compatible if it is optional or removable via hooks/events. USE flags (better: feature flags) are a consequence of the software that already violates the philosophy of CRUX and UNIX. CRUX has to find a way of dealing with them and feature flags are a quite simple way if they are not abused.
And I'm sure there's lots of users who _like_ not having NLS and no USE flags. Really :)
If it is optional, they will be fine with this.
Seems you want Gentoo with ports/pkgutils :)
No, Gentoo is bloated. It has several design mistakes.
Let us (the community) take over the development of CRUX! We are the people, we can change our distribution! The future of CRUX is up to you! You can decide on your own!
That's kind of rude considering we're still active. Feel free to fork if you hate CRUX though.
I prefer co-operation to competition. But there is no alternative, I will perhaps fork. -- Matthias-Christian Ott
(I've been away from this list for years, but i'll write my few thoughts about this... hope to start writing here frequently again :)) Tilman Sauerbeck wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
[...] * automatic version, standards and integration tests for Pkgfiles * more precise and stricter packaging standards * no more footprint mismatches (isolated builds, USE flags like system) * complete localisation (no --disable-nls, ...) * (simple) Pkgfile standard library (common mirrors, functions) * multiple architectures * improvement of pkgutils (attribute, hooks/events, pkgutils library) * redesign of prt-get
You'd have to talk to Johannes to do that, but I guess he's open to suggestions (I believe he's only fixing evil bugs in prt-get these days).
yes, and i'd add that there is ilenia too if you don't like prt-get... ;) it's maintained more than evere and was completely redesigned from 2.x to 3.x.
Some points on your list are totally NOT compatible with Per's idea of CRUX, I think (like NLS, USE flags, ...). And I'm sure there's lots of users who _like_ not having NLS and no USE flags. Really :) Seems you want Gentoo with ports/pkgutils :)
I am among those users... the great thing about the crux ports system is that writing ports is really easy and straight forward... the user can easily modify ports to best suit its need, and so s/he has full control over the system. Examining or ignoring some footprint mismatches doesn't seem such a big problem... it's a deal instead in change of full control over the system. An use flags or feature flags system, extended use of variables in ports, complex footprints and so on would make ports unreadable, hard to create/customize/maintain and will make of pkgutils what now is emerge or pacman. We already have a crux-inspired distribution that has some of those "issues" solved... it's called ArchLinux, is complete, stable, fast (but not as fast as crux) and is a good way between crux, gentoo (and debian). I personally don't like the solutions or maybe those "issues" are not real problems to me so i stick with crux; I happily use it on either ppc (no crux-ppc is not dead... ;)), x86 and sparc. my 2 cents, bye giorgio -- NullPointer || GnuPG/PGP Key-Id: 0x343B22E6
Giorgio Agrelli <giorgio_a@libero.it> wrote:
(I've been away from this list for years, but i'll write my few thoughts about this... hope to start writing here frequently again :))
Tilman Sauerbeck wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
[...] * automatic version, standards and integration tests for Pkgfiles * more precise and stricter packaging standards * no more footprint mismatches (isolated builds, USE flags like system) * complete localisation (no --disable-nls, ...) * (simple) Pkgfile standard library (common mirrors, functions) * multiple architectures * improvement of pkgutils (attribute, hooks/events, pkgutils library) * redesign of prt-get
You'd have to talk to Johannes to do that, but I guess he's open to suggestions (I believe he's only fixing evil bugs in prt-get these days).
yes, and i'd add that there is ilenia too if you don't like prt-get... ;) it's maintained more than evere and was completely redesigned from 2.x to 3.x.
I had a look at it several months ago. I liked it more than prt-get.
Some points on your list are totally NOT compatible with Per's idea of CRUX, I think (like NLS, USE flags, ...). And I'm sure there's lots of users who _like_ not having NLS and no USE flags. Really :) Seems you want Gentoo with ports/pkgutils :)
I am among those users... the great thing about the crux ports system is that writing ports is really easy and straight forward... the user can easily modify ports to best suit its need, and so s/he has full control over the system. Examining or ignoring some footprint mismatches doesn't seem such a big problem... it's a deal instead in change of full control over the system.
An use flags or feature flags system, extended use of variables in ports, complex footprints and so on would make ports unreadable, hard to create/customize/maintain and will make of pkgutils what now is emerge or pacman. We already have a crux-inspired distribution that has some of those "issues" solved... it's called ArchLinux, is complete, stable, fast (but not as fast as crux) and is a good way between crux, gentoo (and debian).
I used Arch Linux for several years. They have the same problems. Arch Linux has no advantages over CRUX. No feature flags are a necessary consequence of autoconf and the design of some applications. There are applications which have GNOME and KDE support for example. These applications need feature flags, because the user neither wants to install both Desktop environments just run a single application nor to use a KDE application on GNOME if it is available for GNOME. This is just one example. There are dozens of applications with features that depend on the installed software. Footprint mismatches exists, because the build process was not isolated (chroot, container, ...). Last year I tried to write a programme that does that task via ptrace. There are three solutions for tracing system calls (open, read, write, ...) and restricting them: 1. LD_PRELOAD (emerge) The standard glibc functions get replaced by wrapper functions which filter the paths. 2. ptrace(2) (strace, ...) See http://www.linuxjournal.com/article/6100. This solution is architecture-specific (see strace source code). 3. Linux Security Module (AppArmor, ...) Also the chroot(2) and RBAC features of grsecurity may be worth a try. -- Matthias-Christian Ott
Hi Matthias, On Fri, Oct 05, 2007 at 17:51:22 +0200, Matthias-Christian Ott wrote:
Hi, [...] That was all in the past. Today I think CRUX has reached its zenith. It will die a slow and silent death. Perhaps this will take months or years; it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing. I don't share this sentiment. I've been running 2.3 on a couple machines happily without any major problems. The pace of development may be lower than when you started, but comparing it with the last couple of years it seems to be fairly stable.
Maybe some of the IRC regulars can comment on that, but from the logs I'd say the fans are still there, and new users are joining #crux as frequently as ever. [...]
I thought about the future of CRUX and conceived some ideas and demands: [...]
I believe some points on you mention are interesting and worth discussing, but I don't think it's worth to do so here in the context of your mail, for two reasons: first, your goals seems incompatible with the ones from the CRUX devs and at least one if its users (yeah, that would be me); and second, your goals seems to take over the project as opposed to help the current devs improve the project. With all due respect, but while I'm sure you're a talented guy, so far you've done very little to convince me that you're capable to run such a project and do "better".
Let us (the community) take over the development of CRUX! We are the people, we can change our distribution! The future of CRUX is up to you! You can decide on your own! That's a bold statement to make in your very first mail to any of the CRUX mailing lists... as for the decision, if it's between your agenda and letting CRUX die, I'd vote for the later.
While I wish you all the best for your future plans, I think both you and me will be happier if you fork: you because you can decide freely on the features of your distro, and me since I can keep using CRUX. Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann <jw@smts.ch> wrote:
Hi Matthias,
On Fri, Oct 05, 2007 at 17:51:22 +0200, Matthias-Christian Ott wrote:
Hi, [...] That was all in the past. Today I think CRUX has reached its zenith. It will die a slow and silent death. Perhaps this will take months or years; it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing. I don't share this sentiment. I've been running 2.3 on a couple machines happily without any major problems. The pace of development may be lower than when you started, but comparing it with the last couple of years it seems to be fairly stable.
Maybe some of the IRC regulars can comment on that, but from the logs I'd say the fans are still there, and new users are joining #crux as frequently as ever.
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
[...]
I thought about the future of CRUX and conceived some ideas and demands: [...]
I believe some points on you mention are interesting and worth discussing, but I don't think it's worth to do so here in the context of your mail, for two reasons: first, your goals seems incompatible with the ones from the CRUX devs and at least one if its users (yeah, that would be me); and second, your goals seems to take over the project as opposed to help the current devs improve the project. With all due respect, but while I'm sure you're a talented guy, so far you've done very little to convince me that you're capable to run such a project and do "better".
I do not know whether I would be more successful than you. But my goal is not to take over the control over the project. The community will control the project.
Let us (the community) take over the development of CRUX! We are the people, we can change our distribution! The future of CRUX is up to you! You can decide on your own! That's a bold statement to make in your very first mail to any of the CRUX mailing lists... as for the decision, if it's between your agenda and letting CRUX die, I'd vote for the later.
While I wish you all the best for your future plans, I think both you and me will be happier if you fork: you because you can decide freely on the features of your distro, and me since I can keep using CRUX.
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans. -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-06 11:48]:
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans.
We don't reject *all* discussion, we just reject ideas that we think don't fit with CRUX! And IMO most of your critique falls into that category. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 11:48]:
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans.
We don't reject *all* discussion, we just reject ideas that we think don't fit with CRUX! And IMO most of your critique falls into that category.
Well, if you define your goals, requirements and conditions (which are subjective), you can find a quite objective solution by discussing it. I think we encounter with our definitions. -- Matthias-Christian Ott
On Sat, Oct 06, 2007 at 11:48:38 +0200, Matthias-Christian Ott wrote:
Johannes Winkelmann <jw@smts.ch> wrote:
Hi Matthias,
On Fri, Oct 05, 2007 at 17:51:22 +0200, Matthias-Christian Ott wrote:
Hi, [...] That was all in the past. Today I think CRUX has reached its zenith. It will die a slow and silent death. Perhaps this will take months or years; it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing. [...] Maybe some of the IRC regulars can comment on that, but from the logs I'd say the fans are still there, and new users are joining #crux as frequently as ever.
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
That was exactly my point. You claimed that CRUX lost its fans and community, yet there's no argument to back it up. My claim is that it's clear from the IRC logs that there's no major change in user base.
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans. I think one of the beautiful things about Free Software is that you can reuse existing code (and hopefully even contribute back) if your goals are far away from those of the original project, which is the case here.
Asking everyone to work together and make compromises is like asking all car companies to join and build just a single model: the resulting compromise won't fit anyone. That's why there are different car models. And that's also why we have different distributions, mail clients etc. Finally, had you written a friendly, reasonable mail, I'm sure that a discussion would not have been rejected. The generalization in your statement makes me think that this is not the first time this happened to you, so I'd suggest to work on these skills, since in general the motivation to work with rude people is very low, even if they make valid points. HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann <jw@smts.ch> wrote:
On Sat, Oct 06, 2007 at 11:48:38 +0200, Matthias-Christian Ott wrote:
Johannes Winkelmann <jw@smts.ch> wrote:
Hi Matthias,
On Fri, Oct 05, 2007 at 17:51:22 +0200, Matthias-Christian Ott wrote:
Hi, [...] That was all in the past. Today I think CRUX has reached its zenith. It will die a slow and silent death. Perhaps this will take months or years; it is just a matter of time. CRUX lost its importance, its fans and community. It is hierarchically structured and slowly developing. [...] Maybe some of the IRC regulars can comment on that, but from the logs I'd say the fans are still there, and new users are joining #crux as frequently as ever.
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
That was exactly my point. You claimed that CRUX lost its fans and community, yet there's no argument to back it up. My claim is that it's clear from the IRC logs that there's no major change in user base.
I just had a look at the mailing list and the content of the e-mails of the last months.
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans. I think one of the beautiful things about Free Software is that you can reuse existing code (and hopefully even contribute back) if your goals are far away from those of the original project, which is the case here.
You can avoid this merging efforts by co-operating.
Asking everyone to work together and make compromises is like asking all car companies to join and build just a single model: the resulting compromise won't fit anyone. That's why there are different car models. And that's also why we have different distributions, mail clients etc.
We could have an universal distribution that is modular and flexible and thus fits for everyone. Additionally cars are not software (as Richard Stallman states) and assembling a car from modules manually is not comparable to installing a modular operating system. -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-06 14:19]:
Asking everyone to work together and make compromises is like asking all car companies to join and build just a single model: the resulting compromise won't fit anyone. That's why there are different car models. And that's also why we have different distributions, mail clients etc.
We could have an universal distribution that is modular and flexible and thus fits for everyone.
There's no chance in hell that this plan is going to work out :o Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On 11:48 Sat 06 Oct?, Matthias-Christian Ott wrote:
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
I think you've got this a bit backwards. In general it seems to be the IRC channel that has consequences for the community, such as it is, rather than the other way around.
I do not know whether I would be more successful than you. But my goal is not to take over the control over the project. The community will control the project.
You speak repeatedly of this "community" that supposedly stands ready to take over development. What community would that be? In what way is it possible to run the development by the "community" to a higher degree than it's currently done? By giving anyone who fires off an email "developer" status? You complain a lot about how hard it is to participate; have you ever had a look at the procedures for becoming a debian/fedora dev?
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans.
Yeah, and in closed software "management" doesn't listen and rejects all discussion. Your point is what, exactly? //treach -- Don't take life too seriously; you'll never get out of it alive. - Elbert Hubbard
treach <treachster@gmail.com> wrote:
On 11:48 Sat 06 Oct?, Matthias-Christian Ott wrote:
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
I think you've got this a bit backwards. In general it seems to be the IRC channel that has consequences for the community, such as it is, rather than the other way around.
I do not know whether I would be more successful than you. But my goal is not to take over the control over the project. The community will control the project.
You speak repeatedly of this "community" that supposedly stands ready to take over development. What community would that be? In what way is it possible to run the development by the "community" to a higher degree than it's currently done? By giving anyone who fires off an email "developer" status? You complain a lot about how hard it is to participate; have you ever had a look at the procedures for becoming a debian/fedora dev?
Currently I do not know who will be part of the community, but I thought that there will be some people. I wrote about this concept of the patch queue which makes developer accounts unnecessary and enables the community to vote for or against patches. So no procedures are required, everything happens transparently in the public.
This is what I do not like about Free Software. If the developers opinions interfere, the project is forked. They do not work together and evaluate possible solutions. They reject all discussion and stick to their plans.
Yeah, and in closed software "management" doesn't listen and rejects all discussion. Your point is what, exactly?
Forking is great opportunity to have, but you should avoid it wherever it is possible. You should only use it like as a "rescue plan" and consider it as the last chance. -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-06 13:27]:
treach <treachster@gmail.com> wrote:
On 11:48 Sat 06 Oct?, Matthias-Christian Ott wrote:
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
I think you've got this a bit backwards. In general it seems to be the IRC channel that has consequences for the community, such as it is, rather than the other way around.
I do not know whether I would be more successful than you. But my goal is not to take over the control over the project. The community will control the project.
You speak repeatedly of this "community" that supposedly stands ready to take over development. What community would that be? In what way is it possible to run the development by the "community" to a higher degree than it's currently done? By giving anyone who fires off an email "developer" status? You complain a lot about how hard it is to participate; have you ever had a look at the procedures for becoming a debian/fedora dev?
Currently I do not know who will be part of the community, but I thought that there will be some people. I wrote about this concept of the patch queue which makes developer accounts unnecessary and enables the community to vote for or against patches. So no procedures are required, everything happens transparently in the public.
How exactly would the community vote on your libtre patch, eg? Most of them probably don't know C or what that patch really meant so giving them the right to decide on its fate seems stupido. Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 13:27]:
treach <treachster@gmail.com> wrote:
On 11:48 Sat 06 Oct?, Matthias-Christian Ott wrote:
Sorry, I was never present in the IRC channel and therefore all my statements were not intended to describe the situation of #crux. But usually the situation of the community has also consequences for the IRC channel.
I think you've got this a bit backwards. In general it seems to be the IRC channel that has consequences for the community, such as it is, rather than the other way around.
I do not know whether I would be more successful than you. But my goal is not to take over the control over the project. The community will control the project.
You speak repeatedly of this "community" that supposedly stands ready to take over development. What community would that be? In what way is it possible to run the development by the "community" to a higher degree than it's currently done? By giving anyone who fires off an email "developer" status? You complain a lot about how hard it is to participate; have you ever had a look at the procedures for becoming a debian/fedora dev?
Currently I do not know who will be part of the community, but I thought that there will be some people. I wrote about this concept of the patch queue which makes developer accounts unnecessary and enables the community to vote for or against patches. So no procedures are required, everything happens transparently in the public.
How exactly would the community vote on your libtre patch, eg? Most of them probably don't know C or what that patch really meant so
But they could have read the references I gave or I could explain it to them. Anyhow this patch is not a great matter of importance.
giving them the right to decide on its fate seems stupido.
Well, I want to have the right to make decisions and everyone should have this right. What you prefer is an oligarchy. -- Matthias-Christian Ott
Hi, I am a relatively new CRUX user (I come from Gentoo and Archlinux) and I really appreciated CRUX typically slow and unobstrusive development, without overburocratized patch management system and without the need to change just to change. CRUX sometimes seems dead, just because it is following linux development without adding any complexity and obstrusity. This is why footprint mismatches should be analyzed directly by the users (something new is entering their system, they have to decide what to do) and why use flags are a way to obfuscate the way a package is built (a user should directly verify how a specific package is compiled editing the Pkgfile). Moreover, in the past six months, I have sent several observations about the way some packages are built and each one has received an answer: the aim of my remarks was never to introduce something peculiar or deviant in the way to build packages, but merely to fix mistakes. I do not see why C++ would have been so essential to the spirit of CRUX: there is no precise design or aim behind that choice, and the advantages of C over C++ are, I would say, well known. Moreover:
* (perhaps) merge with CRUX-PPC
A little distribution should not try to work on multiple architectures, because this implies a massive dissipation of efforts: CRUX is designed to work on i686 machine and should not try to be something else
* more precise and stricter packaging standards
I see no point in this, and many disadvantages affecting distros like debian, gentoo and archlinux: a huge burocracy checking unuseful stuff like the order of fields or the kind of quotation marks deployed.
* complete localisation (no --disable-nls, ...)
I do not need localizations, because their only point, besides wasting disk space, is to obfuscate the original language in which a software is thought and written. They are useful in distros aimed to newbies and casual users who are allowed to ignore english, but the experienced users of CRUX will surely know English well enough (otherwise they could not be really involved in the development of linux) and do not need to be mislead by potentially wrong translations. Other wishes are more vague and could be partially shared. But they do not require any change of mind towards an heavily organized, obstrusive way of development. So I encourage CRUX to remain largely as it is now Giorgio Lando
Giorgio Lando schrieb:
Moreover:
* (perhaps) merge with CRUX-PPC
A little distribution should not try to work on multiple architectures, because this implies a massive dissipation of efforts: CRUX is designed to work on i686 machine and should not try to be something else
Sorry, that's total nonsense! root@ecam:~$ crux CRUX version 2.3 root@ecam:~$ cat /proc/cpuinfo processor : 0 cpu : e500 revision : 2.0 (pvr 8020 0020) bogomips : 823.29 chipset : 8540 Vendor : Freescale Semiconductor Machine : mpc8540ads clock : 825MHz PVR : 0x80200020 SVR : 0x80300020 PLL setting : 0x5 Memory : 256 MB The CRUX philosophy (stay simple and functional) is the key to be portable to other architectures. One example is crux-ppc and the other one my creation called CRUX-embedded for some embedded PowerPC (see above) which I would call the most current native toolchain available for that platform. The funny thing is that from the current 102 ports in x86' core only 10 need special care to build for this (quite strange) embedded PowerPC. (I "forked" crux-embedded from crux-x86 and not from crux-ppc!) So, the official (x86-)CRUX is already over 90% architecture transparent! I don't really care if it's merged with crux-x86 or crux-ppc... It's no big deal to handle the 10 packages (the toolchain plus some crap) when there are some updates. (once every other month)
I do not need localizations, because their only point, besides wasting disk space, is to obfuscate the original language in which a software is thought and written.
Here, you get my ACK! Regards, -- Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19
Clemens Koller wrote: The CRUX philosophy (stay simple and functional) is the key to be portable to other architectures. --- Giorgio Lando wrote: CRUX sometimes seems dead, just because it is following linux development without adding any complexity and obstrusity. This is why footprint mismatches should be analyzed directly by the users (something new is entering their system, they have to decide what to do) and why use flags are a way to obfuscate the way a package is built (a user should directly verify how a specific package is compiled editing the Pkgfile). --- Johannes Winkelmann wrote: if you fork: <snip> you can decide freely on the features of your distro, <snip> I can keep using CRUX. --- And that is relevant even for those of us who don't want to make a new distro, but just want to do a few things differently; CRUX makes that easy and possible. For me it is in some ways the biggest attraction of CRUX. The other BIG attraction is that the mechanisms of the distro are not intruding into the applications software, so that it can be very up-to-date - no waiting for the distro to fiddle with it, and no or minimal interference by the distro in its functions. A point I often forget to mention is that I am not forced into a "desktop", I can function without ever needing to click on an Icon; yet I have as many graphical applications as I want.. clare (Happy CRUX user from version 0.9)
"Clare Johnstone" <claregj@gmail.com> wrote:
Clemens Koller wrote:
The CRUX philosophy (stay simple and functional) is the key to be portable to other architectures. ---
Giorgio Lando wrote:
CRUX sometimes seems dead, just because it is following linux development without adding any complexity and obstrusity. This is why footprint mismatches should be analyzed directly by the users (something new is entering their system, they have to decide what to do) and why use flags are a way to obfuscate the way a package is built (a user should directly verify how a specific package is compiled editing the Pkgfile).
--- Johannes Winkelmann wrote:
if you fork: <snip> you can decide freely on the features of your distro, <snip> I can keep using CRUX. ---
And that is relevant even for those of us who don't want to make a new distro, but just want to do a few things differently; CRUX makes that easy and possible. For me it is in some ways the biggest attraction of CRUX.
Well, but for what reason should we compete instead of collaborate? There is no reason despite the obstinacy of some developers!
The other BIG attraction is that the mechanisms of the distro are not intruding into the applications software, so that it can be very up-to-date - no waiting for the distro to fiddle with it, and no or minimal interference by the distro in its functions.
A point I often forget to mention is that I am not forced into a "desktop", I can function without ever needing to click on an Icon; yet I have as many graphical applications as I want..
You can do this with nearly every distribution. Just think of tools like apt-get, yum, yast, ... -- Matthias-Christian Ott
Clemens Koller <clemens.koller@anagramm.de> wrote:
Giorgio Lando schrieb:
Moreover:
* (perhaps) merge with CRUX-PPC
A little distribution should not try to work on multiple architectures, because this implies a massive dissipation of efforts: CRUX is designed to work on i686 machine and should not try to be something else
Sorry, that's total nonsense!
root@ecam:~$ crux CRUX version 2.3 root@ecam:~$ cat /proc/cpuinfo processor : 0 cpu : e500 revision : 2.0 (pvr 8020 0020) bogomips : 823.29 chipset : 8540 Vendor : Freescale Semiconductor Machine : mpc8540ads clock : 825MHz PVR : 0x80200020 SVR : 0x80300020 PLL setting : 0x5 Memory : 256 MB
The CRUX philosophy (stay simple and functional) is the key to be portable to other architectures.
Yes, I fully acknowledge. Writing a portable and functional programme is often also connected with portability, UNIX is a famous example of this design philosophy.
The funny thing is that from the current 102 ports in x86' core only 10 need special care to build for this (quite strange) embedded PowerPC. (I "forked" crux-embedded from crux-x86 and not from crux-ppc!)
This the result of portability and shows that porting CRUX is a (hopefully) trivial task. Thus we could merge quite quickly.
So, the official (x86-)CRUX is already over 90% architecture transparent!
I don't really care if it's merged with crux-x86 or crux-ppc... It's no big deal to handle the 10 packages (the toolchain plus some crap) when there are some updates. (once every other month)
Perhaps it is not difficult, but I think collaboration would be more successful and effective. -- Matthias-Christian Ott
Matthias-Christian Ott wrote:
Clemens Koller <clemens.koller@anagramm.de> wrote:
Giorgio Lando schrieb:
A little distribution should not try to work on multiple architectures,
Sorry, that's total nonsense!
The CRUX philosophy (stay simple and functional) is the key to be portable to other architectures.
This the result of portability and shows that porting CRUX is a (hopefully) trivial task. Thus we could merge quite quickly.
I don't agree on that. I think you misunderstood Clemens words. It's not trivial (even if in the latest years it became much easier). Archs like ppc are not really one arch, but a dozen of archs who share almost-similar processors. It was not trivial to write a toolchain able to build 64bit kernels for G5 and Pseries. It was not trivial to make an iso that was able to boot on 6 different kinds of powerpc machines, and our last work, making crux-ppc run on sam440ep turned out into writing kernel patches over the denx-tree and rtc drivers writing (cjg is taking care of that). I think Clemens meant that if a port is kept as easy as possible, then it's easy to find out when a port needs to be modified for a specific arch... if you keep putting flag variables in the port, in the footprints etc, you will never know if that port builds just fine in *every* case. If you put conditions in footprints it's very hard to give a simple look at the footprint and understand that it contains arch-specific files... For this reason CRUX is one of the best and easiest distros to port... had it been arch or gentoo or debian, it would have been much harder... those distros have got many developers, that's why they can handle such an huge "overhead". byez giorgio -- NullPointer || GnuPG/PGP Key-Id: 0x343B22E6
Giorgio Agrelli <giorgio_a@libero.it> wrote:
Matthias-Christian Ott wrote:
Clemens Koller <clemens.koller@anagramm.de> wrote:
Giorgio Lando schrieb:
A little distribution should not try to work on multiple architectures,
Sorry, that's total nonsense!
The CRUX philosophy (stay simple and functional) is the key to be portable to other architectures.
This the result of portability and shows that porting CRUX is a (hopefully) trivial task. Thus we could merge quite quickly.
I don't agree on that. I think you misunderstood Clemens words. It's not trivial (even if in the latest years it became much easier). Archs like ppc are not really one arch, but a dozen of archs who share almost-similar processors. It was not trivial to write a toolchain able to build 64bit kernels for G5 and Pseries. It was not trivial to make an iso that was able to boot on 6 different kinds of powerpc machines, and our last work, making crux-ppc run on sam440ep turned out into writing kernel patches over the denx-tree and rtc drivers writing (cjg is taking care of that).
With other architectures it may be complicated (like ARM, ...), but it is not impossible and other distributions have and had the same problems. But this is no reason for forking a separate project.
I think Clemens meant that if a port is kept as easy as possible, then it's easy to find out when a port needs to be modified for a specific arch... if you keep putting flag variables in the port, in the footprints etc, you will never know if that port builds just fine in *every* case. If you put conditions in footprints it's very hard to give a simple look at the footprint and understand that it contains arch-specific files...
I think Pkgsrc does this also and has no real problems with it. -- Matthias-Christian Ott
"Giorgio Lando" <patroclo7@gmail.com> wrote:
Hi, I am a relatively new CRUX user (I come from Gentoo and Archlinux)
I was an Arch Linux developer and user and partially used Gentoo before I switched to CRUX.
and I really appreciated CRUX typically slow and unobstrusive development, without overburocratized patch management system and without the need to change just to change. CRUX sometimes seems dead, just because it is following linux development without adding any complexity and obstrusity. This is why footprint mismatches should be analyzed directly by the users (something new is entering their system, they have to decide what to do) and why use flags are a way to obfuscate the way a package is built (a user should directly verify how a specific package is compiled editing the Pkgfile).
Footprint mismatches occur, because the user has other software installed than the developer who generated the footprint. Configure (autotools) enables additionally features and additionally files are installed. Thus the footprint mismatches. Isolated builds and feature flags (~ USE flags) prevent this situation. Additionally feature flags use configure correctly (in the way it was intended to be used).
Moreover, in the past six months, I have sent several observations about the way some packages are built and each one has received an answer: the aim of my remarks was never to introduce something peculiar or deviant in the way to build packages, but merely to fix mistakes.
But sometimes it is impossible to do so, because of configure.
I do not see why C++ would have been so essential to the spirit of CRUX: there is no precise design or aim behind that choice, and the advantages of C over C++ are, I would say, well known.
Yes, but including standard algorithm source code (lists, binary search trees) conflicts (in my opinion) with the design philosophy of CRUX. Additionally I think the pkgutils C++ source code is much more aesthetic and clean.
Moreover:
* (perhaps) merge with CRUX-PPC
A little distribution should not try to work on multiple architectures, because this implies a massive dissipation of efforts: CRUX is designed to work on i686 machine and should not try to be something else
In the 1970s UNIX and C were designed to make the operating system portable. The success of UNIX is based on this. GNU would not exist if UNIX had not been portable. According to your argumentation operating systems would be written in Assembler. This is really stupid if you have the chance write a portable version of it. Nearly all ports are written in portable languages and work on every architecture. Why should CRUX restrict their usage to i686?
* more precise and stricter packaging standards
I see no point in this, and many disadvantages affecting distros like debian, gentoo and archlinux: a huge burocracy checking unuseful stuff like the order of fields or the kind of quotation marks deployed.
These standards ensure the quality of the software. The examples you mentioned do not reflect the real intention or usage of this standards.
* complete localisation (no --disable-nls, ...)
I do not need localizations, because their only point, besides wasting disk space, is to obfuscate the original language in which a software is thought and written. They are useful in distros aimed to newbies and casual users who are allowed to ignore english, but the experienced users of CRUX will surely know English well enough (otherwise they could not be really involved in the development of linux) and do not need to be mislead by potentially wrong translations.
I have been working on a big translation project and I know that even experienced users liked and wanted it. I do not need translations, but they are included in the packages, so why should we reject them? Maybe other user on your system want them. You can disable them via events/hooks in pkgutils if you do not want them.
Other wishes are more vague and could be partially shared. But they do not require any change of mind towards an heavily organized, obstrusive way of development.
You need some kind of organisation for every non-trivial project. It may not be hierarchical, but there needs to be some standards in order to collaborate effectively. -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-06 12:26]:
Footprint mismatches occur, because the user has other software installed than the developer who generated the footprint. Configure (autotools) enables additionally features and additionally files are installed. Thus the footprint mismatches. Isolated builds and feature flags (~ USE flags) prevent this situation.
You're talking about how pkgutils6 violetes Per's vision and the CRUX philosophy etc, and yet here you are saying we need a better ports/pkgfile system. It's all backwards!
I do not see why C++ would have been so essential to the spirit of CRUX: there is no precise design or aim behind that choice, and the advantages of C over C++ are, I would say, well known.
Yes, but including standard algorithm source code (lists, binary search trees) conflicts (in my opinion) with the design philosophy of CRUX.
Well, the current CRUX maintainers believe otherwise it seems. And all of us are long time users and contributors, so I believe we do know better about what fits with CRUX' philosophy, and Per's ideas of this distribution than you.
architecture. Why should CRUX restrict their usage to i686?
Because it's the most widespread architecture in use in typical desktop and server systems today. eg I only have i686 boxes, how the hell can I vouch for my ported software if I cannot even test it on x86-64? On the one hand, you're constantly claiming that we'd violate CRUX philosophy, on the other hand you're suggesting to extend the ports system etc in ways that were never meant to be. You're wrong. Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 12:26]:
Footprint mismatches occur, because the user has other software installed than the developer who generated the footprint. Configure (autotools) enables additionally features and additionally files are installed. Thus the footprint mismatches. Isolated builds and feature flags (~ USE flags) prevent this situation.
You're talking about how pkgutils6 violetes Per's vision and the CRUX philosophy etc, and yet here you are saying we need a better ports/pkgfile system. It's all backwards!
I think a better ports system does not conflict with the CRUX philosophy.
I do not see why C++ would have been so essential to the spirit of CRUX: there is no precise design or aim behind that choice, and the advantages of C over C++ are, I would say, well known.
Yes, but including standard algorithm source code (lists, binary search trees) conflicts (in my opinion) with the design philosophy of CRUX.
Well, the current CRUX maintainers believe otherwise it seems. And all of us are long time users and contributors, so I believe we do know better about what fits with CRUX' philosophy, and Per's ideas of this distribution than you.
OK, if that is the CRUX philosophy, than the philosophy has to be changed also.
architecture. Why should CRUX restrict their usage to i686?
Because it's the most widespread architecture in use in typical desktop and server systems today.
But what about people that do not have a i686 system, but agree with the CRUX philosophy?
eg I only have i686 boxes, how the hell can I vouch for my ported software if I cannot even test it on x86-64?
The software has been (in the majority of cases) already tested by the original developers, we just package them.
You're wrong.
If you think so, I am probably wrong. Long live the emperor! -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-06 14:09]:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 12:26]:
I do not see why C++ would have been so essential to the spirit of CRUX: there is no precise design or aim behind that choice, and the advantages of C over C++ are, I would say, well known.
Yes, but including standard algorithm source code (lists, binary search trees) conflicts (in my opinion) with the design philosophy of CRUX.
Well, the current CRUX maintainers believe otherwise it seems. And all of us are long time users and contributors, so I believe we do know better about what fits with CRUX' philosophy, and Per's ideas of this distribution than you.
OK, if that is the CRUX philosophy, than the philosophy has to be changed also.
Heh, so you're not interested in CRUX at all? :D
architecture. Why should CRUX restrict their usage to i686?
Because it's the most widespread architecture in use in typical desktop and server systems today.
But what about people that do not have a i686 system, but agree with the CRUX philosophy?
In the past, those people developed their own CRUX flavor in parallel or not so much in parallel to CRUX x86. Examples of this are Daniels' crux64, Matt's and Johannes' crux-sparc and of course also Hannes' current 64 bit Crux and the two PPC flavors. We know this situation isn't perfect, but so far we haven't found a solution that all of the affected parties liked.
eg I only have i686 boxes, how the hell can I vouch for my ported software if I cannot even test it on x86-64?
The software has been (in the majority of cases) already tested by the original developers, we just package them.
This just works in theory, not in practice :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Matthias-Christian Ott [2007-10-05 17:51]:
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Yeah, contacting Per is moot these days. btw, I've seen that mail now in which you tried to get a developer account. I suggest you read that mail again yourself and think about whether the *tone* of the text fits with "asking for access". I've worked with several free software projects in the last few years, and I've never seen somebody behave like that when they wanted to contribute. Commanding us to give you access after you supplied two patches is kind of crazy. And of course, it doesn't make sense at all that you didn't subscribe to the developer list in order to be able to post there to ask for access. Apparently flaming us was enough reason to subscribe to this list after all. Oh well o_O Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Yeah, contacting Per is moot these days.
btw, I've seen that mail now in which you tried to get a developer account. I suggest you read that mail again yourself and think about whether the *tone* of the text fits with "asking for access".
A developer needs access to primary development repository in order to work effectively. Additionally I am not a native speaker.
I've worked with several free software projects in the last few years, and I've never seen somebody behave like that when they wanted to contribute.
In comparison to the GNU procedure for developers (which is really necessary), it is quite unusual to ask that directly. I have been a project primary administrator for a project hosted by berlios and gave commit and write rights to everyone who wanted and never had any problems with this policy.
Commanding us to give you access after you supplied two patches is kind of crazy.
It depends on your perspective and opinion.
And of course, it doesn't make sense at all that you didn't subscribe to the developer list in order to be able to post there to ask for access.
Well, I had an e-mail account at yahoo and used it via webmail which made it practically impossible to subscribe to any mailinglist.
Apparently flaming us was enough reason to subscribe to this list after all. Oh well o_O
No, I never intended to start a flame war. I got a better e-mail account and wanted to make sure that I do everything that is possible before switching or forking a distribution. -- Matthias-Christian Ott
Matthias-Christian Ott [2007-10-06 13:13]:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Yeah, contacting Per is moot these days.
btw, I've seen that mail now in which you tried to get a developer account. I suggest you read that mail again yourself and think about whether the *tone* of the text fits with "asking for access".
A developer needs access to primary development repository in order to work effectively. Additionally I am not a native speaker.
Yes, asking for access is fine and encouraged in general. Hint: you could have greatly helped to back up your argument if you had provided links to your personal git clones of core/opt/whatever. Distributed SCMs make it soo easy to contribute even if you don't have access to the main servers... While this isn't always best as a permanent solution, it's a great way to get your feet wet. re your language skills: From your other mails around here it seems you speak English very well. So it seems a bit hypocritical to blame your language skills for that abusive mail TBH.
I've worked with several free software projects in the last few years, and I've never seen somebody behave like that when they wanted to contribute.
In comparison to the GNU procedure for developers (which is really necessary), it is quite unusual to ask that directly.
What? I don't understand what you're trying to say.
I have been a project primary administrator for a project hosted by berlios and gave commit and write rights to everyone who wanted and never had any problems with this policy.
Good for you, but IMO giving write access to everyone even if you barely had contact with them is a bad idea.
Commanding us to give you access after you supplied two patches is kind of crazy.
It depends on your perspective and opinion.
No, it doesn't! _Commanding_ us to do anything is *not* a good way to achieve your goals! We're not in your debt, you have to earn your privileges here.
And of course, it doesn't make sense at all that you didn't subscribe to the developer list in order to be able to post there to ask for access.
Well, I had an e-mail account at yahoo and used it via webmail which made it practically impossible to subscribe to any mailinglist.
Use another account then? Duh.
Apparently flaming us was enough reason to subscribe to this list after all. Oh well o_O
No, I never intended to start a flame war. I got a better e-mail account
Sure it was, you were proclaiming CRUX' death while it's still active. How'd you think we'd react to that? o_O Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 13:13]:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Yeah, contacting Per is moot these days.
btw, I've seen that mail now in which you tried to get a developer account. I suggest you read that mail again yourself and think about whether the *tone* of the text fits with "asking for access".
A developer needs access to primary development repository in order to work effectively. Additionally I am not a native speaker.
Yes, asking for access is fine and encouraged in general. Hint: you could have greatly helped to back up your argument if you had provided links to your personal git clones of core/opt/whatever.
If you have no access to a hosting server, you can not provide links.
Distributed SCMs make it soo easy to contribute even if you don't have access to the main servers... While this isn't always best as a permanent solution, it's a great way to get your feet wet.
Yes, distributed revision control systems are great, but merging changes from the main server is sometimes really annoying.
re your language skills: From your other mails around here it seems you speak English very well. So it seems a bit hypocritical to blame your language skills for that abusive mail TBH.
That e-mail was not abusing; I never tried to abuse someone or something. I just meant that was maybe not aware of the fact that people feel offence when "asking for access" which sounds to me quite neutral
I've worked with several free software projects in the last few years, and I've never seen somebody behave like that when they wanted to contribute.
In comparison to the GNU procedure for developers (which is really necessary), it is quite unusual to ask that directly.
What? I don't understand what you're trying to say.
Working on the GNU project means basically to transfer to the copyright of your source code to the Free Software Foundation which protects the source code for you.
I have been a project primary administrator for a project hosted by berlios and gave commit and write rights to everyone who wanted and never had any problems with this policy.
Good for you, but IMO giving write access to everyone even if you barely had contact with them is a bad idea.
The concept of the patch queue resolves your concerns.
Commanding us to give you access after you supplied two patches is kind of crazy.
It depends on your perspective and opinion.
No, it doesn't! _Commanding_ us to do anything is *not* a good way to achieve your goals! We're not in your debt, you have to earn your privileges here.
It was not meant to be a command.
And of course, it doesn't make sense at all that you didn't subscribe to the developer list in order to be able to post there to ask for access.
Well, I had an e-mail account at yahoo and used it via webmail which made it practically impossible to subscribe to any mailinglist.
Use another account then? Duh.
I did not have one.
Apparently flaming us was enough reason to subscribe to this list after all. Oh well o_O
No, I never intended to start a flame war. I got a better e-mail account
Sure it was, you were proclaiming CRUX' death while it's still active. How'd you think we'd react to that? o_O
I do not know, but I just expressed what I think. -- Matthias-Christian Ott
On Sat, Oct 06, 2007 at 01:52:51PM +0200, Matthias-Christian Ott wrote:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 13:13]:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Yeah, contacting Per is moot these days.
btw, I've seen that mail now in which you tried to get a developer account. I suggest you read that mail again yourself and think about whether the *tone* of the text fits with "asking for access".
A developer needs access to primary development repository in order to work effectively. Additionally I am not a native speaker.
Yes, asking for access is fine and encouraged in general. Hint: you could have greatly helped to back up your argument if you had provided links to your personal git clones of core/opt/whatever.
If you have no access to a hosting server, you can not provide links.
http://repo.or.cz/ Is the only on I know so far. bye richi -- quoting guide: http://www.xs4all.nl/~hanb/documents/quotingguide.html
Richard Pöttler <richard.poettler@gmail.com> wrote:
On Sat, Oct 06, 2007 at 01:52:51PM +0200, Matthias-Christian Ott wrote:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-06 13:13]:
Tilman Sauerbeck <tilman@crux.nu> wrote:
Matthias-Christian Ott [2007-10-05 17:51]:
I tried to get a developer account and proper e-mail address on the CRUX server in order to be able to participate in development, maintenance and organisation, but nobody replied, my e-mails were rejected. I contacted Per and told him about my plans, but he could not really help me, because he was not a CRUX developer anymore.
Yeah, contacting Per is moot these days.
btw, I've seen that mail now in which you tried to get a developer account. I suggest you read that mail again yourself and think about whether the *tone* of the text fits with "asking for access".
A developer needs access to primary development repository in order to work effectively. Additionally I am not a native speaker.
Yes, asking for access is fine and encouraged in general. Hint: you could have greatly helped to back up your argument if you had provided links to your personal git clones of core/opt/whatever.
If you have no access to a hosting server, you can not provide links.
OK, thanks for the link. -- Matthias-Christian Ott
Hi. After the xorg update to 7.3 there are no longer any good working drivers for people (like me) with a littel bit newer AMD/ATI Graphiccards. The proprietär fglrx driver conflicts withe the new version schema of the xorg-server ( old = 7.X ; new = 1.X ) and the normal radeon driver only supports old Cards (r200 - r400). After AMD/ATI open their graphicchip spezifications last month, there is a new driver called radeonhd. The driver is designed for the newer r500 r600 based cards. I know, this driver is still under heavy development but maybe its although a good idea, include the driver in the xorg repository. For example, with my X1250 it works already very well. regards Hannes -- crux86_64 - http://ecarux.de/crux86_64 CRUX pure 64Bit Edition
Hannes Mayer [2007-10-08 16:16]: Hi Hannes, please don't hijack other people's threads :)
After the xorg update to 7.3 there are no longer any good working drivers for people (like me) with a littel bit newer AMD/ATI Graphiccards. The proprietär fglrx driver conflicts withe the new version schema of the xorg-server ( old = 7.X ; new = 1.X ) and the normal radeon driver only supports old Cards (r200 - r400).
ACK.
After AMD/ATI open their graphicchip spezifications last month, there is a new driver called radeonhd. The driver is designed for the newer r500 r600 based cards. I know, this driver is still under heavy development but maybe its although a good idea, include the driver in the xorg repository.
I'm reluctant to port software that doesn't have any releases at all. Maybe I'll roll weekly tarballs myself and put a port in my private ports repository (rather than in xorg.git). Problem is that I'm lacking the hardware to test the driver. Mmh.
For example, with my X1250 it works already very well.
... though I'm wondering how well it can work considering that it doesn't even have 2D acceleration yet ;)) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Am Montag, 8. Oktober 2007 14:42:40 schrieb Tilman Sauerbeck:
Hannes Mayer [2007-10-08 16:16]:
Hi Hannes,
please don't hijack other people's threads :)
Sorry, I wouldn't do that. But what have I done? I just wrote this mail to crux@lists.crux.nu like before. Hm...
After the xorg update to 7.3 there are no longer any good working drivers for people (like me) with a littel bit newer AMD/ATI Graphiccards. The proprietär fglrx driver conflicts withe the new version schema of the xorg-server ( old = 7.X ; new = 1.X ) and the normal radeon driver only supports old Cards (r200 - r400).
ACK.
After AMD/ATI open their graphicchip spezifications last month, there is a new driver called radeonhd. The driver is designed for the newer r500 r600 based cards. I know, this driver is still under heavy development but maybe its although a good idea, include the driver in the xorg repository.
I'm reluctant to port software that doesn't have any releases at all. Maybe I'll roll weekly tarballs myself and put a port in my private ports repository (rather than in xorg.git). Problem is that I'm lacking the hardware to test the driver. Mmh.
Ok, but better an unstable driver then none. But its your decision. I already build a port. Thats not the problem.
For example, with my X1250 it works already very well.
... though I'm wondering how well it can work considering that it doesn't even have 2D acceleration yet ;))
Don't ask me. I am not a developer. I am just a user with an ati card and glad that it works since yesterday for me. -- crux86_64 - http://ecarux.de/crux86_64 CRUX pure 64Bit Edition
Am Montag, 8. Oktober 2007 14:42:40 schrieb Tilman Sauerbeck:
Hannes Mayer [2007-10-08 16:16]:
Hi Hannes,
please don't hijack other people's threads :)
Sorry, I wouldn't do that. But what have I done? I just wrote this mail to crux@lists.crux.nu like before. Hm... It looks like you hit "reply to" to the 'die happy crux' thread, and just changed the subject; because of this, it's sorted in in this
Hi, On Mon, Oct 08, 2007 at 19:24:16 +0000, Hannes Mayer wrote: thread: http://thread.gmane.org/gmane.linux.distributions.crux.general/3092
I'm reluctant to port software that doesn't have any releases at all. Maybe I'll roll weekly tarballs myself and put a port in my private ports repository (rather than in xorg.git). Problem is that I'm lacking the hardware to test the driver. Mmh.
Ok, but better an unstable driver then none. But its your decision. I already build a port. Thats not the problem. Note that there's already a port available from the portdb.
HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Mon, Oct 08, 2007 at 07:24:16PM +0000, Hannes Mayer wrote:
I already build a port. Thats not the problem.
For example, with my X1250 it works already very well.
... though I'm wondering how well it can work considering that it doesn't even have 2D acceleration yet ;))
Don't ask me. I am not a developer. I am just a user with an ati card and glad that it works since yesterday for me.
If anyone else is interested, i've made my port available: http://crux.nu/portdb/?a=search&q=radeonhd -- Fredrik Rinnestam
Fredrik Rinnestam [2007-10-08 19:39]:
On Mon, Oct 08, 2007 at 07:24:16PM +0000, Hannes Mayer wrote:
I already build a port. Thats not the problem.
For example, with my X1250 it works already very well.
... though I'm wondering how well it can work considering that it doesn't even have 2D acceleration yet ;))
Don't ask me. I am not a developer. I am just a user with an ati card and glad that it works since yesterday for me.
If anyone else is interested, i've made my port available: http://crux.nu/portdb/?a=search&q=radeonhd
I could imagine putting this on the ISOs with version being set to the respective date. And a note saying that it's experimental and might scare your children or so :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hannes Mayer schrieb:
Am Montag, 8. Oktober 2007 14:42:40 schrieb Tilman Sauerbeck:
After AMD/ATI open their graphicchip spezifications last month, there is a new driver called radeonhd. The driver is designed for the newer r500 r600 based cards. I know, this driver is still under heavy development but maybe its although a good idea, include the driver in the xorg repository. I'm reluctant to port software that doesn't have any releases at all. Maybe I'll roll weekly tarballs myself and put a port in my private
Hannes Mayer [2007-10-08 16:16]: ports repository (rather than in xorg.git). Problem is that I'm lacking the hardware to test the driver. Mmh.
Ok, but better an unstable driver then none. But its your decision. I already build a port. Thats not the problem.
For example, with my X1250 it works already very well. ... though I'm wondering how well it can work considering that it doesn't even have 2D acceleration yet ;))
Don't ask me. I am not a developer. I am just a user with an ati card and glad that it works since yesterday for me.
Alex Deucher and some other guys at xorg are quite busy with the new AMD/ATI drivers. As far as I can guess, it will take some month to have the 2d stuff implemented. The 3d spec isn't officially released AFAICT. Anyway, I think they are happy to get feedback on their work and CRUX' clean and compact infrastructure seems ideal as a testing environment. :-) xorg (at@) lists.freedesktop.org is the place to start discussing the driver issues. Regards, -- Clemens Koller _______________________________ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19
participants (11)
-
Clare Johnstone -
Clemens Koller -
Fredrik Rinnestam -
Giorgio Agrelli -
Giorgio Lando -
Hannes Mayer -
Johannes Winkelmann -
Matthias-Christian Ott -
Richard Pöttler -
Tilman Sauerbeck -
treach