On 09/06/2012 09:22 AM, Scott Kitterman wrote: > > > Matthew Paul Thomas <m...@canonical.com> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Scott Kitterman wrote on 05/09/12 18:54: >>> >>> Matthew Paul Thomas <m...@canonical.com> wrote: ... >>>> >>>> That's a near-tautology. "Distributions" are named after the >>>> assumption that selecting and packaging other people's software >>>> is a way to produce a useful operating system. >>>> >>>> That may work for a few hundred thousand or even a few million >>>> notebook/desktop users, but it has failed to grow beyond that. >>>> The distro model discourages application developers, slows >>>> application updates (making the installed base less reliable and >>>> less secure), and distracts Ubuntu developers from improving >>>> Ubuntu itself. Eventually the time comes to say "enough, let's >>>> try something else". >>> >>> This though is a much bigger step than just providing an easy >>> entry point for additional apps. >> >> Sure. It's necessary but not sufficient. >> >>> It brings in many fundamental questions that need to be answered >>> before we can really start to proceed: >>> >>> - In this brave new world, what is the definition of "Ubuntu >>> itself"? If the application developers are unshackled then it must >>> be some subset of what we consider Ubuntu to be today. >> >> The shell and everything that makes it work (down to the kernel and >> init system), the toolchain, official developer APIs and the software >> that implements them, and whichever apps are installed by default. >> >>> - How do we provide stability for users that are more interested >>> in using what they have than the latest upstream crack that was >>> pushed out the door at 2am last night? >> >> By presenting application updates as opt-in rather than opt-out. >> <https://wiki.ubuntu.com/SoftwareCenter#updates> >> >>> - How do we deal with library transitions? >> >> Others on this list can answer that far better than I can. >> >>> - If application author s are getting unleashed, why can't library >>> authors get unleashed too? >> >> Because those are mutually exclusive (at least for libraries that are >> part of Ubuntu itself), and on a successful platform application >> authors are far more numerous and distributed. >> >> A library that wasn't part of Ubuntu itself could be unleashed in the >> same way, but it would be application authors' responsibility to judge >> how serious the library author was about backward compatibility. >> >>> - What about packages that provide both applications and >>> libraries? >> >> They would have to play by library rules: preserve backward >> compatibility, and/or not be part of the official APIs. >> >>> - What does it mean to be a distribution? >> >> A distribution is to an operating system as a runway is to a flight. >> It's the expensive but vital buildup of momentum before takeoff. >> >>> ... >>>> >>>> There are a lot of developers involved in packaging, compared to >>>> what? Two years ago there were 160 MOTUs. Today there are 149. >>>> That isn't how you scale to an order of magnitude more >>>> applications. >>> >>> Certainly, but that's also the result of a determined effort to >>> kill off MOTU from which that community has never recovered. There >>> is some good work going on now to bring in new blood, so I expect >>> the numbers to start to improve. >> >> I'm surprised to read of "a determined effort to kill off MOTU", but >> if those numbers increase then good. MOTUs will be vital for years to >> come. >> >>> I do agree that we need something different to scale to an order >>> of magnitude more applications. I don't agree that doing that >>> particularly solves any problems we're having. I can't remember >>> the last time I wanted a tool to do a job and there wasn't one >>> handy, with the exception of cases where a free software solution >>> wasn't legally possible. >> >> That's great, but not particularly telling, because if it wasn't true >> perhaps you'd no longer be here to discuss this. >> >>>> Maybe the current proposal isn't the best way to solve the >>>> problem. But the first step is to recognize the problem. >>> >>> I understand the problem statement. To the extent there are real >>> problems (e.g. key applications out of date), this proposal is >>> barely the tip of the iceberg of what would need to be addressed to >>> make the transition to a model where we outsource that to >>> application developers. >>> >>> ... >> >> So, assume that we can't do everything at once, but we want to act as >> soon as possible. What do you suggest we do as well, or instead? > > I suspect not everyone shares your definition of what Ubuntu is/will be. > Even the I favor a more traditional scope myself, I'm very surprised you > didn't include the desktop environment (e.g. Unity, Plasma, etc.). > > I think it's critical that there be some shared vision of where we are going > and even though there won't be resources to do everything at once, a broad > outline of the chunks of work needed to get there. > > To pick just one example, rolling delivery of applications and offering > multiple versions of the same package (which is what the BSD Unixes do, > although not in a way I've personally found at all satisfying as a user) > implies huge changes in package management. Not the least of which is the > ability to support downgrades, including migrating per user settings back to > previous versions. It doesn't give the user much to give them the ability to > choose when to upgrade a package if you don't also give them the ability to > change there mind if the experience is poor with the new version. > > In short, there ought to be some shared vision we can work towards. To twist > the story of the blind men and the elephant, if you're making a tail, it's > really hard to tell if you're doing it right if you don't know it will go on > an elephant. > > Scott K >
I assumed that the DE is part of what he meant by "The shell and everything that makes" and "official developer APIs" Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
