Hello list,
I have to build an audio computer running PD for an installation. Since I am not too familiar with actual hardware issues, I would like to ask, if there are any restrictions or aspects to kepp in mind concerning certain processor types, motherboards, graphic cards, HDs (SATA) ...
I will use a Hammerfall HDSP 9652 and the JAD-Distribution on a 32bit-architecture
Thanks a lot and a happy New Year, Michael
Michael Iber www.michael-iber.de mail@michael-iber.de
Hello Michael,
The keyword I read here is "installation", so the first three things on your list should be reliability, reliability and reliability. Nobody wants to see "This installation is out of order", and you don't want people seeing that right next to your name while you are 1000 miles away working on another project and uncontactable. Incidently - I saw a Nat West bank cashpoint yesterday with a "Win32 DLL missing" error - the thought of banking machines using Windows sends a shiver down my spine!
Closely connected to this is remote access, because this is your way into the system to reset or repair it when you are unable to be physically present.
Basically, the system should be designed like a server not a desktop. You will want an SSH shell, thttpd/boa type webserver to give you a page of easy to access stats, (uptime, CPU usage, memory etc). Stock Debian is probably the best all round OS for this application. The motherboard should be set up to reboot on shutdown (power into last state) so you can do a remote reset.
I think the best motherboards for installations are mini ITX 2.4GHz types. (Don't buy them from mini-itx.com if you ever want to see your purchase!) These can be practically silent with the fansink cooling, or if you want to go down to 1GHz (which can deliver a lot of audio) then you can go to a completely silent fanless system (perfect for small galleries). A wall mount case can be bolted to the underside of a desk as well as on a wall so your hardware doesn't go walkies when unattended.
Careful with cases, make sure there's enough slot room for any cards you want to add with mini ITX systems and make sure the PSU is rated high enough for the cards too (it probably is, even with the smallest wattage).
best regards, Andy
On Sun, 30 Dec 2007 15:31:10 +0100 Michael Iber music@chemie.fu-berlin.de wrote:
Hello list,
I have to build an audio computer running PD for an installation. Since I am not too familiar with actual hardware issues, I would like to ask, if there are any restrictions or aspects to kepp in mind concerning certain processor types, motherboards, graphic cards, HDs (SATA) ...
I will use a Hammerfall HDSP 9652 and the JAD-Distribution on a 32bit-architecture
Thanks a lot and a happy New Year, Michael
Michael Iber www.michael-iber.de mail@michael-iber.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
great posting, thanks. I can only support what andy said. I always thought the harddrive is the weakest part, but in all the years I was using pd for installations the only things that broke were a motherboard and a power adapter (and a screen during transport). of course it depends on how long the installation should run. but I know of pd installations that are up since 2000, so you really also want to think about maintanence. good documentation should always be part of your contract. also think about details like log files filling harddrive space or unmounting harddrives if they are not in use (just in case the computer loses its power). btw anyone worked with flash memory for installations? marius.
Andy Farnell wrote:
Hello Michael,
The keyword I read here is "installation", so the first three things on your list should be reliability, reliability and reliability. Nobody wants to see "This installation is out of order", and you don't want people seeing that right next to your name while you are 1000 miles away working on another project and uncontactable. Incidently - I saw a Nat West bank cashpoint yesterday with a "Win32 DLL missing" error - the thought of banking machines using Windows sends a shiver down my spine!
Closely connected to this is remote access, because this is your way into the system to reset or repair it when you are unable to be physically present.
Basically, the system should be designed like a server not a desktop. You will want an SSH shell, thttpd/boa type webserver to give you a page of easy to access stats, (uptime, CPU usage, memory etc). Stock Debian is probably the best all round OS for this application. The motherboard should be set up to reboot on shutdown (power into last state) so you can do a remote reset.
I think the best motherboards for installations are mini ITX 2.4GHz types. (Don't buy them from mini-itx.com if you ever want to see your purchase!) These can be practically silent with the fansink cooling, or if you want to go down to 1GHz (which can deliver a lot of audio) then you can go to a completely silent fanless system (perfect for small galleries). A wall mount case can be bolted to the underside of a desk as well as on a wall so your hardware doesn't go walkies when unattended.
Careful with cases, make sure there's enough slot room for any cards you want to add with mini ITX systems and make sure the PSU is rated high enough for the cards too (it probably is, even with the smallest wattage).
best regards, Andy
On Sun, 30 Dec 2007 15:31:10 +0100 Michael Iber music@chemie.fu-berlin.de wrote:
Hello list,
I have to build an audio computer running PD for an installation. Since I am not too familiar with actual hardware issues, I would like to ask, if there are any restrictions or aspects to kepp in mind concerning certain processor types, motherboards, graphic cards, HDs (SATA) ...
I will use a Hammerfall HDSP 9652 and the JAD-Distribution on a 32bit-architecture
Thanks a lot and a happy New Year, Michael
Michael Iber www.michael-iber.de mail@michael-iber.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
For installations, I've always tried to make the computer as "bulletproof" as possible. Usually, you have these guards or museum assistants who simply turn everything off (often with one mains switch!) every night, for example. You can make whatever documentation you want, but you can also assume that the people at the museum/gallery won't read it, and certainly won't log into your machine and type command lines to get things running again! So the best system is one that takes care of itself with minimal outside assistance beyond making sure the power is on.
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite smart. In the case of the ITX boards, this is a fantastic idea, since they are designed with this in mind and no drive means less moving parts, less weight/bulk and less noise.
Search archives for the "Turning on/off installation", "Hardware suggestions for museum installation, "pd patch startup at boot" and "autoboot in Linux" threads, there's lots there on autostarting PD.
best, d.
marius schebella wrote:
great posting, thanks. I can only support what andy said. I always thought the harddrive is the weakest part, but in all the years I was using pd for installations the only things that broke were a motherboard and a power adapter (and a screen during transport). of course it depends on how long the installation should run. but I know of pd installations that are up since 2000, so you really also want to think about maintanence. good documentation should always be part of your contract. also think about details like log files filling harddrive space or unmounting harddrives if they are not in use (just in case the computer loses its power). btw anyone worked with flash memory for installations? marius.
Andy Farnell wrote:
Hello Michael,
The keyword I read here is "installation", so the first three things on your list should be reliability, reliability and reliability. Nobody wants to see "This installation is out of order", and you don't want people seeing that right next to your name while you are 1000 miles away working on another project and uncontactable. Incidently - I saw a Nat West bank cashpoint yesterday with a "Win32 DLL missing" error - the thought of banking machines using Windows sends a shiver down my spine!
Closely connected to this is remote access, because this is your way into the system to reset or repair it when you are unable to be physically present.
Basically, the system should be designed like a server not a desktop. You will want an SSH shell, thttpd/boa type webserver to give you a page of easy to access stats, (uptime, CPU usage, memory etc). Stock Debian is probably the best all round OS for this application. The motherboard should be set up to reboot on shutdown (power into last state) so you can do a remote reset.
I think the best motherboards for installations are mini ITX 2.4GHz types. (Don't buy them from mini-itx.com if you ever want to see your purchase!) These can be practically silent with the fansink cooling, or if you want to go down to 1GHz (which can deliver a lot of audio) then you can go to a completely silent fanless system (perfect for small galleries). A wall mount case can be bolted to the underside of a desk as well as on a wall so your hardware doesn't go walkies when unattended.
Careful with cases, make sure there's enough slot room for any cards you want to add with mini ITX systems and make sure the PSU is rated high enough for the cards too (it probably is, even with the smallest wattage).
best regards, Andy
On Sun, 30 Dec 2007 15:31:10 +0100 Michael Iber music@chemie.fu-berlin.de wrote:
Hello list,
I have to build an audio computer running PD for an installation. Since I am not too familiar with actual hardware issues, I would like to ask, if there are any restrictions or aspects to kepp in mind concerning certain processor types, motherboards, graphic cards, HDs (SATA) ...
I will use a Hammerfall HDSP 9652 and the JAD-Distribution on a 32bit-architecture
Thanks a lot and a happy New Year, Michael
Michael Iber www.michael-iber.de mail@michael-iber.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
thanks, PP
Either way could work, the ramdisk is a particularly good idea. Unless the installation is networked, there's not too much need for logfiles in the classic server or multiuser environment sort of sense. You could probably also just disable to logging daemon by removing it from the boot scripts using rc-update (on Gentoo at least, or with another distro-specific equivalent). I imagine that logging would simply just fail quietly if the partition were read-only... I mean, what would log the fact that the logs weren't logging? ;-)
best, d.
Peter Plessas wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
- Derek Holzer derek@umatic.nl [2008-01-01 22:18]:
Either way could work, the ramdisk is a particularly good idea. Unless the installation is networked, there's not too much need for logfiles in the classic server or multiuser environment sort of sense. You could probably also just disable to logging daemon by removing it from the boot scripts using rc-update (on Gentoo at least, or with another distro-specific equivalent). I imagine that logging would simply just fail quietly if the partition were read-only... I mean, what would log the fact that the logs weren't logging? ;-)
Right, that's a nice point in particular! Thanks for the hints!
regards, PP
best, d.
Peter Plessas wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 184: "Where is the edge?"
Le Tue, 1 Jan 2008 22:28:10 +0100, Peter Plessas plessas@mur.at a écrit :
- Derek Holzer derek@umatic.nl [2008-01-01 22:18]:
Either way could work, the ramdisk is a particularly good idea. Unless the installation is networked, there's not too much need for logfiles in the classic server or multiuser environment sort of sense. You could probably also just disable to logging daemon by removing it from the boot scripts using rc-update (on Gentoo at least, or with another distro-specific equivalent). I imagine that logging would simply just fail quietly if the partition were read-only... I mean, what would log the fact that the logs weren't logging? ;-)
Right, that's a nice point in particular! Thanks for the hints!
You may also use Pure:Dyne, boot from CD, nest to a USB CF media. No HD needed.
If you have lots of RAM available and really need to write something, just use /dev/shm which is a kind of advanced RAM disk available on most Linux distros. Use a bash script to copy video/audio files & patches from the CD/DVD to /dev/shm in RAM at startup and symlink them to your /home or /tmp
++
The Audiopint project does this - details at audiopint.org if you're interested. We have a stripped-down Ubuntu image that you can download - it can be written to a USB flash drive, which the system boots from. -David
On Jan 4, 2008 11:49 AM, Olivier Heinry olivier.heinry@manga-burgah.net wrote:
Le Tue, 1 Jan 2008 22:28:10 +0100, Peter Plessas plessas@mur.at a écrit :
- Derek Holzer derek@umatic.nl [2008-01-01 22:18]:
Either way could work, the ramdisk is a particularly good idea. Unless the installation is networked, there's not too much need for logfiles
in
the classic server or multiuser environment sort of sense. You could probably also just disable to logging daemon by removing it from the boot scripts using rc-update (on Gentoo at least, or with another distro-specific equivalent). I imagine that logging would simply just fail quietly if the partition were read-only... I mean, what would log the fact that the logs weren't logging? ;-)
Right, that's a nice point in particular! Thanks for the hints!
You may also use Pure:Dyne, boot from CD, nest to a USB CF media. No HD needed.
If you have lots of RAM available and really need to write something, just use /dev/shm which is a kind of advanced RAM disk available on most Linux distros. Use a bash script to copy video/audio files & patches from the CD/DVD to /dev/shm in RAM at startup and symlink them to your /home or /tmp
++
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i'd suggest logging to a loghost, in clasic syslog.conf: *.* @loghost will send all logs to loghost machine, which has to be added to your hosts file. if you are using syslog-ng, it's slightly more complicated, but gives you more advantages! syslog-ng can send via TCP, so you can encrypt it with stunnel .. having an old-skool syslog at port 514(udp) is a potential security hole, but i do use it localy. once tried to have it over the internet - had about 5 people attacking me after a few hours!
i can post a syslog-ng.conf file if you wish .. i couldn't get stunnel working yet ;( but there tutorials ..
On Tue, Jan 01, 2008 at 10:18:13PM +0100, Derek Holzer wrote:
Either way could work, the ramdisk is a particularly good idea. Unless the installation is networked, there's not too much need for logfiles in the classic server or multiuser environment sort of sense. You could probably also just disable to logging daemon by removing it from the boot scripts using rc-update (on Gentoo at least, or with another distro-specific equivalent). I imagine that logging would simply just fail quietly if the partition were read-only... I mean, what would log the fact that the logs weren't logging? ;-)
best, d.
Peter Plessas wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 184: "Where is the edge?"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 1 Jan 2008 21:57:18 +0100 plessas@mur.at (Peter Plessas) wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
Symlink logs to /dev/null or use logrotate to delete them on the hour. Better if you can tell a process not to log though, stop the problem at its source.
thanks, PP
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Can't use logrotate if the partition is mounted readonly. I can see the point if the idea wasn't to fill up disk space, but my whole idea is to not write to the disk at all. Symlink is also a good idea, though.
best, d.
Andy Farnell wrote:
On Tue, 1 Jan 2008 21:57:18 +0100 plessas@mur.at (Peter Plessas) wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
Symlink logs to /dev/null or use logrotate to delete them on the hour. Better if you can tell a process not to log though, stop the problem at its source.
thanks, PP
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hm .. how about locks and other stuff ? there always some things which want to be written to somewhere in /var! the gentoo runscripts use /var/lib/init.d/ i reckon having a bit of space writable in /var and /tmp symlinked to /var ..could be usefull, keep one or two day's logs as well and log them on a loghost or mail before they being wiped off.. you can mail without a server .. might be able to use mutt or some command line util to do it via smtp .. well, this deppends on the network availability!
On Tue, Jan 01, 2008 at 10:49:14PM +0100, Derek Holzer wrote:
Can't use logrotate if the partition is mounted readonly. I can see the point if the idea wasn't to fill up disk space, but my whole idea is to not write to the disk at all. Symlink is also a good idea, though.
best, d.
Andy Farnell wrote:
On Tue, 1 Jan 2008 21:57:18 +0100 plessas@mur.at (Peter Plessas) wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
Symlink logs to /dev/null or use logrotate to delete them on the hour. Better if you can tell a process not to log though, stop the problem at its source.
thanks, PP
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 65: "Emphasize differences"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The whole idea of read-only is for two reasons:
- To protect the HD in case of unexpected shutdowns (which could happen
nightly in a typical museum situation) 2) To preserve the CF memory, which has a limited number of write cycles, in the case of a HD-less system
If the computer needs to be networked, then you might be moving away from the situation I have in mind, mainly an audio/video system in a gallery or museum. Another situation for this would be a "headless" computer for live stage performance, where you would often be powering it up and down like any other effects unit or sound module. (Unless you're one of those weirdos that likes typing on the laptop in front of crowds...)
In case of a networked installation, you'd probably want to set it up more like a "normal" server and put it someplace where you know it won't get zapped. But imagine, you don't *have* to connect to the internet to use a computer... ;-)
d.
errordeveloper@gmail.com wrote:
hm .. how about locks and other stuff ? there always some things which want to be written to somewhere in /var! the gentoo runscripts use /var/lib/init.d/ i reckon having a bit of space writable in /var and /tmp symlinked to /var ..could be usefull, keep one or two day's logs as well and log them on a loghost or mail before they being wiped off.. you can mail without a server .. might be able to use mutt or some command line util to do it via smtp .. well, this deppends on the network availability!
On Tue, Jan 01, 2008 at 10:49:14PM +0100, Derek Holzer wrote:
Can't use logrotate if the partition is mounted readonly. I can see the point if the idea wasn't to fill up disk space, but my whole idea is to not write to the disk at all. Symlink is also a good idea, though.
best, d.
Andy Farnell wrote:
On Tue, 1 Jan 2008 21:57:18 +0100 plessas@mur.at (Peter Plessas) wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
Symlink logs to /dev/null or use logrotate to delete them on the hour. Better if you can tell a process not to log though, stop the problem at its source.
thanks, PP
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 65: "Emphasize differences"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- Derek Holzer derek@umatic.nl [2008-01-02 21:12]:
The whole idea of read-only is for two reasons:
- To protect the HD in case of unexpected shutdowns (which could happen
nightly in a typical museum situation) 2) To preserve the CF memory, which has a limited number of write cycles, in the case of a HD-less system
Are you sure on this point? I just switched from a normal 2.5" IDE drive in my laptop to a compact flash card using an IDE<->CF adaptor. Are you referring to USB memory sticks (which might inhibit the same technology) or to CF cards as well? Now that i am so happy having a completely silent laptop, i might run into read/write errors soon....
rgds, PP
"Flash memory, regardless of format, supports only a limited number of erase/write cycles before a particular "sector" can no longer be written. Memory specifications generally allow 10,000[1] to 1,000,000 write cycles. Typically the controller in a CompactFlash attempts to prevent premature wearout of a sector by mapping the writes to various other sectors in the card - a process referred to as wear levelling."
http://en.wikipedia.org/wiki/CompactFlash#Description
sorry, d.
Peter Plessas wrote:
- Derek Holzer derek@umatic.nl [2008-01-02 21:12]:
The whole idea of read-only is for two reasons:
- To protect the HD in case of unexpected shutdowns (which could happen
nightly in a typical museum situation) 2) To preserve the CF memory, which has a limited number of write cycles, in the case of a HD-less system
Are you sure on this point? I just switched from a normal 2.5" IDE drive in my laptop to a compact flash card using an IDE<->CF adaptor. Are you referring to USB memory sticks (which might inhibit the same technology) or to CF cards as well? Now that i am so happy having a completely silent laptop, i might run into read/write errors soon....
rgds, PP
Come to think of it, are there any Linux distros for x86 architectures which don't use this multi-user/networked server paradigm and instead follow the "embedded" model more closely? This would be very interesting for exactly the situations I describe, where you would want the computer to behave more like a dedicated DSP unit or something similar, which just gets switched on and off with the mains like everything else in the rack without fooling around with screen, mouse or keyboard. I suppose a pushbutton wired to a "shutdown" script might do the trick too, but I'd rather go with something more bulletproof and requiring less attention.
best, d.
Derek Holzer wrote:
The whole idea of read-only is for two reasons:
- To protect the HD in case of unexpected shutdowns (which could happen
nightly in a typical museum situation) 2) To preserve the CF memory, which has a limited number of write cycles, in the case of a HD-less system
If the computer needs to be networked, then you might be moving away from the situation I have in mind, mainly an audio/video system in a gallery or museum. Another situation for this would be a "headless" computer for live stage performance, where you would often be powering it up and down like any other effects unit or sound module. (Unless you're one of those weirdos that likes typing on the laptop in front of crowds...)
OK, on a roll!
David Merrill's Audiopint got mentioned before on this list, since it's a headless box running Linux + PD. Fantastic project, very well-documented! Here's his install instruction for Ubuntu Edgy:
http://audiopint.org/docs/install
He suggests mounting /var and /tmp on a ramdisk using /etc/fstab. Couldn't be simpler!
Where did people suggest to get ITX boards, if mini-itx.com is so unreliable?
best, d.
Derek Holzer wrote:
Come to think of it, are there any Linux distros for x86 architectures which don't use this multi-user/networked server paradigm and instead follow the "embedded" model more closely? This would be very interesting for exactly the situations I describe, where you would want the computer to behave more like a dedicated DSP unit or something similar, which just gets switched on and off with the mains like everything else in the rack without fooling around with screen, mouse or keyboard. I suppose a pushbutton wired to a "shutdown" script might do the trick too, but I'd rather go with something more bulletproof and requiring less attention.
best, d.
Derek Holzer wrote:
The whole idea of read-only is for two reasons:
- To protect the HD in case of unexpected shutdowns (which could happen
nightly in a typical museum situation) 2) To preserve the CF memory, which has a limited number of write cycles, in the case of a HD-less system
If the computer needs to be networked, then you might be moving away from the situation I have in mind, mainly an audio/video system in a gallery or museum. Another situation for this would be a "headless" computer for live stage performance, where you would often be powering it up and down like any other effects unit or sound module. (Unless you're one of those weirdos that likes typing on the laptop in front of crowds...)
On Wed, 2 Jan 2008, Derek Holzer wrote:
The whole idea of read-only is for two reasons:
- To protect the HD in case of unexpected shutdowns (which could happen
nightly in a typical museum situation)
The whole idea of a separate volume for /var that you see on Linux, and the whole idea of /var in the first place, is to allow the rest of the OS to be mounted read-only. (networked volumes were an afterthought added in the 80's, though it fits really well with the /var concept).
The logs normally go in /var. It's much quicker to do an integrity check on the /var volume than on the whole OS, plus it ensures that the OS won't panic like some Linuxes do when the / volume was improperly unmounted. On OSes that don't have that latter problem, it's still a good idea because then you're sure that a fuckup in /var won't affect any of the files on the / volume.
If you don't have a separate /var, you can still do the same using e.g. a USB flash volume or old USB hard disk, for all your logs. In general it's a good idea to keep logs of what's going on in your installation, to improve diagnostic when a problem occurs.
E.g. I used logs to detect a very slow memory leak, that would take two weeks to notice. By looking at the rate at which it occurred, I was able to guess the data type of the leaked memory! (this was before Valgrind made it easier to debug those). Even if you don't program, it's cool to be able to give those details in a bug report.
Also the logs can measure the time between crashes and report it, or even the consistency of framerate, etc.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, Jan 01, 2008 at 09:32:35PM +0000, Andy Farnell wrote:
On Tue, 1 Jan 2008 21:57:18 +0100 plessas@mur.at (Peter Plessas) wrote:
- Derek Holzer derek@umatic.nl [2007-12-31 18:47]:
So I made sure to mount all my drives read-only, and that everything would start from a script on power-up. Having the whole operating system on a Flash card/USB stick (again, no logging, read-only) is also quite
How do you do that? Do you mount /var/log as ramdisk which gets erased at reboot, or do you tell every service/daemon not to log?
Symlink logs to /dev/null or use logrotate to delete them on the hour. Better if you can tell a process not to log though, stop the problem at its source.
well, better to just comment, or empty /etc/syslog.conf, or may be even write something like '*.* /dev/null' in there :)
btw, has anyone heared of something that would give some special features to a directory, so for example all files which are created in there will become just links to /dev/null ? or something else would happend to ecach of them .. ?
thanks, PP
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
David Merrill -
Derek Holzer -
errordeveloper＠gmail.com -
marius schebella -
Mathieu Bouchard -
Michael Iber -
Olivier Heinry -
Peter Plessas -
plessas＠mur.at