*tap* *tap* *tap*

[Dominik 'Rathann' Mierzejewski]

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"