Netscape releasing Source
Mark Lehrer
I understand that Netscape will be releasing the source code to their
Communicator 5.0.
I'd bet it's just Navigator and not abra-Collabra.
This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
leak in 4.04 if I get Motif libs.
Mark
Ramiro Estrugo
nope...it everything.
-re
Joe A. Grassel
Mark Lehrer (ma...@lehrer.nlcomm.com) wrote:
:
: I understand that Netscape will be releasing the source code to their
: Communicator 5.0.
:
: I'd bet it's just Navigator and not abra-Collabra.
:
: This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
: leak in 4.04 if I get Motif libs.
Forget Motif, let's convert it to use GTK instead.
Joe A. Grassel
Joe A. Grassel (vena...@aero.und.edu) wrote:
--------
That should be gra...@aero.und.edu. Some environment variable seems to
get messed up at login.
<snip>
: :
:
David Hinds
Chris Mikkelson (mikk...@maroon.tc.umn.edu) wrote:
:
: > I understand that Netscape will be releasing the source code to their
: > Communicator 5.0.
: >
: >
: > This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
: > leak in 4.04 if I get Motif libs.
:
: checked on Netscape's page, and was very encouraged. It sounds
: like they are going to make the source code very much free
: (for use, modification, *and* redistribution).
...
I think this is a very smart move on Netscape's part. If you've
decided to give a product away, it makes very good sense to also
release the source code. In so doing, Netscape has just "hired" a
team of Linux programmers to hack away at it and make improvements,
which may be folded back into the official version later.
And now that Microsoft is folding their browser technology into the
OS, it seems to me that it would be quite tricky if not impossible for
them to do the same thing with Internet Explorer, even overlooking
their history of never releasing source code.
-- Dave Hinds
stephen farrell
Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
> I wonder how easily it will be to dike out the mail/news reading
> parts of it?
Um... this has been available for *months*--it's called navigator
standalone...
--sf
robert havoc pennington
Arun Sharma <ash...@nospam.netscape.com> writes:
>
> It's going to be everything that we don't have third party license
> restrictions on.
>
> Start working on your TODO lists!
>
> -Arun
Let us in on the full license terms! Will the FSF consider it free
(except for dependencies), or will it have some restrictions (news.com
implies it'll require any modifications to be submitted to you, for
example).
Havoc Pennington
Arun Sharma
Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
>
> I wonder how easily it will be to dike out the mail/news reading
>
There is already a version of Navigator without mail/news available
from Netscape.
-Arun
--
Opinions mine only.
Chris Mikkelson
vena...@aero.und.edu (Joe A. Grassel) writes:
> Mark Lehrer (ma...@lehrer.nlcomm.com) wrote:
> :
> : I understand that Netscape will be releasing the source code to their
> : Communicator 5.0.
> :
> : I'd bet it's just Navigator and not abra-Collabra.
> :
> : This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
> : leak in 4.04 if I get Motif libs.
> :
>
> Forget Motif, let's convert it to use GTK instead.
>
Or LessTif.... I'm kinda hoping it will compile with that as-is.
A GTK conversion could be very hard depending on how the code is
arranged. I probably shouldn't say too much more before we see
the actual source.
-Chris
Marc Lepage
Mark Lehrer wrote:
>
> I understand that Netscape will be releasing the source code to their
> Communicator 5.0.
>
> I'd bet it's just Navigator and not abra-Collabra.
>
> This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
> leak in 4.04 if I get Motif libs.
>
Netscape is freely releasing Communicator Standard Edition, which
supercedes Navigator Standalone. By March they will release the source
code to Communicator Standard 5.0. The Professional Edition will remain
commercial, but at a reduced price (~$30US).
Netscape is also going to provide a forum (NetCenter) for coordinating
development and making enhancements available.
--
SEGV
Marc Lepage
Arun Sharma wrote:
>
> And start thinking about comp.browser.netscape.* newsgroups ;)
>
> -Arun
"Netscape Everywhere" eh? :-)
--
SEGV
Marc Lepage
>
> restrictions on.
>
> Start working on your TODO lists!
Arun, how will this affect Netscape's Java support? Doesn't Netscape
have its own VM? How about 1.2 and Swing (JFC)?
--
SEGV
Arun Sharma
On Thu, 22 Jan 1998 22:22:32 -0500, Marc Lepage wrote:
m> Arun, how will this affect Netscape's Java support? Doesn't
m> Netscape have its own VM? How about 1.2 and Swing (JFC)?
I can't comment on that one :(
-Arun
Ramiro Estrugo
As someone that works on the x/motif front end for communicator, there
is nothing I would like to see more than a good gtk based netscape.
Make it so...
-re
Joe A. Grassel wrote:
>
> Mark Lehrer (ma...@lehrer.nlcomm.com) wrote:
> :
> : I understand that Netscape will be releasing the source code to their
> : Communicator 5.0.
> :
> : I'd bet it's just Navigator and not abra-Collabra.
> :
> : This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
> : leak in 4.04 if I get Motif libs.
> :
Elliot Lee
On 22 Jan 1998 16:32:03 -0600, Chris Mikkelson
<mikk...@maroon.tc.umn.edu> wrote:
>vena...@aero.und.edu (Joe A. Grassel) writes:
>
>> Mark Lehrer (ma...@lehrer.nlcomm.com) wrote:
>> :
>> : I understand that Netscape will be releasing the source code to their
>> : Communicator 5.0.
>> :
>> : I'd bet it's just Navigator and not abra-Collabra.
>> :
>> : This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
>> : leak in 4.04 if I get Motif libs.
>> :
>>
>> Forget Motif, let's convert it to use GTK instead.
>>
>
>Or LessTif.... I'm kinda hoping it will compile with that as-is.
>
>A GTK conversion could be very hard depending on how the code is
>arranged. I probably shouldn't say too much more before we see
>the actual source.
Remember, this browser already runs on the Mac, Windows, and X-Windows.
Portability should be fair-to-middling...
-- Elliot
Will read UCE for food! Charge of only $500 per message received. ;-)
Tero Pulkkinen
Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
> > Forget Motif, let's convert it to use GTK instead.
> >
>
> Or LessTif.... I'm kinda hoping it will compile with that as-is.
Naah, GTK all the way. We're supposed to make it better, not worse :)
> A GTK conversion could be very hard depending on how the code is
> arranged. I probably shouldn't say too much more before we see
> the actual source.
I dont think porting from motif is too hard. Remember that gimp
originally was using motif and thus gtk is probably (I dont know motif
enough to say) using pretty much the same consepts. I think there will
be many versions of netscape when the source gets out with license
even near the GPL.
--
-- Tero Pulkkinen -- te...@modeemi.cs.tut.fi --
Paul D. Smith
%% sop...@bogus.circ.us.eu.org (Elliot Lee) writes:
>>> : I understand that Netscape will be releasing the source code to their
>>> : Communicator 5.0.
>>>
>>> Forget Motif, let's convert it to use GTK instead.
>>
>> Or LessTif.... I'm kinda hoping it will compile with that as-is.
>>
>> A GTK conversion could be very hard depending on how the code is
>> arranged. I probably shouldn't say too much more before we see
>> the actual source.
el> Remember, this browser already runs on the Mac, Windows, and X-Windows.
el> Portability should be fair-to-middling...
Hold it, everyone!
Although full details aren't available, note Netscape is releasing the
source for Netscape _5.0_, not the existing versions.
The next-generation Netscape browser, nick-named "Javagator", code-named
"Maui", is a complete rewrite of Netscape in Java. It seems fairly
certain that _this_ is the version which will be released under the GPL,
not the existing C/C++ browser.
Take a look at http://www.news.com/News/Item/0,4,17705,00.html
Which isn't to say it's not still a cool thing for Netscape to do, but
it's not quite what everyone seems to be assuming it is.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
Ramiro Estrugo
Hold it everybody...
Netscape will release the current source base. Which will basically be
4.0x with many performance and stability improvements. There will also be
some new KEY features, but now nearly as many as in the 3.0x -> 4.0x
transition.
I know it sounds too good to be true. Believe it. Its happening.
-re
Ramiro Estrugo
Unix Communicator
--
-re
Gael Duval
Joe A. Grassel wrote:
> Mark Lehrer (ma...@lehrer.nlcomm.com) wrote:
> :
> : I understand that Netscape will be releasing the source code to their
> : Communicator 5.0.
> :
> : I'd bet it's just Navigator and not abra-Collabra.
> :
> : This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
> : leak in 4.04 if I get Motif libs.
> :
>
> Forget Motif, let's convert it to use GTK instead.
Or dynamically linked with Qt for the KDE ! :-) Great !!!!!!!
Cheers,
Gael.
--
////////////////////////////////////////////////////////
// Gael DUVAL - Reseaux & Applications documentaires //
/ LINUX, LINUX, LINUX ///
/////////////////////////////////////////////////////
Marc Lepage
What will the source be like? Is it well commented and documented?
Perhaps even with doc comments? Does it follow design patterns, or is
spaghetti the order of the day?
Ramiro Estrugo wrote:
>
> Hold it everybody...
>
> Netscape will release the current source base. Which will basically be
> 4.0x with many performance and stability improvements. There will also be
> some new KEY features, but now nearly as many as in the 3.0x -> 4.0x
> transition.
>
> I know it sounds too good to be true. Believe it. Its happening.
>
> -re
>
> Ramiro Estrugo
> Unix Communicator
>
> psm...@baynetworks.com (Paul D. Smith) writes:
>
> > %% sop...@bogus.circ.us.eu.org (Elliot Lee) writes:
> >
> > >>> : I understand that Netscape will be releasing the source code to their
> > >>> : Communicator 5.0.
> > >>>
> > >>> Forget Motif, let's convert it to use GTK instead.
> > >>
> > >> Or LessTif.... I'm kinda hoping it will compile with that as-is.
> > >>
> > >> A GTK conversion could be very hard depending on how the code is
> > >> arranged. I probably shouldn't say too much more before we see
> > >> the actual source.
> >
> > el> Remember, this browser already runs on the Mac, Windows, and X-Windows.
> > el> Portability should be fair-to-middling...
> >
> > Hold it, everyone!
> >
> > Although full details aren't available, note Netscape is releasing the
> > source for Netscape _5.0_, not the existing versions.
> >
> > The next-generation Netscape browser, nick-named "Javagator", code-named
> > "Maui", is a complete rewrite of Netscape in Java. It seems fairly
> > certain that _this_ is the version which will be released under the GPL,
> > not the existing C/C++ browser.
> >
> > Take a look at http://www.news.com/News/Item/0,4,17705,00.html
> >
> > Which isn't to say it's not still a cool thing for Netscape to do, but
> > it's not quite what everyone seems to be assuming it is.
> >
> > --
> > -------------------------------------------------------------------------------
> > Paul D. Smith <psm...@baynetworks.com> Network Management Development
> > "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
> > -------------------------------------------------------------------------------
> > These are my opinions--Bay Networks takes no responsibility for them.
>
> --
> -re
--
SEGV
Ramiro Estrugo
Well, you'll just have to wait and see.
-re
Ramiro Estrugo
Unix Communicator
Arun Sharma
Tero Pulkkinen <te...@assari.cc.tut.fi> writes:
> I think there will be many versions of netscape when the source gets
> out with license even near the GPL.
Let's pray that it doesn't happen and try to keep it unified. Browser
fragmentation isn't going to help anyone.
-Arun
Paul D. Smith
%% I wrote:
>> > The next-generation Netscape browser, nick-named "Javagator", code-named
>> > "Maui", is a complete rewrite of Netscape in Java. It seems fairly
>> > certain that _this_ is the version which will be released under the GPL,
>> > not the existing C/C++ browser.
%% Ramiro Estrugo wrote:
>> Netscape will release the current source base. Which will basically be
>> 4.0x with many performance and stability improvements. There will also be
>> some new KEY features, but now nearly as many as in the 3.0x -> 4.0x
>> transition.
Yep; I've seen some unofficial email from developers working at Netscape
this morning, and they say that the released code will indeed be the
existing Netscape code base, with some cleanups, etc. They make the
excellent point that they don't have the developer-cycles to put into a
major rewrite of the code, just to turn around and get no revenue from
it.
However, this person also suggested that the licensing might not be as
"free" as vanilla GPL. However, it's way too early to start getting
riled about this; there's just not enough data to draw conclusions.
So, sorry for the misinformation! Back to your regularly-scheduled
salivating.
Doug DeJulio
In article <34C80CF8...@cgocable.net>,
Marc Lepage <mle...@cgocable.net> wrote:
>Arun Sharma wrote:
>> It's going to be everything that we don't have third party license
>> restrictions on.
>
I am *sure* that if it doesn't include Java, one of the first projects
will be to get it workking with Kaffe/Guava. And I usually leave Java
and JavaScript disabled anyway...
*I'm* excited about the possibility of getting a reasonable GUI IMAP
mailer for free.
--
Doug DeJulio | mailto:d...@hks.net
HKS, Incorporated | http://www.hks.net/~ddj/
Chris Mikkelson
Gael Duval <du...@unicaen.fr> writes:
> Joe A. Grassel wrote:
>
> > Forget Motif, let's convert it to use GTK instead.
>
> Or dynamically linked with Qt for the KDE ! :-) Great !!!!!!!
>
Not to start up the Qt license flamewar again (I'm serious, now...),
but I'd prefer to:
1) Remove bloat, not add, and
2) Stay with a *free* toolkit. Qt cannot be modified by anybody
outside of troll tech according to their so-called "free software
license."
Flames/responses *via e-mail*
Chris Waters
Arun Sharma <ash...@nospam.netscape.com> writes:
> Tero Pulkkinen <te...@assari.cc.tut.fi> writes:
Well, except those who don't want to use the standard version of
course. This is always a tricky question. Does having three free
BSDs help or hurt BSD? Does having CDE, KDE, GNOME and GNUSTEP help
or hurt UNIX? Should everyone in the world be using the same OS?
(That last is obviously a loaded question in this group.)
Personally, I think some branching might be a good thing. I can
understand why someone from Netscape might find this a little scary,
though. Just remember, it can be a good thing *if* it's intelligently
managed.
Heck, there already *is* branching in a sense, if you consider the
Windows, Mac, and Motif versions as branches. And there's little
question that people are going to want to create a GTK branch, and
probably even a (yuck) Qt branch. Maybe we'll even see an
Inferno/Plan 9 branch.
--
Chris Waters | The real problem with the the year 2000 is
cwa...@systems.DHL.COM | that there are too many zero bits and that
xt...@dsp.net (personal) | adversely affects the global bit density.
www.dsp.net/xtifr/ (web) | -- Boyd Roberts <bo...@france3.fr>
Gregory Propf
>Forget Motif, let's convert it to use GTK instead.
OK, what's GTK?
George
>>Forget Motif, let's convert it to use GTK instead.
>
>OK, what's GTK?
LGPLed toolkit that better and faster then Motif (and far less bloated),
yet still very OO .. and written in C with bindings for MANY langauges ...
look at http://www.gimp.org/gtk
gtk is in it's final stages, so that 1.0 will be released fairly soon now,
but it's already very stable and the interface is not changing too much
anymore ...
I'd expect 1.0 before netscape comes out in source anyway ...
also would be nice to "gnomify" the navigator ... once an ORB is chosen and
implemented ... (www.gnome.org)
George
--
------------------------------------------------------------------------------
George Lebl <ji...@5z.com> http://www.5z.com/jirka/
------------------------------------------------------------------------------
While some may have the year 2000 | $ emacs
problem, my 64-bit alpha's got the | bash: emacs: command not found
year 292471208677 problem | YES!!
Marc Lepage
Java is important because companies such as the one I work for are
building multi-tier architectures to perform enterprise stuff using
servers, Java applets, CORBA, etc. One of the IMPORTANT things is
running the thin clients in the browsers that the customers already
have. In fact, this is so important that we have to write Java 1.0
compliant code because our customers (enterprises, not individuals)
simply will not upgrade to Java 1.1 compliant browsers this early.
If Netscape Navigator cannot perform this function, those enterprises
will switch to MS IE. The more market share IE gains, the worse off
Netscape and its browser will be. So even if you don't run Java, believe
me it is important.
--
SEGV
M Sweger
Paul D. Smith (psm...@baynetworks.com) wrote:
: %% I wrote:
: Yep; I've seen some unofficial email from developers working at Netscape
: this morning, and they say that the released code will indeed be the
: existing Netscape code base, with some cleanups, etc. They make the
: excellent point that they don't have the developer-cycles to put into a
: major rewrite of the code, just to turn around and get no revenue from
: it.
Hi,
I was thinking that maybe the US Government could bail them out by
giving R&D funding (deep pockets) support to Netscape as a subsidy so that
they can compete agains't Msoft. They might as well level the playing field.
If both Msoft and Netscape go at it by offering stuff for free, then the
only thing left is the money part. Remember the Postgres RDBMS that we use
for Linux was orginally funded by the US government under a DARPA contract
with the University of Berkley back in about 1975-1980 by some graduate
students and a professor. That is why the source code for will be forever
free. This is similar to the browser Mosaic which was done under NSF
(National Science Foundation) contract, the CU-SEEME and the ability to
talk on the network. It just happens that the professor went and started
a company which was the Ingres RDBMS based on this code,
then sold the company around 1985 and then
came back on another government contract to develop Montage (later Illustra)
which then was sold to Informix. The same applies to Mosaic whereby Andressen
started Netscape in 1995. Alot of software that is free on the net was
either developed by hobbyists or under government contract which was later
copied by the larger corporations (such as Msoft) and sold as their own
original ideas and as new technology.
The same reasons could be applied to just about any s/w that
has been developed. So whats the difference, you have Universities, large
companies and some small companies that all have been funded by the US
Government to improve upon and develop s/w for later use in commericial
products that you then have to pay and license. The same may apply to
stuff developed over seas - but in this case be funded by their own
respective governements.
My 0.02c
--
Mike,
mik...@whiterose.net
Christopher B. Browne
On 23 Jan 1998 07:33:15 +0200, Tero Pulkkinen <te...@assari.cc.tut.fi> posted:
>Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
>> > Forget Motif, let's convert it to use GTK instead.
>>
>
Most important principle:
If a month's worth of effort makes "GNU-Netscape" run with Lesstif, that
provides *working system* sooner than if making "GNU-Netscape" run using Gtk
takes 4 months.
While neither 1 month nor 4 are precise estimates, I'd hazard the guess that
they're fairly characteristic of reality.
--
I develop for Linux for a living, I used to develop for DOS.
Going from DOS to Linux is like trading a glider for an F117.
(By ent...@world.std.com, Lawrence Foard)
cbbr...@hex.net - "What have you contributed to Linux today?..."
<http://www.hex.net/~cbbrowne/lsf.html>
Uri Blumenthal
Jamie Zawinski wrote:
> I'd be surprised if making Mozilla work with Lesstif took more than a
> week. I think that Mozilla's use of Motif is not particularly
> complex.
I agree.
> I think that retargetting it to a different GUI toolkit, given that
> the free implementation of Motif exists, would be a huge waste of
> time. There are ten zillion improvements you could make; who cares
> what toolkit it uses, as long as it works and the toolkit is widely
> available.
I strongly support this opinion, and urge serious developers to
concentrate on bug-fixes and adding *important* features. Let
the crackpots who can't hear the word "Motif" without emitting
foam, convert it to GTK or whatever.
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer> COLT...The original point and click interface!
Mark Lehrer
>>> This is wonderful news! I can fix that !#%^%@ Linux Netscape
>>> memory leak in 4.04 if I get Motif libs.
>>
>> Forget Motif, let's convert it to use GTK instead.
> Or dynamically linked with Qt for the KDE ! :-) Great !!!!!!!
SVGAlib would be nice... and I want to remove the capability of
the browser to launch multiple browsers... I hate that.
Also - the ability to accept/refuse cookies per host is something I
want... i.e. refuse cookies from all hosts that I have not
specifically allowed.
Mark
Christopher B. Browne
On Sun, 25 Jan 1998 04:22:09 -0800, Jamie Zawinski <j...@netscape.com> posted:
>Christopher B. Browne wrote:
>>
>> If a month's worth of effort makes "GNU-Netscape" run with Lesstif, that
>> provides *working system* sooner than if making "GNU-Netscape" run using Gtk
>> takes 4 months.
>>
>> While neither 1 month nor 4 are precise estimates, I'd hazard the guess that
>> they're fairly characteristic of reality.
>
>week. I think that Mozilla's use of Motif is not particularly complex.
I'll certainly trust the opinions of a developer that works at Netscape over
other opinions, with the caveat that it may involve more than simply syncing
things with a different GUI toolkit...
The more major things that are liable to cause "difficulties" that consume
time are that some pieces of "Mozilla" aren't Netscape's property to give
away, such as the JVM that is very probably licensed from SunSoft, SSL
components from RSA, and assorted other things from Bitstream, Marimba,
INSO, SGI, Visigenic, and Object Design.
>I think that retargetting it to a different GUI toolkit, given that the
>free implementation of Motif exists, would be a huge waste of time.
>There are ten zillion improvements you could make; who cares what
>toolkit it uses, as long as it works and the toolkit is widely
>available.
99% agreed.
Those that want a Gtk-based web browser should work on "Mnemonic."
Although there would be *some* value to targetting another GUI, if that
allows common functions to be shared, thus saving on memory consumption.
Saving 4MB of memory is worth about $10 these days...
--
Christopher B. Browne
On 25 Jan 1998 17:38:06 -0500, Mark Lehrer <ma...@lehrer.nlcomm.com> posted:
>
>>>> This is wonderful news! I can fix that !#%^%@ Linux Netscape
>>>> memory leak in 4.04 if I get Motif libs.
>>>
>>> Forget Motif, let's convert it to use GTK instead.
>> Or dynamically linked with Qt for the KDE ! :-) Great !!!!!!!
>
>SVGAlib would be nice...
By the time that you've created a set of "graphics infrastructure" capable
of replacing the combination of X and Motif, you'll have pretty much created
a "monster" about as big and "bad" as X/Motif.
X has the advantage over all comers at this time on UNIX and UNIX-like
systems that it is:
a) Generally available on *many* platforms (e.g. - more than just Linux), and
b) Runs on lots more devices than any alternatives.
In contrast, SVGAlib only supports a few graphics cards, and notably does
NOT support many of the newer ones. GGI has big plans, but presently only
supports a few graphics cards on Linux and a *tiny* number of frame buffer
systems on other platforms. GGI of course supports *LOTS* of graphic
systems if run atop X...
I'm not aware of any other alternatives to SVGALIB and GGI that would be
reasonable to consider. And they would of course only replace X. You would
still be left with recreating Motif. And there are at this time *no*
libraries running atop SVGALIB/GGI that provide anything resembling a
full-featured GUI.
Moving from Motif to Gtk *could* be reasonable; one could equally argue for
a number of other X libraries such as Tk, FL, Fresco, GNUStep, or wxWindows.
An even better choice would arguably be to use the wxWindows C++ class
library, as that could be used to simultaneously target both UNIX and
MS-Windows systems. (In the case of X, Gtk would be an acceptable "target.")
Wouldn't it be nice for us to have benefit of Windows users' interest and
assistance?
Of course, retargetting in this fashion would probably require a substantial
rewrite of big chunks of the system, thus putting off availability of a
useful release probably 'til at 1999. Comparing that to having a release in
April 1998 using Motif or Lesstif, *I THINK I CAN LIVE WITH LESSTIF.*
>and I want to remove the capability of
>the browser to launch multiple browsers... I hate that.
That might be easy enough to code in, albeit being something you are
unlikely to get substantial agreement for. I quite *like* the fact that I
can dispatch multiple browsers. It's quite useful to me, as I can browse
and compare multiple pages at once. I do *NOT* want to remove this
capability. I suspect that the "allow launching multiple browsers" camp is
more likely to "win..."
>Also - the ability to accept/refuse cookies per host is something I
>want... i.e. refuse cookies from all hosts that I have not
>specifically allowed.
This is more appropriately handled via a separate process. No need to add
Yet Another Configuration File to Netscape, when you can install something
like JunkBuster, which does this quite nicely, and can do the task for all
web browsers as opposed to merely Netscape. (Thus requiring
reimplementation for any other web browser one might try...)
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
Jonathan Apfelkern
Tero Pulkkinen wrote:
>
> Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
> > > Forget Motif, let's convert it to use GTK instead.
> > >
> >
>
> Naah, GTK all the way. We're supposed to make it better, not worse :)
And most of all: THREADED.
I hate not being able to use netscape for five minutes just because
of some stupid hostname lookup.
Jonathan
Jonathan Apfelkern
Doug DeJulio wrote:
>
> In article <34C80CF8...@cgocable.net>,
> Marc Lepage <mle...@cgocable.net> wrote:
> >Arun Sharma wrote:
> >> It's going to be everything that we don't have third party license
> >> restrictions on.
> >
> >Arun, how will this affect Netscape's Java support?
>
> I am *sure* that if it doesn't include Java, one of the first projects
> will be to get it workking with Kaffe/Guava. And I usually leave Java
> and JavaScript disabled anyway...
Who cares?
> *I'm* excited about the possibility of getting a reasonable GUI IMAP
> mailer for free.
Yes, that's nice! Not only a separate navigator, but a separate mailer
and a sparate newsreader too. And MY icons in the titlebar, and the
widgets I want, etc...
Jonathan
David M. Cook
On Sun, 25 Jan 1998 04:22:09 -0800, Jamie Zawinski <j...@netscape.com> wrote:
>There are ten zillion improvements you could make; who cares what
>toolkit it uses, as long as it works and the toolkit is widely
>available.
If you're already using Gtk on your desktop, a Gtk Netscape will load faster
and take less memory.
Dave Cook
M Sweger
Jamie Zawinski (j...@netscape.com) wrote:
: Elliot Lee wrote:
: >
: > Contrary to popular opinion, threads don't solve design problems. They
: > just (a) allow you to take advantage of multiple processors for
: > CPU-intensive problems (b) increase program overhead.
: Absolutely true.
So, does this mean that I shouldn't write code using threads unless it
is a multiple processor system?
--
Mike,
mik...@whiterose.net
Wolfram Gloger
Jamie Zawinski <j...@netscape.com> writes:
> Elliot Lee wrote:
> >
> > Contrary to popular opinion, threads don't solve design problems. They
> > just (a) allow you to take advantage of multiple processors for
> > CPU-intensive problems (b) increase program overhead.
>
> Absolutely true.
Absolutely not. Threads solve a whole class of design problems with
extremely little `program overhead' (as in used resources overhead)
and little programming overhead (which was probably meant above).
The discussion below is an excellent example.
> > For example, Gnome (http://www.gnome.org/) has a totally non-blocking
> > DNS lookup mechanism, and there's not a single program that uses
> > threads in Gnome.
If this ends up becoming Gnome policy (no threads whatsoever), that is
a real shame ! Win32 and Java have had a working thread model for
ages, not without reason. GUIs without concurrency are extremely
awkward.
> I've posted technical details about how this works a few times;
> see <342876E8...@netscape.com> from c.i.w.b.x back in September.
> (DejaNews will find it in the "old" database if you do an advanced
> search for "~a j...@netscape.com fork dns".)
In those articles, you admit yourself that the `fork' approach has a
lot of overhead.
> Using native threads would not make your DNS problems magically go away.
> They are just an implementation detail. The real problem is that Unix
> does not have a non-blocking API for hostname lookup, meaning that doing
> it in a nonblocking way is either, very hard, or unportable (pick one.)
No. Using threads _will_ make the problem go away. You just use the
blocking API gethostbyname_r() in a subthread and post a condition
when it returns. The main thread can query the status of the request
at any time, and won't notice at all that a blocking syscall is
happening. This is actually not so different from the `fork+pipe'
solution, but without _any_ of the overhead.
I've pointed this out to you before. You claimed that threads weren't
portable. Fair enough, however they are standardized in the Single
Unix Spec, and any vendor refusing to implement them certainly
deserves the blame of application developers who have to resort to
ugly hacks to solve such basic problems. (I think they also deserve
unsatisfied users because of blocking GUI applications.) Fortunately,
Linux, Solaris, Digital Unix, Irix, etc. now all have excellent,
standardized thread support.
If you want to develop for the future rather than the past, I see
no reason not to go for threads.
Regards,
Wolfram.
Christopher B. Browne
On 26 Jan 1998 09:59:45 GMT, David M. Cook <dmc...@cts.com> posted:
And a Gtk Netscape won't likely load onto your system until *much* later in
1998, whereas a (Mo|Less)tif Netscape can load on today, and once available
as source, will likely be able to load in by some time in April.
In other words, a *tif Netscape will load several *months* faster, which can
overcome rather a lot of memory differences.
Moreover, the additional memory consumed by (Mo|Less)tif is likely worth
(with today's EDO street prices) on the order of between $5 and $10.
Repeat three times: "Gtk does not magically reduce memory consumption and
increase system speed."
Marc Lepage
Christopher B. Browne wrote:
>
> On 25 Jan 1998 17:38:06 -0500, Mark Lehrer <ma...@lehrer.nlcomm.com> posted:
> >
> >and I want to remove the capability of
> >the browser to launch multiple browsers... I hate that.
>
> That might be easy enough to code in, albeit being something you are
> unlikely to get substantial agreement for. I quite *like* the fact that I
> can dispatch multiple browsers. It's quite useful to me, as I can browse
> and compare multiple pages at once. I do *NOT* want to remove this
> capability. I suspect that the "allow launching multiple browsers" camp is
> more likely to "win..."
I think he means he doesn't want the BROWSER to launch multiple copies
of itself. I agree, I hate that. And you mean that you want the USER to
be able to do it, which also is desirable.
--
SEGV
Elliot Lee
On 25 Jan 1998 23:09:08 GMT, Christopher B. Browne
<cbbr...@news.brownes.org> wrote:
>>I think that retargetting it to a different GUI toolkit, given that the
>>free implementation of Motif exists, would be a huge waste of time.
>>There are ten zillion improvements you could make; who cares what
>>toolkit it uses, as long as it works and the toolkit is widely
>>available.
>
>99% agreed.
>
>Those that want a Gtk-based web browser should work on "Mnemonic."
Mnemonic will be useful when pigs fly (I've been wrong before, mind
you)... Porting it to Gtk will also allow people who don't have any other
Motif apps normally running to reduce system memory usage quite a bit, and
it may well expose some bugs in Netscape in the porting process.
I also think that Gtk is easier to learn than (less|Mo)tif, which should
encourage more people to work on improving Netscape.
>Although there would be *some* value to targetting another GUI, if that
>allows common functions to be shared, thus saving on memory consumption.
>Saving 4MB of memory is worth about $10 these days...
No, saving 4MB of memory can make your machine run x times faster (x being
a number above but reasonably close to 1), and I consider my time to be
valuable, so... :)
-- Elliot
Will read UCE for food! Charge of only $500 per message received. ;-)
Elliot Lee
Contrary to popular opinion, threads don't solve design problems. They
just (a) allow you to take advantage of multiple processors for
CPU-intensive problems (b) increase program overhead.
For example, Gnome (http://www.gnome.org/) has a totally non-blocking DNS
lookup mechanism, and there's not a single program that uses threads in
Gnome.
-- Elliot
a...@muc.de
sop...@bogus.circ.us.eu.org (Elliot Lee) writes:
>
> For example, Gnome (http://www.gnome.org/) has a totally non-blocking DNS
> lookup mechanism, and there's not a single program that uses threads in
> Gnome.
Bad example. The gnone DNS lookup function forks, which is some kind
of thread (just worse speedwise)
-Andi
James Youngman
>>>>> "Elliot" == Elliot Lee <sop...@bogus.circ.us.eu.org> writes:
Elliot> Contrary to popular opinion, threads don't solve design
Elliot> problems. They just (a) allow you to take advantage of
Elliot> multiple processors for CPU-intensive problems (b) increase
Elliot> program overhead.
I have to say that my experience indicates strongly otherwise. Your
arguments may be correct if one considers only Unix, but I don't think
thet they are in general.
I make heavy use of threads for embedded systems, but none at all for
Unix programs; but then, I write very different programs for the two
types of systems.
Elliot Lee
Not sure about other platforms, but on Linux, the difference between
fork() and clone() is a 4K memcpy, IIRC. In fact fork() is just a
redirection to clone() with certain flags.
Processes are supported a *lot* more widely (and the API is actually
standardized) than threads on most Unices, and legacy systems such as
F[lr]eeBSD don't even have kernel threads (no actual speed advantage to
using userland threads, and I don't think a userland thread implementation
would be quite as stable either...?).
Elliot Lee
On 26 Jan 1998 14:44:58 +0100, Wolfram Gloger
<wm...@dent.med.uni-muenchen.de> wrote:
>> Using native threads would not make your DNS problems magically go away.
>> They are just an implementation detail. The real problem is that Unix
>> does not have a non-blocking API for hostname lookup, meaning that doing
>> it in a nonblocking way is either, very hard, or unportable (pick one.)
>
>No. Using threads _will_ make the problem go away. You just use the
>blocking API gethostbyname_r() in a subthread and post a condition
>when it returns. The main thread can query the status of the request
>at any time, and won't notice at all that a blocking syscall is
>happening. This is actually not so different from the `fork+pipe'
>solution, but without _any_ of the overhead.
Notice your use of the word "query" there. Polling doesn't sound too
efficient to me. I'd much rather have a main event loop select() on a pipe
to a tiny (20k) program (along with the fd's for the X connection and
whatever else you have that might generate events), especially since the
difference in overhead between a thread & a process isn't all that
much....
Chacun son gout,
Elliot Lee
Yes, but when everything is running in the same address space (which my
$0.01 worth of embedded system knowledge leads me to believe) the
difference between a thread and a process is negligible on that type of
platform.
I should have added that (c) sometimes using threads really do help make
the problem simpler to tackle (i.e. a multithreaded web server can be
more efficient ), but that 90% of the time people use threads as a cop-out
instead of select() :-)
Chris Waters
cbbr...@news.brownes.org (Christopher B. Browne) writes:
> On 23 Jan 1998 07:33:15 +0200, Tero Pulkkinen <te...@assari.cc.tut.fi> posted:
> >Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
> >> > Forget Motif, let's convert it to use GTK instead.
> >> Or LessTif.... I'm kinda hoping it will compile with that as-is.
> >Naah, GTK all the way. We're supposed to make it better, not worse :)
> Most important principle:
> If a month's worth of effort makes "GNU-Netscape" run with Lesstif, that
> provides *working system* sooner than if making "GNU-Netscape" run using Gtk
> takes 4 months.
Netscape runs now, no month's worth of effort needed. Making it run
with Lesstif wouldn't buy much except dynamic linking, which is only
an advantage if you're using other Lesstif-based programs. I, and a
lot of other people, have none.
As for GTK, yes, it's more work, but remember that GIMP was based on
Motif not too long ago, so it's clearly feasible. And a lot of people
use GIMP, so the opportunity for sharing memory is there.
Red Hat and Debian have both announced that they will be moving to
GNOME as soon as it becomes feasible. At that point, a GTK-based
Netscape will be a Big Win. And since GNOME isn't done yet, it's not
such an issue that the GTK-based Netscape isn't done either.
--
Chris Waters | The real problem with the the year 2000 is
cwa...@systems.DHL.COM | that there are too many zero bits and that
xt...@dsp.net (personal) | adversely affects the global bit density.
www.dsp.net/xtifr/ (web) | -- Boyd Roberts <bo...@france3.fr>
Chris Waters
Uri Blumenthal <u...@ibm.net> writes:
> Jamie Zawinski wrote:
> > I think that retargetting it to a different GUI toolkit, given that
> > the free implementation of Motif exists, would be a huge waste of
> > time. There are ten zillion improvements you could make; who cares
> > what toolkit it uses, as long as it works and the toolkit is widely
> > available.
> I strongly support this opinion, and urge serious developers to
> concentrate on bug-fixes and adding *important* features. Let
> the crackpots who can't hear the word "Motif" without emitting
> foam, convert it to GTK or whatever.
I made this same argument when the original call-for-programmers for
KDE first went out. I advocated helping the Lesstif developers
instead, and starting a free-CDE project. However, the fact is,
people went ahead and developed KDE, and now they're working on GNOME.
Neither of these desktops is based on *tif. To the best of my
knowledge, there is no free *tif-based desktop in the works.
So, at this point, I think that Qt or GTK-based versions of Netscape
make a fair amount of sense. Basically, a KDE Netscape and a GNOME
Netscape. And, OC, a commercial, Motif-based Netscape for CDE. Heck,
who knows what kind of hacking the Enlightenment people will feel they
need to do to make Netscape consistent with *their* environment.
Yes, it's going to involve some wasted effort. But we've been
guaranteed some wasted effort ever since, one, CDE was released under
a commercial license, and two, the alternative free desktop projects
started.
Yes, it will take some time. But when I started with Linux, there
were only about four running apps. It won't take *that* long.
Tom Gravgaard Christensen
On Fri, 23 Jan 1998 18:07:11 -0500, "Gregory Propf" <gr...@home.com>
wrote:
>
>>Forget Motif, let's convert it to use GTK instead.
That would be nice ;)
>
>OK, what's GTK?
It's the Gimp ToolKit
Homepage is here: www.gimp.org/gtk
--
Tom G. Christensen, Denmark
tom dot christensen at get2net dot dk
Elliot Lee
On 26 Jan 1998 16:25:06 -0500, Rajappa Iyer <r...@lucent.com> wrote:
> Incidentally, FreeBSD-current has kernel threads.
My apologies - I was told that OpenBSD had rfork() and that was it.
However, -stable doesn't have it (?), and that's what people are likely to
be running, and that's what I'm comparing.
>That said, the advantages of kernel threads for non-SMP boxes is
>questionable. User threads are useful only in limited situations and
>multi-processing (especially when processes are cheap) will win in
>most cases.
Well, kernel threads give the uniprocessor advantage that allows other
threads of a process to run if one thread gets blocked in a syscall.
Jungshik Shin
In <xdu90s7...@assari.cc.tut.fi>, Tero Pulkkinen wrote:
: Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
:> >
:>
:> Or LessTif.... I'm kinda hoping it will compile with that as-is.
: Naah, GTK all the way. We're supposed to make it better, not worse :)
:> A GTK conversion could be very hard depending on how the code is
:> arranged. I probably shouldn't say too much more before we see
:> the actual source.
I don't know much about GTK, but I'm afraid it may lack as mature
level of I18N(internationalization) support as Motif has. Thanks to
built-in I18N features of X11 and Motif, netscape under Unix has very
little problem displaying web pages in a number of
non-European(non-ISO-8859-x based) languages as long as fonts are
available. (Nothing else was necessary). IMHO, a lot of care should be
taken not to lose I18N support of Netscape if one wants to use GUI APIs
other than Motif.
Jungshik Shin
Wolfram Gloger
sop...@bogus.circ.us.eu.org (Elliot Lee) writes:
> On 26 Jan 1998 14:44:58 +0100, Wolfram Gloger
> <wm...@dent.med.uni-muenchen.de> wrote:
> >
> >No. Using threads _will_ make the problem go away. You just use the
> >blocking API gethostbyname_r() in a subthread and post a condition
> >when it returns. The main thread can query the status of the request
> >at any time, and won't notice at all that a blocking syscall is
> >happening. This is actually not so different from the `fork+pipe'
> >solution, but without _any_ of the overhead.
>
> Notice your use of the word "query" there. Polling doesn't sound too
> efficient to me.
I said `can query' not `must poll'. See pthread_cond_signal(3),
pthread_cond_{timed,}wait(3).
> I'd much rather have a main event loop select() on a pipe
> to a tiny (20k) program (along with the fd's for the X connection and
> whatever else you have that might generate events),
You can certainly do that. With a threaded design, the extra pipe
(per pending DNS query) can be avoided however (e.g. you could just
signal the main event loop from the `DNS query' thread on completion).
Handing over the DNS result is also much easier due to the shared
address space.
> especially since the
> difference in overhead between a thread & a process isn't all that
> much....
I disagree, although in this case indeed it probably doesn't matter
that much. If you look at Jamie's original article, on some systems
there are big problems with a many-Meg application fork()ing, just to
exec() the tiny helper program.
Regards,
Wolfram.
Joerg Schilling
In article <6ahlmj$amk$2...@janis.virago.org.au>,
Rachel Polanskis <r.pol...@nepean.uws.edu.au,gr...@zeta.org.au> wrote:
>In article <34CB2E71...@netscape.com>,
> Jamie Zawinski <j...@netscape.com> writes:
>>
>Remember, Linux is still UNIX, and a good programmer will adhere to
>the paradigms that make a an application portable between UNIX versions.
....
>A good Linux programmer is a portable UNIX programmer.
But these programmers are rare. At least if they learnd UNIX with Linux.
Linux documentation and the Linux include file system makes it hard to become
a good programmer by only seeing Linux code. Most programs that have been
developped on Linux are hard to port to other UNIX flavours.
The main reason for the non-portability of code developped on Linux is that
programmers usually use the wrong include files (those that are only present
for portability reasons and those that are located in the directories
/usr/include/linux and friends). Creating an operationg system that makes it
easy to compile BSD and SYSV derived code is one thing but writing documentation
that allows newbies to learn how to use it is another thing.
A good idea would be if all include files that are only present for portability
reasons have a top comment line that warns to directly include this file.
Joerg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
James Youngman
>>>>> "Elliot" == Elliot Lee <sop...@bogus.circ.us.eu.org> writes:
Elliot> I should have added that (c) sometimes using threads really
Elliot> do help make the problem simpler to tackle (i.e. a
Elliot> multithreaded web server can be more efficient ), but that
Elliot> 90% of the time people use threads as a cop-out instead of
Elliot> select() :-)
A good example is that there are some protocols whose implementations
benefit from running the transmit and receive halves in different
threads. It makes the program much clearer, as I found out when I
had to rewrite the protocol handler for a system that didn't support
threads.
However, you state that often for embedded systems there is little
difference between a process and a thread; I'll admit that in the case
of the particular embedded system I'm talking about, this is precisely
the case; in fact the documentation doesn't even call them threads,
but instead calls them processes. In other respects, the OS (JMI's C
Executive) is a bit like a simple Unix.
The mutex interface is, fwiw, much simpler than Pthreads but not as
flexible. However, it *is* robust.
James Youngman
>>>>> "Rachel" == Rachel Polanskis <rac...@virago.org.au> writes:
Rachel> I will be severely disappointed if Netscape gets totally
Rachel> assimilated by the Linux community, given their penchant for
Rachel> completely reinventing traditional UNIX ways of doing
Rachel> things, at the expense of portability.
IMHO now that Linux has switched to glibc version 2, the shoe is on
the other foot. Linux programs including linux/*.h simply don't
compile any more. And I should add that there are now complete
glibc2-based distributions, so these programs have been ported (if
required) already.
IMHO those programs that were gratuitously nonportable deserved to be
broken.
Rachel> I use Motif for lots of things, and GTK (for example) for
Rachel> just one - GIMP. What a waste of space. I have a program
Rachel> that uses Xforms. It's the only one. What a waste of
Rachel> memory and space. I also have a program that uses Qt - just
Rachel> one program. Also a waste of space.
Yes. Sometimes an outright winner in a milti-horse race is a good
thing. An exception to the "variety is good" mantra of the Unix
crowd.
Rachel> Motif might be horrible (personally I like it, and can't see
Rachel> what the fuss is about) but it's a *standard* library that
Rachel> can be found on nearly all commercial UNIX OS's - if you
Rachel> don't have it, it's not hard to come by. So what if you
But it *is* expensive.
Rachel> have to spend a few dollars for it. It came free with
Rachel> Solaris, so I'm happy. If I had to use linux as a desktop
Rachel> console there's no way I would not have Motif on there, even
Rachel> if I have to fork out AUD100...
I use Linux for things thich are not very X; for example network
servers. I don't think it is appropriate to purchase Motif for
these. However, I might occasionally still run X. Still having
decent-looking GUI programs is nice.
Rachel> If Netscape goes the way of 10,000 other Linux GUI projects,
Rachel> I'll just stick to the standard source tree, and conserve my
Rachel> disk space for the shared objects I'll use the most...
The decision by Linux distribution vendors to ship Gnome (i.e. GTK)
will weigh the scales heavily. I suppose this isn't an irreversible
decision, and SuSE are shipping KDE. But if I had to bet, I know
which way I'd have gone.
Rachel> A good Linux programmer is a portable UNIX programmer.
IMHO anybody deliberately makign a program nonportable has failed to
learn one of the lessons of the success of the Linux kernel; the
secret to good testing is having many people use your code in a
greater variety of ways than you could possibly so do yourself.
R!ch
On 27 Jan 1998, James Youngman wrote:
> Rachel> Motif might be horrible (personally I like it, and can't see
> Rachel> what the fuss is about) but it's a *standard* library that
> Rachel> can be found on nearly all commercial UNIX OS's - if you
> Rachel> don't have it, it's not hard to come by. So what if you
>
> But it *is* expensive.
>
> Rachel> have to spend a few dollars for it. It came free with
> Rachel> Solaris, so I'm happy. If I had to use linux as a desktop
> Rachel> console there's no way I would not have Motif on there, even
> Rachel> if I have to fork out AUD100...
>
> I use Linux for things thich are not very X; for example network
> servers. I don't think it is appropriate to purchase Motif for
> these. However, I might occasionally still run X. Still having
> decent-looking GUI programs is nice.
Isn't Lesstif a free, drop in replacement for Motif, thereby negating
the cost issue? [I don't follow this stuff that closely, so I could
be talking bollocks!]
--
R!ch (Email is flakey at present: use rich...@keaton.uk.sun.com)
If it ain't analogue, it ain't music.
#include <disclaimer.h> \\|// - ?
(o o)
/==================================oOOo=(_)=oOOo========\
| Richard Teer richar...@uk.sun.com |
| |
| |
| WWW: www.rkdltd.demon.co.uk |
| .oooO |
| ( ) Oooo. |
\===================================\ (==( )==========/
\_) ) /
(_/
Wolfram Gloger
Jamie Zawinski <j...@netscape.com> writes:
> Well, one hidden overhead of using threads is that most people in the
> world have an easier time understanding and debugging state machines
> than they do understanding and debugging lock contention problems.
True, but for the example being discussed there would be little lock
contention, I hope.
> > You claimed that threads weren't portable. Fair enough, however they
> > are standardized in the Single Unix Spec, [...]
> >
> > If you want to develop for the future rather than the past, I see
> > no reason not to go for threads.
>
> Well, that's the point on which we disagree -- I'm not interested in
> developing for the future, I'm interested in developing for the present.
> I don't want to write programs that will work only on some future
> (perfect) system, I want to write programs that run on the widest
> variety of systems that are *deployed today*. This very often means
> making all kinds of ugly compromises.
I fully accept this reasoning. What prompted my followup was your
claim that `Unix lacks a non-blocking DNS query API'. The API is
there -- via POSIX threads at least since 1995 (final standard); for
some reason it just isn't as widely implemented as you seem to
require.
Regards,
Wolfram.
Elias Martenson
R!ch <rich...@uk.sun.com> writes:
> > I use Linux for things thich are not very X; for example network
> > servers. I don't think it is appropriate to purchase Motif for
> > these. However, I might occasionally still run X. Still having
> > decent-looking GUI programs is nice.
>
> Isn't Lesstif a free, drop in replacement for Motif, thereby negating
> the cost issue? [I don't follow this stuff that closely, so I could
> be talking bollocks!]
I'm developing a freeware game, that uses Motif for its GUI, and the
people that use Linux+LessTif have a lot of problems. LessTif seems to
be very buggy, and development progress is slow. A pity IMO, since a
standard GUI is a Good Thing, and Motif is already standard everywhere
else.
--
Elias Martenson
elias.martenson (atsign) sweden.sun.com
stephen farrell
rac...@virago.org.au (Rachel Polanskis) writes:
> In article <34CB2E71...@netscape.com>,
> Jamie Zawinski <j...@netscape.com> writes:
> >
> > I think that retargetting it to a different GUI toolkit, given that the
> > free implementation of Motif exists, would be a huge waste of time.
> > There are ten zillion improvements you could make; who cares what
> > toolkit it uses, as long as it works and the toolkit is widely
> > available.
>
> I agree.
> I will be severely disappointed if Netscape gets totally
> assimilated by the Linux community, given their penchant for
> completely reinventing traditional UNIX ways of doing things,
> at the expense of portability.
I have a lot of gripes with linux but this isn't one of them. Could
you please give an example? (I have built with almost zero
portability problems (well... the "top" programs don't work but what
do you want??) kde, gnome, gimp and other new linux programs on
my freebsd box). (in fact I can run the binaries =)
> Remember, Linux is still UNIX, and a good programmer will adhere to
> the paradigms that make a an application portable between UNIX versions.
>
> It's no good if those of us with access to Motif (Solaris, AIX, etc)
> have to download and compile YAWK to make a favourite piece of software
> run.
>
> I use Motif for lots of things, and GTK (for example) for just one - GIMP.
> What a waste of space. I have a program that uses Xforms.
> It's the only one. What a waste of memory and space.
> I also have a program that uses Qt - just one program. Also a waste
> of space.
Um... and that's how ppl with free unixes see motif. It just depends
which side of the fence you're on. Thing is, motif is largely dead
for new development, whereas there is tons of new stuff for qt and
gtk.
>
> Motif might be horrible
> (personally I like it, and can't see what the fuss is about)
> but it's a *standard* library that can be found on nearly all commercial
> UNIX OS's - if you don't have it, it's not hard to come by.
> So what if you have to spend a few dollars for it.
> It came free with Solaris, so I'm happy.
> If I had to use linux as a desktop console there's no way I
> would not have Motif on there, even if I have to fork out AUD100...
>
> If Netscape goes the way of 10,000 other Linux GUI projects, I'll just
> stick to the standard source tree, and conserve my disk space for
> the shared objects I'll use the most...
Well, you *can* do that. Unless they have something better to
offer.... so what's the problem?
> A good Linux programmer is a portable UNIX programmer.
yeah... but most of the decent stuff that's coming out for linux *is*
portable. Sure mnemonic requires thread safe X libraries and
linuxthreads and doesn't work but guess what--no one cares. no one
uses it. Do you have any decent examples? (oh, wait, I've got
one--gnoom... but this is prerelease stuff, and the portability issues
are trivial (location of a few header files), at least to freebsd
(which happens to use the linux sound drivers), even if it does
compile to a directory called "linux" =)
James Youngman
>>>>> "R!ch" == R!ch <rich...@uk.sun.com> writes:
R!ch> Isn't Lesstif a free, drop in replacement for Motif, thereby
R!ch> negating the cost issue? [I don't follow this stuff that
R!ch> closely, so I could be talking bollocks!]
Yes, but it's a Motif-1.2 clone, whereas CDE (afaik) is 2.x. Many
"Motif" programs just don't run on Lesstif, often because they're
designed for the wrong version.
Meelis Roos
> IMHO now that Linux has switched to glibc version 2, the shoe is on
> the other foot. Linux programs including linux/*.h simply don't
> compile any more.
Just my curiosity, but why don't they compile? The /usr/include/linux
is still there on my RH 5.0 system (symlink to kernel source as usual).
--
Meelis Roos e-mail: mr...@ut.ee
www: http://www.cs.ut.ee/~mroos/
Jani Hakala
On 27 Jan 1998 17:06:29 +0000, James Youngman <JYou...@vggas.com> wrote:
>
>Yes, but it's a Motif-1.2 clone, whereas CDE (afaik) is 2.x. Many
>"Motif" programs just don't run on Lesstif, often because they're
>designed for the wrong version.
>
libXm.so.1.2 => not found
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40004000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40047000)
...
So a Motif-1.2 clone could be enough...
Jani Hakala
Albert D. Cahalan
Rajappa Iyer <r...@lucent.com> writes:
> stephen farrell <sfarrel...@farrell.org> writes:
>> rac...@virago.org.au (Rachel Polanskis) writes:
>>> I will be severely disappointed if Netscape gets totally
>>> assimilated by the Linux community, given their penchant for
>>> completely reinventing traditional UNIX ways of doing things,
>>> at the expense of portability.
>>
>> I have a lot of gripes with linux but this isn't one of them. Could
>> you please give an example? (I have built with almost zero
>> portability problems (well... the "top" programs don't work but what
>> do you want??) kde, gnome, gimp and other new linux programs on
>> my freebsd box). (in fact I can run the binaries =)
>
> rpm and dpkg.
>
> Both could be implemented better and more portably with make and SVR4
> pkgadd/rm etc. See, for example, FreeBSD's ports mechanism.
>
> 'nuff said.
Nope, get a clue. Both are portable applications with available
source code, even though it doesn't matter for system software.
Actually, I wonder how well "ports" would work with AT&T or GNU make.
bill davidsen
In article <6a8eo4$c5s$1...@sirius.aero.und.edu>,
Joe A. Grassel <vena...@aero.und.edu> wrote:
| Forget Motif, let's convert it to use GTK instead.
I would suspect that the code is pretty portable, since there are
MOTIF and Windows versions (and Mac as well if I remember). I only
like GTK a little better than MOTIF, I'd like to see several ports,
maybe Athena widgets, or something like that.
IE is in DEEP trouble...
--
bill davidsen <davi...@tmr.com> CTO, TMR Associates, Inc
My job description says I am responsible for solving all technical
problems. Cute sigs are not a technical problem.
Nick Andrew
>In article <6ahlmj$amk$2...@janis.virago.org.au>,
>Rachel Polanskis <r.pol...@nepean.uws.edu.au,gr...@zeta.org.au> wrote:
>>A good Linux programmer is a portable UNIX programmer.
Linux is a dream to program compared to some of the stuff I've had to
work on (e.g. SysIII, SysV, SunOS 4.x). While I believe Rachel's coming
down too hard on Linux "reinventing the wheel" I also believe it's
important for programmers to understand the _standard_ - the interface
between the programming language and the system.
So read POSIX.1, POSIX.you-name-it and various other specifications
until you understand what's important therein.
>But these programmers are rare. At least if they learnd UNIX with Linux.
The man pages in sections 2 and 3 are pretty good. For example, look at
this fragment from open(2):
CONFORMING TO
SVID, AT&T, POSIX, X/OPEN, BSD 4.3
Now look at this fragment from setfsuid(2):
CONFORMING TO
setfsuid is Linux specific.
With suitable documentation it isn't hard to learn what is Linux-specific
and what is Unix, even if you only have Linux man pages for your docs.
>Linux documentation and the Linux include file system makes it hard to become
>a good programmer by only seeing Linux code. Most programs that have been
>developped on Linux are hard to port to other UNIX flavours.
Nah. Using "the source" and then writing applications is the wrong way.
The right way is to read the man pages before writing code, and only
use "the source" if you think you found a kernel bug (really unlikely) or
you just can't figure out why your program behaves as it does.
Linux is no different to any implementation of Unix in that it has hundreds
of files under /usr/include which can be included anytime, but which should
usually not be.
Nick.
--
Zeta Internet Fax: +61-2-9233-6545 Voice: 9837-1397
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
Kai Henningsen
r...@lucent.com (Rajappa Iyer) wrote on 27.01.98 in <xnyg1m9...@placebo.hr.lucent.com>:
> stephen farrell <sfarrel...@farrell.org> writes:
>
> > rac...@virago.org.au (Rachel Polanskis) writes:
> > > I agree.
> > > I will be severely disappointed if Netscape gets totally
> > > assimilated by the Linux community, given their penchant for
> > > completely reinventing traditional UNIX ways of doing things,
> > > at the expense of portability.
> >
> > I have a lot of gripes with linux but this isn't one of them. Could
> > you please give an example? (I have built with almost zero
> > portability problems (well... the "top" programs don't work but what
> > do you want??) kde, gnome, gimp and other new linux programs on
> > my freebsd box). (in fact I can run the binaries =)
>
> rpm and dpkg.
>
> Both could be implemented better and more portably with make and SVR4
> pkgadd/rm etc. See, for example, FreeBSD's ports mechanism.
I wouldn't know about rpm, but you're wrong on several counts wrt dpkg.
First of all, the only part relevant to make - the building packages part
- uses ... guess what? Make.
As to pkgadd/rm, well, the less said about these, the better. I'll be glad
if I never have to use them again.
As to portability - dpkg seems to run on several non-Linux Unices just
fine, from what I hear. (And in any case, you can unpack every .deb with
ar, gzip, and tar (in that sequence). But you knew that, didn't you?)
> 'nuff said.
Kai
--
Internet: k...@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/private/khms/
Kai Henningsen
j...@netscape.com (Jamie Zawinski) wrote on 26.01.98 in <34CCE207...@netscape.com>:
> Wolfram Gloger wrote:
> >
> > Absolutely not. Threads solve a whole class of design problems with
> > extremely little `program overhead' (as in used resources overhead)
> > and little programming overhead (which was probably meant above).
>
> Well, one hidden overhead of using threads is that most people in the
> world have an easier time understanding and debugging state machines
> than they do understanding and debugging lock contention problems.
Well, I don't know about other people, but I switched a program of mine to
hand-implemented threads (this being a DOS program) exactly because the
non-thread version had become *much* too complicated to debug, and I
couldn't see how to implement further features without either going
threaded, or taking about ten times the effort.
And it has worked out even better than I expected. It's _much_ easier to
debug this way. Most of the time, the threading is completely invisible to
whatever problem I'm hunting down, and the separate threads have _much_
simpler logig than a non-threaded version would have.
If you think about it, doing without threads is equivalent to an
exponential rise in complexity whenever your different threads mostly
independant in what they do. (Of course, if they are closely related, it's
the other way around.)
Kai Henningsen
sop...@bogus.circ.us.eu.org (Elliot Lee) wrote on 26.01.98 in <slrn6cpulj....@bogus.circ.us.eu.org>:
> more efficient ), but that 90% of the time people use threads as a cop-out
> instead of select() :-)
Don't you mean "90% of the time people use select() just as a sort of poor
man's threads"? :-)
Elias Martenson
James Youngman <JYou...@vggas.com> writes:
> >>>>> "R!ch" == R!ch <rich...@uk.sun.com> writes:
>
> R!ch> Isn't Lesstif a free, drop in replacement for Motif, thereby
> R!ch> negating the cost issue? [I don't follow this stuff that
> R!ch> closely, so I could be talking bollocks!]
>
> Yes, but it's a Motif-1.2 clone, whereas CDE (afaik) is 2.x. Many
> "Motif" programs just don't run on Lesstif, often because they're
> designed for the wrong version.
CDE 1.2 (in Solaris 2.6) is based on Motif 1.2.x. (can't remember the
patchlevel but I think it's 3).
Elliot Lee
On 28 Jan 1998 00:50:00 +0200, Kai Henningsen
<kaih=6mjhh...@khms.westfalen.de> wrote:
>sop...@bogus.circ.us.eu.org (Elliot Lee) wrote on 26.01.98 in <slrn6cpulj....@bogus.circ.us.eu.org>:
>
>> more efficient ), but that 90% of the time people use threads as a cop-out
>> instead of select() :-)
>
>Don't you mean "90% of the time people use select() just as a sort of poor
>man's threads"? :-)
select() is more efficient than threads, so I don't see it as the poor
man's solution.
Paul Flinders
sop...@bogus.circ.us.eu.org (Elliot Lee) writes:
>
> select() is more efficient than threads, so I don't see it as the poor
> man's solution.
No it isn't.
If you use select and have a large number of connections then you must
scan a long list of file descriptors to decide which one became
available for reading. With threads typically each thread is just
blocked on a single descriptor - no scanning.
Also as you deal with each bit of new data you may have to wait for
I/O to service a request. This means that all requests wait for that
I/O even if they could be serviced from data in memory.
Giles Douglas
Chris Bitmead wrote:
> One thing I am sure of though, is that Linux is unequalled when it
> comes to the ease of porting _to_ it from other versions of UNIX.
Yeah, its great fun porting tli code to linux.
Oh no, it isn't, I'm lying.
Giles
--
Giles Douglas - Senior Software Engineer - Sailfish Systems Ltd - 212 607 3016
Mandatory Sailfish Disclaimer:
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Sailfish System, Ltd.
just a viking..
David Hinds wrote:
>
> Chris Mikkelson (mikk...@maroon.tc.umn.edu) wrote:
> :
> : Mark Lehrer <ma...@lehrer.nlcomm.com> writes:
> : > I understand that Netscape will be releasing the source code to their
> : > Communicator 5.0.
> : >
> : > I'd bet it's just Navigator and not abra-Collabra.
> : >
> : > This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
> : > leak in 4.04 if I get Motif libs.
> :
> : I had only heard the rumor on Macintouch up until now. I just
> : checked on Netscape's page, and was very encouraged. It sounds
> : like they are going to make the source code very much free
> : (for use, modification, *and* redistribution).
>
> ...
>
> I think this is a very smart move on Netscape's part. If you've
> decided to give a product away, it makes very good sense to also
> release the source code. In so doing, Netscape has just "hired" a
> team of Linux programmers to hack away at it and make improvements,
> which may be folded back into the official version later.
>
> And now that Microsoft is folding their browser technology into the
> OS, it seems to me that it would be quite tricky if not impossible for
> them to do the same thing with Internet Explorer, even overlooking
> their history of never releasing source code.
>
> -- Dave Hinds
An "Active Desktop" for linux using some Navigator Code would be nice!
Chris Bitmead
j...@cs.tu-berlin.de (Joerg Schilling) writes:
> Linux documentation and the Linux include file system makes it hard to become
> a good programmer by only seeing Linux code. Most programs that have been
> developped on Linux are hard to port to other UNIX flavours.
I havn't found that myself, but then maybe I am already a good
programmer :-)
One thing I am sure of though, is that Linux is unequalled when it
comes to the ease of porting _to_ it from other versions of UNIX.
--
Chris Bitmead
http://www.thepla.net/~chrisb
I have a web site, therefore I am.
Tony Cooper
Rajappa Iyer wrote:
> kaih=6mjhg$xm...@khms.westfalen.de (Kai Henningsen) writes:
>
> > r...@lucent.com (Rajappa Iyer) wrote on 27.01.98 in <xnyg1m9...@placebo.hr.lucent.com>:
> > > rpm and dpkg.
> > >
> > > Both could be implemented better and more portably with make and SVR4
> > > pkgadd/rm etc. See, for example, FreeBSD's ports mechanism.
> >
> > I wouldn't know about rpm, but you're wrong on several counts wrt dpkg.
> >
> > First of all, the only part relevant to make - the building packages part
> > - uses ... guess what? Make.
>
> Yeah, right! Do tell us how you build packages on debian. Here's my
> experience.
>
> % dpkg-buildpackage
>
> The first thing that happens when you do this is:
>
> debian/rules: cannot execute.
>
> Guess what debian/rules is: a makefile. Why not name it makefile? Why
> make it an executable? Product differentiation?
>
> % chmod +x debian/rules
> % dpkg-buildpackage
> ... configure, compile ...
> You must be root to do this.
>
> Gee, why doesn't dpkg-buildpackage check upfront if you've sufficient
> permissions to run the whole script?
>
> % su
>
> # dpkg-buildpackage
> ... clean, configure, compile, build ...
>
> For large packages, going through clean, configure build over again is
> unacceptable, IMHO.
>
> Sure, one could argue that these are inevitable glitches and minor
> bugs which would be present in any system... but the fact is that
> using debian's packaging mechanism was not a pleasant experience by
> any stretch of the imagination. On the other hand, using FreeBSD's
> ports was trouble free and quite intuitive.
>
> In the end, what really annoyed me about both rpm and dpkg is that
> they had FreeBSD's ports as well as pkgadd/rm to look at, learn from
> and build on. While I can understand the decision to go away from
> pkgadd/rm, I cannot understand why they did not build on top of
> FreeBSD's ports. Nothing short of a cussed NIH attitude can explain
> it.
>
> > As to pkgadd/rm, well, the less said about these, the better. I'll be glad
> > if I never have to use them again.
>
> Do tell us about the problems with pkgadd / rm. I agree that they're
> not perfect, but they certainly achieve most of the functionality
> offered by dpkg and rpm.
>
> > As to portability - dpkg seems to run on several non-Linux Unices just
> > fine, from what I hear. (And in any case, you can unpack every .deb with
> > ar, gzip, and tar (in that sequence). But you knew that, didn't you?)
>
> The question was, why invent a new, gratuitously incompatible method
> to achieve something that was already quite possible to do well with
> existing tools such as make and friends? I've yet to see an earthly
> reason why building packages with dpkg and rpm is so different from
> what would be naturally expected:
>
> % make configure all package install
> --
> Rajappa Iyer <r...@lucent.com> #include <std_disclaimer.h>
> We're too busy mopping the floor to turn off the faucet.
hmm interesting argument.I use slackware for my developmental n testing stuff. I was considering
changing to Debian because of its inherent nature of checking to see what versions you have of all
required packages. Should I stick with Slackware which is currently working well :)
or take a punt and run into similar problems when I wanna run a simple makefile??
Joerg Schilling
In article <m3ra5so...@thepla.net>,
Chris Bitmead <Chr...@thepla.net> wrote:
>j...@cs.tu-berlin.de (Joerg Schilling) writes:
>
>> Linux documentation and the Linux include file system makes it hard to become
>> a good programmer by only seeing Linux code. Most programs that have been
>> developped on Linux are hard to port to other UNIX flavours.
>
>I havn't found that myself, but then maybe I am already a good
>programmer :-)
>
>One thing I am sure of though, is that Linux is unequalled when it
>comes to the ease of porting _to_ it from other versions of UNIX.
What I wanted to say, is that I read man pages and good programmers
do read man pages but people who start learning UNIX on Linux
tend to read the source (maybe they have been influenced by
George Lucas: UTSL = Use The Source Luke)
Unfortunately, innocent people seem to be irritated by reading
the include files and tend to use the wrong files.
John Pagonis
Mark Lehrer wrote:
> I understand that Netscape will be releasing the source code to their
> Communicator 5.0.
>
> I'd bet it's just Navigator and not abra-Collabra.
>
> This is wonderful news! I can fix that !#%^%@ Linux Netscape memory
> leak in 4.04 if I get Motif libs.
>
> Mark
Could you tell us more about that leak......
John
Christopher B. Browne
On 26 Jan 1998 17:37:10 -0800, Chris Waters <cwa...@systems.dhl.com> posted:
>cbbr...@news.brownes.org (Christopher B. Browne) writes:
>
>> On 23 Jan 1998 07:33:15 +0200, Tero Pulkkinen <te...@assari.cc.tut.fi> posted:
>> >Chris Mikkelson <mikk...@maroon.tc.umn.edu> writes:
>> >> > Forget Motif, let's convert it to use GTK instead.
>
>
>> >Naah, GTK all the way. We're supposed to make it better, not worse :)
>
>> Most important principle:
>
>> If a month's worth of effort makes "GNU-Netscape" run with Lesstif, that
>> provides *working system* sooner than if making "GNU-Netscape" run using Gtk
>> takes 4 months.
>
>Netscape runs now, no month's worth of effort needed. Making it run
>with Lesstif wouldn't buy much except dynamic linking, which is only
>an advantage if you're using other Lesstif-based programs. I, and a
>lot of other people, have none.
I suspect that there will be more to it than simply recompiling. Netscape
will be rather unlikely to be able to release sources for:
- Rogue Wave C++ libraries
- Visigenics object libraries
- RSA SSL support
- Java (from SunSoft)
- Bitstream font libraries
There will be a fair bit of effort required to replace these components.
>As for GTK, yes, it's more work, but remember that GIMP was based on
>Motif not too long ago, so it's clearly feasible. And a lot of people
>use GIMP, so the opportunity for sharing memory is there.
Feasibility is one thing; the overall value of saving $5 worth of memory is
another.
>Red Hat and Debian have both announced that they will be moving to
>GNOME as soon as it becomes feasible. At that point, a GTK-based
>Netscape will be a Big Win. And since GNOME isn't done yet, it's not
>such an issue that the GTK-based Netscape isn't done either.
I would like to see GNOME "succeed" as much as anybody that's not actually
directly involved with the project; it does not do, nonetheless, to
overglorify it.
A Gtked Netscape is not a "Big Win." It is a Small Win. Getting Netscape
released *at all* in a free form is the Big Win.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
cbbr...@hex.net - "What have you contributed to Linux today?..."
Soren Aalto
Giles Douglas wrote:
> Chris Bitmead wrote:
>
> > One thing I am sure of though, is that Linux is unequalled when it
> > comes to the ease of porting _to_ it from other versions of UNIX.
>
> Yeah, its great fun porting tli code to linux.
>
> Oh no, it isn't, I'm lying.
*Is* there much in the way of tli code out there? It looked like a great
idea at the time, but nobody really seems to have bought into streams
stuff. I know of a couple of projects where folk decided that streams
would be the eventual winner...and they're still waiting.
BTW, has anybody taken a recent look at LiS (Linux Streams)? Somebody
told me the project got somewheres, but I haven't followed it up.
--
Soren Aalto
Internet Guy, University of Zululand
Factorials were someone's attempt to make math LOOK exciting.
bill davidsen
In article <34CF6E6C...@TheOffice.Net>,
Tony Cooper <GuruBon...@TheOffice.Net> wrote:
| hmm interesting argument.I use slackware for my developmental n
| testing stuff. I was considering changing to Debian because of its
| inherent nature of checking to see what versions you have of all
| required packages. Should I stick with Slackware which is
| currently working well :) or take a punt and run into similar
| problems when I wanna run a simple makefile??
Unless you are having a problem with what you are running, I would
stay where you are (and would say that about most other
distributions, as well).
I regard Slackware as the right answer for people who want to do
aggressive system admin, and redhat or debian as better for people
who want to work more with running apps under the o/s and are
willing to do it the way the distribution is intended to work.
Every time you change you hit things which used to be easy and are
now not (as in the original post).
David M. Cook
On 26 Jan 1998 14:02:44 GMT, Christopher B. Browne
<cbbr...@news.brownes.org> wrote:
>Repeat three times: "Gtk does not magically reduce memory consumption and
>increase system speed."
Repeat thre times: "I will not put words into other peoples mouths."
I was arguing for a reason to port Netscape to Gtk or, for that matter, any
library. I was not claiming magical qualities for Gtk.
I could just as well have written, "If you're using the Lesstif WM, a
Lesstif Netscape will load faster and take less memory" because of the
shared library code.
I don't disagree with your argument, but it's not a good argument for not
porting Netscape to other libraries, but I don't think you meant it to be.
Dave Cook
David M. Cook
On 27 Jan 1998 14:01:51 -0500, Rajappa Iyer <r...@lucent.com> wrote:
>rpm and dpkg.
From www.rpm.org:
Known-Working RPM Platforms
Linux - Sparc/Intel/PowerPC/Alpha/m68k/SGI
Solaris - Sparc/Intel
Hewlett-Packard HP-UX 10.20
SCO OpenServer 5.0.2
Digital UNIX 3.2/4.0
SunOS 4.1.3
HP-UX 9.05
AIX 3.2.5
NCR v2.02 (i486-ncr-sysv4.3.2.2.0)
Dave Cook
Nicola.Montecchiari
Hello all,
all the comments and discussions about on wich gui to use with the
source of netscape, is IMHO useless.
If we just port the core of netscape (see HTML parsing and object
locating of the objects into the page) and then we wrap it with a common
protocol, everyone could use the gui that he prefers.
regards,
--
Nicola