why do we think one size can create all?

August 31, 2010

Why is it we think that we can build a server and a desktop and a mobile platform and a computational cluster platform and EVERYTHING out of a single tree of pkgs and a single kernel? Is it not possible that easy, functional and versatile is too many things to ask for and keep everyone getting along?

I’m going to suggest something radical:

fedora server should be a complete tree branch – with its own criteria for admittance of pkgs and updates

fedora should continue as is with the focus being the desktop and targetted the user that the board defined a little while back:

http://lwn.net/Articles/358865/

specifically:

 We found four defining characteristics that we
believe best describe the Fedora distribution's target audience:
Someone who (1) is voluntarily switching to Linux, (2) is familiar
with computers, but is not necessarily a hacker or developer, (3) is
likely to collaborate in some fashion when something's wrong with
Fedora, and (4) wants to use Fedora for general productivity, either
using desktop applications or a Web browser.

Perfect, right? We can focus on the issues of a server and of cutting the edge of what servers need while the desktop-oriented folks make a great desktop (or desktops) and we don’t have to have these pitched battles over systemd and networkmanager and policykit and what not.

sounds like a winner to me.

14 Responses to “why do we think one size can create all?”


  1. It’s an interesting idea. I think it’s important, still, to have common core. (No historical pun intended.) Maybe the server branch would delay longer and be more cautious on something like systemd, but the ultimate goal should be to track together closely. Otherwise, we end up with a lot more work and simultaneously become less relevant. If we went for something like this, we’d still need a voice in the features process. It doesn’t need to a whole lot of super-veto-power or anything, just an official recognition that some basic principles vital to server and enterprise use should be considered.

    • skvidal Says:

      Does it? Think of the use case of systemd or even upstart. What does the server get out of it? Not a lot. Why would we have transitioned away from sysvinit? faster bootups? Really? does that matter much to a server?

      That’s my point. Maybe we wouldn’t do the systemd or even upstart transition AT ALL on a server spin.

      • Christof Says:

        One thing that would be interesting to see would be how many people end up running the server spin.

        RHEL probably would also be interested in that split. It might even be possible to replace CentOS if the support time could be raised.

        The question is how far they drift apart. If it is too far it would be too much work for the packagers.


      • It’s init. It should be the same.

        Ironically, if, like our upstart configuration vs. old sysvinit, the change didn’t make any practical difference, it might be viable to stay apart, but this is such a wide division at the heart of everything that it just would be… wrong.

        If something that fundamental can’t make a good case for general purpose use, I don’t think we want it in either desktop or server. I think systemd has some _potential_ advantages in the server case (cgroups managed daemons with resource controls, on-demand services, more sophisticated cron replacement, even just having meaningful dependencies for services…).

        It’s completely reasonable to wait and see if that all pans out, and to keep the server branch conservative in the interim. But eventually, the goal should be reunification. If, after several releases, it’s clear that systemd won’t ever be a good choice for the server case, we need to talk with the desktop folks and find if it’s really meeting their needs either.

  2. Greg Dek Says:

    What are the practical issues that would need to be resolved to make such a split?

    Better tools allowing maintainters to keep packages synched in two different repos? What else?

  3. skvidal Says:

    You’d need a separate branch, I think and you’d need support for that branch in bodhi and the push tools, I think.

  4. skvidal Says:

    Matt,
    Why should init be the same? Why does it matter? Does it matter that your phone doesn’t boot the same way your desktop does? Or your server? Or for that matter your router?

    I don’t really see why it has to be the same.

    Does a Mac boot the same way windows machine does?
    Of course not. Why should we keep up this pretense of unity? We’ve not had it.


    • As we’re seeing from the widespread effects of systemd in F14/Rawhide, init does a lot more than get the system started. It governs configuration, manages the processes while the system is running, and maintains and alters state of the system as a whole. If Fedora server and desktop do all that differently, it’s a pretty wide split.

      Maybe you can sell me on that being okay, but I’m skeptical. If my phone were a lot more like my desktop system, I’d be happier with it. (*Eyes the N900*), and I personally get a lot of value from having my desktops and servers be closely related. It’s, you know, synergy.

      Right now, there’s no “control group” in Fedora. It’s all experimentation with no reference point except remembering how it used to be. Retaining the right to diverge — and doing it where necessary — gives the project as a whole a much-needed counterbalance. But at a point, someone should look at the experiment and draw a conclusion. That’s something we can give back, which seems a lot better than just saying “fine, have fun, we’ll be over here if you need us”.

      • skvidal Says:

        Matt,
        It’s a pretty wide split how? Does it matter that clients on OSX don’t have internal operations the same as your server on rhel? No – it matters that they communicate over the same protocols.

        At lets be honest – to create a desktop of the ‘gnome-os’ kind that the desktop-team seems to want to make – will require a fundamental change in how things are done. A change that I do not believe is beneficial or will be looking out for the requirements of the server.

        This is the fundamental problem.

        I do not comprehend the value in a phone, a laptop and a server all running the same bits and operating in the same way. That feels like a bad monoculture to me.


      • It matters when I’m asked to fix some problem on an OS X server, and I’m bewildered as to how to tell a service to start or how to even look at the network configuration.

  5. skvidal Says:

    Matt,
    I understand your argument – but then it sounds more like you’re arguing for:

    fedora to have the same as rhel in all cases.

    ie: network-scripts and sysvinit.

    Is that right?

  6. allenhalsey Says:

    “why do we think one size can create all?”

    Because:

    1) fragmentation is something to be avoided

    2) I want to leverage and reinforce the same skill set for administering my desktop as I use on my servers. Multiply by number of people on my team.

    3) I run some services on my desktop

    4) I use my desktop as a test server before applying changes to our staging server.

    5) we have a powerful package management system that can handle package selection for different needs; no need for distinct package trees.

    Can you further explain how desktop features harm server features? You mentioned kernel and systemd. How exactly would the kernel differ? How would fast boot-up time be harmful to servers?

  7. bochecha Says:

    Wait, you mean I’d have to maintain my packages in two different repositories, potentially in different versions and different build options?

    That sounds a lot like Fedora vs EPEL, except that those are 2 distinct distributions.

    If you want different Fedoras, each one in its own tree, why call them all Fedora? Why not simply create a different distribution, with Fedora as upstream but focused on the server? (and thus with a slower release cycle, less bleeding-edge experimentation, …)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: