Closed Bug 381331 Opened 15 years ago Closed 14 years ago

Overhaul OS/2 README.txt files

Categories

(Core :: General, defect)

x86
OS/2
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

References

Details

Attachments

(1 file, 1 obsolete file)

With Thebes builds we probably need to overhaul the readme files. One thing that I know for sure is that if we ever make a release, the mention of bug 167884 in the readme can be removed. But with Thebes we will probably have to note several other things there... Depending on how bug 381330 turns out that might be something...
OK, the font stuff about WarpSans/Workplace Sans was now added in bug 381330. What I think we should change are the hard/software requirements. I think Pentium as a minimum and 500 MHz for optimum performance are no longer valid. I think this:

   - Minimum hardware requirements
     + 500 MHz processor
     + 256 MiB RAM plus 64 MiB free swap space
     + 40 MiB free harddisk space for installation
       plus storage space for disk cache and mail

   - Recommended hardware for acceptable performance
     + 1.5 GHz processor
     + 512 MiB RAM plus 64 MiB free swap space
       NOTE: SeaMonkey's performance and stability increases the more
       physical RAM is available.

would be more reasonable for trunk builds.
I get pretty good performance with a 800 MHz Duron and with your memory patch 512 MBs of memory is plenty. I'd think recommending 1 Ghz processor would be plenty. Still once trunk gets even more stable and in wider testing might be worth asking on the newsgroup
Two other things that need to be fixed are
- the location of the profile with MOZILLA_HOME set (at least for
  SeaMonkey)
- we always wanted to mention ConfigApps and IAEA (what is Chuck's
  tool called again?)

When the RWS patch has gone in we also need to document that but I'll file another bug on that when we are there.
(In reply to comment #3)
> - we always wanted to mention ConfigApps and IAEA (what is Chuck's
>   tool called again?)

Internet Application Integration - http://7cities.net/~mckinnis/os2/
Attached patch 1st draft (obsolete) — Splinter Review
OK, so this is what I quickly changed/added for the Firefox 3.0 beta 3 release. Suggestions for improving this are very welcome. :-)
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
-The default internet browser on OS/2 can set using WPS URL objects. Their
-properties notebook contains a tab "Browser" where the default browser
-executable can be set. Any changes to these settings will be stored and
+The default web browser can be set using WPS URL objects.  The properties +notebook of every URL object contains a "Browser" tab where the browser +executable can be selected. Any changes to these settings will be stored and
 reflected in all URL objects once the user presses the "Set Default" button.

-     http://hobbes.nmsu.edu/pub/os2/apps/misc/configapps1_1
+     http://hobbes.nmsu.edu/cgi-bin/h-search?key=configapps&sort=date
Only thing I wonder about is if you are setting the minimum memory requirements to low. Perhaps at least 128MB+128MB swap?
Also wouldn't the minimum version be Warp 4 + fp13? 
(In reply to comment #7)
> Also wouldn't the minimum version be Warp 4 + fp13? 

Due to the highmem feature?  Doesn't that fail gracefully with earlier kernels?
Thanks for the additional input.

Highmem should indeed not be a problem on old systems, but I am told that libc06x has dependencies on the newer TCP/IP stack. As for the memory requirements I don't really know. Will ask in the newsgroup. But if really 128 MB of swap would be needed that would be bad, with any swapping beyond 50 MB or so it feels awfully slow to me, so I hesitate to put anything more than 64 MB.
The reason I mention more swap is that when OS/2 runs out of swap the system just stops, much like a kernel crash. For good performance your figures are probably closer to minimum.
Also IIRC the 32 bit stack will install on Warp v3 fp17+ and Warp v4 fp5+. I think there is another reason that libc06x doesn't work on Warp v3.
Probably best to ask in the newsgroup for the minimum that works.
Another software package we should point to in the ReadMe is DSSaver >=1.8 because that's what is now used (or will be used once I check in bug 411573) to determine idle time which is used in Places somehow.
Does Places do some background stuff when it detects the system is idle?  What happens if DSSaver is not installed - does it never do those things?  Perhaps this is covered in another bug, but 411573 is not it.  ;)
If DSSaver isn't installed (or a version before 1.8 is) then it acts just the way it did until now. I don't understand what it really does with that value. There are a number of timeouts listed at http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/components/places/src/nsNavHistory.cpp&rev=1.248#190 but from looking at related code I didn't learn anything besides the weird spelling that is used for "frequency" in the Places code.

One other thing I found out is that if the user is away from the machine for longer than 30 minutes, it will not reload livemarks.
(In reply to comment #13)
> I didn't learn anything besides the weird
> spelling that is used for "frequency" in the Places code.

"recency" + "frequency" = "frecency" apparently.

location bar that uses an algorithm based on site visit recency and frequency (called “frecency”) to provide better matches against your history and bookmarks for URLs and page titles
Attached patch 2nd draftSplinter Review
Updated README changes. As there were no useful responses in the newsgroup I have just changed the hardware values to what was recommended here. I noticed that as we have now removed the ugly palette handling code that won't work (well) with cairo, we also have to _require_ deep color. The Warp3 issue is still unresolved, so I just added a remark that it's unsupported. The info on the usefulness of DSSaver is a bit vague but I don't really want to hardcode values that are currently changing in the code.

Please let me know, if anything is missing or badly phrased. Otherwise I will get this in together with the changes from bug 411573 (and use in FF 3 beta4).
Attachment #302904 - Attachment is obsolete: true
Changes checked in.

At some point we need to update the info for SM and TB, too.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.