Letting the cat out of the box

June 30, 2013

Another San Lorenzo Valley Sunday, charcoal burning everywhere . . .

A few items culled over an unreasonably hot week here in Felton — we’re talking the area being Miami with redwoods (but thankfully without humidity) — include:

Schrodinger’s Cat lives: After a go/no-go meeting last week which sided with the former, Fedora 19 “Schrodinger’s Cat” went gold and gets a non-radioactive green light for Tuesday, July 2. Curious about it, I downloaded the beta and put it on a Toshiba Satellite L455, ahem, “laptop” — a laptop if your lap is the size of, say, Andre the Giant’s — and the silver behemoth ran the beta flawlessly. As I’ve mentioned before, I don’t review distro alphas or betas because it’s akin to sticking your finger in a bowl of batter and writing about how good (or bad) the cake will be once it’s finished.

I can tell you this: I do like what Fedora has done with the install process, so much so that it was worth the wait when Fedora 18 was delayed (and I could take this opportunity to launch into why a six-month release cycle leaves a lot to be desired, but I won’t, even though I just did). In addition, I think this one will be a good one, but you’ll have to find out when I write about it next week. Get more information, and take the living cat out of the box on Tuesday, here.

The best distros: Last week, I said that a FOSSForce.com write-up a few weeks ago about what constitutes a community distro was an “uncharacteristically ludicrous article posted by the usually right-on-the-mark” site for FOSS news and commentary. As a blogger, I live in the glass house known as FOSS commentary and, regardless, I still reserve the right to throw stones. I can also admit without reservation or apology that the history of this blog is strewn with dozens of blogged eggs laid over the past several years; enough eggs to feed omelets to a small army during the course of a military campaign.

That said, I should clarify that I thought the message, not the messenger, was sorely lacking. But Christine Hall makes up for the article I slammed, and gains extra yardage on the play, by writing a great “top five” distro article which concludes — spoiler alert — with this: “Just keep in mind, there really isn’t a best Linux distro, or even a list of five best Linux distros. There’s only a best distro for you, the job you need it to do and the equipment on which you need it to operate.”

Amen to that, Christine, and thanks for reciting the Larry the Free Software Guy mantra.

Widespread adoption of Unity? Not exactly: Like FOSSForce.com, LXer.com is also one of my daily stops on the web for news and commentary. Also, more entertaining is visiting the LXer.com discussion forums — yes, that’s a reflection of how exciting my life is; deal with it (I have) — and finding some interesting morsels.

One item has an original poster bemoaning the fact that people continue to beat up on Unity. While I find it hard to agree with his premise — for a variety of reasons on several levels, Unity deserves its reputation as the pinata it has become in the tech press, with little in the way of argument against — it did prompt me to think about this question: If Unity is such an outstanding desktop environment, why hasn’t it been widely adopted by other distros?

Think about it. Personal preferences aside, a metric which speaks to how good, or not, a desktop environment is would be its adoption by other distros. So you could describe Unity as having widespread appeal if you define “widespread appeal” as being adopted by 10 — count ’em, 10 — distros other than Ubuntu.

If you’re keeping score at home, here’s the list of distros other than Ubuntu using Unity as a default desktop environment (with DistroWatch ranking in parentheses): DreamStudio (49), The People’s Republic of China’s Ubuntu Kylin (105), Hybride Linux (108), Vinux (110), Leeenux (165); Bio-Linux (174), Ubuntu Christian Edition (188), Oz Unity (195), iQuinixOS (261), and Baltix GNU/Linux (274).

OK, so I would argue that it’s not widespread adoption, for reasons I’ve mentioned in past blog posts — the posts you couldn’t scramble and serve with toast.

Oh, and one more thing: Lindependence rides again. We’re going to take Software Freedom Day in September and make it SFD-Lindependence Felton 2012, with all the trappings of the first one. More on this as plans develop. I would urge any group — Linux User Group, FOSS software-specific user groups, even the sectarian Ubuntu LoCos — to participate in Software Freedom Day by signing up here.

See you next Sunday, if not sooner.

This blog, and all other blogs by Larry the Free Software Guy, Larry the CrunchBang Guy and Larry Cafiero, are licensed under the Creative Commons Attribution-NonCommercial-NoDerivs CC BY-NC-ND license. In short, this license allows others to download this work and share it with others as long as they credit me as the author, but others can’t change it in any way or use it commercially.

(Larry Cafiero is one of the founders of the Lindependence Project and develops business software at Redwood Digital Research, a consultancy that provides FOSS solutions in the small business and home office environment.)

Add to Technorati Favorites EFF Binary Freedom Dead button Wordpress button Xfce button dbEntrance button AntiX 7.0 fedora badge GIMP Scribus Linux Mint Kororaa Salix OS Fluxbox Conky Thunderbird LibreOffice Crunchbang Bodhi Linux PostgreSQL identi.ca python scale 10x

Eliminate DRM!

  1. June 30, 2013 at 11:40 am

    The reason why Unity hasn’t been established in any other distro is quite simple. Unity isn’t developed like an independent vender neutral piece of tech. There is no establish roadmap for releases…they drop releases out of the sky. And historically Unity requires non-trivial patching of other project code to work correctly…making life extremely difficult for any distribution that uses a different policy with regard to patchset selection than Ubuntu does. You can’t just build the Unity shell against stock upstream libraries and expect things to work. That’s a real problem for most distributions.

    Additionally Canonical has a track record of killing off specific Unity branded codebases so quickly that its not even clear its worth trying to get it up and running anywhere else.

    Mutter based Unity… dead within 6 months..replaced by compriz based Unity.
    qt based Unity2d…dead inside of what a year of its announcement? And this was actually the codebase that was the easiest to work work at the source code level to smoke test.

    compiz based Unity is now dead… why would anyone bother at this point to attempt to roll Unity7 into a distro when that entire codebase is a deadend?

    And now Unity8. Which on its surface seems like a much easier codebase to work with to pull into say debian… but alas… with the introduction of Mir/Xmir..the vendor specific patch situation is just as bad..but now lower down into the stack. Mir/Xmir requires patches to Mesa and xorg’s xserver…patches not formally submited to either of those projects to start discussion on integrating them. So any other distro has to make a judgement, is it worth the risk to enclude the mir enabling patchset into their mesa and xorg packages when there isn’t even on-the-record discussion about upstream mesa/xorg buy-in to include some version of those patches into the upstream mainline? I don’t think any other distribution team can safely judge that the mir enablement patches is worth the risk of inclusion. Until some version of the mir enablement patchset has a clear vector for inclusion into the upstream codebases, this stuff has to be considered the linux distribution equvilent of a mutagenic biohazard.

    How in the hell is any distro that has comptent..sane…patch review policy…going to justify pulling the necessary Mir enabling patches to make it possible to integrate Unity8 as a deliverable? Only distros which are derived for Ubuntu’s packages are going to do it..because they parasitically rely on Canonical to make those decisions for them. Debian on the other hand…. no way in hell is debian going to pull in the Mir patchset to xorg prior to it even being a recognized experimental upstream xorg feature branch.

    And technically speaking Mir hasn’t even had an official development release yet. No 0.000001 tarball or anything of the sort. Its a rolling furrball of hacked up bzr and git branches that get fed into Ubuntu’s packaging automation and vomits out binary staging packages. Noone can just take the necessary source code even from development head branches and build a local Mir/Xmir to play with and to test. The build from source instructions they provide ASSUME you are the necessary custom mesa and xorg from the Ubuntu ppa staging crap. No sane distribution maintainer is going to touch that code and waste time on it. No external upstream desktop environment developer is going to touch that code and play with or even attempt to see if Mir/Xmir is a supportable target for their DE codebase. The Mir build/test from source instructions make a very interesting contrast to the Wayland build/test from source instructions. I can and have built wayland from source without destablizing my running system because the devs have actually made an effort to provide an on-ramp to externals who need to work with the source code and need to smoke test in a local environment.

    Canonical has a hard time standing up projects that think about the needs of externals..even people working with debian instead of Ubuntu. So much of Canonical project “upstream” development is predicated on access to a running Ubuntu environment as the dev platform that even project teams have a hard time keeping up with what the actual minimum dependency requirements are for their code. “Whatever ships in ubuntu xx.yy” is the surragate response… and its just not sufficient for externals. If upstream projects can’t communicate what their minimum deps really are, and what specific downstream patchsets they rely on..then they aren’t an upstream project team you can rely on when you need to work with them to resolve a problem.

    So Unity will continue to be relegated to Ubuntu and Ubuntu derived distros, until such time Unity and Mir/Xmir devs teams start to think of themselves as delivering vendor neutral tech, and start thinking seriously about correctly documenting how to build and test their project directly from source code.

    Can you imagine how absolutely craptastic it would be to work with the kernel or xorg, if as a course of upstream development those projects produced srpm and rpm deliverables for a specific vendor environment and only had dev instructions on how to install those packages and test development/pre-release quality code? It would be horrible. And that is exactly analagous to how Unity/Mir upstream projects operate right now. No thought at all to providing the sufficient vendor neutral instructions to work with the upstream mainline. No thought at all, because fundamentally these projects are not classic upstream projects.

    These projects are vendor specific projects meant specifically to provide market differentiated tech and there is absolutely no interest in seeing them adopted widely. So meh. It actually hurts Canonical’s business position to see any other distro provide a compelling Unity experience so its works against their self-interest to make any effort at all to build the on-ramp for externals. In fact its actually not in their self-interest to see other DEs take up Mir native support. If Mir provides any advantage at all over xorg, then having Unity be the only environment that gets the full advantage ties right in with their new business stategy of the UI that spans mobile/device/desktop. The vision statement is only muddled if alternative DEs can replace Unity in that strategy. Canonical needs Unity to be superior in this regard. Keeping Mir difficult to work and Unity difficult to package externally works to their advantage as a business strategy…in the short term at least.

  2. joncr
    June 30, 2013 at 1:30 pm

    >>”…a metric which speaks to how good, or not, a desktop environment is would be its adoption by other distros.”

    Can’t really agree with that.

    People put DE’s in their distributions for all kinds of reasons, many of them having nothing to do with merit. Ego and Not-Invent-Here are in the mix, too. Plus, it seems a lot of developers and packagers are out to stiffarm Canonical, no matter what.

    Personally, as a user, the more the merrier. Competition is good. Lord knows we don’t have enough of it in FOSS. I have no loyalty; I’ll use the best product.

    • June 30, 2013 at 1:53 pm

      stiffarm Canonical? I call BS. Canonical makes it difficult to work with the codebase by taking an extremely cavalier attitude to patching other projects without getting buy-in from those projects before driving those patches into user-visible Ubuntu releases.

      Right now Mir/Xmir relies heavily on patches to mesa and xorg xserver that have not even been submitted for inclusion into those projects. That’s pretty much a non-starter situation for externals who _need_ to get Mir/Xmir up and running in their environments to smoke test and evaulate mir. Who is stiffarming who again?

      Canonical is stiffarming everyone else by making this tech hard to integrate by skipping the whole step of communicating back with the projects they are patching… BEFORE…they drive the patches into production…creating all sorts of really bad problems for any alternative DE dev team who gets blind sided by user bug reports from a system running Mir/xmir.

      No sir. Canonical is the one dousing bridges with gasoline and lighting them up with their indiscrimenate patch policy for other projects and their inability to actually you know _release_ Mir ahead of driving it into production for externals to work with at the source code level. They have given up entirely on the concept of upstream communication and are building a stack they control from a top-down management perspective without regard to the need to give anyone else time to work with the tech. It’s very…google of them really. Except of course, Google has the cash to pay for all the in-house development they need..and Canonical does not.

      • jonc
        July 4, 2013 at 5:55 am

        I’m a user, not a developer. What I see are a lot of developers upset with Canonical. That’s none of my concern. I have no skin in that game. If Canonical makes a better product, I’ll use it. Until someone else bests them.

  3. Colonel Panik
    July 3, 2013 at 5:44 am

    @Jef Spaleta, THANK YOU. The explanation you gave is perfect. I don’t understand
    a lot of the “how” that these distros do things but Ubuntu went wonky in a hurry.

    May I ad this: Unity is not unific.

    Lindependence rides again! Your fellow believers in the Portales Linux Users Group here in Portales, GNU Mexico are standing on the sidelines waving our pompoms and cheering
    you on to success. Maybe you could package this and send it around?

    @FSG is there a link? ” to participate in Software Freedom Day by signing up here.”

  4. jspaleta
    July 4, 2013 at 9:31 am

    jonc :
    I’m a user, not a developer. What I see are a lot of developers upset with Canonical. That’s none of my concern. I have no skin in that game. If Canonical makes a better product, I’ll use it. Until someone else bests them.

    if its none of your concern…. then why in the hell are you forming an opinion as to why developers are upset at Canonical. Go back and read your first comment again. Make a choice. Either care about developer relations, and get informed. Or don’t make driveby character assassinations concerning developer motivations. Either get informed of shut up.

    I really don’t care if you care or not about how developers feel. But I do care when people speak up in such an ignorant manner. I doubly care when that person then uses the age old “well I don’t really care” rhetorical when their ignorant opinion is challanged. What you have uttered previously is indefensible. Good day sir.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: