Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:28 -0400, Matthew Miller wrote:
Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes:
Fedora Server
HAHAHAHAHAHAHAHAHAHAHAHAHAHAH -sv
On 08/30/2010 10:29 AM, seth vidal wrote:
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:28 -0400, Matthew Miller wrote:
Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes:
Fedora Server
HAHAHAHAHAHAHAHAHAHAHAHAHAHAH -sv
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
<quietly hides his own infrastructure from sv's view>
-J
On Mon, 2010-08-30 at 12:11 -0500, Jon Ciesla wrote:
On 08/30/2010 10:29 AM, seth vidal wrote:
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:28 -0400, Matthew Miller wrote:
Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes:
Fedora Server
HAHAHAHAHAHAHAHAHAHAHAHAHAHAH -sv
<quietly hides his own infrastructure from sv's view>
hey, if you want to keep it updated, I think that's fine - however I am far too lazy to keep up with that.
-sv
On 08/30/2010 12:15 PM, seth vidal wrote:
On Mon, 2010-08-30 at 12:11 -0500, Jon Ciesla wrote:
On 08/30/2010 10:29 AM, seth vidal wrote:
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:28 -0400, Matthew Miller wrote:
Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes:
Fedora Server
HAHAHAHAHAHAHAHAHAHAHAHAHAHAH -sv
<quietly hides his own infrastructure from sv's view>
hey, if you want to keep it updated, I think that's fine - however I am far too lazy to keep up with that.
-sv
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
Nope. Too busy. Not, ironically, because I run servers on Fedora. Just personal and work stuff.
-J
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:28 -0400, Matthew Miller wrote:
Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes:
Fedora Server
And isn't that sad? I just subscribed to this group last week, but it seems pretty dead. So, what's happening? Is anything happening?
Jon.
On Mon, 2010-08-30 at 14:58 -0400, Jon Masters wrote:
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:29 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 11:28 -0400, Matthew Miller wrote:
Hello? Is this thing on?
It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes:
Fedora Server
And isn't that sad? I just subscribed to this group last week, but it seems pretty dead. So, what's happening? Is anything happening?
without a change in the support timeframe I suspect nothing will happen.
-sv
On Mon, 2010-08-30 at 15:09 -0400, seth vidal wrote:
On Mon, 2010-08-30 at 14:58 -0400, Jon Masters wrote:
And isn't that sad? I just subscribed to this group last week, but it seems pretty dead. So, what's happening? Is anything happening?
without a change in the support timeframe I suspect nothing will happen.
Right. But don't you think this group could at least come up with a list of proposals, or even one proposal? It could include a longer support timeframe, but also detail how Fedora is not friendly to Server today.
I looked over the wiki, excuse me if I missed this already. But if not, let's get something going that we can take to the wider audience.
Jon.
On Mon, 2010-08-30 at 15:13 -0400, Jon Masters wrote:
Right. But don't you think this group could at least come up with a list of proposals, or even one proposal? It could include a longer support timeframe, but also detail how Fedora is not friendly to Server today.
It needs a longer support lifetime and/or a slower update rate.
I think that's really all.
-sv
On 08/30/2010 09:27 PM, seth vidal wrote:
On Mon, 2010-08-30 at 15:13 -0400, Jon Masters wrote:
Right. But don't you think this group could at least come up with a list of proposals, or even one proposal? It could include a longer support timeframe, but also detail how Fedora is not friendly to Server today.
It needs a longer support lifetime and/or a slower update rate.
I think that's really all.
-sv
Hi all, longer support should be great. I thing that updates generally doesn't bring problems, only the one which changes API or brings regressions. For example the problem on Web servers is that half of the users demand new features like new PHP, new MySQL, but the other half doesn't want to repair their broken stuff. Maybe something like OpenVZ or Virtual machines should be the solution, but it still doesn't solve the problem that CentOS uses some very old components and Fedora is changing them too quickly.
sHINOBI
On 08/30/2010 03:27 PM, seth vidal wrote:
On Mon, 2010-08-30 at 15:13 -0400, Jon Masters wrote:
Right. But don't you think this group could at least come up with a list of proposals, or even one proposal? It could include a longer support timeframe, but also detail how Fedora is not friendly to Server today.
It needs a longer support lifetime and/or a slower update rate.
I think that's really all.
Nope, it needs:
1. To escape being put together by people that don't seem to understand that server people have to maintain more than one OS version.
2. To escape RPM hell. I wonder if you still need to install Perl to get PHP?
3. People on the IRC that aren't nazis.
4. To actually work. I'm on problem #15 with a straight F13 install. Of those, only one has been operator error.
5. And yeah, a longer support life.
Leam
On Mon, 2010-08-30 at 16:49 -0400, Leam Hall wrote:
Nope, it needs:
- To escape being put together by people that don't seem to understand
that server people have to maintain more than one OS version.
not sure I understand this one.
- To escape RPM hell. I wonder if you still need to install Perl to get
PHP?
that's not what RPM hell means - but your issue is with the deps not being constrained as much, I assume.
- People on the IRC that aren't nazis.
godwin's law so early? :)
- To actually work. I'm on problem #15 with a straight F13 install. Of
those, only one has been operator error.
do you have your list of those?
-sv
On 08/30/2010 04:52 PM, seth vidal wrote:
On Mon, 2010-08-30 at 16:49 -0400, Leam Hall wrote:
Nope, it needs:
- To escape being put together by people that don't seem to understand
that server people have to maintain more than one OS version.
not sure I understand this one.
"info" pages vs "man" Changing the -l option to mean something other than "--one-file-system" Using UIDs in /etc/fstab vice /dev/sdX --although this one either seems fixed or I already "fixed" it manually. Network Manager whacking /etc/resolv.conf. --Actually, it took me a year to find one decent use for Network Manager SElinux and iptables on by default. Both are useful but I've yet to see someone actually fully use them in a production environment.
- To escape RPM hell. I wonder if you still need to install Perl to get
PHP?
that's not what RPM hell means - but your issue is with the deps not being constrained as much, I assume.
RPM Hell to me is having to install several dozens of unrelated packages for one thing I want. I realize there's more than one level of this particular hell. Thanks for what you've done to ease the pain.
- People on the IRC that aren't nazis.
godwin's law so early? :)
Adolph's boys jumped into a bad stereotype. Godwin's wrong; Nazi is not an issue but what the term communicates is fairly common across a lot of cultures and is much shorter than "anal-retentive pinheads".
So a whlie back I'm on IRC and some bozo who seems to think they run the channel threatens to boot me because I found an answer to someone's issue on the Ubuntu forum and mentioned it.
- To actually work. I'm on problem #15 with a straight F13 install. Of
those, only one has been operator error.
do you have your list of those?
Not all, but here's some. It took me three or four days to do an install. Part of me wants to re-do the install from scratch and see if there were more op errs. Part of me is so tired of this Ubuntu is looking very nice.
1. Install nfs-utils to be able to mount NFSv4 filesystems. Problems with rpc.lockd that takes a reboot. https://bugzilla.redhat.com/show_bug.cgi?id=514427
2. Installing a Window Manager does not install other stuff required to run X. Sort of the backwards image of rpm deps. https://bugzilla.redhat.com/show_bug.cgi?id=624890
3. Gnome panel requires evolution-server.
4. dd based directions to create a USB stick don't work.
5. Directions to use the program to write a USB stick, the name of the program frustratingly escapes me at the moment, require Fedora and several packages to run. Not good when the Fedora install you were doing failed after wiping out the Fedora install you used to use.
6. User added in /etc/passwd. Logging in the WM is fine, the usual desktop stuff is there. Opening a terminal drops me in "/" as it can't read my home directory in /etc/passwd? Even running: cd `grep <me> /etc/passwd | awk -F":" '{ print $6 }'` drops me in the right place but opening a terminal does not. Haven't logged a bug on that one yet.
7. Installing on my IBM T30 in a docking station fails to utilize the entire external screen when I finally do get X installed. I can't remember how I fixed that one but it sort of works now. In return, booting into init 3 only uses part of the screen.
Those are the ones off the top of my head.
Leam
On 08/30/2010 04:52 PM, seth vidal wrote:
On Mon, 2010-08-30 at 16:49 -0400, Leam Hall wrote:
Nope, it needs:
- To escape being put together by people that don't seem to understand
that server people have to maintain more than one OS version.
not sure I understand this one.
Great...I try to get to sleep and my mind keeps chasing the Fedora-Server vapor...
What I mean is that there are cross-platform Unix-isms. Diverging from those makes it harder to support a heterogenous environment. If Fedora were simply a Desktop OS then going off into the blue with Fedora-isms is fine. However, as Fedora feeds RHEL I'm mildly confused about how the balance between Desktop and Sever got so skewed.
Correcting that imbalance would do a couple things. First, RHEL maintainers would have less cruft to sift through when importing. It might make their job easier. Secondly, and more to our point, it would make long term support much easier. Correcting that imbalance would not eliminate Fedora as a Desktop, but make it a bit easier to do either.
Long term support would be very useful, as would:
1. Minimal OS build that fit onto one CD per ARCH. a. That build allowed ssh, vi, yum, and networking so updates and adds were easy. b. That build had a kernel that was less full. Most servers don't use Bluetooth, for example.
2. Application packages that installed in FHS compliant application filesystems vice OS filesystems. For example, apachectl should not be in /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in /opt/httpd/logs. a. Those filesystems, like "/opt" and /srv", should be seperate filesystems. b. Applications that fill up their own space do not crash the server. c. Applications can be backed-up seperately from the OS and then moved quickly in case of disaster recovery or server consolidation.
3. Base OS packages that needed very little outside what was in the Base OS enclave. a. There would probably be multiple levels of inclusion. For example, Python should not be in the base OS but should be one of the first tools installed afterwards. b. Editor and other religious wars would favor Unix-common minimalism.
4. Documentation that favored command line solutions vice GUI tools.
To be honest, I'm not sure how much work this would entail and I'm sure there are things to correct or add in my list. What I would suggest is that we take the small subset mentioned earlier and use F12 or F13 as a proof of concept. The real target should be F15 or F16; by then we should have enough practice to build the base OS and enough credibility to convince the Project Leader to include our efforts.
Interestingly, I can see one advantage Fedora-Server would have over something like CentOS; more frequent critical OS updates would allow usage in secure environments where latest kernel and other security patches must be applied soon after their availability.
Thoughts?
Leam -- I'll be unable to respond until this evening but hopefully can find a way to read while at work. ;)
On Tuesday, 31 August 2010 at 11:35, Leam Hall wrote: [...]
Long term support would be very useful, as would:
- Minimal OS build that fit onto one CD per ARCH.
a. That build allowed ssh, vi, yum, and networking so updates and adds were easy. b. That build had a kernel that was less full. Most servers don't use Bluetooth, for example.
A quick idea: join the kernel maintainers team and create a kernel-server subpackage with a minimal config.
- Application packages that installed in FHS compliant application
filesystems vice OS filesystems. For example, apachectl should not be in /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in /opt/httpd/logs.
Um, no. There are reasons why we don't package anything in /opt.
a. Those filesystems, like "/opt" and /srv", should be seperate filesystems. b. Applications that fill up their own space do not crash the server.
I think you've just reinvented quotas, badly.
c. Applications can be backed-up seperately from the OS and then moved quickly in case of disaster recovery or server consolidation.
With rpm packages you don't need to back-up the applications, only configuration files, data and logs. Installing applications in separate directory trees doesn't improve the situation a lot.
- Base OS packages that needed very little outside what was in the Base
OS enclave. a. There would probably be multiple levels of inclusion. For example, Python should not be in the base OS but should be one of the first tools installed afterwards.
A rephrasing of 1.a.?
b. Editor and other religious wars would favor Unix-common minimalism.
- Documentation that favored command line solutions vice GUI tools.
Well, someone needs to write that documentation.
To be honest, I'm not sure how much work this would entail and I'm sure there are things to correct or add in my list. What I would suggest is that we take the small subset mentioned earlier and use F12 or F13 as a proof of concept. The real target should be F15 or F16; by then we should have enough practice to build the base OS and enough credibility to convince the Project Leader to include our efforts.
I think the low-hanging fruit is working on reducing package interdependencies. There's an ongoing effort, which is and will be of benefit to both Server and Mini SIGs.
Interestingly, I can see one advantage Fedora-Server would have over something like CentOS; more frequent critical OS updates would allow usage in secure environments where latest kernel and other security patches must be applied soon after their availability.
RHEL solves that by backporting. We can't and won't do that due to lack of manpower, so yes, it can be seen as an advantage. On the other hand, new versions sometimes come with new bugs, so I wouldn't push the "enterprise" angle too much. :)
Regards, Dominik
On Tue, 2010-08-31 at 18:19 +0200, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 31 August 2010 at 11:35, Leam Hall wrote: [...]
Long term support would be very useful, as would:
- Minimal OS build that fit onto one CD per ARCH.
a. That build allowed ssh, vi, yum, and networking so updates and adds were easy. b. That build had a kernel that was less full. Most servers don't use Bluetooth, for example.
A quick idea: join the kernel maintainers team and create a kernel-server subpackage with a minimal config.
I'm actually interested in doing that, with the RHEL config options turned on. I think there would be a number of others (not just RH) who would like to have that, and I suppose they could be amenable.
Jon.
On 08/31/2010 12:19 PM, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 31 August 2010 at 11:35, Leam Hall wrote: [...]
Long term support would be very useful, as would:
- Minimal OS build that fit onto one CD per ARCH. a. That build allowed ssh, vi, yum, and networking so updates and adds
were easy. b. That build had a kernel that was less full. Most servers don't use Bluetooth, for example.
A quick idea: join the kernel maintainers team and create a kernel-server subpackage with a minimal config.
The server is much more than the kernel. However, good idea and something to keep in mind.
- Application packages that installed in FHS compliant application
filesystems vice OS filesystems. For example, apachectl should not be in /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in /opt/httpd/logs.
Um, no. There are reasons why we don't package anything in /opt.
Compared to /usr? I've not found a single one. Anything that the server must have to boot, care for itself, and let you log in and edit config files should be in /bin:/sbin:/usr/bin:/usr/sbin. Everything else goes in /opt. The point being that /opt is a seperate filesystem and you can unmount it, fsck it, and do whatever with it without taking down the server.
a. Those filesystems, like "/opt" and /srv", should be seperate filesystems. b. Applications that fill up their own space do not crash the server.
I think you've just reinvented quotas, badly.
Nope. Think of it like this. Your OS is X gig of space. If you use LVM then it's in a VG. The average hard drive today is huge. Allocate ~20G for the OS (using curently overly large F13 installs) and everything else for the applications. The app buys whatever space they need outside of the base disks. That lets you export your apps to, if you like, :)
c. Applications can be backed-up seperately from the OS and then moved quickly in case of disaster recovery or server consolidation.
With rpm packages you don't need to back-up the applications, only configuration files, data and logs. Installing applications in separate directory trees doesn't improve the situation a lot.
It improves it tremendously. Not all applications are in RPM format. Not all applications fit best with the latest version so that means you have to set up your own repositroy using just the versions you want. Besides, if I have to back up config files, data, and logs, why not the entire bundle? Saves time and hassle in a recovery.
- Base OS packages that needed very little outside what was in the Base
OS enclave. a. There would probably be multiple levels of inclusion. For example, Python should not be in the base OS but should be one of the first tools installed afterwards.
A rephrasing of 1.a.?
Extension, though driving in to work I rememberd that yum is python based. The core gets the server up and accessible. The next layer gets the server tols like python, yum, kernel src, etc. Stuff that's nice to have but you can live without it if necessary.
- Documentation that favored command line solutions vice GUI tools.
Well, someone needs to write that documentation.
Yup.
I think the low-hanging fruit is working on reducing package interdependencies. There's an ongoing effort, which is and will be of benefit to both Server and Mini SIGs.
Agreed.
Interestingly, I can see one advantage Fedora-Server would have over something like CentOS; more frequent critical OS updates would allow usage in secure environments where latest kernel and other security patches must be applied soon after their availability.
RHEL solves that by backporting. We can't and won't do that due to lack of manpower, so yes, it can be seen as an advantage. On the other hand, new versions sometimes come with new bugs, so I wouldn't push the "enterprise" angle too much. :)
Problem is not solved when you have to document that you're using version SomePackage 3.5.4 or higher. THere are places that just have no awareness and I've been in a few. Also, note that security vulnerabilities still come out after RHEL/CentOS is no longer providing or prioritizing those back ports.
Leam
On 08/31/2010 10:34 PM, Leam Hall wrote:
- Application packages that installed in FHS compliant application
filesystems vice OS filesystems. For example, apachectl should not be in /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in /opt/httpd/logs.
Um, no. There are reasons why we don't package anything in /opt.
Compared to /usr? I've not found a single one. Anything that the server must have to boot, care for itself, and let you log in and edit config files should be in /bin:/sbin:/usr/bin:/usr/sbin. Everything else goes in /opt. The point being that /opt is a seperate filesystem and you can unmount it, fsck it, and do whatever with it without taking down the server.
Why are you trying to reinvent /usr and just call it /opt? The whole point of dividing the path in (s)bin and /usr/(s)bin is so that (s)bin contains "anything that the server must have to boot" and that /usr can be "a seperate filesystem" and you can "unmount it, fsck it, and do whatever with it without taking down the server".
Also storing a application and all its data in /opt/<app> defeats the purpose of separating the two in /usr and /var.
Have you previously been working in a Windows environment because you don't seem to have any understanding of the filesystem layout on linux and why the things are the way they are.
I'm all for constructive change but what you are describing sounds like a nightmare to me and would probably make Fedora Server unusable for most admins.
Regards, Dennis
On 08/31/2010 05:02 PM, Dennis J. wrote:
On 08/31/2010 10:34 PM, Leam Hall wrote:
- Application packages that installed in FHS compliant application
filesystems vice OS filesystems. For example, apachectl should not be in /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in /opt/httpd/logs.
Um, no. There are reasons why we don't package anything in /opt.
Compared to /usr? I've not found a single one. Anything that the server must have to boot, care for itself, and let you log in and edit config files should be in /bin:/sbin:/usr/bin:/usr/sbin. Everything else goes in /opt. The point being that /opt is a seperate filesystem and you can unmount it, fsck it, and do whatever with it without taking down the server.
Why are you trying to reinvent /usr and just call it /opt? The whole point of dividing the path in (s)bin and /usr/(s)bin is so that (s)bin contains "anything that the server must have to boot" and that /usr can be "a seperate filesystem" and you can "unmount it, fsck it, and do whatever with it without taking down the server".
Also storing a application and all its data in /opt/<app> defeats the purpose of separating the two in /usr and /var.
Have you previously been working in a Windows environment because you don't seem to have any understanding of the filesystem layout on linux and why the things are the way they are.
I'm all for constructive change but what you are describing sounds like a nightmare to me and would probably make Fedora Server unusable for most admins.
Regards, Dennis
Dennis,
I have been working with Linux and some Unix versions for a bit. There is a differnce between "things the server needs to run" that go in /usr and "applications the server hosts" that go in /opt.
Historically Linux stuff went into /usr/local, defined as local stuff for that environment/server/whatever. If we're putting together packages then they are by definition not local to that specific server or environment. However, things like apache don't go in /usr. Just because Linux does it doesn't mean the rest of the Unix version follow suit. Since I have worked in a mixed environment for a while I tend to find better work happening when things are reasonably similar.
Of course, that precludes HP/UX putting SSH in /opt. :(
Leam
On 09/01/2010 12:02 AM, Leam Hall wrote:
On 08/31/2010 05:02 PM, Dennis J. wrote:
On 08/31/2010 10:34 PM, Leam Hall wrote:
- Application packages that installed in FHS compliant application
filesystems vice OS filesystems. For example, apachectl should not be in /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in /opt/httpd/logs.
Um, no. There are reasons why we don't package anything in /opt.
Compared to /usr? I've not found a single one. Anything that the server must have to boot, care for itself, and let you log in and edit config files should be in /bin:/sbin:/usr/bin:/usr/sbin. Everything else goes in /opt. The point being that /opt is a seperate filesystem and you can unmount it, fsck it, and do whatever with it without taking down the server.
Why are you trying to reinvent /usr and just call it /opt? The whole point of dividing the path in (s)bin and /usr/(s)bin is so that (s)bin contains "anything that the server must have to boot" and that /usr can be "a seperate filesystem" and you can "unmount it, fsck it, and do whatever with it without taking down the server".
Also storing a application and all its data in /opt/<app> defeats the purpose of separating the two in /usr and /var.
Have you previously been working in a Windows environment because you don't seem to have any understanding of the filesystem layout on linux and why the things are the way they are.
I'm all for constructive change but what you are describing sounds like a nightmare to me and would probably make Fedora Server unusable for most admins.
Regards, Dennis
Dennis,
I have been working with Linux and some Unix versions for a bit. There is a differnce between "things the server needs to run" that go in /usr and "applications the server hosts" that go in /opt.
Historically Linux stuff went into /usr/local, defined as local stuff for that environment/server/whatever. If we're putting together packages then they are by definition not local to that specific server or environment. However, things like apache don't go in /usr. Just because Linux does it doesn't mean the rest of the Unix version follow suit. Since I have worked in a mixed environment for a while I tend to find better work happening when things are reasonably similar.
But /usr/local isn't the same as /usr. /usr tended to be mounted remotely using NFS on some sites which was also the reason why the split of /(s)bin and /usr/(s)bin was necessary. That way if /usr wasn't available because of e.g. network issues you still had all the basic tools available in /(s)bin to perform maintenance. So /usr pretty much handles the split between the core and the rest of the system already. The additional feature you propose is to contain the applications and their data in their own directory under /opt. I don't really see much of an advantage to this especially since you break virtually every tool under the sun that assumes the standard layout of the filesystem. If you really have the time as an admin to deal with such a system that so completely deviates from the name then consider yourself lucky but I will go on record that I don't have any aspirations to buy into something like this and I'm pretty sure I'm not the only one.
Given the lack of manpower to accomplish the goals of this SIG I doubt that throwing all conventions over board will make things easier for this project.
Regards, Dennis
On 08/31/2010 07:19 PM, Dennis J. wrote:
On 09/01/2010 12:02 AM, Leam Hall wrote:
<snip for brevity>
But /usr/local isn't the same as /usr. /usr tended to be mounted remotely using NFS on some sites which was also the reason why the split of /(s)bin and /usr/(s)bin was necessary. That way if /usr wasn't available because of e.g. network issues you still had all the basic tools available in /(s)bin to perform maintenance. So /usr pretty much handles the split between the core and the rest of the system already. The additional feature you propose is to contain the applications and their data in their own directory under /opt. I don't really see much of an advantage to this especially since you break virtually every tool under the sun that assumes the standard layout of the filesystem. If you really have the time as an admin to deal with such a system that so completely deviates from the name then consider yourself lucky but I will go on record that I don't have any aspirations to buy into something like this and I'm pretty sure I'm not the only one.
Given the lack of manpower to accomplish the goals of this SIG I doubt that throwing all conventions over board will make things easier for this project.
Regards, Dennis
Dennis,
Fedora curently steps outside of convention. What I'm advocating is returning to them. You're right that the /usr filesystem is somewhat less critical to server boot and control that /bin and /sbin. However. the applications that the server hosts, like apache and sendmail, should not be there.
Seperate the server from what it serves. We should be able to totally keep the application unconcerned about the base OS. Maintaining them intermingled as they are now makes support that much more difficult. With isolation you don't have to worry about filesystem space consumption, about changing the OS packages and hoping the upgrade didn't whack the application's files anywhere, or about trying to recover from a bad crash and remembering what all goes where at 3AM.
Yes, I realize the drift Linux people have made over the years will take some work to fix. However, we're still looking to be FHS compliant and I think that's a good thing. Whether or not it's doable with the people who are or will be involved, I don't know. However, I'm fairly confident that if we don't try to really do things right it'll be a waste of time no matter how much we try.
Leam
On 09/01/2010 02:24 AM, Leam Hall wrote:
On 08/31/2010 07:19 PM, Dennis J. wrote:
On 09/01/2010 12:02 AM, Leam Hall wrote:
<snip for brevity>
But /usr/local isn't the same as /usr. /usr tended to be mounted remotely using NFS on some sites which was also the reason why the split of /(s)bin and /usr/(s)bin was necessary. That way if /usr wasn't available because of e.g. network issues you still had all the basic tools available in /(s)bin to perform maintenance. So /usr pretty much handles the split between the core and the rest of the system already. The additional feature you propose is to contain the applications and their data in their own directory under /opt. I don't really see much of an advantage to this especially since you break virtually every tool under the sun that assumes the standard layout of the filesystem. If you really have the time as an admin to deal with such a system that so completely deviates from the name then consider yourself lucky but I will go on record that I don't have any aspirations to buy into something like this and I'm pretty sure I'm not the only one.
Given the lack of manpower to accomplish the goals of this SIG I doubt that throwing all conventions over board will make things easier for this project.
Regards, Dennis
Dennis,
Fedora curently steps outside of convention. What I'm advocating is returning to them. You're right that the /usr filesystem is somewhat less critical to server boot and control that /bin and /sbin. However. the applications that the server hosts, like apache and sendmail, should not be there.
Virtually all Linux distributions keep the applications in /usr and that makes it pretty much the convention. Unless you want to suggest that the server version of Fedora should stop being Linux and adopt the convention used elsewhere.
Seperate the server from what it serves. We should be able to totally keep the application unconcerned about the base OS.
That's not really possible unless you suggest that each application should be compiled and packed with their own copies of all dependencies which would be a maintenance nightmare. If they are linked to their dependencies in the "base OS" then the application by definition can no longer be unconcerned about the bast OS.
Maintaining them intermingled as they are now makes support that much more difficult.
I don't really see that difficulty.
With isolation you don't have to worry about filesystem space consumption, about changing the OS packages and hoping the upgrade didn't whack the application's files anywhere, or about trying to recover from a bad crash and remembering what all goes where at 3AM.
Why don't you have to worry about filesystem space consumption? You can create separate filesystems right now for /usr, /var, /home, etc. as well and don't have to worry about this either. Putting the applications elsewhere doesn't change this at all and if a filesystems is full then it is full regardless how you shuffle around the files.
Yes, I realize the drift Linux people have made over the years will take some work to fix.
No fixing necessary.
However, we're still looking to be FHS compliant and I think that's a good thing. Whether or not it's doable with the people who are or will be involved, I don't know. However, I'm fairly confident that if we don't try to really do things right it'll be a waste of time no matter how much we try.
So Red Hat has been wasting time all these years with RHEL because they've been doing it wrong the whole time?
What you are asking for is a complete overhaul of the entire system that would make it mostly completely incompatible with everything else that calls itself Linux out there. You'll have to come up with a pretty rock-solid and extensive rationale before this is worth considering.
Regards, Dennis
On Tue, Aug 31, 2010 at 08:24:30PM -0400, Leam Hall wrote:
Fedora curently steps outside of convention. What I'm advocating is returning to them. You're right that the /usr filesystem is somewhat less critical to server boot and control that /bin and /sbin. However. the applications that the server hosts, like apache and sendmail, should not be there.
Leam, Fedora follows the convention established in the FHS. Vendor-provided packages (that's us) are managed by RPM and install to the standard hierarchy. Third-party packages install in /opt. This is absolutely the correct approach for an integrated distro, and with modern package management tools there's little disadvantage to it.
Seperate the server from what it serves. We should be able to totally keep the application unconcerned about the base OS. Maintaining them intermingled as they are now makes support that much more difficult.
So, Rocks Linux does this with its own bundled packages, to keep them out of the way of the CentOS-based core OS. In my (unfortunately now considerable) experience with it, this turns out to be a horrible, horrible nightmare when they're all managed by the same RPM database.
And if we're talking about giving up RPM, that's a pretty drastic deviation from Fedora and Fedora's history. Unless a lot of though and work were put into doing it right, we'd probably end up reinventing the wheel, lumpily. Something else might be done with multiple RPM databases, but that's also a lot of refactoring, and probably the wrong tool for the job.
With isolation you don't have to worry about filesystem space consumption, about changing the OS packages and hoping the upgrade didn't whack the application's files anywhere, or about trying to recover from a bad crash and remembering what all goes where at 3AM.
This isolation idea also goes against several other core Fedora packaging rules, like using system libraries in preference to bundled ones.
Your idea may have merit, but it's really not a match for Fedora Server.
On 08/31/2010 09:08 PM, Matthew Miller wrote:
On Tue, Aug 31, 2010 at 08:24:30PM -0400, Leam Hall wrote:
Fedora curently steps outside of convention. What I'm advocating is returning to them. You're right that the /usr filesystem is somewhat less critical to server boot and control that /bin and /sbin. However. the applications that the server hosts, like apache and sendmail, should not be there.
Leam, Fedora follows the convention established in the FHS. Vendor-provided packages (that's us) are managed by RPM and install to the standard hierarchy. Third-party packages install in /opt. This is absolutely the correct approach for an integrated distro, and with modern package management tools there's little disadvantage to it.
Matt,
Fedora packages third-party apps like Apache. So your point is taken as it supports what I've been saying. ;)
And if we're talking about giving up RPM, that's a pretty drastic deviation from Fedora and Fedora's history. Unless a lot of though and work were put into doing it right, we'd probably end up reinventing the wheel, lumpily. Something else might be done with multiple RPM databases, but that's also a lot of refactoring, and probably the wrong tool for the job.
No, not giving up RPM. But fixing the SRPMs so that the third party stuff gets installed in /opt.
With isolation you don't have to worry about filesystem space consumption, about changing the OS packages and hoping the upgrade didn't whack the application's files anywhere, or about trying to recover from a bad crash and remembering what all goes where at 3AM.
This isolation idea also goes against several other core Fedora packaging rules, like using system libraries in preference to bundled ones.
Until those system libraries have an application dependancy that precludes OS upgrade. I agree that the application should use a system bit if the system bit is in the OS core itself. However, if the application needs libXYZ and we don't package libXYZ in the core then they can keep their own versions and their own coherency.
The other point I'm hoping to get across is that just because a Fedora rule has been made doesn't mean it's the best answer for mixed environments. Fedora rules so far seem pretty desktop centric and RH-Linux myopic. Most of the SysAdmins I know work with 3-5 different OS's, 2-4 versions of each, a few applicance OS versions, and take care of applications 'cause the developers don't have a clue. The simpler we can make that job for them the more valuable Fedora Server would be, to me.
Your idea may have merit, but it's really not a match for Fedora Server.
If there's consensus on the latter, that's fine. I have not heard that though, nor have I really heard anything that convinces me /opt and separate filesystems are not the way to go. If you can convince me, great! It means you've been able to help me learn more.
Leam
On Wed, Sep 01, 2010 at 03:36:54PM -0400, Leam Hall wrote:
Fedora packages third-party apps like Apache. So your point is taken as it supports what I've been saying. ;)
The packages are provided by the vendor -- Fedora, us. They're not third-party in that sense. This has been the standard interpretation of the FHS since forever.
No, not giving up RPM. But fixing the SRPMs so that the third party stuff gets installed in /opt.
What's "third party stuff"? Where would you suggest to draw the line? Apache? APR? Glibc?
How are dependencies of these things managed? Since the dependencies go in the same RPM database, what's the value of having things separated?
Until those system libraries have an application dependancy that precludes OS upgrade. I agree that the application should use a system bit if the system bit is in the OS core itself. However, if the application needs libXYZ and we don't package libXYZ in the core then they can keep their own versions and their own coherency.
What happens if two packages need libXYZ? What happens when it's added to the core ? What if two packages need it? What if there's a security problem in a library? Again, this opens up a whole bunch of packaging issues that are _already addressed_ by Fedora.
The other point I'm hoping to get across is that just because a Fedora rule has been made doesn't mean it's the best answer for mixed environments. Fedora rules so far seem pretty desktop centric and RH-Linux myopic.
But this particular approach is taken by Debian, Ubuntu, RHEL, SUSE, Gentoo, Slackware... I can't think of a Linux distribution that doesn't follow it, so it seems weird to call it myopic or desktop-centric.
Most of the SysAdmins I know work with 3-5 different OS's, 2-4 versions of each, a few applicance OS versions, and take care of applications 'cause the developers don't have a clue. The simpler we can make that job for them the more valuable Fedora Server would be, to me.
That's a fair argument, but I don't think it's an argument for Fedora Server. It's an argument for trying some new thing -- which you're welcome to do, but I don't think it's a productive discussion *here*.
Your idea may have merit, but it's really not a match for Fedora Server.
If there's consensus on the latter, that's fine. I have not heard that though, nor have I really heard anything that convinces me /opt and separate filesystems are not the way to go. If you can convince me, great! It means you've been able to help me learn more.
If you want to discuss this particular idea further, please mail me off-list. Thanks.
On 09/01/2010 08:07 PM, Matthew Miller wrote:
Your idea may have merit, but it's really not a match for Fedora Server.
If there's consensus on the latter, that's fine. I have not heard that though, nor have I really heard anything that convinces me /opt and separate filesystems are not the way to go. If you can convince me, great! It means you've been able to help me learn more.
If you want to discuss this particular idea further, please mail me off-list. Thanks.
Matt,
Um, why take an open conversation off-line? So far I've heard two folks who feel differently than I. If it's just the three of us then you have a majority. If there's a few more then the silence has the numbers. If we can't figure out why or why not as a group, then there's a bigger why, isn't there?
Leam
On Wed, Sep 1, 2010 at 19:24, Leam Hall leam@reuel.net wrote:
On 09/01/2010 08:07 PM, Matthew Miller wrote:
Your idea may have merit, but it's really not a match for Fedora Server.
If there's consensus on the latter, that's fine. I have not heard that though, nor have I really heard anything that convinces me /opt and separate filesystems are not the way to go. If you can convince me, great! It means you've been able to help me learn more.
If you want to discuss this particular idea further, please mail me off-list. Thanks.
Matt,
Um, why take an open conversation off-line? So far I've heard two folks who feel differently than I. If it's just the three of us then you have a majority. If there's a few more then the silence has the numbers. If we can't figure out why or why not as a group, then there's a bigger why, isn't there?
For all the reasons he has listed. Your discussion is not really meant for this list.. you are looking at inventing something completely different from what Fedora offers. Take it off list and if something comes from that. This is really my only say on this.
Leam
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
Matthew Miller wrote:
On Wed, Sep 01, 2010 at 03:36:54PM -0400, Leam Hall wrote:
Fedora packages third-party apps like Apache. So your point is taken as it supports what I've been saying. ;)
The packages are provided by the vendor -- Fedora, us. They're not third-party in that sense. This has been the standard interpretation of the FHS since forever.
No, not giving up RPM. But fixing the SRPMs so that the third party stuff gets installed in /opt.
What's "third party stuff"? Where would you suggest to draw the line? Apache? APR? Glibc?
Don't forget the kernel. It's third party as well. It should therefor be in /opt. Obviously.
-- Jeroen
On 09/01/2010 12:36 PM, Leam Hall wrote:
If there's consensus on the latter, that's fine. I have not heard that though, nor have I really heard anything that convinces me /opt and separate filesystems are not the way to go. If you can convince me, great! It means you've been able to help me learn more.
I've used Unix since 1991 and Linux since 1992 and I'm telling you, that's not what /opt is for.
/opt is analogous /usr/local, but with each application -- or in some cases, groups of applications -- in its/their own directory. Both /opt /and /usr/local are for your own in-house builds of apps -- we use it extensively on our servers, because we have a lot of in-house software that we maintain.
If you're building and maintaining your own (say) Apache, it makes perfect sense for you to put it in /opt. But consider: how would you like it if your httpd binary -- in /opt -- was overwritten by "yum update"? I'm guessing you would not be happy with that, because nobody would be happy with that.
I'm a survivor of various filesystem standards. (Did you know that binaries for various Net servers used to live in /etc ?) So I'm here to tell you know, the current FSS is fine, fine business. That's not to say it couldn't use some improvement -- for instance, I'd love to have an easy way to change the java symlinks in /etc/alternatives with some sort of ncurses tool. (Or the same for any large application suite for which we have /etc/alternatives.) But I know that Internet servers provided by the distribution live in /usr/sbin, and it's been that way since before we stopped putting "in." in Net server binary filenames.
The other point I'm hoping to get across is that just because a Fedora rule has been made doesn't mean it's the best answer for mixed environments. Fedora rules so far seem pretty desktop centric and RH-Linux myopic.
I disagree, and point out that the Linux FSS isn't just a RH thing, it's used all across Linux distributions. Also, I should mention that Fedora itself is community-governed, so if you want to depart from the Linux FSS, you only have to convince a certain X number of people that it should be changed...but count me out of that, I think both /opt and /usr/local need to remain off-limits to the distribution.
Most of the SysAdmins I know work with 3-5 different OS's, 2-4 versions of each, a few applicance OS versions, and take care of applications 'cause the developers don't have a clue.
This is not only unfair to the developers, it's also the way _we_ used to do things, maybe around 8 years ago. The world has moved on: if you're not using (say) Fedora's httpd on your Fedora servers, I have to wonder what it is that you don't like about Fedora's Apache? I use it on two of my personal servers that are running Fedora, and I have no problem with them.
Back in the bad-ol' days, if a distro-provided package didn't do its job right, we'd grab the sources and build our own version, since that was a lot easier to keep up with all the issues we were tracking. Nowadays, it's a simple matter (in Fedora) to grab the SRPM and come up with a change that can be passed upstream to whomever is interested in it.
The simpler we can make that job for them the more valuable Fedora Server would be, to me.
On our network, we (at work) make all changes in SRPMS, and keep the resulting binary rpms in our own repos, to update our 200+ servers. Though they are a mix of CentOS 5.5 and RH 7.3 servers, the principle is the same as Fedora, albeit with different build host guests running in kvm virts. I finally took the time to learn how to manage SRPMS (since the operations guys had done this long ago), and found the learning curve really wasn't as steep as I thought it would be.
Even to look as sources, I use Fedora's "yumdownloader --source X" feature, where "X" is the package name. That way, I not only get the pristine tgz of the original sources, but I can see what patches folks with the Fedora Project have added.
Finally, I should mention that there's another advantage to using an SRPM for a vital server application: so far, I haven't found an SRPM that won't build working binaries for both Fedora _and_ CentOS 5.5. This is a beautiful thing for packages that aren't (yet?) in CentOS, but can be found in Fedora.
Take care, and happy Thursday. :)
-Scott CTO, Sonic.net, Inc.
seth vidal píše v Po 30. 08. 2010 v 15:27 -0400:
On Mon, 2010-08-30 at 15:13 -0400, Jon Masters wrote:
Right. But don't you think this group could at least come up with a list of proposals, or even one proposal? It could include a longer support timeframe, but also detail how Fedora is not friendly to Server today.
It needs a longer support lifetime and/or a slower update rate.
I think that's really all.
slower update rate - I don't think the core required for running server services changes so often and the server services itself also don't have too many updates, I've not done any analysis though
longer lifetime - one upgrade per year can be survived
Also the reason for this mailing list and SIG is not necessarily only about running the server on Fedora, but about testing and preparing "server things" for the next RHEL. It's clear that only a minority of people will run production servers on Fedora and it would be nice to show the world what can be expected in the next RHEL. But it all begins at the definition of a server and also what today's admins expect as a server. My view is still minimalistic - you need kernel + init system + yum + the server ...
Dan
PS: I know I don't give this project as much time as I originally planned, but the work on Fedora/s390x takes a lot of time and we see it as an investment into the future. The dinosaurus will be here for a long time :-)
On Mon, Aug 30, 2010 at 15:36, Dan Horák dan@danny.cz wrote:
seth vidal píše v Po 30. 08. 2010 v 15:27 -0400:
On Mon, 2010-08-30 at 15:13 -0400, Jon Masters wrote:
Right. But don't you think this group could at least come up with a list of proposals, or even one proposal? It could include a longer support timeframe, but also detail how Fedora is not friendly to Server today.
It needs a longer support lifetime and/or a slower update rate.
I think that's really all.
slower update rate - I don't think the core required for running server services changes so often and the server services itself also don't have too many updates, I've not done any analysis though
PS: I know I don't give this project as much time as I originally planned, but the work on Fedora/s390x takes a lot of time and we see it as an investment into the future. The dinosaurus will be here for a long time :-)
Should we try and experiment with a 'sub' distribution? Say take Fedora 12 and keep it running for 18 months? [Lets not get into how this will fail... how could we make it work?]
On Mon, 2010-08-30 at 15:57 -0600, Stephen John Smoogen wrote:
Should we try and experiment with a 'sub' distribution? Say take Fedora 12 and keep it running for 18 months? [Lets not get into how this will fail... how could we make it work?]
As I was saying to someone on IRC, the problem is two-fold:
1). Lifetime of the release. When it's over, you're fedora-legacy.
2). Stable updates are often wholesale rebases. So if you want stability, you need to cherry-pick stuff that wasn't cherry-picked in the original branch. You need to do a lot of extra work, and as was pointed out to me, you'd also be trying to duplicate the legacy model in this aswell, but now with the added overhead of extra backports.
So maybe we could pick a very small set of packages and call it a base platform, and have a longer lifetime on it. But first look at why the Fedora Legacy project failed and ask if we can avoid that.
Jon.
On Mon, Aug 30, 2010 at 15:56, Jon Masters jonathan@jonmasters.org wrote:
On Mon, 2010-08-30 at 15:57 -0600, Stephen John Smoogen wrote:
Should we try and experiment with a 'sub' distribution? Say take Fedora 12 and keep it running for 18 months? [Lets not get into how this will fail... how could we make it work?]
As I was saying to someone on IRC, the problem is two-fold:
1). Lifetime of the release. When it's over, you're fedora-legacy.
The big issue with Fedora Legacy though was trying to do too much. We were supporting RHL-7.3, RHL-8 and RHL-9 and old Fedora's. You pick one release and you support it. You don't do 4+ ones. As much as sine people like to think RH used to support 7.0/7.1/7.2/7.3 we didnt... we supported 6.2 and latest. if you were at 7.1 and 7.2 came out.. you needed to upgrade.
2). Stable updates are often wholesale rebases. So if you want stability, you need to cherry-pick stuff that wasn't cherry-picked in the original branch. You need to do a lot of extra work, and as was pointed out to me, you'd also be trying to duplicate the legacy model in this aswell, but now with the added overhead of extra backports.
Well the 'solution' to that is choosing what your 'base' is very carefully and only supporting that. Instead of trying to support 1800 src.rpms you focus on 600. Everything else above that 600 that people want goes into powertools :).
[600 is an arbitrary number pulled out of well we don't need to go there.]
So maybe we could pick a very small set of packages and call it a base platform, and have a longer lifetime on it. But first look at why the Fedora Legacy project failed and ask if we can avoid that.
Been there, done that, have the scars (though Jesse got the tattoos).
1) We supported too much: too many releases and too long a lifetime. 2) We expected that the people clamoring for a stable RHL (consultants, small business, etc) would pony up when their business models was more on using other stuff for free. They instead went to new free stuff instead. 3) We did not have a target audience beyond "everyone who was left behind on RHL's crash and burn." [Yes people called it that and worse at the time] 4) Our infrastructure of rebuilding stuff was not very solid so getting a rebuild seemed horribly painful 5) Our rules were at times oppressive because we were trying to satisfy people who wanted RHEL without paying for it... 6) Our audience (both customers and developers) shrank as RHEL became more stable and/or people moved to Fedora or Ubuntu to complete their 'visions'.
There are others but those are the ones I have memorized everytime Mr Kofler brings up my shame. Answers to the above:
1) We support 1 release at a time. 2) We realize that we are small and not expect help until given it. 3) Our audience is people wanting to push beyond what RHEL has in it but want the idea that things break weakly. Our audience is server and o 4) Git/Koji/bodhi/etc are very nice. even plague would be better than what we started with back then 5) We use established rules for packaging and keep our core small. We cherry pick a minimal amount of stuff that we can find a longterm upstream help with and everything else gets 'rebased' regularly if needed. 6) We define what our expected audience is and we keep them with stuff they are looking for. This means figuring out a key 'visionary' market and supplying them with things they need. [The classic RHL market was web servers (ok 'porn') but we can find something more web-3.0 and help them get ahead.]
Jon.
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
On Mon, Aug 30, 2010 at 04:46:50PM -0600, Stephen John Smoogen wrote:
The big issue with Fedora Legacy though was trying to do too much. We were supporting RHL-7.3, RHL-8 and RHL-9 and old Fedora's. You pick
And it turned out that very few people wanted to do the work to support Fedora, just old RHL.
If you really want to do this, I suggest starting *opposite* RHEL 6. People who want something kinda like Fedora 13 to last for a very long time already have their answer. Wait a year and a half, though, and people will start itching a little bit. And then they'll want what they picked at that point to last forever.
- We did not have a target audience beyond "everyone who was left
behind on RHL's crash and burn." [Yes people called it that and worse at the time]
Yeah, this. :)
If Fedora had been ready to pick up at that point, things might have been different. But it's putting it mildly to say that the project floundered a bit for the first few releases.
- We define what our expected audience is and we keep them with stuff
they are looking for. This means figuring out a key 'visionary' market and supplying them with things they need. [The classic RHL market was web servers (ok 'porn') but we can find something more web-3.0 and help them get ahead.]
Hello, cloud-sig. :)
On 08/31/2010 01:05 AM, Matthew Miller wrote:
On Mon, Aug 30, 2010 at 04:46:50PM -0600, Stephen John Smoogen wrote:
The big issue with Fedora Legacy though was trying to do too much. We were supporting RHL-7.3, RHL-8 and RHL-9 and old Fedora's. You pick
And it turned out that very few people wanted to do the work to support Fedora, just old RHL.
If you really want to do this, I suggest starting *opposite* RHEL 6. People who want something kinda like Fedora 13 to last for a very long time already have their answer. Wait a year and a half, though, and people will start itching a little bit. And then they'll want what they picked at that point to last forever.
Isn't this what CentOS is about? Even though I like this idea to have something between slow running RHEL and fast forward Fedora.
Radek
- We did not have a target audience beyond "everyone who was left
behind on RHL's crash and burn." [Yes people called it that and worse at the time]
Yeah, this. :)
If Fedora had been ready to pick up at that point, things might have been different. But it's putting it mildly to say that the project floundered a bit for the first few releases.
- We define what our expected audience is and we keep them with stuff
they are looking for. This means figuring out a key 'visionary' market and supplying them with things they need. [The classic RHL market was web servers (ok 'porn') but we can find something more web-3.0 and help them get ahead.]
Hello, cloud-sig. :)
On 08/31/2010 08:28 AM, Radek Vokál wrote:
On 08/31/2010 01:05 AM, Matthew Miller wrote:
On Mon, Aug 30, 2010 at 04:46:50PM -0600, Stephen John Smoogen wrote:
The big issue with Fedora Legacy though was trying to do too much. We were supporting RHL-7.3, RHL-8 and RHL-9 and old Fedora's. You pick
And it turned out that very few people wanted to do the work to support Fedora, just old RHL.
If you really want to do this, I suggest starting *opposite* RHEL 6. People who want something kinda like Fedora 13 to last for a very long time already have their answer. Wait a year and a half, though, and people will start itching a little bit. And then they'll want what they picked at that point to last forever.
Isn't this what CentOS is about? Even though I like this idea to have something between slow running RHEL and fast forward Fedora.
I think the fact that Centos exists is one big Problem to get people rallied for a long-term Fedora release. A lot of them simply go "why bother?".
I also think that the gap in between the two is pretty much the only way to go to get the people motivated for whom the now three year release cycle of RHEL/Centos is simply a bit too long. My feeling is:
1. Pick up a Fedora release every 18 months and use that as a basis for a long-term release. This should make things slow enough to make Fedora viable as a server platform but still fast enough so that packages don't get too outdated.
2. Support support such a release for 3 years. That way people have plenty of time to plan for updates yet the server SIG only has to support two releases at a time. This is basically the Fedora approach of supporting the current and the previous release.
This still leaves you with the problem of having to maintain the packages for three years though. But even if you limit the number of "supported" packages to a smaller number (i.e. Fedora Server becomes a subset of Fedora) you still have the issue that not everbody can easily support every package. When a major overhaul like say of python happens then you can't just put some random person in charge of getting that sorted out and maintained for 3 years. The current python maintainers would pretty much have to officially sign up for Fedora Server to make this work and the same is true for a lot of other core packages/package groups. Not sure if this is possible/viable.
Regards, Dennis
On Mon, Aug 30, 2010 at 05:56:55PM -0400, Jon Masters wrote:
On Mon, 2010-08-30 at 15:57 -0600, Stephen John Smoogen wrote:
Should we try and experiment with a 'sub' distribution? Say take Fedora 12 and keep it running for 18 months? [Lets not get into how this will fail... how could we make it work?]
As I was saying to someone on IRC, the problem is two-fold:
1). Lifetime of the release. When it's over, you're fedora-legacy.
2). Stable updates are often wholesale rebases. So if you want stability, you need to cherry-pick stuff that wasn't cherry-picked in the original branch. You need to do a lot of extra work, and as was pointed out to me, you'd also be trying to duplicate the legacy model in this aswell, but now with the added overhead of extra backports.
oh, dreaming is so nice, but where is manpower? :-)
Anyway, from wiki:
Our main goal is to find a technical solution - by maintaining compatibility, with possibility to enable/disable certain features, etc. We think that the main problem is the lack of communication between groups and we would like to focus from the very beginning on improving it.
In other words, our goal is (was?) to by *constructive* opposition to desktop maniacs from fedora-devel. And we would like to keep Fedora usable on servers (as Dan said "testing and preparing server things").
Things like long lifetime and slower update rate is the next level in this game.
Karel
On Mon, Aug 30, 2010 at 11:29:46AM -0400, seth vidal wrote:
Hello? Is this thing on? It's dark out there.... anyone in the house tonight?
TELL A JOKE OR GET OFF THE STAGE!
Here I'll start with the jokes: Fedora Server HAHAHAHAHAHAHAHAHAHAHAHAHAHAH
Nice. :)
server@lists.fedoraproject.org