English Summary of the ROCK Linux Chat Organized for Rootboard Members Date: 10 May 2003 Time: 20:00 Attendance: 30—40 people Language: German History: The idea for a discussion between ROCK developers and Rootboard members arose at 19C3 in a conversation between +esden: (a ROCK developer) and dzafez_ConCode: (a Rootboard moderator). Related Documents ----------------- * Original IRC log in plain text, https://www.rocklinux.org/people/esden/talks/rocklinux-rootboard-talk * Cleaned IRC log in plain text, https://www.rocklinux.org/people/esden/talks/rocklinux-rootboard-talk.cleaned * Cleaned IRC log in HTML, https://www.rocklinux.org/people/esden/talks/rocklinux-rootboard-talk.cleaned.html * English summary in plain text (this document), https://www.rocklinux.org/people/jocelyn/talks/10May2003-summary * English summary in HTML, https://www.rocklinux.org/people/jocelyn/talks/10May2003-summary.html Many thanks to all who participated in the chat. Notes ----- 1. ROCK Linux developers have nicknames starting with a plus "+" sign. Most, but not all, of these nicknames are the same as the ones used on the mailing list. 2. Various problems arising from the nature of the medium (IRC chat) have been solved by simply organizing this document by topic rather than chronologically. This also has the effect that the order of statements may be reversed, and statements that were made half an hour apart may appear as if they occurred immediately one after the other. 3. The author of this document is not a native German speaker (or even a good German speaker), so it is extremely likely that there are severe errors in translation.Much editing and paraphrasing has also been done. 4. This is not a line-by-line translation. Therefore, many statements thought to be of relatively little importance have been omitted. Similar statements may have been made by more than one person, in which case either the most comprehensive or the earliest version (as determined by the log file) is used. 5. Editorial comments and notes are enclosed in square brackets []. 6. If you wish to complain or make corrections, please email jocelyn@rocklinux.org. 7. If you would like to attend or organize a future chat, please email jocelyn@rocklinux.org, stating what language you prefer. Introduction to ROCK Linux -------------------------- dzafez_ConCode: What are the most important advantages of ROCK Linux? +esden: The most important thing is that ROCK is a Distribution Build Kit. +chaosmaster: That means that it is not a distribution in the conventional sense, but is something over and above it. dzafez_ConCode: Like how Gentoo is a metadistribution. +chaosmaster: No, because Gentoo always remains Gentoo—only with other packages. +daja77: Gentoo is AFAIK not a metadistribution. [Actually, Gentoo does call itself a metadistribution.] +praenti: Thus you have advantages like optimization and portability, and an unbelievable range of customization possibilities for the final product. +esden: Many options can be adjusted with bash scripts to produce a suitable customized distribution. [Conclusion: ROCK is a tool for making your own distribution.] Prerequisites for Building with ROCK ------------------------------------ dzafez_ConCode: What conditions must I fulfill in order to build and develop a Linux distribution with ROCK? +daja77: You should be able to program in Bash. +chaosmaster: You take ROCK, or better said, a target that already has an initial configuration, which you can adjust and make yourself. dzafez_ConCode: To make things clear: if I would like to make a ROCK for myself, I have two choices, either a default build or a customized build. +chaosmaster: Exactly. +n00kie; For example, you can build a straight minimum environment, with which you can customize your own build. dzafez_ConCode: There must be a certain environment available for the build? +esden: Yes. dzafez_ConCode: That includes curl, devfs...? +esden: Those are the two basic things which one needs. Naturally, also gcc and make, all the basic build tools. +praenti: devfs, curl and Posix-able Bash. +Be-El: A “normal” Linux + devfs. +kasc: It works, in principle, with any Linux, only with some distributions you must repair a few packages by hand. At present, it functions best if you have a minimum ROCK. +esden: I have built ROCK Linux on Debian... only small adjustments were necessary. +rygar: Does it also work for any system (Intel/Sparc/PA-RISC/etc.)? +kasc: Ideally, yes. +Be-El: Yes, it does... as far as I know there are ports for Sparc, Alpha and PowerPC. The adjustments there concern, to a large extent, the kernel and glibc. [Conclusion: To build with ROCK, you need to have the basic build tools available, as well as bash, devfs and curl. A ROCK build can be made (with some manual adjustments) on most Linux distributions, but works best on a minimum ROCK system. This initial environment can be installed using an ISO image.] Building with ROCK ------------------ __ 20h __: You have long installation times. esden: No, that is not true. You only build binary installation CDs with ROCK Linux and with those you install your system... so the actual installation time is no longer than with RH or Debian or other binary-based distributions. +tcr: Installation is something about which the target can worry... [Here a distinction is being made between “compilation” and “installation”.] ccm_rootboard:: How long does it take to build ROCK Linux on slower systems? Let's say, a PII 200 MHz with 256 MB RAM. esden: For a complete Generic build on a Athlon TB 1.2GHz and 512MB RAM, I need 4 days, but that includes the rebuild stage which is not necessarily required. daja77: 5 days. praenti: I estimate 6 days. +kasc: With kde, qt, etc., etc.? ccm_rootboard:: No, only as a server. +kasc: With only the most necessary things for a server and your hardware, a few hours. For me qt takes scarcely half a day, xfree86 scarcely 5 hours. praenti: I would build on a faster system and afterwards install by CD on the slower one. esden: That is a large advantage of ROCK--you can build on a fast machine and then install on a slow one... or quickly install on many machines without building everything each time. n00kie: Or you could use an already-compiled system. ccm_rootboard:: What are these “stages” you mentioned? praenti: The build is divided into 10 stages. Stage 0 is cross-compile, Stage1 is environment assembly, Stage 2 is chroot, Stage 3 builds tools for Stage 5, Stage 5 is the main part where most packages are built, Stage 9 rebuilds everything (and is optional). chaosmaster: The important concept is that ROCK is cross-buildable. n00kie: You can make, for example, a build for an Intel architecture on a Sparc architecture. esden: You practically always do cross builds. Even if you build on an Intel machine for Intel, a pseudo cross-compile environment is built. __ 20h __: Is ROCK Linux buildable under Visual C? daja77: No. +tcr: Yes, theoretically. That would not be a large problem—the problem is rather that all the programs which you want to use must also be ported. ccm_rootboard:: How large is an average server build, both to download and in terms of disk space? +tcr: That is your decision. It depends on what you want to put on it. Be-El: Approximately 1.4 GB as source code... and 3-4 MB ROCK scripts and package descriptions. In addition, a build tree (Generic, x86) needs on average 5 GB. Substantially more, if you use the compiler cache. martin: I have a self-built ROCK at home and now want to give it a new KDE. What must I do? Procure the source code from ftp.kde.org? Use cvs and get it from ROCK Linux? Subsequently, build it with ROCK scripts? daja77: Getting it from ROCK Linux would be the simplest way. esden: You should deinstall the old KDE. Then download the new ROCK tree from the ROCK site or from cvs/svn. Then run ./scripts/Download -package . n00kie: Then run Build-Pkg to compile and install. chaosmaster: Or do a ROCK Linux checkout and run ./scripts/Build-Pkg -repository kde. martin: In the future, will there also be something like an automatic update system? +esden: There is one already. +n00kie: You can do that with either Update-Src or Update-System. ccm_rootboard: If I want to install a package can the script solve the dependencies for me? +tcr: Build dependencies are resolved. Others must be resolved by hand. +esden: There is a considerable dislike of automatic runtime-dependency resolution in the ROCK Linux developer ranks. But if you use STONE [see section on configuration] to install, the dependencies are kept track of. [Conclusion: ROCK is used to build a custom distribution, which can be packed onto a CD for installation elsewhere, if desired. It can be resource-intensive to build, depending on your hardware and what packages you decide to include. However, it is cross-buildable, so that the resulting build is independent of the hardware or software configuration of the system on which it was built. Among other things, this means that builds for a slow system can be done on a fast system, thus speeding up the process. The scripts are used to download and build packages, and can update individual packages as well as update the whole system.] Optimization ------------ martin: Does a ROCK built for my PC really run so much faster, than e.g. Debian? Is it really worth the 5 days' wait? +kasc: Yes. Especially with larger packages like KDE, you notice the difference very clearly. +Be-El: The speed increase depends, naturally, on the compiler... but starting from gcc3 the extended command set of the x86 processor will be better supported. +chaosmaster: The difference is so great that recently an attempt to install a P3 build on my Athlon caused a crash. praenti A small note on that subject—Athlon can make use of P2 optimization, but not the other way around, so between AMD and Pentium I would choose Intel optimization. dzafez_ConCode: So, you need to know exactly which system a build was made for. +chaosmaster: Or at least the common denominator. dzafez_ConCode: It would be a good idea to make that information known for the prebuilds available on the ROCK Linux web site. +chaosmaster: They are generally for 586. +esden: Unfortunately, we don't have enough fast hardware to make binaries available for all optimizations. [Conclusion: The advantage of compiling from source is the ability to optimize the code for your hardware or to make a special-purpose distribution.] Targets ------- dzafez_ConCode: What popular targets are already available? +chaosmaster: Generic, boot disk, desktop, router, rescue, minimum.... +esden: dietlibc, which is a target where dietlibc replaces glibc. It is smaller and faster than glibc, and it adheres to the standards more. +daja77: And the real-time target, supposedly available next week. +esden: Soon, also uclibc. +chaosmaster: That is an alternative libc particularly for embedded systems. +Be-El: The interesting thing is the combination of targets you need for a bootable CD—you need the boot disk target and another one (the one you want to install). However, nothing prevents you from building a complete set of targets, with a boot disk, e.g., to run on several computers. butch: What must I do to make the router target? +daja77: AFAIK, boot the router target into a RAM disk. dzafez_ConCode: Is it like fli4l? +daja77: No, fli4l is different. +n00kie: Select the router target and build it. butch: So I can select directly between several targets? +n00kie: Yes. When you have configured everything, download the files for the router target by running ./scripts/Download -required. butch: Ah, so it's like a normal installation only you select the router target in ./scripts/Config? +n00kie: Yes, exactly. butch: So you install from source? You don't need another distribution? +n00kie: No, you build the target in, for example, a ROCK system. butch: Wait, I must boot from somewhere for the first time so I can build. Do I boot from the source CD? +Be-El: No. +chaosmaster: Ideally you boot a ROCK rescue, but in principle all other Linuxes will work. Be El You then provide a configuration (scripts/Config), download the sources (scripts/Download), build your distribution (scripts/Build-Target) and produce from it an ISO image (scripts/Create-ISO). Pack the image on CD and boot your target with that. ccm_rootboard: Which firewall/packet filter is used for the router target? +daja77: netfilter. +tsa: But before you configure, no iptables scripts are present. martin: Does ROCK also have a Live CD? A ROCK Knoppix? +daja77: Yes, soon. dzafez_ConCode: That would be very cool! [Conclusion: There are many specialized targets already available. The choice of a target is made in the configuration script.] Security -------- Rembrandt: How is the security compared to OpenBSD? +tcr: That is up to you. I think that is one of the most important characteristics of ROCK anyway: since it is a distribution build kit, it does not limit you. The only limit is your knowledge and your experience. You can use, for example, the new EXEC Shield for the kernel, or some other techniques—but you must take care of it yourself. Other than the gcc stack-smashing protection, ROCK itself does not have real safety principles. Which does not mean that it is not feasible—simply that nobody has yet had the time [to make a security target]. praenti: Stack protection has an interesting history. There is a patch to gcc so that those binaries are no longer susceptible to ordinary buffer overflows. Naturally, however, many of the holes are not at all related to stack protection so large safety problems must nevertheless be fixed. The only downer for the moment is that we have some small problems with the stack protection, which I will address shortly. +esden: The stack protection is a config option, you can choose to use it or not. +chaosmaster: It is a generally accepted ROCK principle—make security a target if you like, and patch packages as much as you have want—everything is easy to do. +daja77: By default, no redundant services are activated, so it is similar to OpenBSD in that sense. Ports are not examined [in ROCK]. Rembrandt: I mean, OpenBSD examines everything which it delivers, and who the shells belong to... +chaosmaster: OpenBSD has a lot more developers than we do. +tcr: Why should we remove your responsibilities as a sysadmin? That is not the purpose of ROCK. At the most, it is the task of a specific target, which does not yet exist. But naturally, packages are updated, if safety holes in them become public. +chaosmaster: We don't look for holes ourselves, but we fix them as soon as they are known, from reading SecurityFocus or bugtraq. +george: Or from reading changelogs. [Conclusion: Security is considered the responsibility of the sysadmin, who is free to address his own needs by constructing a specialized security target, if desired. Known security bugs are fixed quickly, but no special security features are present in ROCK Linux itself.] Configuration ------------- dzafez_ConCode: A system is only as good as how it is made! Is it true to say that someone who wants to run ROCK has to do more work? +chaosmaster: No, since by default all services are off and the default configs are provided. dzafez_ConCode: I mean, "build-configure-download-build-burn-install-configure": the work some commercial distributions take care of for you. +Be-El: As already mentioned, nobody forces you to do your own build. There are also ISOs available. But if you want a customized build, there is always a minimum amount of effort you have to put in to configure it. +esden: In a way, yes, there is more work... However, we see that as making the hidden power behind the simplifications of commercial distributions available to the user/admin. It's an advantage, in my view. ccm_rootboard: So I pull all the packages on a Linux computer, then let the config tool run there, and build my distribution, which I then slap onto the target computer? +chaosmaster: Yes, approximately. ccm_rootboard: I shouldn't use an ISO because I would lose the benefit of customization? +esden: It is best that you take an ISO, and install your system with it... and then on this sytem, build your new desired distribution. +n00kie: You configure everything, usually, with the config files. +tcr: Or with STONE. +n00kie: But you generally edit everything anyway. +n00kie: STONE is the "setup tool" of ROCK Linux, by the way. +daja77: STONE is in the initial phase of the installation. +chaosmaster: You only have to perform the configuration once and then can you portably re-use it elsewhere. +Be-El: Those who don't want a completely conventional configuration and have had some experience with yast will love ROCK Linux. saintjoe: STONE is specific to ROCK Linux, isn't it? +chaosmaster: STONE is ROCK specific—and optional. saintjoe: Is it installed by default? +daja77: Yes, but you don't have to use it. saintjoe: The fact that it is there annoys me. +daja77: Deactivate it in the package selection and it will not be installed. +tcr: Until a quarter ago there was nothing like STONE [actually, the first implementation of STONE was seen at 19C3, and it had been discussed 6 months before that], but there was demand (from within our own ranks). An advantage of STONE is that it is very modularly developed (and after the KISS principle), i.e. targets have it as a framework for a configuration tool, which can be very useful. ccm_rootboard: Do you have to install network cards by hand? +esden: No, you can use STONE. +chaosmaster: There is hardware recognition there too. moep: Which kernel is standard? +daja77: 2.4.21-rc1 +chaosmaster: We have stable (aka 2.4.x) and unstable (2.5.x). devilz: Must I apply all available kernel patches, or is there already a prepatched kernel? Be El ROCK Linux uses a vanilla kernel + a series of smaller patches but it is open to everyone to insert further patches. +daja77: You can apply kernel patches very easily. devilz: But I can't downgrade the kernel or use emerge ac-sources. +chaosmaster: It's not standard, but you are free to add that capability. [Conclusion: ROCK Linux allows you to completely configure many aspects of the customized distribution. A comprehensive configuration tool called STONE is available, but its use is not required.] Binaries -------- +esden: Mine—that is a package unpacking program that the installs and deinstalls Gem binary packages. But you don't have to use Mine and Gem; you can tell ROCK Linux to build the resulting binary packages as tar.bz2... and then use tar for the install and a line of shell script to deinstall. martin: Can I download binary packages, e.g. KDE, somewhere? +chaosmaster: No, even dROCK [Desktop ROCK, which is now a target in ROCK] does not make finished packages available (yet). martin: You mean rxr [maintainer of the Desktop target] is working towards that goal?! +chaosmaster: AFAIK, yes. +n00kie: For XFree, KDE and QT there are binary packages you can get. +chaosmaster: But when you use pre-compiled binaries you may no longer have the benefit of optimization for your specific needs. saintjoe: Does ROCK Linux offer a "binary" version? +chaosmaster: ROCK Linux itself does not, but the target maintainer may. dzafez_ConCode: There aren't enough targets available as ISOs. I would gladly try out a few things if I did not have to compile them. +Be-El: As soon as 2.0 is finished, more images will be available. +chaosmaster: Everything will be better after 2.0. [Conclusion: Binary ISOs for specific targets may be made available by the target maintainer.] The Infamous Gentoo Question... ------------------------------- [I have selected a particularly representative portion of the classic Gentoo discussion to summarize here, and omitted all the rest, as nobody on either side ever knows enough about the issue for this sort of conversation to be accurate and/or useful to anybody. No disrespect is intended to anyone concerned.] devilz: But if you use, for example, Gentoo, you can also make an optimized build from its system from scratch (and much more easily besides)! Gentoo is faster... +Be-El: A ROCK Linux build lasts for anything from a few hours to a few days... I build a complete ROCK (750 packages) in 1.5 days. How fast is Gentoo? devilz: For me, 20 hours including KDE. +Be-El: And how much can you customize Gentoo? devilz: Very much! Because of the Use flag and CCU flag. I personally think that Gentoo is the better choice for a user system. +Be-El: Can you also make cross-compiles for other architectures with Gentoo? devilz: Definitely, theoretically. +Be-El: I do not know Gentoo well enough. devilz: Then test it sometime. +esden: Gentoo is completely different from ROCK Linux. It could be a part of ROCK Linux, like a “Gentoo target”... Though “emerge” is admittedly a sexy name, I could write a script in half an hour to do exactly what it does. +Be-El: If I understand correctly, Gentoo makes a primary system, into which you can then build further packages. ROCK Linux builds, in addition, a complete primary system for a chroot environment, i.e., with ROCK Linux you can make a build independent of the system you are building on. But I do not know Gentoo well enough. [Conclusion: We don't know enough about Gentoo.] Other Features -------------- +Be-El: One of the large advantages of ROCK Linux is the cluster-build ability. If you have several computers in a network, you can build distributedly over the cluster. +chaosmaster: We had a beautiful diagram in the docs, or on the Web... [This diagram, which dates from LinuxTag 2002, shows all the features of ROCK, not just the cluster build.] dzafez_ConCode: I find that feature very cool. I could then build at my workplace on 7 x 1.9 GHz computers at night. ccm_rootboard: Is there a network install? +chaosmaster: Yes. Lately, even HTTP has been added. ccm_rootboard: Can you build directly from the net? Like if I have a second computer which I use to access the server? +chaosmaster: You can build over NFS, if that's what you mean. It doesn't matter where the stuff is as long as you can access it. ccm_rootboard: So I could make a ftp mount, and build directly from your servers? +chaosmaster: It would simply not give good performance. [Conclusion: Some other important features of ROCK are the cluster build ability, and the network install.] Documentation ------------- martin: Is there simple, clear documentation, where all targets are described and how I build my system in 4 steps? Perhaps in different languages? +chaosmaster: The documentation is there already, and before the official 2.0 release there will be a supplement/revision. +daja77: The ROCK Linux Guide should be out soon. saintjoe: I am a BSD user, but I think that all distributions should take the www.freebsd.org/handbook as an example. I don't see this with Gentoo, or Debian, or ROCK. I have to search the whole Web for information, whereas the FreeBSD handbook answers 95% of all questions straight away. +chaosmaster: The others you mentioned are distributions, but we are not. We don't want to address the same things they do. dzafez_ConCode: I can find lots of information on rocklinux.org. And I must say that an event like this evening's is very informative. +Be-El: The documentation is one score. With ROCK 2.0 it is still partly missing... more work needs to be done there. saintjoe: I don't mean it badly, I just think the documentation should be better. +Be-El: Have you looked in the source tarball? saintjoe: Do I have to install it? +chaosmaster: No, just unpack it. We have also done some i18n work recently. saintjoe: Can't I just go on xxx.ROCKlinux.yyy/handbook or something? +tsa: See http//www.rocklinux.org/sources/Documentation/. saintjoe: Now I will compare this with the FreeBSD handbook and see which one is clearer. dzafez_ConCode: FreeBSD is much older and has many more developers than ROCK. +tsa: If we had as many developers as FreeBSD, we would probably have the same amount of documentation... +chaosmaster: Why don't you contribute some documentation yourself? saintjoe: No, I am too busy translating FreeBSD documentation into German. [Conclusion: There is documentation in the sources/Documentation directory, and there is also the ROCK Linux Guide. But it must be admitted that the standard of documentation could be very much improved.] Attracting Users and Developers ------------------------------- CmdKeen_RadioMod: I am an admin but it looks genuinely complicated to manufacture a ROCK Linux build. And to tell the truth, I don't have much of a clue about Linux. I am more a SuSE or Knoppix user. I get things done mostly owing to the "wizards". +daja77: But you are an admin??? CmdKeen_RadioMod: Yes, but not of Linux, we have Linux only on file servers. [As might be expected, the discussion threatens to get a bit nasty here. However, there is some value to be extracted. I have therefore edited ruthlessly...] CmdKeen_RadioMod: Can I build a clean NT kernel in ROCK Linux? +Be-El: No, but wine is one of the packages... it provides a "NTkernel". martin: What kind of users would ROCK Linux like to address? +chaosmaster: Actually, all kinds, but some previous knowledge is desirable, if they want to compile things. dzafez_ConCode: I think, more experienced users who know how to configure things. +daja77: Probably not Windows users who only want to click on things. +tcr: Commercial companies, which have plenty of money! No, that was sarcastic. martin: Is there going to be PR [public relations] for 2.0? +chaosmaster: PR is already there, but few people really dare to try it. martin: ROCK does not have many developers or users. You should think about how to win more people over. +tcr: ROCK is unique, but often misunderstood. We need to show the uniqueness and universality of ROCK as a framework to make distributions, not replace them. +n00kie: Well, ROCK Linux is still relatively young. +chaosmaster: I have been around several LinuxTag events and there are new people who respond. +daja77: We don't need Windows people as developers. martin: I was speaking rather of, say, SuSE people, not Windows people. +daja77: There's not much difference. [Getting nasty again...] +chaosmaster: SuSE is not the target group—rather Debian, Gentoo, LFS. +n00kie: SuSE users aren't necessarily bad developers, there are probably very many good developers. +chaosmaster: Clearly, but most of them use Linux 8.2. +daja77: Most have the same philosophy as Windows users. +kasc: I indirectly come from SuSE... +chaosmaster: SuSE users are not worse people, they mostly just don't have the background required. martin: But you should really show now with 2.0 that you would like more. +daja77: I believe the Desktop target ISO has already helped many people. +chaosmaster: We have 25 active (more or less) developers! And, nevertheless, we have 750 packages! +Be-El: How many packages do you need for a "normal" installation? +chaosmaster: Do you install the whole SuSE DVD? 100 different editors? dzafez_ConCode: The mail clients... martin: No, dROCK [Desktop target] has more than enough packages for me. It's just that the community behind it is still quite small. +tcr: Our target group is not specifically desktop users. +chaosmaster: But Desktop ROCK still has the largest potential for mass appeal. martin: I see dROCK as for the user who simply wants a good working Linux. +chaosmaster: The user group of the Desktop target is a subset of the whole—of all distributions that are “powered by ROCK”. [Conclusion: The target user group for ROCK itself is the set of users who want to create customized distributions. These are generally fairly advanced users. Individual targets built with ROCK will also have their own user groups who will not necessarily be advanced users. In general, however, the number of users and developers of ROCK is small. In order to increase this number, it is important to make sure that all the various aspects of ROCK are understood properly.] ROCK Development ---------------- saintjoe: With what is ROCK Linux developed? cvs? +daja77: cvs and subversion. +tcr: But cvs is bad. And svn is bad too. [Developers can never agree on a version control system.] dzafez_ConCode: What do the developers mostly do? Make packages, write documentation, build targets? +tcr: Now, before 2.0, bug-fixing. +chaosmaster: I can only speak for myself—I make patches, test things, polish things and maintain my own packages. +daja77: I tinker with my own target. dzafez_ConCode: If I, as a member of a project, want to maintain my code with you, can I? +chaosmaster: What do you mean? Everyone who wants to contribute is welcome—whether in terms of patches, documentation or a target... martin: How would I provide a patch for ROCK Linux? I see so many fly over the mailing list, but I don't see any documentation on how to do it. +Be-El: See Documentation/Developer/PATCHES. brainache: Is it true that ROCK comes from Austria? +n00kie: Clifford Wolf is the founder of ROCK Linux and he is from Austria. But ROCK is not Austrian, it is international. +chaosmaster: Correct, it is known and developed all over the world, apart from its strong presence in the western EU and in the USA. saintjoe: Is there a "core team" which must approve changes? +tcr: There is Clifford. +daja77: And there is René [stable tree maintainer]. +chaosmaster: No, it's the package maintainer for the packages, and Clifford for the scripts. +tsa: We do not have "release engineers" like FreeBSD, the individual package maintainer approves changes to their packages. +tcr: However, this organizational structure is the result of the “patch” method. With a proper RCS it would be different. dzafez_ConCode: I might want to insert 2 or 3 new packages. However I would rather try to define new targets. Like a Samba target and LAMP target. Also interesting would be a live-CD-ssh-x-terminal-client target... [Some other potential ROCK targets are mentioned in the ensuing discussion, including a WinServer, an Active Directory replacement, Red Hat clone, etc...] +n00kie: I don't think we should make so many targets. The whole point is to build your own target yourself. Live-CD is a good idea, by the way. But we already have so many, why make more? +chaosmaster: Because more will appear and we want them all. dzafez_ConCode: Yes, I have 100 other ideas for targets and would like ISOs of all of them to be available. +tcr: Exactly, that is the purpose of ROCK Linux! To make a distribution that can then be released independently of ROCK Linux. [Conclusion: ROCK welcomes contributions of all kinds, from work on documentation and the ROCK system itself, to new distributions built using ROCK.]