From: Mike Jones on
Responding to Grant (and the topic in general):

[...]
>>Try iso9660 - it's even better. Mounting a conventional file system
>>'read-only' and 'noatime' may also be a simple solution.
>
> I agree, for a kiosk style web browser box -- simply hit the reset
> button to reboot after crash. Opera has kiosk mode.


Hmmm? A read-only file system?

What, I wonder, could the potential be for setting up a fast-boot kill-it-
quick system using a read-only file system?

What could be done about all those write-to-disk processes to get them
out of the way and allow things to just be killed to stop the system, and
to have them aready written to speed up system initialisation?

This caught my eye as I've recently pulled an old WinBox out of the attic
to play my old games on, and its annoying to have a 20thC box with
Barbiware on it boot and shut down faster than my dual-core 2GB SATA mega-
box. Surely by now our computers should switch on and off with
lightswitch-like speed?

I suppose a variation of my question could be "How to nail down the
accumulated function-creep we seem to be constantly taking for granted?"

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Grant on
On Sun, 24 Jan 2010 23:24:37 GMT, Mike Jones <Not(a)Arizona.Bay> wrote:

>Responding to Grant (and the topic in general):
>
>[...]
>>>Try iso9660 - it's even better. Mounting a conventional file system
>>>'read-only' and 'noatime' may also be a simple solution.
>>
>> I agree, for a kiosk style web browser box -- simply hit the reset
>> button to reboot after crash. Opera has kiosk mode.
>
>
>Hmmm? A read-only file system?
>
>What, I wonder, could the potential be for setting up a fast-boot kill-it-
>quick system using a read-only file system?

It's like the appliance Virtual Machines one can download, just reload the
VM per session.
>
>What could be done about all those write-to-disk processes to get them
>out of the way and allow things to just be killed to stop the system, and
>to have them aready written to speed up system initialisation?

One of the overlay filesystems (there's two popular ones, unionfs and ??)
plus write to tempfs in memory for logs? Perhaps run logless (like a
sober legless?)

I've not done this so I can't provide more info.
>
>This caught my eye as I've recently pulled an old WinBox out of the attic
>to play my old games on, and its annoying to have a 20thC box with
>Barbiware on it boot and shut down faster than my dual-core 2GB SATA mega-
>box. Surely by now our computers should switch on and off with
>lightswitch-like speed?

Well, that would be suspend to ram (usually windoze crashes here 'cos it
doesn't properly handle quiesced network) or suspend to disk (hibernate),
which is still slow to start as one reads memory image on restart.
>
>I suppose a variation of my question could be "How to nail down the
>accumulated function-creep we seem to be constantly taking for granted?"

Be satisfied at some performance level? For example for the last couple
years I'm happy with Core2Duo or C2Q performance, so I'm no longer
chasing latest mobo/memory/CPU :)

Grant.
--
http://bugs.id.au
From: Mike Jones on
Responding to Grant:

> On Sun, 24 Jan 2010 23:24:37 GMT, Mike Jones <Not(a)Arizona.Bay> wrote:
>
>>Responding to Grant (and the topic in general):
>>
>>[...]
>>>>Try iso9660 - it's even better. Mounting a conventional file system
>>>>'read-only' and 'noatime' may also be a simple solution.
>>>
>>> I agree, for a kiosk style web browser box -- simply hit the reset
>>> button to reboot after crash. Opera has kiosk mode.
>>
>>
>>Hmmm? A read-only file system?
>>
>>What, I wonder, could the potential be for setting up a fast-boot
>>kill-it- quick system using a read-only file system?
>
> It's like the appliance Virtual Machines one can download, just reload
> the VM per session.
>>
>>What could be done about all those write-to-disk processes to get them
>>out of the way and allow things to just be killed to stop the system,
>>and to have them aready written to speed up system initialisation?
>
> One of the overlay filesystems (there's two popular ones, unionfs and
> ??) plus write to tempfs in memory for logs? Perhaps run logless (like
> a sober legless?)
>
> I've not done this so I can't provide more info.
>>
>>This caught my eye as I've recently pulled an old WinBox out of the
>>attic to play my old games on, and its annoying to have a 20thC box with
>>Barbiware on it boot and shut down faster than my dual-core 2GB SATA
>>mega- box. Surely by now our computers should switch on and off with
>>lightswitch-like speed?
>
> Well, that would be suspend to ram (usually windoze crashes here 'cos it
> doesn't properly handle quiesced network) or suspend to disk
> (hibernate), which is still slow to start as one reads memory image on
> restart.
>>
>>I suppose a variation of my question could be "How to nail down the
>>accumulated function-creep we seem to be constantly taking for granted?"
>
> Be satisfied at some performance level? For example for the last couple
> years I'm happy with Core2Duo or C2Q performance, so I'm no longer
> chasing latest mobo/memory/CPU :)
>
> Grant.



Satisfaction for me would be seeing my serious hardware boot at least
twice as fast as my old WinBox, and shut down faster too.

Applications seem to have bloated to absorb all this new hardware
capacity too, as I'm not noticing anything "standard" performing much
faster than it used to do a decade ago.

If I still had the old software on the new hardware, it should run very
quickly indeed. In fact, Dillo runs at light-switch response times, but
Seamonkey is like loading up a secondary OS compared to Dillo.

Just what desperately important features do these new mega-apps provide
to justify slowing hardware that is many many times faster than the old
stuff, down to response speeds of a decade ago?

I mean, just how many fonts do we want already? ;)

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Moe Trin on
On Mon, 25 Jan 2010, in the Usenet newsgroup alt.os.linux, in article
<pan.2010.01.25.12.53.36(a)Arizona.Bay>, Mike Jones wrote:

>Responding to Grant:

>> Mike Jones <Not(a)Arizona.Bay> wrote:

>>> Responding to Grant (and the topic in general):

>>>>> Try iso9660 - it's even better. Mounting a conventional file
>>>>> system 'read-only' and 'noatime' may also be a simple solution.

>>>> I agree, for a kiosk style web browser box -- simply hit the reset
>>>> button to reboot after crash. Opera has kiosk mode.

Getting close to an NDA here, but we've been using this on servers
for security - perhaps 25 years now (pre-dates Linux).

>>>Hmmm? A read-only file system?

Exaggerating a bit, but remember the write-protect notches/tabs/rings
and similar on floppies and tapes? Some hard drives also had a
similar capability.

>>>What, I wonder, could the potential be for setting up a fast-boot
>>>kill-it- quick system using a read-only file system?

It's done

>> It's like the appliance Virtual Machines one can download, just
>> reload the VM per session.

It's also done with entire (real) systems. Depends on your needs.

>>>What could be done about all those write-to-disk processes to get them
>>>out of the way and allow things to just be killed to stop the system,

uhhh.... how do you write to a 'read-only' system?

>> One of the overlay filesystems (there's two popular ones, unionfs and
>> ??) plus write to tempfs in memory for logs? Perhaps run logless (like
>> a sober legless?)

Mainly logs - write to an external device, whether it be a log server or
what-ever. An olde story often heard:

+---------------------
|> The best solution i've ever heard of was directing your log output,
|> especaily if you have an IDS, to a line printer. That way they are
|> unable to erase logs unless they have physical access to the
|> printer/machine. Pretty hard to erase a paper trail.
|
|Brilliant, and pretty cheap too...
|
|old dot matrix printer $15
|continuous paper stock $5
|look on script kiddie's
|face when they discover
|the logs are symlinked
|to /dev/lp0 priceless
+---------------------

>> I've not done this so I can't provide more info.

It's really dependent on what your needs are, but the implementation
can be quite trivial (r-o file system, logs elsewhere) on up to very
very complex - with a non-modular kernel and O/S hardened/stripped to
the absolute minimum.

>Applications seem to have bloated to absorb all this new hardware
>capacity too, as I'm not noticing anything "standard" performing
>much faster than it used to do a decade ago.

Again, it depends on what your specific needs are. Window managers
and desktops being but one example. If you don't need all of the brass
tinted bells and whistles, you can use lighter software.

>Just what desperately important features do these new mega-apps provide
>to justify slowing hardware that is many many times faster than the old
>stuff, down to response speeds of a decade ago?

"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." -- Henry Petroski

Henry Petroski (born 1942) is an American civil engineering professor at
Duke University where he specializes in failure analysis. bachelor's
from Manhattan College in 1963 and his Ph.D. from uiuc.edu in 1968.
Author of To Engineer is Human: The Role of Failure in Successful
Design (1985). weekly contributor to the journal 'American Scientist'

>I mean, just how many fonts do we want already? ;)

Fonts? Wazzamatta with "courier" or "typewriter"?

Old guy
From: Mike Jones on
Responding to Moe Trin:

[...]
>>Just what desperately important features do these new mega-apps provide
>>to justify slowing hardware that is many many times faster than the old
>>stuff, down to response speeds of a decade ago?
>
> "The most amazing achievement of the computer software industry is its
> continuing cancellation of the steady and staggering gains made by the
> computer hardware industry..." -- Henry Petroski


So its not just me thinking this then? ;)

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.