Please don't continue to support a packaging system that has fundamental flaws to it.
Please don't post ridiculous unfounded statements about technology you don't comprehend. If you want to discuss RPM from a technical point of view, do so, but don't just make untrue statements with neither evidence nor explanation attached.
Why are all the RPM based distros shipping with their own cobbled version of apt-get? Maybe it's the packaging concept is better than RPM.
We do not use apt. You really should try to know what you're talking about before you post. You'll look a lot less silly.
Why didn't Gentoo use RPM?
For the same reason they didn't use DEB/dpkg: Because they wanted a source-based packaging model similar to FreeBSD's ports system. It has nothing to do with either RPM or DEB except that neither fills that role.
Slackware still isn't RPM based and they are doing well enough thank you.
Clearly your definition of "doing well enough" differs quite a bit from mine.:-)
I'm getting a little tired of all these distros popping up every two weeks claiming to be the latest and greatest since sliced bread.
We claim nothing of the sort. We fill a specific role: a community-driven, RPM-based distribution that is not controlled by a company with a vested interest in not allowing it to compete with enterprise-class distributions.
I don't even thing the facade of community based means a whole lot these days.
If "community-based" means nothing to you, then by all means, use something else. But there are many for whom it has a significant meaning, and we exist for them.
Because RPM already won. It is the Linux standard. Period. Until that changes, arguing over package formats is simply political/religious and accomplishes nothing.
Nope. You're simply refusing to acknowledge my point and are instead attempting to make one of your own as a red herring to avoid conceding my point.
* Regular releases encourage developers to keep their code in a buildable, maintainable state.
Maybe, maybe not. I never said either way, and I'm not going to get into that discussion. I will, however, say that good developers keep their code that way without needing "encouragement."
* Regular releases - whether actually stable or not - give packagers an attractive target with which to create pacakges, and they have a reasonable expectation that packagers from other distros will build packages.
Mostly true.
* Regular releases, especially with packages for their distro's package manager, attract users to try it out, much more than saying "hey download this CVS snapshot and compile and install it" does.
Packages do that, with or without releases. And that's why we have packages for every major distro (including cAos/CentOS, Fedora, RH, Debian, and Gentoo).
In the general sense, more users means more feedback, and often more developer interest. Of course, as I said, more interest also means you have to deal with the clueless people that end up doing nothing but waste your time.
Right on all counts. There has been a significant amount of frustration in the past with the latter situation which may explain some things.
However, the bottom line is that, these days, for the average Linux user (and even above-average), E *is* nothing but eye candy. It's not usable in the sense that I feel like I could sit down and make it my primary desktop environment without annoyances.
E isn't targetted at the average Linux user. It's aimed at the power user. Always has been. That said, it is perfectly usable as a window manager.
Obviously, you feel differently - but I'd argue that the majority of people out there feel as I do. I dunno, maybe E needs a marketing department to get more exposure - if that's what the community wants, but I get the feeling that you guys just want to sit up in your castle, play with your toys, and pretend the rest of the world doesn't exist, while taking potshots at anyone who dares meddle with technology that's so old hat to you guys, you haven't made a *real* release of said technology after years of work.
If by "taking potshots" you mean "pointing out that the so-called revolutionary new ideas are neither revolutionary nor new," then you might have a point.
The problem is relevance. E is not relevant anymore.
You are entitled to your opinion, wrong though it may be.
Yes, people use it. Yes, it's being developed. But it's not relevant. GNOME and KDE are relevant because the developers are satisfied to make baby-step, *useful* improvements rather than sitting down and saying, "Ok, we have great ideas, but they're not too implementable/workable today. We'll take a break from actually being useful and toil for years on the next best thing." To put it another way, if GNOME used E's development model, the vast majority of GNOME users would all still be using GNOME 1.4 right now. (Or, more likely, they would have jumped ship to KDE.) Perhaps, when E17 is finally released, E will become relevant again - I certainly hope so, because it looks like you guys are doing a lot of (quiet) work to make a kickass desktop environment. But it appears that the GNOME and KDE folks have a much more mature understanding about how to run large-scale projects on reasonable timetables to produce useful software in a timely manner.
I'm beginning to see the fundamental problem with your logic. You are comparing GNOME and KDE, which are both complete desktop environments, to Enlightenment, which is nothing of the sort. Enlightenment is a window manager. Always has been. Its development has repeatedly necessitated core component libraries w
Why do you keep bringup up an unstable branch of Linux? Linux-2.5.157 certainly was NOT beyond alpha or beta.
Then you concede that your statement that "releases are indicators that the code has progressed beyond alpha, beyond beta" is erroneous. Releases are not indicators of the progression of anything. They are simply labels.
It was the unstable branch. But at least that branch didn't languish for years, but progressed steadily towards 2.6.
Go back and read the CVS logs. Nothing has "languished." Steady progress has been, and continues to be, made.
Prove me wrong! Release a stable E17 sometime this year!
Chances are very good that it will happen, but whether it does or not has no bearing on proving you right or wrong. You made statements which are not based in fact irrespective of E's release status.
Funny how you chose not to quote my entire sentence. The point being that the kernel development series is *not* different from E17 - except that the kernel devs provide periodic releases.
That's their choice, and entirely beside the point. The point is that just because something is deemed a "release" doesn't endow it with magical powers of stability. A release can be just as alpha-quality and buggy as a CVS snapshot and belief to the contrary is simply illusion.
Scoffers? Who's scoffing? The posts by Seth and Havoc were about new directions to take, not about putting down the work of others.
Again, you're missing the point. This isn't just about what they said most recently. It's about what has been said/done in the past. These guys and others have long scoffed at E for being nothing but eye candy, and now here they are saying the same things raster said years ago. I think he has a right to say "I told you so."
No, it seems more like raster's acting a bit smugly in a "See what we've been doing? Why haven't you noticed what we've been doing? You're proposing the same thing that we've been doing, and acting like it was your idea! Sheesh!" sort of way. My argument is that if the E devs were more a part of the Linux desktop development community, maybe we'd see some of these nifty things outside of E. The OSS world is about cooperation.
And cooperation is a 2-way street. We've never hidden what we're doing and why from anyone. We're not viewed as "part of the community" because we don't believe in the same things that the GNOME and KDE camps do. We have very different views on how things should be done. And that's perfectly okay.
If, as you say, the E community is happy with their place in the world, that's fine. But it's a bit hypocritical for raster to jump out and scoff at Seth's and Havoc's ideas when raster hasn't bothered to collaborate with any of them.
It's not hypocritical at all, and we HAVE tried to collaborate with them. You really have to understand the history here.
Even if it's true as you say that making a release of E17 would be nothing more than slapping a number on a CVS snapshot of a particular date, that really means quite a bit. It's an official release for packagers to target, and, presumably, somewhat stable. You can say that your CVS environment runs fine, but there's no guarantee that someone won't commit something new or experimental right before I check out *my* snapshot, which breaks the system. The point is that the random person who wants to try out E just won't know about these things without getting involved in the development process, which most people won't want to do.
You seem to be confused regarding the difference between Random Joe User taking a CVS snapshot vs. downloading a CVS snapshot from, say, http://www.code-monkey.de/e-snapshots/. Numerous packagers do that, or something similar, with great results. Myself included. (See previous posts for URL.)
I find it rather telling that you use the Linux 2.5 kernel series as an example. Note that 2.5 wasn't intended to be run by anyone but people interested in the new technology
And that's different from E 0.17...how, exactly? Oh, wait, it's not.
I don't think I need to point out that the Linux kernel is a very active project with many active contributors and corporate backing, largely because the project is organised so well, and - you guessed it - has a reasonable release schedule.
"Reasonable" is a highly subjective concept. And there have been several releases of the E libraries over the past few years.
E17 is... well, I really don't know. E has been pretty much off the radar for the past few years. And that's part of the problem too.
Maybe off your radar. Not everyone's.
Is release engineering easy? No. It takes effort to make a release. But I think E17 would attract a lot more testers if it were to put out a dev release every now and then. Of course, this also means that you have to deal with both ends of the spectrum - people that will provide good bug reports and be helpful in tracking down and fixing problems, as well as people who really shouldn't be trying out the software, and can't get it to compile because they don't have autoconf installed (or something inane like that). Bottom line: if the E community is happy with how things are going now (steady but slow development, not a lot of outside interest), then there's nothing that needs to change.
I don't think anyone in the E community is complaining about the way things have been. raster was just pointing out the irony that the scoffers are now talking wistfully about technology we offer today. And it works.
LOL! You really have no idea what you're talking about, do you?:) EWL did not even exist years ago, and calling something a "prototype" that you've clearly failed to research even slightly is at best misguided.
I doubt anyone would argue that, for example, linux-2.5.17 was beyond alpha or beta. Your assertions simply don't hold up in very notable cases, so applying them in general would be fallacious.
In fact, the only indication of truth in what you've said is that the project as a whole has not always done very well at Software Engineering. There are those of us who've noted that for years as a source of frustration. But things have improved dramatically this time around, and anyone who is actually paying attention knows that. Just ask the numerous developers (tilman, RbdPngn, HandyAndE, dj2, xcomp, and others).
That's what I would do too. But that's not really the point.
While you may have been trying to make the statement "coding free software does not doom you to a life of poverty," your diction was such that the resultant message received came across as, "no one who codes free software has an excuse for being poor because I'm not."
When was the last time you installed open source software that came with guarantees?
E 0.17 cannot mature without testing, and now you're telling me no one can test it because it's not mature? Interesting.
Now that the underlying libraries are maturing (stable API's, feature-complete with few or no known issues), work on the WM can progress rapidly. And unlike previous incarnations of E (and unlike most every other WM out there), E 0.17 itself will deal almost exclusively with managing windows; all the drawing/event loop/X socket/etc. nasties are handled already.
But not everyone is fortunate enough to have one of those jobs.
Compare the number of open source developers in the world with the number of those who write it for a living. Then compare that number to how many write open source software they want to write and get paid for it as a vocation.
So when is RedHat going to step up, Mr. Nitehorse, and hire all those other developers? Hmmm?
Had you actually bothered to read what was written and do some research, you'd know that Evas, Edje, and EWL do not in any way require the E 0.17.x window manager. I use them just fine, and I have never once run E 0.17.
But then, accuracy has never been the strong suit of the Anonymous Coward.:-)
It's a shame that you've lost faith, but your aim is off. CVS snapshots and such are a lot faster and require less overhead than putting together some bogus "release" that in reality is nothing more than a snapshot. The 2.5 Linux kernel series was exactly that: a bunch of snapshots made out to be releases. The only difference is the version number, and frankly it's not always worth the headache to call something 2.5.20 instead of 2.6.0-20050223.
The reality is that we have been talking about this stuff for years, and now we have much of it working. E 0.17.x notwithstanding, countless applications (engage, evidence, et al.) and even a widget set (EWL) are using these very concepts that the GNOME/KDE developers are just now realizing might be kinda spiffy.
Of course, Mac users were saying the same things in '95 about Windows, so if you think Windows "won," I'm sure you'll look at GNOME and KDE the same way. And we'll continue innovating like we always have and waiting for others to catch up.
Clearly this depends on your definition of "deliver." raster has been delivering for years and will continue to do so. Just because E lacks the huge user base of GNOME/KDE does not mean it doesn't deliver.
Or are you one of those folks who measures "better" in terms of total installed base? In which case, the cockroaches would like to know when you'll be vacating their planet. (Quote borrowed from Michael Paquette.)
I believe you have it backward, actually. CentOS is not self-hosting and does not change packages for the purpose of being such. I believe we have the smallest number of modified packages.
cAos Linux, on the other hand, is self-hosting. It is built entirely on itself. As I like to say, you can build the core from the core using nothing but the core. In fact, we do exactly that...and then we do it again! Every change to the core OS is regression tested to make sure it continues to be both self-hosting and self-sufficient.
There was some verbiage on the centos.org web site which could reasonably have been misinterpreted as an endorsement or a partnership between ourselves and Red Hat. As is their legal right and obligation, they notified us of the ambiguous wording, and we have (perhaps over-) corrected it.
The best advice I can give you is to make sure you have legal counsel.;-) Barring that, choose your words carefully so that even a brain dead chimp on Valium can tell how your project is, and is not, related to your upstream vendor.
From a personal standpoint, I have been down the road of doing my own distribution, and even armed with a good set of tools, it's a lot of work for one person. I encourage you to consider helping out with existing community efforts like CentOS and Tao rather than taking all that on your own shoulders. But if you choose to go it alone, I wish you the best of luck. And stock up on the caffeine; you'll need it.;-)
There's been a lot of heresay, misinterpretation, and speculation in this thread, and while I respect the right and responsibility of the community to speak their minds, I also encourage everyone to take a step back and really examine the situation from a more unbiased perspective. I think we've been trained by the various nay-sayers and scoffers over the years to react strongly and loudly to anything we perceive as a threat to us. Sometimes this is a good thing; I'm reminded of Bruce Perens very eloquently calling Michael Dell on the carpet at LWCE '99 for paying lip service to Linux while giving nothing at all back. But there's a big difference between poseurs and those companies that, at least for the most part, really do Get It, and I don't think we always take the time to see that.
The knee-jerk defensive reaction is only going to harm us down the road and gain us the closed-minded elitist reputation that has caused numerous "community" projects to fail. True community means seeing issues from others' points of view and not just our own. It also means realizing that mistakes will be made from time to time by everyone involved, be they individuals, projects, or even companies. And it means working together to resolve the issues in the best interests of all the community.
What it comes down to is this: We screwed up. We chose our words poorly, and we were called on it. And we can't promise we won't screw up again. But we're going to try not to make the same mistake twice, and we hope other community projects might learn from our mistakes.
I would like to clarify the position of the cAos Foundation, of which CentOS is a project, on the web site matter.
First, I'll refer to the following summary (taken from this post):
First let me say that I appreciate your feedback and your candor. Your comments are well received.
However, the situation as it currently stands is that we do not have legal counsel to advise us on what we can or cannot say on our web site, nor do we have the financial resources to pay for such. Furthermore, RedHat is required by law to protect their trademarks or risk losing them, and they do have valid concerns about trademark dilution.
RedHat has always been very generous with their code and open with their processes and resources. I would point out that their primary competition in the commercial RPM-based distribution space is not nearly as generous or cooperative. While we may not agree with everything they have said, we have an obligation to respect their trademarks and their role in helping to create what we are and what CentOS is.
The bottom line is this: The references to Red Hat and any other marks they own MUST be removed from the web site and will remain so indefinitely. We want to be clear about what CentOS is and what it offers, but until we can secure legal counsel to help us balance our interests with those of RedHat and other companies in this space, we must err on the side of caution. That means if we're not sure we can say it, we don't say it.
This course of action, while perhaps not the ideal solution from a purely Libertarian point of view, is correct and in the best interests of the project and the community at this time. We gain nothing by hurting, diluting, or pissing off RedHat, nor would we want to. And we certainly gain nothing turning this into a big legal fiasco.
Please understand that this is right and necessary at this point in time, and support Donavan and the rest of the CentOS team in following through on what we've asked of them.
Second, I want to reiterate that the RH legal team has been extremely patient and helpful. They pointed out a number of legitimate concerns, and we continue to work with them to make sure our web site is in compliance with their trademark usage policies.
Third, as we (and our projects) continue to grow and develop, we will be in need of legal counsel. If you are willing to provide pro bono legal advice to the Foundation and its member projects, please contact us (legal ~a~t~ caosity ~d~o~t~ org).
And finally, I would like to point out that projects like CentOS could not exist without the continued support of RedHat, and we thank them for their continued efforts to find the right balance between running a for-profit business and helping the non-profit community.
As you might imagine, our single-CPU web server is taking quite a beating at the moment. We took the site down briefly to tune some things, and it's back up for the moment, but we're working with several potential resources to post static copies of the linked pages in case the situation worsens again.
You never sent it to me. I have every e-mail we exchanged. The first was October 14th, 2001, in which you asked if it would be possible to have UTF-8 support in a future Eterm version. The last of the 6 e-mails was March 3rd, 2003, asking me to post CVS instructions on eterm.org. Only the first two dealt with UTF-8, and neither contained a patch.
Slashdot Mirror
Given that we're not based on anything, I fail to see the relevance of your comment WRT our distribution.
Please don't continue to support a packaging system that has fundamental flaws to it.
:-)
Please don't post ridiculous unfounded statements about technology you don't comprehend. If you want to discuss RPM from a technical point of view, do so, but don't just make untrue statements with neither evidence nor explanation attached.
Why are all the RPM based distros shipping with their own cobbled version of apt-get? Maybe it's the packaging concept is better than RPM.
We do not use apt. You really should try to know what you're talking about before you post. You'll look a lot less silly.
Why didn't Gentoo use RPM?
For the same reason they didn't use DEB/dpkg: Because they wanted a source-based packaging model similar to FreeBSD's ports system. It has nothing to do with either RPM or DEB except that neither fills that role.
Slackware still isn't RPM based and they are doing well enough thank you.
Clearly your definition of "doing well enough" differs quite a bit from mine.
I'm getting a little tired of all these distros popping up every two weeks claiming to be the latest and greatest since sliced bread.
We claim nothing of the sort. We fill a specific role: a community-driven, RPM-based distribution that is not controlled by a company with a vested interest in not allowing it to compete with enterprise-class distributions.
I don't even thing the facade of community based means a whole lot these days.
If "community-based" means nothing to you, then by all means, use something else. But there are many for whom it has a significant meaning, and we exist for them.
One, stop trolling. Two, somebody needs to mod this troll down.
c id=12547628
Three, read this: http://linux.slashdot.org/comments.pl?sid=149694&
Four, what makes DEB's "just work" is policy, not technology. An RPM-based distribution with as anal a policy as Debian's would "just work" too.
Because RPM already won. It is the Linux standard. Period. Until that changes, arguing over package formats is simply political/religious and accomplishes nothing.
You're missing the point again.
Nope. You're simply refusing to acknowledge my point and are instead attempting to make one of your own as a red herring to avoid conceding my point.
* Regular releases encourage developers to keep their code in a buildable, maintainable state.
Maybe, maybe not. I never said either way, and I'm not going to get into that discussion. I will, however, say that good developers keep their code that way without needing "encouragement."
* Regular releases - whether actually stable or not - give packagers an attractive target with which to create pacakges, and they have a reasonable expectation that packagers from other distros will build packages.
Mostly true.
* Regular releases, especially with packages for their distro's package manager, attract users to try it out, much more than saying "hey download this CVS snapshot and compile and install it" does.
Packages do that, with or without releases. And that's why we have packages for every major distro (including cAos/CentOS, Fedora, RH, Debian, and Gentoo).
In the general sense, more users means more feedback, and often more developer interest. Of course, as I said, more interest also means you have to deal with the clueless people that end up doing nothing but waste your time.
Right on all counts. There has been a significant amount of frustration in the past with the latter situation which may explain some things.
However, the bottom line is that, these days, for the average Linux user (and even above-average), E *is* nothing but eye candy. It's not usable in the sense that I feel like I could sit down and make it my primary desktop environment without annoyances.
E isn't targetted at the average Linux user. It's aimed at the power user. Always has been. That said, it is perfectly usable as a window manager.
Obviously, you feel differently - but I'd argue that the majority of people out there feel as I do. I dunno, maybe E needs a marketing department to get more exposure - if that's what the community wants, but I get the feeling that you guys just want to sit up in your castle, play with your toys, and pretend the rest of the world doesn't exist, while taking potshots at anyone who dares meddle with technology that's so old hat to you guys, you haven't made a *real* release of said technology after years of work.
If by "taking potshots" you mean "pointing out that the so-called revolutionary new ideas are neither revolutionary nor new," then you might have a point.
The problem is relevance. E is not relevant anymore.
You are entitled to your opinion, wrong though it may be.
Yes, people use it. Yes, it's being developed. But it's not relevant. GNOME and KDE are relevant because the developers are satisfied to make baby-step, *useful* improvements rather than sitting down and saying, "Ok, we have great ideas, but they're not too implementable/workable today. We'll take a break from actually being useful and toil for years on the next best thing." To put it another way, if GNOME used E's development model, the vast majority of GNOME users would all still be using GNOME 1.4 right now. (Or, more likely, they would have jumped ship to KDE.) Perhaps, when E17 is finally released, E will become relevant again - I certainly hope so, because it looks like you guys are doing a lot of (quiet) work to make a kickass desktop environment. But it appears that the GNOME and KDE folks have a much more mature understanding about how to run large-scale projects on reasonable timetables to produce useful software in a timely manner.
I'm beginning to see the fundamental problem with your logic. You are comparing GNOME and KDE, which are both complete desktop environments, to Enlightenment, which is nothing of the sort. Enlightenment is a window manager. Always has been. Its development has repeatedly necessitated core component libraries w
They are not pipes. They are similar, but they are not the same.
Then you missed the point.
With a "release" people can expect that:
This theory falls apart more often than you might think.
People will actually download and use your software!
They already do. The sources, RPM's, SRPM's, and DEB's are there for anyone who wants to give them a try.
Why do you keep bringup up an unstable branch of Linux? Linux-2.5.157 certainly was NOT beyond alpha or beta.
Then you concede that your statement that "releases are indicators that the code has progressed beyond alpha, beyond beta" is erroneous. Releases are not indicators of the progression of anything. They are simply labels.
It was the unstable branch. But at least that branch didn't languish for years, but progressed steadily towards 2.6.
Go back and read the CVS logs. Nothing has "languished." Steady progress has been, and continues to be, made.
Prove me wrong! Release a stable E17 sometime this year!
Chances are very good that it will happen, but whether it does or not has no bearing on proving you right or wrong. You made statements which are not based in fact irrespective of E's release status.
Funny how you chose not to quote my entire sentence. The point being that the kernel development series is *not* different from E17 - except that the kernel devs provide periodic releases.
That's their choice, and entirely beside the point. The point is that just because something is deemed a "release" doesn't endow it with magical powers of stability. A release can be just as alpha-quality and buggy as a CVS snapshot and belief to the contrary is simply illusion.
Scoffers? Who's scoffing? The posts by Seth and Havoc were about new directions to take, not about putting down the work of others.
Again, you're missing the point. This isn't just about what they said most recently. It's about what has been said/done in the past. These guys and others have long scoffed at E for being nothing but eye candy, and now here they are saying the same things raster said years ago. I think he has a right to say "I told you so."
No, it seems more like raster's acting a bit smugly in a "See what we've been doing? Why haven't you noticed what we've been doing? You're proposing the same thing that we've been doing, and acting like it was your idea! Sheesh!" sort of way. My argument is that if the E devs were more a part of the Linux desktop development community, maybe we'd see some of these nifty things outside of E. The OSS world is about cooperation.
And cooperation is a 2-way street. We've never hidden what we're doing and why from anyone. We're not viewed as "part of the community" because we don't believe in the same things that the GNOME and KDE camps do. We have very different views on how things should be done. And that's perfectly okay.
If, as you say, the E community is happy with their place in the world, that's fine. But it's a bit hypocritical for raster to jump out and scoff at Seth's and Havoc's ideas when raster hasn't bothered to collaborate with any of them.
It's not hypocritical at all, and we HAVE tried to collaborate with them. You really have to understand the history here.
Even if it's true as you say that making a release of E17 would be nothing more than slapping a number on a CVS snapshot of a particular date, that really means quite a bit. It's an official release for packagers to target, and, presumably, somewhat stable. You can say that your CVS environment runs fine, but there's no guarantee that someone won't commit something new or experimental right before I check out *my* snapshot, which breaks the system. The point is that the random person who wants to try out E just won't know about these things without getting involved in the development process, which most people won't want to do.
You seem to be confused regarding the difference between Random Joe User taking a CVS snapshot vs. downloading a CVS snapshot from, say, http://www.code-monkey.de/e-snapshots/. Numerous packagers do that, or something similar, with great results. Myself included. (See previous posts for URL.)
I find it rather telling that you use the Linux 2.5 kernel series as an example. Note that 2.5 wasn't intended to be run by anyone but people interested in the new technology
And that's different from E 0.17...how, exactly? Oh, wait, it's not.
I don't think I need to point out that the Linux kernel is a very active project with many active contributors and corporate backing, largely because the project is organised so well, and - you guessed it - has a reasonable release schedule.
"Reasonable" is a highly subjective concept. And there have been several releases of the E libraries over the past few years.
E17 is... well, I really don't know. E has been pretty much off the radar for the past few years. And that's part of the problem too.
Maybe off your radar. Not everyone's.
Is release engineering easy? No. It takes effort to make a release. But I think E17 would attract a lot more testers if it were to put out a dev release every now and then. Of course, this also means that you have to deal with both ends of the spectrum - people that will provide good bug reports and be helpful in tracking down and fixing problems, as well as people who really shouldn't be trying out the software, and can't get it to compile because they don't have autoconf installed (or something inane like that). Bottom line: if the E community is happy with how things are going now (steady but slow development, not a lot of outside interest), then there's nothing that needs to change.
I don't think anyone in the E community is complaining about the way things have been. raster was just pointing out the irony that the scoffers are now talking wistfully about technology we offer today. And it works.
LOL! You really have no idea what you're talking about, do you? :) EWL did not even exist years ago, and calling something a "prototype" that you've clearly failed to research even slightly is at best misguided.
I doubt anyone would argue that, for example, linux-2.5.17 was beyond alpha or beta. Your assertions simply don't hold up in very notable cases, so applying them in general would be fallacious.
In fact, the only indication of truth in what you've said is that the project as a whole has not always done very well at Software Engineering. There are those of us who've noted that for years as a source of frustration. But things have improved dramatically this time around, and anyone who is actually paying attention knows that. Just ask the numerous developers (tilman, RbdPngn, HandyAndE, dj2, xcomp, and others).
That's what I would do too. But that's not really the point.
While you may have been trying to make the statement "coding free software does not doom you to a life of poverty," your diction was such that the resultant message received came across as, "no one who codes free software has an excuse for being poor because I'm not."
When was the last time you installed open source software that came with guarantees?
E 0.17 cannot mature without testing, and now you're telling me no one can test it because it's not mature? Interesting.
Now that the underlying libraries are maturing (stable API's, feature-complete with few or no known issues), work on the WM can progress rapidly. And unlike previous incarnations of E (and unlike most every other WM out there), E 0.17 itself will deal almost exclusively with managing windows; all the drawing/event loop/X socket/etc. nasties are handled already.
But not everyone is fortunate enough to have one of those jobs.
Compare the number of open source developers in the world with the number of those who write it for a living. Then compare that number to how many write open source software they want to write and get paid for it as a vocation.
So when is RedHat going to step up, Mr. Nitehorse, and hire all those other developers? Hmmm?
We eagerly await your call.
Actually. It. is. Network-based.
It uses a UNIX-domain socket, not a pipe. I suggest you consult "man 7 unix".
You can get RPM's and SRPM's for all the EFL stuff (though not quite yet E 0.17 itself) here:
r /
http://caos.oregonstate.edu/cAos-2/ext/autobuilde
Or at any of our other mirrors.
Had you actually bothered to read what was written and do some research, you'd know that Evas, Edje, and EWL do not in any way require the E 0.17.x window manager. I use them just fine, and I have never once run E 0.17.
:-)
But then, accuracy has never been the strong suit of the Anonymous Coward.
It's a shame that you've lost faith, but your aim is off. CVS snapshots and such are a lot faster and require less overhead than putting together some bogus "release" that in reality is nothing more than a snapshot. The 2.5 Linux kernel series was exactly that: a bunch of snapshots made out to be releases. The only difference is the version number, and frankly it's not always worth the headache to call something 2.5.20 instead of 2.6.0-20050223.
The reality is that we have been talking about this stuff for years, and now we have much of it working. E 0.17.x notwithstanding, countless applications (engage, evidence, et al.) and even a widget set (EWL) are using these very concepts that the GNOME/KDE developers are just now realizing might be kinda spiffy.
Of course, Mac users were saying the same things in '95 about Windows, so if you think Windows "won," I'm sure you'll look at GNOME and KDE the same way. And we'll continue innovating like we always have and waiting for others to catch up.
Clearly this depends on your definition of "deliver." raster has been delivering for years and will continue to do so. Just because E lacks the huge user base of GNOME/KDE does not mean it doesn't deliver.
Or are you one of those folks who measures "better" in terms of total installed base? In which case, the cockroaches would like to know when you'll be vacating their planet. (Quote borrowed from Michael Paquette.)
because the lawyers like to think that they have someone to sue if catastrophe strikes.
How many viruses have been a direct result of programming mistakes Microsoft made?
How many companies have suffered losses in the millions because of these vulnerabilities?
Of those companies, how many have filed lawsuits against Microsoft? Not won, mind you. Just filed.
Are your lawyers really ready to step up to the plate?
I believe you have it backward, actually. CentOS is not self-hosting and does not change packages for the purpose of being such. I believe we have the smallest number of modified packages.
cAos Linux, on the other hand, is self-hosting. It is built entirely on itself. As I like to say, you can build the core from the core using nothing but the core. In fact, we do exactly that...and then we do it again! Every change to the core OS is regression tested to make sure it continues to be both self-hosting and self-sufficient.
There was some verbiage on the centos.org web site which could reasonably have been misinterpreted as an endorsement or a partnership between ourselves and Red Hat. As is their legal right and obligation, they notified us of the ambiguous wording, and we have (perhaps over-) corrected it.
;-) Barring that, choose your words carefully so that even a brain dead chimp on Valium can tell how your project is, and is not, related to your upstream vendor.
;-)
The best advice I can give you is to make sure you have legal counsel.
From a personal standpoint, I have been down the road of doing my own distribution, and even armed with a good set of tools, it's a lot of work for one person. I encourage you to consider helping out with existing community efforts like CentOS and Tao rather than taking all that on your own shoulders. But if you choose to go it alone, I wish you the best of luck. And stock up on the caffeine; you'll need it.
There's been a lot of heresay, misinterpretation, and speculation in this thread, and while I respect the right and responsibility of the community to speak their minds, I also encourage everyone to take a step back and really examine the situation from a more unbiased perspective. I think we've been trained by the various nay-sayers and scoffers over the years to react strongly and loudly to anything we perceive as a threat to us. Sometimes this is a good thing; I'm reminded of Bruce Perens very eloquently calling Michael Dell on the carpet at LWCE '99 for paying lip service to Linux while giving nothing at all back. But there's a big difference between poseurs and those companies that, at least for the most part, really do Get It, and I don't think we always take the time to see that.
The knee-jerk defensive reaction is only going to harm us down the road and gain us the closed-minded elitist reputation that has caused numerous "community" projects to fail. True community means seeing issues from others' points of view and not just our own. It also means realizing that mistakes will be made from time to time by everyone involved, be they individuals, projects, or even companies. And it means working together to resolve the issues in the best interests of all the community.
What it comes down to is this: We screwed up. We chose our words poorly, and we were called on it. And we can't promise we won't screw up again. But we're going to try not to make the same mistake twice, and we hope other community projects might learn from our mistakes.
I would like to clarify the position of the cAos Foundation, of which CentOS is a project, on the web site matter.
First, I'll refer to the following summary (taken from this post):
First let me say that I appreciate your feedback and your candor.
Your comments are well received.
However, the situation as it currently stands is that we do not have
legal counsel to advise us on what we can or cannot say on our web
site, nor do we have the financial resources to pay for such.
Furthermore, RedHat is required by law to protect their trademarks or
risk losing them, and they do have valid concerns about trademark
dilution.
RedHat has always been very generous with their code and open with
their processes and resources. I would point out that their primary
competition in the commercial RPM-based distribution space is not
nearly as generous or cooperative. While we may not agree with
everything they have said, we have an obligation to respect their
trademarks and their role in helping to create what we are and what
CentOS is.
The bottom line is this: The references to Red Hat and any other
marks they own MUST be removed from the web site and will remain so
indefinitely. We want to be clear about what CentOS is and what it
offers, but until we can secure legal counsel to help us balance our
interests with those of RedHat and other companies in this space, we
must err on the side of caution. That means if we're not sure we can
say it, we don't say it.
This course of action, while perhaps not the ideal solution from a
purely Libertarian point of view, is correct and in the best interests
of the project and the community at this time. We gain nothing by
hurting, diluting, or pissing off RedHat, nor would we want to. And
we certainly gain nothing turning this into a big legal fiasco.
Please understand that this is right and necessary at this point in
time, and support Donavan and the rest of the CentOS team in following
through on what we've asked of them.
Second, I want to reiterate that the RH legal team has been extremely patient and helpful. They pointed out a number of legitimate concerns, and we continue to work with them to make sure our web site is in compliance with their trademark usage policies.
Third, as we (and our projects) continue to grow and develop, we will be in need of legal counsel. If you are willing to provide pro bono legal advice to the Foundation and its member projects, please contact us (legal ~a~t~ caosity ~d~o~t~ org).
And finally, I would like to point out that projects like CentOS could not exist without the continued support of RedHat, and we thank them for their continued efforts to find the right balance between running a for-profit business and helping the non-profit community.
Regards,
Michael Jennings
The cAos Foundation
As you might imagine, our single-CPU web server is taking quite a beating at the moment. We took the site down briefly to tune some things, and it's back up for the moment, but we're working with several potential resources to post static copies of the linked pages in case the situation worsens again.
Please bear with us.
Michael Jennings
Technical Lead, cAos Linux
The cAos Foundation (http://www.caosity.org/)
You never sent it to me. I have every e-mail we exchanged. The first was October 14th, 2001, in which you asked if it would be possible to have UTF-8 support in a future Eterm version. The last of the 6 e-mails was March 3rd, 2003, asking me to post CVS instructions on eterm.org. Only the first two dealt with UTF-8, and neither contained a patch.