|
Bugzilla – Full Text Bug Listing |
| Summary: | SUPER: preloading data for faster application startup | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Stefan Nordhausen <nordhaus> |
| Component: | X11 Applications | Assignee: | Stephan Kulow <coolo> |
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | matz |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | RPM | ||
|
Description
Stefan Nordhausen
2005-08-24 09:44:22 UTC
Sounds like sth. for Coolo. note that half the info on that page is wrong as we redone the preload package. But I took over your files in the package The info is based on openSUSE beta2. You really redid the preload package for beta3? If so, where can I get it? Created attachment 47349 [details]
RPM
Not even for beta3. there is a bug in the .sh script now, the files have to be used from /var/cache/preload/ You got me confused now: Do you mean that preload 0.2.2 was not finished in time for beta3 but will be in beta4 and final? This is at least how I understand you. Another question: I also provide an autostart file for KDE and a preloader.sh which you have not included into your package. Can you include that into preload as well or should I ask the KDE people about it? I second the more aggressive preloading Stfan suggests. I also would suggest to create a boot.preload and do this very early on in the boot process as the login time is hugely affected by having a .desktop file. Doing it very early on in the bootprocess allows preload to catch up time when the USB/dev stuff is happening and counting down .... I know this would break the ability to preload if /usr is mounted via NFS.Maybe a boot.preload should check for that and not run in such a case. I have personally in 15 years UN*X experience not seen any place doing that however. Seems like an old UN*X tradition, that is not really used on modern desktops. Ideally the preload information should also be gathered dynamically by having some kind of preload daemon gather such information from the application a user is running. I don't know if that is possible or if such a daemon would possibly hit the performance of the system hard, but a dynamic creation of the files would be excellent. That would also allow us then to think how those files could be stored on disc in a manner that the preload/disc seeking is fast. We do this already starting with the next beta. Btw, note that due to a timing error in finishing beta3, the new preload rpm is already included, but not dependend package (like earlykdm or the boot scripts, which need new dependencies) were included. The effect is, that preload effectively is not used in beta3 :-( Just so you don't wonder. still, it's in there |