[openbeos] Re: Add-ons/Module problems/ideas??
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 02 Aug 2002 05:02:50 +0200 (MEST)
En réponse à Isaac Yonemoto <ityonemo@xxxxxxxxxxxx>:
> > > It is different having an option to do that and making
> > > that automatic. What Helmar sugested was that all apps
> > > the user had opened when the computer shutdown would be
> > > reopened when it restarted.
>
> I'm sorry, we seemed to have deviated from what I was suggesting:
>
> I suggested that apps get "dehydrated" at the kernel-land level (and
> not the userland level). This means that there is no message-passing,
> or
> app-server involved (in fact, app_server, itself, would be dehydrated
> in
> the process).
This already exist, it's what laptops do when you stop them.
But it needs ACPI support in kernel *and* drivers.
>
> As to malicious apps:
>
> 1. They would have to be running already.
> 2. BeOS is excellent at killing unresponsive apps already.
> 3. There's no "startup" message/app loading. It gets immediately put
> back to where it was. As far as the app knows, it just suffered a
> time
> lapse. This might interfere with media apps that use strict time
> codes,
> so perhaps a "you've just entered a timewarp" message needs to be
> passed
> systemwide.
>
> As to the idea of rebootless kernel upgrades:
>
> The entire state of the kernel need not be saved, in fact only certain
> critical information (you can't bootstrap from nothing, anyway, so
> there
> must at least be some rudimentary kernel functions active, like FS,
> for
> example). Whatever future versions of the kernel naturally need to be
> able to understand whatever stored data there is, but there's nothing
> stopping the data format from being augmented or changed a little.
>
As I said not even GNU Hurd does it, so I bet it's pretty hard (nothing is
impossible, but...) to implement.
François.
Other related posts:
