Re: Why does Ubuntu have all the ideas?
On Mon, Aug 28, 2006 at 11:33:00AM +0200, Mgr. Peter Tuharsky wrote:
> >>I don't tell the ideology is not valid; I just tell that often this is
> >>in the state "Users, wait until we solve this ideologically, it may
> >>take some years". Well, user dosen't have the years and need things
> >>working, so he either does it himself (if he is sortof admin) by
> >>downloading, compiling etc, or says "Things don't work in Debian and
> >>it's too difficult to solve it. I'll better stick with XYZ".
> >Can you give a concrete and extensive example of this? It's hard to
> >discuss such things with hypothetical scenarios.
> Well, this is exactly the case why I have asked at the very beginning
> everyone not to try to play the catch-me this way.
It is not useful to discuss hypothetical scenarios, sorry. I refuse to
> I have given handful of examples, and if You really care, You'll find
> even more. Hint: video, graphics, acceleration..
Yes, but most of them were not valid.
> >Mplayer can be installed easily by adding the right line to your
> >sources.list. It's all over the internet. Same goes for codecs.
> Yes, I'll try to replicate that sentence to my aunt or cousin. It will
> be of great help for sure.
> Besides, if it is "that easy", why Debian just dosen't do it itself?
Because the mplayer people refuse to think about licenses, which means
that it is illegal software in many countries. We cannot take that risk.
> >Besides, mplayer is starting to get increasingly obsolete. There are
> >less and less things that cannot be played by either gstreamer or xine.
> >Which both have a *much* saner design, too.
> This is out of scope, however I also have much stuff that I cannot play
> on neither of these, but can on Mplayer. And I don't mean Windows Media
> by that.
I didn't say it is obsolete yet, but that it is getting there.
> >True type fonts and flash have nice installer packages that will
> >download and install the stuff for you. What's the problem?
> Did You try it in real?
wouter@country:~$ LC_ALL=C dpkg -l msttcorefonts
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
ii msttcorefonts 1.2 Installer for Microsoft TrueType core fonts
> >In case you missed it, there is now a java package in non-free for
> >unstable. Once etch releases, it will be in stable. Obviously we cannot
> >go ahead and change stable after the fact; but installing Java on a
> >Debian stable system is no harder than it is on a RedHat or Ubuntu or
> >Fedora or whatnot system. In fact, because of java-package, it's
> >actually easier to manage and uninstall if that ever becomes necessary.
> >I _really_ don't understand what your problem is here.
> We're speaking about distributions that are intended for daily use, not
> for experiments. To make it clear, Debian 3.1 Sarge and Ubuntu 6.06. If
> the Etch has it, that's great.
java-package has existed since way before sarge, and is part of that
The regular java package is not, but we obviously cannot just go ahead
and destabilize stable just for the sake of a java package. When I said
"it is in unstable", that was because we are working on getting better
integration with java in the *next* stable release. It was not a
suggestion that you should start using unstable.
> However that dosen't matter answering the "Debian is at least as good
> as Ubuntu, just needs more advertising". Would You advertise Etch? It
> is clearly advertised for Etch, that it is in TESTING state. Would You
> recommend it everyone for daily usage? I hope You'ld not.
That is so totally besides the point it isn't funny anymore.
Of course I wouldn't suggest etch for stable environments. But will you
at least allow me to point out that the problems you point to have been
fixed for the next stable release already?
There's nothing we can do to improve sarge now anymore, anyway; so
anything you suggest here would result in etch getting better when it
releases. Since there's a java package for etch, that particular problem
has already been dealt with.
(of course, that doesn't make etch and java be totally free of problems,
since the sun jdk is in non-free, not main. But still)
> >>1b, If things don't work, it's sometimes hard to get them working
> >>either. Example: Bug 372719. The OOo 2.0 keeps crashing for 2 months
> >>thank to KNOWN bug in security upgrade. Now tell somebody, that Debian
> >>is as good _for_average_Joe_user_ as Ubuntu. Or that Debian cares about
> >>average_Joe_user at least as much as Ubuntu does.
> >I can't comment on this; I'm writing this on the train, so have no
> >Internet access currently.
> >However, I will add that I haven't seen this bug on the stable systems
> >that I run; even though that of course doesn't have to mean anything, it
> >is at least an indication that the bug is not everywhere, and that it
> >may be a problem to track it down.
> Not every stable system runs security updates, and even less desktop
> systems do.
Their loss. I know I do, and my stable systems do not see the bug.
> That might be a reason why "everyone complains" is not the
> case. And might even becouse there are just too few desktop
> installations of Debian,
I suggest you google for "extramadura". Yes, they're slightly customized
and modified, but AIUI, they're not extremely radical.
> >There is an infrastructure to support a fully i18n'ed environment upon
> >installation. It uses language-based tasks, and the installer will
> >install the task of the language you've used in the installer upon
> >completion of the installation. If you chose to install the desktop
> >task, it will also install the desktop-$language task (or was it
> >$language-desktop? not sure, doesn't really matter).
> Do You speak of Debian Sarge?
Yes. The infrastructure has been improved for etch too, IIRC.
> >k3b actually has a "suggests" header for k3b-i18n. This means that if
> >you install k3b using a frontend such as apt-get or aptitude, it will
> >tell you up-front that there is a k3b-i18n package. They are separate
> >from eachother because k3b-i18n takes 15.2 MB when installed, whereas
> >k3b itself takes only half of that; some people may therefore prefer not
> >having k3b translations installed.
> Altogether, You exactly paint that picture -many things can be done in
> Debian. The difference is, that in user-friendly system, the user
> shouldn't even care about that.
What is "user-friendly"?
Is it user-friendly to dump a whole load of stuff on a user's system,
even if they do not have a whole lot of storage? Note that the
"k3b-i18n" package contains a *lot* of translations; not just the one
for your language (in fact, not even necessarily the one for your
> >"too" is a very subjective thing. I actually prefer not having to plan,
> >test, and execute upgrades every half year.
> The too-slow release plan is oscilating in Debian community too; I
> haven't invented the issue. You may not need the new versions of desktop
> software. Many users do.
It doesn't matter. The point is not that I do not need it; the point is
that Debian has not done it for many years, and that many of *our* users
*expect* it to take long before there is another Debian release. We
wouldn't be doing them a favour by shortening our release cycles too
Of course, some people *do* prefer shorter release cycles. Such people
should just not be using Debian.
> If You remember, the last year of Woody, many users escaped to other
> desktop distro,
Nobody is saying that woody wasn't getting too old by the time sarge
released. In case you missed it, we're well on track to release etch by
December 2006, which is approximately half the time it took us to get
sarge out the door.
It was a problem, it is being fixed. No point in pointing out problems
that have been fixed already.
I repeat: do you have an actual, founded gripe, or are you just
> >>We should, for certain kinds of software, shorten the release cycle to,
> >>say, 6 months.
> >You seem to think that it is possible to do this without having to
> >change the lower layers upon which you compile the software. This is
> >wrong. Newer versions of applications often require newer libraries to
> >support them, which in turn may also require newer versions of some
> >other packages. This is a very slippery slope.
> It is pretty well possible. I keep the whole Debian. I just install a
> few newer applications on top of that. They work much better than the
> distributional ones.
Giving an example to the contrary does not disprove the fact that it
'often' is so. I did not say that it 'always' is so.
If we go ahead and promise that we will update 'some layers' of Debian,
then the day we have to break that promise because things would
otherwise break, people will get mad.
Additionally, your idea isn't exactly new. People have tried and failed
to implement it. Google for "Componentized Linux", if you care.
> >>and it's nearly impossible to maintain that old software in meaningful
> >Mind if we decide about that for ourselves?
> That's exactly what I'm speaking of.
Please expand. If we decide that we want to keep things as they are, and
only update as necessary to fix security issues, then that's our
decision -- especially if we can keep it up.
> >>And who will ever use that ancient versions at the end.. Especially
> >>painful in the end time of release's lifecycle.
> >Have you ever talked to someone who has to maintain, say, a network of
> >20.000 nodes?
> I must humbly say, no, I haven't. My network is two grades smaller.
No offense, but it shows.
> A little paraphrase: "stable" means, that feature bugs are kept for the
> whole release circle; don't expect them to get fixed."
You could see it that way, yes.
Another way to see it: "stable" means that features will remain exactly
as they are, for as long as stable is supported. You can write scripts
and teach your employees how to use the software (with all its
peculiarities), and you won't have to revisit that until the next stable
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22