On Mon, Aug 28, 2006 at 11:33:00AM +0200, Mgr. Peter Tuharsky wrote:
Wouter:
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
do that.
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
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ 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
distribution.
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
language).
[...]
"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
drastically.
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
trolling?
[...]
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.
[...example snipped...]
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
way.
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
releases.