This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Maintainers/Packages List, 2003-11-01 (fwd)


I'm forwarding it since Petr isn't subscribed.

---------- Forwarded message ----------
Date: Sat, 1 Nov 2003 21:52:23 +0100
From: Petr Baudis <pasky@ucw.cz>
To: n@ml.org
Cc: fredlwm@fastmail.fm, cygwin-apps@cygwin.com
Subject: Re: Re: Maintainers/Packages List, 2003-11-01

Disclaimer: ELinks maintainer on the line.

Dear diary, on Sat, Nov 01, 2003 at 08:16:08PM CET, I got a letter,
where Daniel Reed <n=F5axq6iy7m4@public.gmane.org> told me, that...
> On 2003-11-01T16:42-0200, Frédéric L. W. Meunier wrote:
> ) On Sat, 1 Nov 2003, Daniel Reed wrote:
..snip..
> ) > ) links                   Sami Tikka              !!! last updated 2002-01-23
> ) > Our Links is from the 0-tree, whereas current is the 2-tree. I am not sure
> ) Links and Links2 are different projects. Both support SSL.
> ) Links2 would require XFree86 for graphical support. You
> To solve that it might be possible to have separate links and links-x11
> packages.
>
> ) Anyway, ELinks is a much better project, mainly the 0.5
> ) prereleases, but they have problems running under cmd.exe.

FYI, 0.5 is still under heavy development and is not suitable for
productional use. If you want stable ELinks version, use 0.4.

> I would hesitate at including (and thereby potentially endorsing) ELinks,
> which appears to be a "hostile fork" of the Links project code. Links is
> relatively feature-rich and is still actively maintained, and its
> maintainers advise against using ELinks.

In fact, we tried hard to cooperate and be friendly. And it is rather
sucessful with Mikulas, the Links-0.9x maintainer (and Links2
co-author). However, for some reasons the rest of the Links2 team does
not like us very much. I'm probably not quite objective source of
informations regarding this situation for you, so if you care, you can
check the mailing lists archives and just see for yourself.

Whatever - what matters is whether it is bad to include ELinks or not.
And I'm not sure if the reason of some Links authors not quite liking
ELinks should be enough not to include it. Various Linux distros (and
BSD clones) include both Links and ELinks (Debian, Gentoo, Redhat,
Mandrake, FreeBSD, ...) and they probably do not care about endorsing
something or not, what matters is the added value. And I don't think
ELinks would be an example of controversial project ;-).

There are both advantages and downsides of ELinks. ELinks sucks if you
want graphics rendering - ELinks just does not support that (yet). Same
with JavaScript - if you make use of the JavaScript implementation
Links2 has, you won't like ELinks, which can't do JavaScript at all
(yet).

Well, these are the two downsides of ELinks compared to Links2 I can't
think of... If you just want text browser, the missing JavaScript can be
balanced by XBEL bookmarks, persistent cookies, tabbed browsing (only in
devel series), better colors support (MUCH better in devel series),
passive FTP support, HTTP authentication, compression support, downloads
resuming, IPv6 support, mailcap support, internal scripting, much higher
configurability, UTF8 I/O... [fade out]

Links package certainly should not be *substituted* by ELinks. But it
would be maybe good to reconsider the ELinks fear based on some Links
web page.

By the way, details about ELinks history are available at
http://elinks.or.cz/history.html. Some description of the other members
of Links family is provided as well, but of course it should be taken
with equal care as Links comments about ELinks ;-).

PS: I'm not subscribed to the list, so please Cc me in replies.

Kind regards,

-- 

				Petr "Pasky" Baudis
.
To get something done, a committee should consist of no more than three
persons, two of them absent.
.
Stuff: http://pasky.ji.cz/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]