On Thursday, September 06, 2012 09:28:58 AM Michael Hall wrote: > 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"
Right. To me shell is something completely different, but I imagine you're right. Thanks, Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel