On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Scott Kitterman wrote on 06/09/12 14:22:
> > Matthew Paul Thomas <m...@canonical.com> wrote:
> >
> > ...
> >
> >> Scott Kitterman wrote on 05/09/12 18:54:
> > ...
> >
> >>> - 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.
> >
> > ...
> >
> > 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.).
>
> That's what I meant by "the shell".
Yes. Someone else pointed that out already.
> > 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.
>
> Windows, OS X, iOS, and Android all let an author issue a new or
> updated application within a week or so of wanting to, which I guess
> is what you mean by "rolling delivery". This whole discussion is
> predicated on that being a requirement for a mass-market OS.
On iOS and Android there's rather more extreme sandboxing than is being
proposed here that make potential interactions between applications less of an
issue. The term DLL hell was invented for Windows. I don't think it's at all
obvious that replicating the existing systems is a path to success.
There is an assumption here that there's a vast user base that awaits if only
it weren't so hard to run the latest versions of things. While there are
certainly many such people in the geek community, the vast majority of non-
technical end users neither know nor care about what version of anything they
are running. The class of users that will tell their friends "I just bought
Facebook" to mean the bought a computer isn't interested in such things. To
give a specific example, it was only about 5 years ago I got my father off of
Office 95 and that took pressure. He saw no reason to change something that
was
doing what he needed.
If Ubuntu wants to hit the mass market, it needs to find ways to be better, not
ways to be the same, but cheaper. Personally, while I know that application
developers get grumpy about it, I think that the stable model with periodic
upgrades if desired is something most users would like better than what they
experience with other O/S's. It's still good to find ways to make the flow of
fixing actual bugs work better, but I don't think there's a huge market for
getting every single application update and working through new sets of
issues.
> None of those OSes offer application downgrades (though individual
> applications might). None of them migrate user settings to previous
> versions. ("The file “iTunes Library” cannot be read because it was
> created by a newer version of iTunes. Would you like to download
> iTunes now?") And absent that settings problem, OS X is the only one
> that makes multiple application versions moderately easy ("portable
> apps" on Windows being the exception rather than the rule). That tells
> me that while they might be desirable, none of those three things is a
> requirement for a mass-market OS.
It is also quite normal for things to get screwed up on other operating
systems and people do a full reinstall to fix it. One of the fundamental
design principles behind package management in Debian and by extension Ubuntu
is that once installed, systems can just be upgraded. Reinstalls should not
be needed. I think this is an important feature that should not be lightly
abandoned. I think the implication of that is you've got to find a way to
support downgrades. I think it's feasible, perhaps using something like
etckeeper, but it would take work.
Allowing areas where we beat the proprietary competition in quality/
capability to degrade to their level is not a recipe for success.
> > 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.
> >
> > ...
>
> Even if that's a problem worth solving, that doesn't necessarily mean
> it's best solved at the same time as the app developer upload problem,
> or that it even affects the solution for that problem. If you think
> either is true, perhaps you could explain why, and describe how the
> solutions might coexist.
The app developer story is only one small part of a larger story. Without
having some understanding of the broader visions, it's hard to know what's
suitable and what's not. While I think the proposed changes, modulo resolving
the file conflict issue, are largely suitable to the goals that are proposed
for
them, that doesn't follow that this is a step towards delivering all
application this way.
The current ARB process and this new proposal are focused on a specific class
of applications that make use of some specific restricted features of the
operating system. The current proposal is geared towards that. If the real
goal though, is to deliver all applications this way, I think this proposal is
not very useful because I don't think it's extensible in the ways it would
need to be to grow into that.
So if the goal is the class of applications that the ARB has been focused on
so far, it's a decent proposal that with a little work is probably worth
doing. If the goal is ALL (or almost all) applications, then that's a very
different story. I think it's probably a dead end path.
That's why I believe it's important to have the larger picture in mind and
some consensus around it before plunging in to implementing bits of it that
may or may not prove to be useful to the actual long term goal.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
