On 11/16/2013 12:34 AM, Miloslav Trmač wrote:
On Fri, Nov 15, 2013 at 1:04 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
> On 11/14/2013 11:44 PM, Miloslav Trmač wrote:
>> On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson"
>> <johannbg(a)gmail.com> wrote:
>>> On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
>>>> On Tue, 12 Nov 2013 16:32:13 +0000
>>>> "Jóhann B. Guðmundsson"<johannbg(a)gmail.com> wrote:
>>>> Is FOS (Fedora OS) the product from our base working group?
>>>> Or something else?
>>> That depends heavily on the outcome of the base working group but as
>>> things
>>> stand now what they have discussed and how I see us moving forward to the
>>> future are quite different.
>> That kind of defeats the point of having a "base" group. Where will
>> we find extra maintainers for doing the same kind of work one more
>> time for the two "quite different" bases?
<snip>
> FedoraOS is that "Core Layer" of the operating system
> FedoraOS Server Platform "Is the "Base Layer for servers" what *we*
define
> should be on it and made available to *all* administrator'
Never mind the naming, what's the point of the base WG if we won't use
what they produce?
As I see it they would handle the core ( think comps minimal here ) not
base since base is something that cannot be shared.
>> I'd rather have a fairly small list of things we guarantee to keep
>> compatible, driven "top-down" by what the sysadmins will need to
>> interact with, rather than "bottom-up" from the upstream components.
>> Implicitly importing every feature a project may implement wholesale
>> would be fairly restrictive if we ever wanted to change or replace the
>> implementation of any particular feature.
> Which is one of the reason why I came to the conclusion that we should keep
> each FedoraOS in it's own release cycle in it's own repositiory, FedoraOS
> Server Platform in another and each application in specific Fedora Server
> Role in their own.
I can't see how release cycles and repositories (which are pretty much
per-package) are related to the concern that per-package stability
promises may not be what we want.
Community driven distribution cannot promise stability of any sort.
The only thing they can promise is best effort.
>>> ks files are easy to maintain.
>> Not the ks files I have seen; they are at least as difficult as shell
>> scripts,
> Hmm perhaps a bit of history lesson is in order here an no one better to
> tell it other then Bryan Cantrill so I suggest you listen to [¹].
>
> There is a reason why the shell is an administrator tool of chose which
> plays a big part in the success of the *nix platforms in the servers space.
Yes, primarily, "you don't have any other option". (Insert rant about
shell making the rare things easy and the common things difficult,
starting with quoting variable expansions.)
Regardless whether shell is a good language or not, it is a
_language_, hence impossible to generally manage with higher-level
software.
Not disagreeing here
> Common/generic is the problem here , which is an place we already
are at so
> why this effort if we are not going that extra mile that extra length to
> separate us from the masses?
I think "write a kickstart shell script" or "set up your own
puppet-based management infrastructure" is exactly where we are at.
We can go many extra miles further from there :)
Yes long term short term to actually start delivering $something we
should use what exist.
"Sometimes you get to do a complete reboot, and when you can,
it's a
beautiful thing" (or something like that, I can't find the exact quote
about Java). Yes, I'm also maintaining a list of items a
from-the-ground-up-rewritten-and-cleaned-up OS should have (starting
with a better language, and a real common runtime so that there aren't
hundreds of string and hashing libraries, and on from there).
I'm afraid Fedora.next isn't that complete-cleanup OS though.
1) We don't have the consensus on the need to reinvent.
("kickstarts/puppet/shell/X11/fork()/... work just fine, thank you")
2) We don't have the manpower and time. It took ~10 years for Linux
to become reasonably-feature complete, with a world-wide collaboration
pretty much on one project, _which was sorely needed because nothing
like it existed_. We don't have 10 years, we are one project among
many, and everyone has other options (perhaps not as good but better
than spending a month programming a missing component).
3) The various upstreams will continue expanding and modifying the
"Linux" ecosystem faster than we can "clean it up" for FedoraOS.
(Or perhaps you have a much more limited "clean up" in mind?)
Limited to the distribution it's packaging and the selected component
that make up FedoraOS, FOSSP and each application it it's server role etc.
>
> Quite frankly looking at our whole ecosystem what we need is a generation
> change to flush out that outdated way's of thinking perhaps that's what's
is
> slowly making us irrelevant and obsolete.
The trouble is that flushing out that outdated ways of thinking
automatically implies flushing out all the working software with no
replacement but well-intentioned ideas.
How do you come to that conclusion?
( I'm talking about those making decisions in Fedora lacking fresh
mindset/ideas and perspective )
So I think we can practically
only choose _specific areas that matter to us_ (perhaps configuration
and monitoring) and fix those, and _only_ those.
Perhaps, sometime somewhere, someone will start from scratch, and
design a complete new thing that is so great that the community will
eventually migrate, but I honestly can't see that. I've seen far too
many "this is my hobby OS kernel that has better API than Linux",
"this is my hobby language that is better than C++ and Java", "this is
my better IPC", "this is my unified configuration library" projects
that have had no chance to ever gather critical mass.
Of course, that leads to the question "why can't Fedora lead the
change? It is big enough after all". Yes, perhaps it is big enough,
sbut _only if we stay as big as we are_, not if we throw out all
existing packages and then try to introduce a new mechanism from the
position of a big distribution while actually being one of the
smallest ones.
Keeping these two things separated ( Fedora vs FedoraOS ) we wont be
throwing out anything. We simply will be choosing existing bits cleaning
them up, intergrade them better with one another ( if applicable ) and
place them in FedoraOS
> Anyway to be able to clean us up and make us agile again we need to keep
> that work separated from "Generic Fedora" because it will cause disruption
> and yes I'm aware of what that means work wise but it's absolutely necessary
> for us to do, to succeed in the long run.
I don't think it's necessary, any more. It might have been necessary
5 years ago, but now the kernel has enough namespacing technology (...
which I otherwise... don't like) that it's fairly feasible to keep
compatibility. For example, create /FedoraOld1/{bin,etc,usr,...}, let
the old system live in there, and take over / for the all new design.
(FedoraOld1 because there _will_ be FedoraOld2; we wouldn't get it
exactly right either.)
This will just lead to a mess for everybody...
JBG