Closed Bug 86977 Opened 23 years ago Closed 15 years ago

-turbo on unix

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Product:
Core Graveyard
Component:
QuickLaunch (AKA turbo mode)
Platform:
SGI
IRIX
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: johnv, Assigned: blizzard)

References

Details

Attachments

(1 file)

my little component bar tool
1.31 KB, application/octet-stream
Details 
Richard Hess and I have decided this could be benificial, and SGI is happy for
me to investigate this, and start coding when the majority of Windows -turbo
bugs are fixed.

I have not spent much time on this yet, but here are some issues that I am sure
all UNIX vendors will want provide feedback on:
1) The concept of a mozilla.exe -turbo on UNIX is just BAD!  'Thats not how we
do it.' is one comment I got.  The solution could be a very 'Windows' solution,
assuming the user is the only user on the machine, and integrating the -turbo
option into their UNIX desktop like is being done in bug 85984.  This may be
useful for some Linux users, but IMHO we need a solution that also works on a
system that has many users on it all the time.
2) Are we wanting to cross the boundary of merely keeping dso's in the OS. To
only force dso's into memory does not seem like 'The right thing' TM   To cross
that line, and yet still benifit more than one user, means essentially turning
-turbo into a daemon.

I believe that in crossing the line ... we may end up with two solutions on UNIX
... one which follows the Windows approach, to benifit single user Linux systems
... and one to provide a performance benifit on a system with many users.

Personally I believe we should cross that line, make it a daemon, which loads
all, up till the first user/display specific code, waits for a request, and
given a 'DISPLAY' and 'USER', forks and setuid(USER), and continues.  Obviously
the security guys will go nuts over this, so I would ensure its a configure
flag, disabled by default.  We can also run it as a mozilla user who only has
the additional capabilities to setuid/setgid ... but while I know that is
possible on IRIX/TRIX, I am not so sure about it being possible on Linux and the
other Ports

There are many benifits, other than performance, which can be gained from
turning mozilla -turbo into an 'application server' (I use that term lightly).
->vishy
Assignee: law → vishy
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: sairuh → paw
Blocks: 75599
To cross the machine boundary ... I believe our options are: 
1) Corba
2) XML-RPC - in 'bitrot' according to recent post on n.p.m.xml
3) Enhancing XPCOM - highest risk
4) DCOM - cross-platform implementation ?
5) UNO (OpenOffice) - not available on IRIX or OS/X
6) Sockets (TCP/IP) - least risk
7) Other ???
woah woah woah, we already have a way to "cross the machine boundary" - Mozilla
(and Netscape 4.x) already have a lightweight, X-based way to send signals to
running processes. it's called x-remote, and it works great. Let's use that.
I have looked on mozilla.org for mention of x-remote, and this is where it led 
me.

http://www.mozilla.org/unix/remote.html
http://home.netscape.com/newsref/std/x-remote.html

We would essentially need openURL(URL, new-window, USER) in order to benifit a 
system with many users.  Is x-remote going to be able to provide that?  It 
seems like currently x-remote does not fork, but rather only creates new 
windows.  Please correct me on this one ... I believe I have used x-remote long 
enough to get a .rx file to work, and here I am assuming the .rx plugin used 
this x-remote functionality.
Woah there.  That is just plain overkill.  There is no way that I would support
crossing user boundries for launching Mozilla.  The security implications alone
make it something that we don't want to go near.

It's simple enough to leave an X connection open with only a hidden window
listening for X property changes so that it can respond to X remote requests.  I
would like to generalize the code between Windows and Unix, though.  I already
started that with the nsIXRemoteClient interface.  The code is (mostly) there. 
Who has been working on -turbo for windows?  We should talk about sharing code.

Personally, I would probably use this.  It would be nice to leave Mozilla
running without any windows open and just have one pop up when I need one.  It's
the way that I usually use it, anyway.  I just suffer with the startup times
right now.

Vishy, if you want to reassign this to me I would love to work on it.
Chris ... for a mainly single user system, extending what you have would be 
sufficient, however on a system that is frequently used by many users, this is 
not as useful.  Imagine 10 users all having a mozilla -turbo sitting in the 
background.  The more I think about this ... the more I believe we need two 
methods here.

I dont see what the security implications of crossing the user boundary are ... 
mozilla runs up till either the first user specific code, or the first 
communication.  I assume at this point it will have loaded the majority of the 
dso's, or at least it would not be hard to have it do so.  At this point it 
halts, waits for a user to request a browser, and it forks and setuid/gid down.

On IRIX (and I am sure Linux has the same capacity), the server can run as a 
totally unpriviliged user, with capabilities set to specificually allow it to 
setuid/gid.  In this way we can ensure that no super user attributes cascade 
down to the children, and that the server itself can be hacked and will result 
in no benifit to the hacker.  To use sockets would mean we can allow the sys-
adm to select AF_UNIX only, or AF_INET if they are sufficiently satisfied that 
their firewall is doing a great job.

I would love any input on security, however to flatly reject crossing the user 
boundary almost certainly restricts this feature to 'Desktop' unix.
While i've done the basic couple of units of cryptology ... should we end up 
crossing the user boundary and need to do authentication, I would love the NSS 
team to give there suggestions.  Personally I think the mozilla server should 
be able maintain its own authentication tokens to authenticate/authorise the 
user, as well as provide system authentication.

One immediate benifit of crossing the user boundary on a multi-user system, is 
this would be the first step in turning Mozilla into an application server.  
Couple this with MozOffice and we have groupware.

And at the end of the day ... does it hurt to have code that is disabled by 
default?
The assumption here is that if you are using -turbo you have a connection open
to the X server.  That means that if you have 10 people on your machine they all
have connections open to remote machines?  You're going to run into problems no
matter whether or not they have -turbo on.

That being said, what you are suggesting here would require that we have the
ability to open more than one connection to more than one server at the same
time, we would have to be able to handle running more than one profile at the
same time and sandbox each user's information and application state.

You also suggest using a fork() and then letting each process connect to the X
server.  First of all, fork() and threads don't mix.  Second, we've still got an
RPC problem.  And third, it doesn't buy you anything since you can't load most
of the modules and those forked off processes still need to load profiles and
all of the modules.

Saying that this is the way to move Mozilla to an application server doesn't
make any sense.  Do you know what an application server is?  Mozilla isn't one.

Here's the deal.  If you want to go ahead with what you're talking about go
right ahead - there's nothing stopping you.  Please open another bug and work on
it there.  In the meantime we need to get something working for people that use
single unix machines.
How many Mozilla's can be run is hardware/OS architecture dependant, and 
currently on the machine I do my builds ... 3 ppl left mozilla running 
overnite.  You can imagine what its like during the day.  I am not trying to 
cause a problem here ... I am only trying to find a solution for SGI who happen 
to be paying for my time.  The main problem on IRIX is that rqs doesnt work 
with dlopen (as far as I know ... please correct me Richard/anyone if I am 
wrong).  A static build will definately bring down startup times for more than 
one user, esp. if the static build includes components/lib*.

On threads and fork ... it works for me on IRIX and I tried a small test case 
on linux.  Should what you say be the case, and they cant be mixed beyond the 
smallest cases on your reference platforms, then indeed there is quite a hole 
in my idea.

Why cant I pre-load the components?

Finally, if a multi-user performance benefit is not desired by Netscape or 
Mozilla, then little input will be given, and there is no point in opening 
another bug.
blizzard, regarding your earlier queries, law@netscape.com has been working on
-turbo mode esp with regard to DDE stuff...but now he's on sabbatical.. I can
answer questions about it though, find me on AIM...
I'm not sure if you want to cover tray icons for unix in this bug or fork
another one.

I've implemented a silly little hack which does what I want, that is embedding
the mozilla component-bar into my Gnome panel. It's just a xul file which
includes the parts necessary for the component-bar and displays it alone in a
window. Using Gnome panel's "Swallow App" feature to embed it inside my panel,
mozilla is effectively preloaded when I log into my desktop.

It's not a particularly clean hack. It will exit when you select "Quit" from any
window, and the mailnews biff doesn't seem to work.

I have it in an XPI file if any of you are interested.

I don't see what is wrong with ten people having `-turbo' Mozillas running in
the background.  If these people are logged in and if they are using Mozilla as
their primary browser, they will probably have open (non-"-turbo") Mozilla
windows lying around anyway.  Therefore the machine has to be able to handle
them with or without `-turbo'.

In this case I think the simplest solution is also exactly the best one.  XEmacs
has supported this for ages, except it's not as user-friendly as Mozilla could
(and should) be.  With XEmacs, it works like this:

a) You can choose to run XEmacs with `-unmapped'.  This means that it will
start, open the connection to the X server, but it will not map any top-level
windows.

b) You can use `gnuclient' to run things within the existing XEmacs, which has a
consequence as opening new top-level windows.

XEmacs comes with a script that checks whether an XEmacs is already running; if
no, it starts xemacs -unmapped followed by the gnuclient incantation; if yes, it
just calls gnuclient.  This script is useful for setting your EDITOR variables
and similar; in spirit it is exactly equivalent to `mozilla -turbo'.

IMHO `mozilla -turbo' should follow that implementation strategy.  The other
proposals would be just too gross for a Unix application, not to mention the
implementation problems.


Here, here!

The UNIX version of -turbo would be useful, and has nothing to do with trying to
extend CPU/memory/bandwidth-to-disk, etc for the overall system. It's about
speeding Mozilla startup time.

If someone wants to open a new bug to address the former topics, I say more
power to 'em, but this is not the place to have that discussion.

Let me just add one more voice from the outside *nix commuity in support of a
solution that (like the xemacs one) that does not cross user boundaries. If
Mozilla implements a setuid daemon (even a non-root-suid daemon) I will take it
off all the machines I manage faster than you can say "Galeon+Evolution". Such a
daemon opens up all sorts of god-awful local exploit possibilities. Unix
(properly configured) can handle multiple (pernicious!) users; any user of my
machines concerned about mozilla startup time is welcome to start a mozilla
process in the background via a login script.  As a sysadmin I could even put
such a script in /etc/skel (if you want to make your *nix sysadmins and users
happy, offer such a script publically for download). Might I also point out that
Unix, unlike NT, is optimizied for rapid process startup, so this is less of an
issue for us that for Windows anyway.
->trudelle for triage.
Assignee: vishy → trudelle
I've got a lot of the bad infastructure work in place to get this working.  The
x remote code, which is where all this message passing would have to take place,
should be able to keep a window open so that you can get remote requests when
there are no other windows open.  We just need to hook up the code in apprunner.
->blizzard, unless he'd rather assign it back to the reporter, per first
sentence of original bug report.
Assignee: trudelle → blizzard
I'll take this on sometime soon.
Status: NEW → ASSIGNED
I like Nick Lewycky sulotion to this.

What is needed is a --persistant option mening:

1) When mozilla is started with it a URL must be given on the comand line.

2) When You quit mozilla, it will not quit persistent windows. These windows 
can only be quited from them self.

3) A persistant window will newer be reused to anything else, It will always 
use the URL it's started with.

In that way, one can write a system tray app to ones need i XUL, and then embed 
it in any system tray (fvwm, gnome e t c) and get 'turbo' as an side efekt.

A default system tray app i XUL with a open new window button would be cool, to 
get us XUL newbis a starting point ;-)

/Lars

Hey, thanks lahg@micropp.se!

Having persistant windows would be useful for those of us who would like to have
gecko technology powering desktop components without having to worry about a
user pressing "Quit" in the browser.

I'll attach the XPI file I created for your interest.

*** Bug 101125 has been marked as a duplicate of this bug. ***
Component: XP Apps: Cmd-line Features → QuickLaunch (AKA turbo mode)
No longer blocks: 75599
Blocks: 75599
changing qa contact to gbush@netscape.com
QA Contact: paw → gbush
*** Bug 188212 has been marked as a duplicate of this bug. ***
What's the status of this bug?? Still not fixed?
Anything will be included in 1.4 final?

Don't get mad at me. I'm just wondering...
I haven't had any time to work on it and it's not a really high priority.
Hope this would be fixed soon, I want to have mozilla launched inmediatly :-)
*** Bug 231091 has been marked as a duplicate of this bug. ***
> Chris ... for a mainly single user system, extending what you have would be 
> sufficient, however on a system that is frequently used by many users, this is 
> not as useful.  Imagine 10 users all having a mozilla -turbo sitting in the 
> background.  The more I think about this ... the more I believe we need two 
> methods here.

I don't have any statistics, but I'd bet $10 (who'd bet more?) that 99% of *nix
Mozilla users are running it on a single user system.

To prevent running 10 users on a multi-user system from running Mozilla with
-turbo setting would be very easy indeed. Just add some config file like
/etc/mozilla.conf with entry "quickstarter = no" or "quickstarter_only =
joe-the-boss-user mary-the-director-user". It would be read by Mozilla every
time the program is started on that machine, no matter by whom.

That easy to code!

And that would make happy all the current *nix Mozilla users who feel they have
plenty of resources they want to fill, who feel that their Mozilla starts slowly
etc.

Even more - some newbie *nix users (mainly Linux? but I may be wrong) feel that
applications run on *nix start way slower than they do on Windows, and
therefore, switch back to Windows.

What do you think?


Quicklaunch/Turbo Mode is no longer supported in Seamonkey 2 and Seamonkey1.X is in the maintenance mode (fixing only security bugs)
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: