Current situation of amarok, and of latex tools
ciancia at di.unipi.it
Thu May 14 13:30:11 UTC 2009
Il giorno gio, 14/05/2009 alle 19.55 +0800, John McCabe-Dansted ha
> On Thu, May 14, 2009 at 2:39 AM, Daniel Chen <seven.steps at gmail.com> wrote:
> > Grave for whom? For you? For what common use cases? These are things
> > that are factors to consider when affecting an entire release.
> Quite. I haven't noticed any problems with LaTeX. This may be because
> I use LyX+xdvi. LyX+Okular seems to be fine too, although Okular is
> rather sluggish compared to xdvi, it is usable unlike e.g. Acroread
> (on either Linux or Windows). Forward and backward search "works for
> me" in Okular.
AFAIK okular does not implement forward search :) If it does then tell
us how because I want to close the bug. For backward search I think you
refer to emacs or other tex editors, because lyx does not implement it.
If it did, lyx would be the perfect creation of the Tex God :) If it
does, then I have to light a candle for the aforementioned God.
> LyX also has all the features the OP mentioned, though it is more of a
> GUI than an text editor
Lyx can't be used in environments where other people use pure tex. It
may work with some effort, but the point is that you constantly have to
convert between lyx and tex. And unfortunately in research I can't just
go to my professor and tell him to use lyx. He is a busy scientist and
is productive with his own tools.
> AFAICT Amarok didn't just have a couple of annoying bugs, it was never
> really ready for widespread use. According to Jeff Mitchel "We've
> maintained that until 2.1, most users should stick with 1.4.
> Unfortunately, just as Intrepid shipped with the
> it's-not-meant-to-be-a-user-release KDE 4.1, Jaunty shipped with
> Amarok 2.0."
Could you provide a link to this?
> Ubuntu introduces regressions far faster than any mortal could be
> expect to fix them. More unpaid bug fixers would help slightly, but we
> can't solve the problem without limiting the number of regressions and
> severity of regressions. Here are some ways this could be achieved:
> 1) Clear communication with upstream. If we could agree on a way of
> clearly marking (e.g. Early Adopter Release) releases that are not
> meant for widespread consumption, then Ubuntu could made a policy of
> not making EAR releases the default except in exceptional
I personally would love this. Also the opposite: if upstream clearly
recommends a release ubuntu should prioritise adopting that release. If
upstream recommends NOT to use a certain switch, ubuntu should not use
it. In normal circumstances, and "cum grano salis" indeed, not like in
front of a court of mathematicians :).
E.g., I had to struggle quite a bit to remove the "enable assertions"
option from lyx in ubuntu. Upstream did not recommend it and it made lyx
as slow as a snail. But the debian maintainer was mistakenly convinced
that it was very useful. Better communication with upstream would have
saved me and the persons who sponsored my upload some time, and would
have saved users from switching to other distributions or recompiling
lyx in the meantime. Perhaps freedesktop.org could be a place where to
discuss a standard way to publish links to information about releases in
a machine readable format, together with the source code of a program.
Don't know. It would be a big innovation, hence a long path.
> Windows has the advantage in this case that it is up to the user which
> versions of applications they install, thus a regression in an
> application is rarely a regression in windows. There are a number of
> avenues to reduce the impact of application regressions on Ubuntu.
That's a disadvantage in windows. Letting the computer choose the right
version of a thing for me is very comfortable. So we should do this
> 2) Make it easier to chose the version of the application you want.
> This has become easier, with PPAs and multiple versions of
> contraversial applications packaged. There is still some way to go in
> making these options more easily available to the user. Perhaps there
> should be a standard and easy way to "revert this application", and
> the user could be informed of this option during upgrade.
You can already add the intrepid repository and then block a version of
a package. You don't get intrepid's upgrades, though; if you don't block
it, it gets reverted to jaunty with next upgrade. Adding priorities to
synaptic and perhaps adding the old repository by default would be nice,
but it is a big change and I bet it has many drawbacks.
> 3) Make it easier to revert to an old version of Ubuntu. There is some
> work on this using aufs, but currently you can't reboot into the new
> version so you can't really tell how well it works, all you know is
> whether the upgrade itself is smooth. If you could keep the old
> version of Ubuntu around in the same way you can keep old kernels
> around this would really help. Btrfs may help here, and the
> reflink/cowlink systcalls they are proposing for ext4 may also help.
That is not going to convince new users: they'll install the latest
release, notice that it sucks in their favourite area (e.g. texing),
laugh in the face of who adviced ubuntu (e.g. "hey didn't you say that
linux was great for texing? then how do I spellcheck a document? How do
I do inverse search?") and then get back to windows or osx. Again, yes,
emacs does it all, I do not question it. Your ordinary texnic center
user will, OTOH.
More information about the Ubuntu-devel-discuss