Dear developers of CentOS, I plan to create/start Desktop version/fork/respin of CentOS, practically just to add useful packages, modified repository with prioritized third-party repositories, maybe few tweaks, and built ISO and repositories, so we are not limited to messing with manually adding third-party repositories and dealing with dependency problems. Basic repositories will remain from CentOS project.
I plan to latter on ask about endorsement, maybe even hosting/mirroring project or even running it under the CentOS project flag. I will have to formulate my goals for the project and see how it resonates with you, developers of CentOS.
For the time being, to keep the ball rolling, I have question about the name that you find acceptable (even in the case that I can not find common ground with CentOS project and it remains on the sidelines):
1. CentDOS (Community Enterprize Desktop Operating System) 2. DentOS (Desktop Enterprize Operating System) 3. CentOS-DE (Community Enterprize Operating System - Desktop Edition) 4. Any new suggestion?
I personally and few other people like the first name, CentDOS.
On Fri, Jan 20, 2012 at 12:34 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
Dear developers of CentOS, I plan to create/start Desktop version/fork/respin of CentOS, practically just to add useful packages, modified repository with prioritized third-party repositories, maybe few tweaks, and built ISO and repositories, so we are not limited to messing with manually adding third-party repositories and dealing with dependency problems. Basic repositories will remain from CentOS project.
I plan to latter on ask about endorsement, maybe even hosting/mirroring project or even running it under the CentOS project flag. I will have to formulate my goals for the project and see how it resonates with you, developers of CentOS.
For the time being, to keep the ball rolling, I have question about the name that you find acceptable (even in the case that I can not find common ground with CentOS project and it remains on the sidelines):
- CentDOS (Community Enterprize Desktop Operating System)
- DentOS (Desktop Enterprize Operating System)
- CentOS-DE (Community Enterprize Operating System - Desktop Edition)
- Any new suggestion?
I personally and few other people like the first name, CentDOS.
-- Ljubomir Ljubojevic
"CentOS Desktop" would be sufficiently descriptive and not overly confusing. We already have issues (just by nature) with confusion on the different parallel generations (4, 5, 6). The fact that "CentOS" is an acronym should not be taken too seriously, as it easily stands on it's own as a word with a brand behind it.
"CentDOS" is too close to MS-DOS, which could be taken as some sort of free DOS replacement.
❧ Brian Mathis
On 01/20/2012 12:34 PM, Ljubomir Ljubojevic wrote:
Dear developers of CentOS, I plan to create/start Desktop version/fork/respin of CentOS, practically just to add useful packages, modified repository with prioritized third-party repositories, maybe few tweaks, and built ISO and repositories, so we are not limited to messing with manually adding third-party repositories and dealing with dependency problems. Basic repositories will remain from CentOS project.
I plan to latter on ask about endorsement, maybe even hosting/mirroring project or even running it under the CentOS project flag. I will have to formulate my goals for the project and see how it resonates with you, developers of CentOS.
For the time being, to keep the ball rolling, I have question about the name that you find acceptable (even in the case that I can not find common ground with CentOS project and it remains on the sidelines):
- CentDOS (Community Enterprize Desktop Operating System)
- DentOS (Desktop Enterprize Operating System)
- CentOS-DE (Community Enterprize Operating System - Desktop Edition)
- Any new suggestion?
I personally and few other people like the first name, CentDOS.
CentDOS has negative connotations, both with respect to MS-DOS, and Denial of Service. As well the td letter combination sounds a little clumsy.
CentOS - DE or CentOS Desktop would be perfectly acceptable, as long as the CentOS project itself was fine with you using their trademark.
You could also be a little adventurous and call it something entirely different, like Chocolate. (though that probably popped into my head because of Linux Mint).
Matt
--
Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe
Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/20/2012 06:53 PM, Matt Rose wrote:
You could also be a little adventurous and call it something entirely different, like Chocolate. (though that probably popped into my head because of Linux Mint).
I would like to stay as close as possible to CentOS name, because it practically is CentOS, with third-party repositories enabled. Intention is to provide easily installable packages from various repositories, but I have no desire to make it into developing distro, just a bunch of carefully chosen and above all as stable as possible packages sitting on top of the CentOS (with as little as possible replaced packages) that will attract Desktop users wanting stability above all, but not knowledgeable enough to decide what package from what repository they are to chose.
I have not made any decision yet about a name, and I am very well aware of negative implications some proposed names have, that is precisely why I asked for a fresh perspective and additional input. I did not want to put any ideas into your heads, but I have chosen instead to hear your original sentiment.
Problem with CentOS-DE I see is that it consists of two words when you say it, it would be better that it is one fluid word that clearly defines it in conversation.
On Fri, Jan 20, 2012 at 12:24 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
I would like to stay as close as possible to CentOS name, because it practically is CentOS, with third-party repositories enabled. Intention is to provide easily installable packages from various repositories, but I have no desire to make it into developing distro, just a bunch of carefully chosen and above all as stable as possible packages sitting on top of the CentOS (with as little as possible replaced packages) that will attract Desktop users wanting stability above all, but not knowledgeable enough to decide what package from what repository they are to chose.
Why bother spinning an install for that? A repository-release file and list of packages or group for yum should work on top of a standard install. I've always thought there should be some standard/easy way for anyone to publish a set suitable for some particular use, but I don't think it really exists.
On 01/20/2012 07:37 PM, Les Mikesell wrote:
On Fri, Jan 20, 2012 at 12:24 PM, Ljubomir Ljubojevicoffice@plnet.rs wrote:
I would like to stay as close as possible to CentOS name, because it practically is CentOS, with third-party repositories enabled. Intention is to provide easily installable packages from various repositories, but I have no desire to make it into developing distro, just a bunch of carefully chosen and above all as stable as possible packages sitting on top of the CentOS (with as little as possible replaced packages) that will attract Desktop users wanting stability above all, but not knowledgeable enough to decide what package from what repository they are to chose.
Why bother spinning an install for that? A repository-release file and list of packages or group for yum should work on top of a standard install. I've always thought there should be some standard/easy way for anyone to publish a set suitable for some particular use, but I don't think it really exists.
The problem is that regular CentOS .repo files, and .repo files of all third-party repositories have no concept of "priorities", so what must be done is to totally replace all .repo files, and I do not feel comfortable with calling such a move a minor one. Also, At least on repository must be more important then stock CentOS repositories, so overrides can be done.
My wish is to create LiveDVD, and even regular install ISO's with at least ElRepo driver packages, and those ISO's can not be called CentOS since CentOS brand = ~100% RHEL clone without any additions.
On Fri, Jan 20, 2012 at 10:56 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
My wish is to create LiveDVD, and even regular install ISO's with at least ElRepo driver packages,
You might remember this story:
http://dag.wieers.com/blog/centos-based-livecd-at-froscon
Akemi
On 01/20/2012 08:07 PM, Akemi Yagi wrote:
On Fri, Jan 20, 2012 at 10:56 AM, Ljubomir Ljubojevicoffice@plnet.rs wrote:
My wish is to create LiveDVD, and even regular install ISO's with at least ElRepo driver packages,
You might remember this story:
No, I was not aware of this. Even though I was building my own repo and packages at that time, I think I became more active on CentOS mailing list (and following more closely events) only after that time frame.
But that is exactly what I would like to see. I've created my own LiveCD for 5.3 2 months after that event with mdadm and LVM support, GParted, Krusader, mc, Skype (I think) and other packages so I have disaster recovery CD able to perform all desktop functions including communication and net surfing. I still carry it with me until I supersede it with 6.x version (but not replace it, for older PC's).
I see that this threatens to turn from name audition to discussion, So I offer following solution:
1. All of you think about what name would be acceptable for CentOS sponsored project (if such desire exists), and what would be acceptable for separate project (headed by me for example).
2. I will write the text, in next 7 days, that will embody my vision for CentOS based fork(s?), and then we can discuss it in detail. At the moment I have to answer about my envision without comprehensive overview, and it could become a very long thread.
Am 20.01.2012 um 19:56 schrieb Ljubomir Ljubojevic:
On 01/20/2012 07:37 PM, Les Mikesell wrote:
On Fri, Jan 20, 2012 at 12:24 PM, Ljubomir Ljubojevicoffice@plnet.rs wrote:
I would like to stay as close as possible to CentOS name, because it practically is CentOS, with third-party repositories enabled. Intention is to provide easily installable packages from various repositories, but I have no desire to make it into developing distro, just a bunch of carefully chosen and above all as stable as possible packages sitting on top of the CentOS (with as little as possible replaced packages) that will attract Desktop users wanting stability above all, but not knowledgeable enough to decide what package from what repository they are to chose.
Why bother spinning an install for that? A repository-release file and list of packages or group for yum should work on top of a standard install. I've always thought there should be some standard/easy way for anyone to publish a set suitable for some particular use, but I don't think it really exists.
The problem is that regular CentOS .repo files, and .repo files of all third-party repositories have no concept of "priorities", so what must be done is to totally replace all .repo files, and I do not feel comfortable with calling such a move a minor one. Also, At least on repository must be more important then stock CentOS repositories, so overrides can be done.
what do you think about a (meta) package? that provides "all" desktop-like add-ons. a rpm with "prioritized" repo files (3rd), post scripts to patch exiting base repo files, defined requires that force installation of additional "desktop" rpms (e.g. audio codecs) and so on (i known that the codec dependency can't be resolved if the repo files are not installed) ... would this address all your "desktop" needs? Or are there any packages that are not in one 3rd party software repository?
anyway - i like the core idea of a desktop version but what distinguish that one from the upstream client / workstation version (beside any 3rd party software repository).
-- LF
On 01/23/2012 12:02 AM, Leon Fauster wrote:
anyway - i like the core idea of a desktop version but what distinguish that one from the upstream client / workstation version (beside any 3rd party software repository).
All 3rd party repos have their own pace. RepoForge for instance does not care what happens in EPEL. I see a need for possible "override of certain packages in "master" repository for the "desktop distro" so upgrade and install paths are stable.
On Mon, 2012-01-23 at 15:36 +0100, Ljubomir Ljubojevic wrote:
All 3rd party repos have their own pace. RepoForge for instance does not care what happens in EPEL.
This is a misstatement.
"RepoForge does not have sufficient resources to deeply care about what happens in EPEL" would be somehow closer to the reality.
Having that said, this and other (organizational) issues are being worked on, albeit very slowly, resources permitting.
Dne 23.1.2012 15:36, Ljubomir Ljubojevic napsal(a):
All 3rd party repos have their own pace. RepoForge for instance does not care what happens in EPEL. I see a need for possible "override of certain packages in "master" repository for the "desktop distro" so upgrade and install paths are stable.
So, Epel does so? DH
On Mon, Jan 23, 2012 at 10:28 AM, David Hrbáč david-lists@hrbac.cz wrote:
Dne 23.1.2012 15:36, Ljubomir Ljubojevic napsal(a):
All 3rd party repos have their own pace. RepoForge for instance does not care what happens in EPEL. I see a need for possible "override of certain packages in "master" repository for the "desktop distro" so upgrade and install paths are stable.
So, Epel does so?
EPEL's policy is to not replace any upstream packages so there is generally no versioning issue if they are the only additional repo, although they only consider RHEL to be upstream, not centos plus or extras which would be from some perspectives. Sometimes there are good reasons for needing newer, not just additional packages, and sometimes things you need are introduced in some other repo before EPEL and a conflict arises when EPEL adds it or the versions leapfrog each other. I don't think there can ever be a general solution as long as policy restrictions keep things from being managed together.
On Mon, 2012-01-23 at 10:38 -0600, Les Mikesell wrote:
EPEL's policy is to not replace any upstream packages so there is generally no versioning issue if they are the only additional repo
There is much more than just that to it, read inconsistent package naming, "public" libraries residing together with the application in the same package and the list goes on.
On top of this there are things like packages compiled against libraries with different ABI versions etc., which very quickly gets messy once your package base becomes sufficiently large and you are mixing sources.
All of this can only be fully resolved by a substantial effort to keep repositories compatible, which in turn requires the resources that neither RF or EPEL have to spare.
There have been some efforts to keep the repositories "reasonably" compatible from both sides, but that's pretty much as far as you can get given current situation; it will never be perfect.
On Mon, Jan 23, 2012 at 10:50 AM, Yury V. Zaytsev yury@shurup.com wrote:
On Mon, 2012-01-23 at 10:38 -0600, Les Mikesell wrote:
EPEL's policy is to not replace any upstream packages so there is generally no versioning issue if they are the only additional repo
There is much more than just that to it, read inconsistent package naming, "public" libraries residing together with the application in the same package and the list goes on.
On top of this there are things like packages compiled against libraries with different ABI versions etc., which very quickly gets messy once your package base becomes sufficiently large and you are mixing sources.
All of this can only be fully resolved by a substantial effort to keep repositories compatible, which in turn requires the resources that neither RF or EPEL have to spare.
I think this misses the point that they can't be compatible for the common case where RF wants to have a newer version of something that in turn needs newer supporting libraries. No amount of resources can solve an inherent conflict when the distribution and packaging systems don't have a concept of having multiple versions installed concurrently.
There have been some efforts to keep the repositories "reasonably" compatible from both sides, but that's pretty much as far as you can get given current situation; it will never be perfect.
The design is just not there to permit it. Look at something as simple and frequently desired as running two different java applications under different jvm versions. The OS itself has no problem with that, but you can't get the packaging tools to deal with it.
On Mon, 2012-01-23 at 11:09 -0600, Les Mikesell wrote:
I think this misses the point that they can't be compatible for the common case where RF wants to have a newer version of something that in turn needs newer supporting libraries.
They certainly can, read libcompatXXX...
On Mon, Jan 23, 2012 at 11:13 AM, Yury V. Zaytsev yury@shurup.com wrote:
On Mon, 2012-01-23 at 11:09 -0600, Les Mikesell wrote:
I think this misses the point that they can't be compatible for the common case where RF wants to have a newer version of something that in turn needs newer supporting libraries.
They certainly can, read libcompatXXX...
Isn't that just for shared C libs? What about perl/python/java/php, etc. where the new app you want needs supporting versions of things that will break the older packages you want to keep?
On 01/23/2012 05:28 PM, David Hrbáč wrote:
Dne 23.1.2012 15:36, Ljubomir Ljubojevic napsal(a):
All 3rd party repos have their own pace. RepoForge for instance does not care what happens in EPEL. I see a need for possible "override of certain packages in "master" repository for the "desktop distro" so upgrade and install paths are stable.
So, Epel does so? DH
Yury and David, forgive me for not being thorough in my statement. I do not accuse RepoForge of anything, all of you guys there do your best and I appreciate it. Bad choice of words. And I especially should have limited this statement to audio/video codec subsistem (gstreamer particularly). My sincere apologies. But you have to concede that consequence for noob user is the same regardless of the cause.
I wanted to explain that with conflicts between aTrpms, RepoForge and EPEL (and others) regular user must have larger knowledge how to resolve those conflicts via yum commands.
I regard EPEL as second level repository (base/updates/centosplus/extras and ElRepo are first), RepoForge third level repository and aTrpms forth level repository (compiling/rebuilding environment issues and other stuff). That is why I singled out RepoForge and not some other repository.
On Mon, 23 Jan 2012, Ljubomir Ljubojevic wrote:
On 01/23/2012 05:28 PM, David Hrbáč wrote:
Dne 23.1.2012 15:36, Ljubomir Ljubojevic napsal(a):
particularly). My sincere apologies. But you have to concede that consequence for noob user is the same regardless of the cause.
question: What does all this have to do with CENTOS DEVELOPMENT ?
answer: nothing, but Ljubomir knows people here will answer
Take this elsewhere ... please, now ; main has been ruined with chat and OT chatter. I won't have it here
-- Russ herrold
On 01/20/2012 01:24 PM, Ljubomir Ljubojevic wrote:
On 01/20/2012 06:53 PM, Matt Rose wrote:
You could also be a little adventurous and call it something entirely different, like Chocolate. (though that probably popped into my head because of Linux Mint).
Problem with CentOS-DE I see is that it consists of two words when you say it, it would be better that it is one fluid word that clearly defines it in conversation.
DesCent? Slightly negative connotations, but I like the way it rolls off the tongue. If you wanted more association you could call it DesCentOS.
Matt
--
Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe
Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Fri, 20 Jan 2012, Ljubomir Ljubojevic wrote:
I would like to stay as close as possible to CentOS name, because it practically is CentOS, with third-party repositories enabled
You know, the CentOS project takes much care to avoid coming 'too close' to the trade marks of others ... It is just unfriendly not to respect that effort and history, and to consciously try to be 'as close as possible' to the mark of another
the proposed name form will cause brand confusion in the mind of un-careful readers who do not follow 'inside baseball' branding issues. It will result in 'load' coming to the CentOS support venues, rather than the place that shipped non-CentOS code. When the such confused souls do show up anyway in CentOS support venue, the load will fall on people other than your sub-project, Ljubomir. Is this just?
Please choose something else
my $0.02
-- Russ herrold
On 01/20/2012 07:56 PM, R P Herrold wrote:
On Fri, 20 Jan 2012, Ljubomir Ljubojevic wrote:
I would like to stay as close as possible to CentOS name, because it practically is CentOS, with third-party repositories enabled
You know, the CentOS project takes much care to avoid coming 'too close' to the trade marks of others ... It is just unfriendly not to respect that effort and history, and to consciously try to be 'as close as possible' to the mark of another
the proposed name form will cause brand confusion in the mind of un-careful readers who do not follow 'inside baseball' branding issues. It will result in 'load' coming to the CentOS support venues, rather than the place that shipped non-CentOS code. When the such confused souls do show up anyway in CentOS support venue, the load will fall on people other than your sub-project, Ljubomir. Is this just?
Please choose something else
Once again, THAT IS why I am asking here before I make any decision. My first impulse was CentDOS, but I chose to suppress it and come here and ask for projects opinion what is and what is not acceptable, and choose from acceptable ones.
Ljubomir Ljubojevic wrote on 01/20/2012 02:03 PM:
Once again, THAT IS why I am asking here before I make any decision. My first impulse was CentDOS, but I chose to suppress it and come here and ask for projects opinion what is and what is not acceptable, and choose from acceptable ones.
Seems like Russ is saying nothing close to CentOS, so the rest of the namespace is open to your imagination. Maybe LLOS? :-)
Personally I like your idea and think it would be a good contribution to the EL ecosystem. About time someone offered easy access to a "plus" spin with additional drivers, multimedia, and other applications. Much of the support load on the fora is from people trying to add such things.
Phil
I tried building a desktop spin, There is no software to make a spin, I tried using refracta, but failed to get it work or figure out how to port it over, I tried other methods but all failed,
I am now building a xfce 4.8 based system using debian squeeze, that is only 400mb iso, that will be out in a few months,
On Fri, Jan 20, 2012 at 7:02 PM, Phil Schaffner <Philip.R.Schaffner@nasa.gov
wrote:
Ljubomir Ljubojevic wrote on 01/20/2012 02:03 PM:
Once again, THAT IS why I am asking here before I make any decision. My first impulse was CentDOS, but I chose to suppress it and come here and ask for projects opinion what is and what is not acceptable, and choose from acceptable ones.
Seems like Russ is saying nothing close to CentOS, so the rest of the namespace is open to your imagination. Maybe LLOS? :-)
Personally I like your idea and think it would be a good contribution to the EL ecosystem. About time someone offered easy access to a "plus" spin with additional drivers, multimedia, and other applications. Much of the support load on the fora is from people trying to add such things.
Phil
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/21/2012 01:19 AM, lowlux wrote:
I tried building a desktop spin, There is no software to make a spin, I tried using refracta, but failed to get it work or figure out how to port it over, I tried other methods but all failed,
First part will be repo rpm for online conversion to "new OS", and virtual rpm's to install additional apps/packages. That is very close, first versions can be released in few days once I choose the name.
The next step would be to push LiveDVD ISO, which will not be a problem, I already have configs from official LiveDVD. This could be out in a week from decision about a name.
The problem will be with distribution, I do not have bandwidth to serve ISO downloads, but will provide torrents.
The third stage will be adding rpm's to existing ISO with changing the "index" files. Someone already posted a e-mail about it (centos-users ml I think).
Fedora
Ljubomir Ljubojevic wrote:
Dear developers of CentOS, I plan to create/start Desktop version/fork/respin of CentOS, practically just to add useful packages, modified repository with prioritized third-party repositories, maybe few tweaks, and built ISO and repositories, so we are not limited to messing with manually adding third-party repositories and dealing with dependency problems. Basic repositories will remain from CentOS project.
I plan to latter on ask about endorsement, maybe even hosting/mirroring project or even running it under the CentOS project flag. I will have to formulate my goals for the project and see how it resonates with you, developers of CentOS.
For the time being, to keep the ball rolling, I have question about the name that you find acceptable (even in the case that I can not find common ground with CentOS project and it remains on the sidelines):
- CentDOS (Community Enterprize Desktop Operating System)
- DentOS (Desktop Enterprize Operating System)
- CentOS-DE (Community Enterprize Operating System - Desktop Edition)
- Any new suggestion?
I personally and few other people like the first name, CentDOS.
On 01/21/2012 05:36 AM, Mike wrote:
Fedora
You said "Bugs" or "Perpetum restituo" (Constant reinstall) ?
You must not create desktop respin of CentOS as fork. You must create packages for CentOS, such as Atheros modules for kernel, updated licq (pidgin, kopete), applications such as yakuake, etc. And AFTER this you must create CD ISO. And... You can do the same thing, such as many package maintainers? Or your distribution have only changes with desktop wallpaper?
-----Исходное сообщение----- From: Ljubomir Ljubojevic Sent: Saturday, January 21, 2012 12:34 AM To: The CentOS developers mailing list. Subject: [CentOS-devel] What name would be acceptable for Desktop version ofCentOS?
Dear developers of CentOS, I plan to create/start Desktop version/fork/respin of CentOS, practically just to add useful packages, modified repository with prioritized third-party repositories, maybe few tweaks, and built ISO and repositories, so we are not limited to messing with manually adding third-party repositories and dealing with dependency problems. Basic repositories will remain from CentOS project.
I plan to latter on ask about endorsement, maybe even hosting/mirroring project or even running it under the CentOS project flag. I will have to formulate my goals for the project and see how it resonates with you, developers of CentOS.
For the time being, to keep the ball rolling, I have question about the name that you find acceptable (even in the case that I can not find common ground with CentOS project and it remains on the sidelines):
1. CentDOS (Community Enterprize Desktop Operating System) 2. DentOS (Desktop Enterprize Operating System) 3. CentOS-DE (Community Enterprize Operating System - Desktop Edition) 4. Any new suggestion?
I personally and few other people like the first name, CentDOS.
On 01/21/2012 07:00 AM, Коненко Андрей Викторович wrote:
You must not create desktop respin of CentOS as fork. You must create packages for CentOS, such as Atheros modules for kernel, updated licq (pidgin, kopete), applications such as yakuake, etc. And AFTER this you must create CD ISO. And... You can do the same thing, such as many package maintainers? Or your distribution have only changes with desktop wallpaper?
You will see what I mean when I am ready to publish it. I already have all packages that I need for my own CentOS Desktop in my repository, with complete and balanced .repo file(s). Just be patient.
P.S. I was hoping for help about the name from this thread, not concept criticism based on drafted text.
On Sun, Jan 22, 2012 at 3:31 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
P.S. I was hoping for help about the name from this thread, not concept criticism based on drafted text.
Desktop Enterprise Linux or Community Desktop Enterprise Linux, since one of the CentOS devs has already complained about trademark likeness and none of the others have stepped in to disagree.
On 01/23/2012 12:15 AM, Tom Sorensen wrote:
On Sun, Jan 22, 2012 at 3:31 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
P.S. I was hoping for help about the name from this thread, not concept criticism based on drafted text.
Desktop Enterprise Linux or Community Desktop Enterprise Linux, since one of the CentOS devs has already complained about trademark likeness and none of the others have stepped in to disagree.
Till such time as a package manifest is published, the name and content are a bit academic to discuss </opinion>
On 01/22/2012 06:26 PM, Karanbir Singh wrote:
On 01/23/2012 12:15 AM, Tom Sorensen wrote:
On Sun, Jan 22, 2012 at 3:31 PM, Ljubomir Ljubojevicoffice@plnet.rs wrote:
P.S. I was hoping for help about the name from this thread, not concept criticism based on drafted text.
Desktop Enterprise Linux or Community Desktop Enterprise Linux, since one of the CentOS devs has already complained about trademark likeness and none of the others have stepped in to disagree.
Till such time as a package manifest is published, the name and content are a bit academic to discuss</opinion>
OP stated right off, "practically just to add useful packages,"
So, the base of the "package manifest" is CentOS right from the start. I also concur with the thinking that OP is starting a new distro, With "distro" heavily defined by the resultant .repo files. Along those lines, I'd suggest "the name" (the key here, and subject to this thread) be completely non-CentOS oriented, *unless* .repo files are kept as shipped. OP also stated intent to "to totally replace all .repo files". In other words, the name should not be CentOS oriented in any way. That said, however, the CentOS connection should be *documented* well, along with the all aspects of the distro.
jerry
ps. I'd probably commit some time this, or similar, Desktop effort. After several years with a Fedora workstation at my work place, I switched to CentOS at the release of 6.0. Lets just say I owe my employer hundreds of hours back for the futile effort. :-( p.p.s. Now running EL 6 as my workstation has fun stuff (in KDE), yet very stable, and has virtual potential (with the right hardware). It's getting close to having a Mac or Windows PC. :-)
On 01/23/2012 03:43 AM, Jerry Amundson wrote:
Till such time as a package manifest is published, the name and content are a bit academic to discuss</opinion>
OP stated right off, "practically just to add useful packages," So, the base of the "package manifest" is CentOS right from the start.
its the ones that didnt come from CentOS Base that are most interesting- how many of them have legal/patent/re-distribution 'issues' or 'baggage as it were'. Where are these packages going to come from, how are they going to be maintained and patched, what level of assurances can be put into place that say that these bits will be maintained for a reasonable level of time...
Provided everything in the stack is opensource, re-distributable and have no baggage in the areas where we have a local presence, it could very well be a CentOS subproject. Retain name/branding and use the distribution network etc.
Also, as Russ already pointed out - we would need to make sure that the messaging around this are quite clear and dont dilute the distro / CentOS messaging. Wont be hard to do, just needs a bit of thinking and organising.
On 01/23/2012 11:31 AM, Karanbir Singh wrote:
On 01/23/2012 03:43 AM, Jerry Amundson wrote:
Till such time as a package manifest is published, the name and content are a bit academic to discuss</opinion>
OP stated right off, "practically just to add useful packages," So, the base of the "package manifest" is CentOS right from the start.
its the ones that didnt come from CentOS Base that are most interesting- how many of them have legal/patent/re-distribution 'issues' or 'baggage as it were'. Where are these packages going to come from, how are they going to be maintained and patched, what level of assurances can be put into place that say that these bits will be maintained for a reasonable level of time...
Provided everything in the stack is opensource, re-distributable and have no baggage in the areas where we have a local presence, it could very well be a CentOS subproject. Retain name/branding and use the distribution network etc.
Also, as Russ already pointed out - we would need to make sure that the messaging around this are quite clear and dont dilute the distro / CentOS messaging. Wont be hard to do, just needs a bit of thinking and organising.
As I previously said, I will prepare something by the end of the week.
On 01/23/2012 02:39 PM, Ljubomir Ljubojevic wrote:
its the ones that didnt come from CentOS Base that are most interesting-
...
As I previously said, I will prepare something by the end of the week.
Excellent. I would be glad to help with the centos side of things, should we all decide, and if its possible, to go down that route.
-
Akemi Yagi -
Brian Mathis -
David Hrbáč -
Jerry Amundson -
Karanbir Singh -
Leon Fauster -
Les Mikesell -
Ljubomir Ljubojevic -
lowlux -
Matt Rose -
Mike -
Phil Schaffner -
R P Herrold -
R P Herrold -
Tom Sorensen -
Yury V. Zaytsev -
Коненко Андрей Викторович