On Tuesday, 31 August 2010 at 11:35, Leam Hall wrote:
[...]
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.
A quick idea: join the kernel maintainers team and create
a kernel-server subpackage with a minimal config.
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.
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.
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.
A rephrasing of 1.a.?
b. Editor and other religious wars would favor Unix-common
minimalism.
4. 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
--
Fedora
http://fedoraproject.org/wiki/User:Rathann
RPMFusion
http://rpmfusion.org | MPlayer
http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"