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. ;)