What was wrong with the NTBackup supplied with XP (developed by Veritas, wouldn't you know)? * Easy to pick exactly what you want to back up * Easy to add pattens or folders to always exclude, with a sensible default list. * Volume shadow support * Schedule it to run anytime.
Why... it didn't support burning to DVD?
It doesn't take anyone who has the sense to make backups more than minute to see you can drag that file into a DVD burning application.
-- Provided that auditing is turned on and you're logging the minimum of: process execution / fork system calls, opens, closes and process exits.
Have a cron job that runs daily and mines the audit data for file access that happens after execs of programs (on a per program basis). Have it analyze at least N execs and find all the common file open-for-reads that happen consistently in that process or any child. (You need to log closes/exit so you know the scope of a process and when to stop looking for file opens that might belong to a process you're interested in... speeds up log processing).
Once the cron job has culled enough data, it would create a "prefetch profile" listing the files that are common, and stat them to find how big they all are. If there are a lot of small files, it'll check to see if the blocks of each file are roughly in the same area of the disk. If not, unlink and copy in place to try to coerce them into the same allocation group. Finally, it would create a small script or config file in a directory somewhere, one for each monitored program, listing the files in sorted order by their block positions on the disk. This file would be read by a system service that runs before login and occaisonally wakes up and reads those files, thus forcing them into the buffer cache. It would decide which file groups to read first based on the amount of time each parent exec process ran during the log interval examined (100% of the time, 50% of the time). A certain weight would be given to programs that are started repeatedly (since they may incur many disk IOs [page in AND page out] better to do it upfront). The file service would constantly run, reading files aggresively when the IO load is otherwise low (sort of like the minimum and maximum transfer rates of the softraid kernel threads), but throttling back when in IO contention. It would wake up after short intervals, find the most "important" program it hasn't loaded files for that isn't already running, and work that file list. Then go to sleep for a time that keeps the average IO rate below the max threshold. A side effect of this might be that the page flush kernel threads need not run so frequently since this program will put page-out pressure on old pages.
And the service would go to sleep for a long time when IO counters indicate less than a certain threshold of page-ins since the last time it ran (and collected said statistics)... this indicates that it can no longer improve any program's startup time.
Wow. This is intense. I wonder if the optimizer in OSX is anything like this, or the RedHat prefetch service.
Hahaha... yeah. Well, color me unimpressed. They extend the presence concepts (Jaber, XMPP, Google Talk, everybody's doin it) and notification APIs (what, on top of UPnP, right?). Never mind that you need to have apps that support it. Basically, Office.
Oh, and Office on other OSs (2000/XP) will support the same workflow features.
So, what's so great about this? It's not like you can't bundle a simple API with your API to talk the talk. UPnP was available in XP Gold..NET 1.1 can talk XMPP and has messaging APIs.
when they fail to understand what 2LOT really means, or misinterpret the terms used in its definition. Like what exactly is entropy, and what exactly is heat? About defining the boundary of a system. About local vs. global, pinning down the boundary of system, unseen or assumed sources and sinks of energy, even not accounting for the radiation of heat away into the ever-increasing space of the universe (ultimate limitless heat sink).
It could clear things up for a lot of people and save millions upon millions of keystrokes in forum replies and usenet posts.:-/
There are always so many facets of each theory to find support for, and more consequences that lead to more theories and questions and derivative truths that must be verified... and if stuff doesn't quite make sense, well then you need to go back and see what assumptions were wrong and fill in the gaps.
I mean, that IS the scientific process! There's always debate and uncertainty. That's not an indication of a wrong avenue of investigation, rather it's a good sign of a worthy field of inquiry.
Of course, we know enough to posit we're in the right ballpark with evolution. There are a lot of basic prinicples we know to be verifiable, but there's still a lot of questions. But we find places to hang the evidence on the framework and the picture is getting sharper all the time. And the theories have tangible derivative ideas that help us in biochemstiry and agriculture and environmental studies, so we have to be on the right track.
* Lifeforms change over time to adapt to changing conditions. * Lifeforms never change.
Note that this doesn't even begin to address how life came into being in the first place, nor even exactly what life is!
The researchers who study where life came from do not overlap with those who study the origin of species. This is because we have little to no evidence to make any claims to what happened before the fossil record, and we little left of the earth's surface that hasn't been turned into magma in the last half billion years. So the only we can posit how life might have began is to try different biochemical theories and try to duplicate it ourselves... then test to see if there any indicators that the earth could have those same conditions long ago.
So either we came from goo... Or maybe life came from elsewhere in the solar system. Or maybe the Christian god did it. Or maybe we are all living in a computer simulation and the fauna and flora are the creation of a deranged ex-Disney employee.
This is a completely divorced concept from evolution.
I mean we could have the Genesis creation scenario, where all the animals appeared at once, and a false fossil record created... AND STILL HAVE EVOLUTION. You know, maybe animals evolved anyway and in 50,000 years we'll have slightly different or new furry friends.
Maybe there is a god. And evolution. Or maybe there isn't, and there's evolution. Or maybe there is no god or evolution, and animals just spawn like in an MMORPG.
I think you could get away with a 256x256 sensor (real cheap IC) that is hooked up with a plastic lens to read a 1/2" square area at roughly 300dpi.
It could break the image up into tiles, and autocorrelate them as you scan to build up the document on the fly in the onboard memory. An ARM core with a few meg of onboard RAM and flash, maybe a DSP, it shouldn't take much to make that possible in a mouse-sized, lightweight device.
Put a few LEDs on top that tell you where to move the "mouse" to get full coverage of the page since you don't have a realtime preview.
Instructions might say: "Move mouse in back and forth scanning motion over text you want to capture. Do not rotate mouse for best results." Of course you could omit parts of the page that are blank or you don't want to copy.
After I posted this, I found even cheaper ways to hook up CD-ROMs... there's these IDEUSB converter dongles which are basically the guts of the enclosures. You can get 'em for half the price.
You don't have to spend more than a few hundred dollars. Set them up in some kinda lego tower with all the cables snakin out of it.:-D The cool part about this is being able to just insert CDs and have the software automatically rip and index it. The system would eject the drive when it can accept another.
Besides, I already have thousands of CDs. I'm not paying to have some kid manhandle them and rip them for his own personal use.:-/
1) Buy as many external USB2.0 5.25" enclosures that you possibly afford. They run anywhere from $20-$40. The main thing you're getting out of this is POWER ADAPTERS.
2) Buy an equal number of IDE CDROM drives. If you paid more than $20 for any of them, you paid too much.
I wouldn't spend more than $50 with tax and shipping for each pair of CD-ROM + enclosure. You can do it for $40 if you buy refurbed/OEM/surplus stuff.
If you managed to get more than 12 drives, then also buy a cheap, bus-powered 4-way USB 2.0 hub for every 4 drives. This should be $15 or less a piece, shipped. Make sure it comes with a short A-B cable. (some of the cheap one's don't)
Add up the total number of USB-2.0 connections you have to make with the host computer. If you have 14 drives, that's 3 + 2 = 5 (3 from the USB hubs that hold 4 each, and 2 left over). You'll need that many connections on your host computer.
Purchase an appropriate number of USB-2.0 expansion cards with at least 3 ports each. You may have some onboard, but you shouldn't plug all your drives into it because the southbridge becomes a bottleneck when you have a lot of USB endpoints behind it. Try to put one hub on the onboard USB-2.0, and then 1 per expansion card. Once you put a hub on each expansion card, loop around at put another hub on the onboard USB, then visit all the expansion cards again. Finally, do the same procedure with the non-hub attached CDROMs.
This should balance your connections among the USB controllers in your system in such a way to minimize PCI and USB bus contention.
So let's say I bought 24 external CDROMs. I would buy 6 USB2 4-way hubs, and 2 PCI USB-2.0 controllers (in addition to the one in my motherboard)
I would plug all 24 drives into the hubs, and then 2 hubs into each PCI card, and the remaining 2 into my onboard USB2.
Stack up all the external CDROMs into a couple of nice rows, and turn on your system.
Boom! You should detect 24 CDROM drives. You should be able to rip in parallel.
Note: You may have trouble ripping from a lot of CDROM drives simultaneously. If so, break your work into chunks that operate a few drives at a time, and go full tilt ripping and encoding. When one set is done, move onto the next set of drives. At least you don't have to run around changing CDs every 5 minutes.
Try different combinations of numbers of drives until you find your max throughput.
Note: Windows might not like having 20+ individual drives plugged in. At least, the shell might not give drive letters to all of them. You'll have to get creative with the volume manager and accessing them in other ways. In linux/BSD, it's a matter of starting a lot of ripping processes in parallel, appropriately niced.
Note: You might need a lot of powerstrips. Try the "Squid". It's $15 a pop but you'll use it for more than just this.
Example costs (all with 3 day shipping):
* 24 Samsung CDROM drives from CSO: $ 200 * 24 external 5.25" enclosures from NewEgg $ 700 * 6 USB2.0 hubs from NewEgg $ 90 * 2 USB2.0 controller cards from NewEgg $ 25 * 5 "Squids" from any etailer: $ 75
Total cost for 24 CDs AT ONCE: ~$1100
Now that's not bad at all. A lot less power draw and more managable than 8 PCs on your dining room table. Plus you can probably get away with returning those CD-ROM enclosures. Better yet, you could probably net a profit reselling the assembled external CD-ROMs on ebay.:-D
It's funny because I've done exactly that. I'll be at work and need a obscure bunch of tracks for a mix CD for someone in the office. Shit... my CDs are at home, of course. But sure enough, AllofMP3 has it. Do I pay a dollar to save the hassel of lugging around and flipping through a CD album? You bet I do, especially when I get to pick the encoding technique. The day is saved! Huzzah!
Costco is the only retailer besides Walmart that regularly gets vendors to specially package/distribute products exclusively for their benefit. Witness larger-than-usual boxes of diapers or laundry detergent with a costco label and item number on the packaging... Kirkland Signature "Starbucks Roasted" coffee beans, complete Dell computers in boxes, etc...
That should read d(t)/dt or dt/delta_t (imagine the delta_t is dt with the curvy d representing a partial derivative with respect to t). In any case you are finding the derivative of the function f(t) -> t with respect to t, which by definition, is 1. Not because dt/dt cancels out. Same result, different reason.
Strictly speaking the partial derivative of the component t with respect to t (that is, d(t)/dt) is 1. But not because dt/dt = 1. It's d(t)/dt. There's a difference.:-) Hell... x, y, z could be defined in terms of some parameter that isn't t, or is the application of an operator to t... in which case d(U)/dt (where U represents whatever the hell it is) isn't so simple anymore... and you need THE CALCULUS (dunh dunh dunh)
just like windows used to use FAT32 by default (and many OEMs still do)
Modern linux systems have MAC systems (SELinux, grsecurity, and a few others) and POSIX ACLs on disk (ext3, XFS, JFS and NFS v3/4 all support it).
I think the one thing that windows has that is interesting from a security perspecitve is the ACEs on registry entries and how this configuration API is system-level, cannot be bypassed, tied to the user/process, etc.
Unix apps have nothing as advanced as that and I would like to see some progress in configuration management and the administrative features thereof (security especially). I think GConf/dbus is a step in the right direction... but there should be something more basic, like a POSIX extension that enforces some semantics... something to be implemented in the kernel.
Maybe a virtual FS (configuration FS). Like sys or proc. Have it backed by a partition or network server or something and configured at boot time like initrd.
Plus side of scheduler: You can run tasks as domain users. Minus side of scheduler: You can't run anything as a domain user without an existing token (i.e. parent process) or authenticating to Domain as said user.
Hence the built-in password.
Of course, protection of said password is only as good as machine protection, which isn't great if you can remove the HD and retrieve it from the job files.
So, that being said, since the supposed security of the running job is only as good as physical machine security, you might as well run the task as system because it isn't any more or less protected.
If you want to run it with reduced rights, create a local user who's password does not expire and pick a lengthy password that is unlikely to be broken. Also, remove all login rights EXCEPT login as a batch job, to avoid attempts to guess the password through logon attempts (local or network based).
If you need the rights of a Domain user (with resources that reside on machines on the domain), well you're SOL.:-) You're just going to have to keep updating that job...
Applications which are happy enough to be installed in ~/bin can usually be configured (or built in such a fashion) to check ~/lib or something similar for their requisite libraries. You can get pretty fancy with a setup like that... multiple versions of apps and utilities and whatnot.
But interesting none-the-less. Too bad it got modded into oblivion. Some of these "losers" could have learned a thing or two about industry. But then, you had to get all offensive.
You have to be _subtle_ with your barbs, so it flies over the heads of the moderators with PMS.
1) Most new servers will be damaged if you attempt to run them without their covers on (warnings are usually written inside the case) 2) If a server runs cooler with it's cover off than when it does with it on.... THROW IT OUT, GET A NEW ONE. That indicates shit-poor design and I'd replace it if you value the data stored therein, let alone the power savings going with a newer, well engineered system.
However I do second the box fan notion. It's lowtech but it can be the perfect solution for a less than perfect server room layout or AC design (often this is out of your hands...)
XFS and ext3 can have their metadata logs/journals on other physical devices, seperate from the actual filesystem blocks. Sometimes filesystems are RAID aware, in that they choose to allocate blocks at the beginning of RAID strides and stuff like that, But that's about as flexible as filesystems get.
Slashdot Mirror
What was wrong with the NTBackup supplied with XP (developed by Veritas, wouldn't you know)?
* Easy to pick exactly what you want to back up
* Easy to add pattens or folders to always exclude, with a sensible default list.
* Volume shadow support
* Schedule it to run anytime.
Why... it didn't support burning to DVD?
It doesn't take anyone who has the sense to make backups more than minute to see you can drag that file into a DVD burning application.
-- Provided that auditing is turned on and you're logging the minimum of: process execution / fork system calls, opens, closes and process exits.
Have a cron job that runs daily and mines the audit data for file access that happens after execs of programs (on a per program basis). Have it analyze at least N execs and find all the common file open-for-reads that happen consistently in that process or any child. (You need to log closes/exit so you know the scope of a process and when to stop looking for file opens that might belong to a process you're interested in... speeds up log processing).
Once the cron job has culled enough data, it would create a "prefetch profile" listing the files that are common, and stat them to find how big they all are. If there are a lot of small files, it'll check to see if the blocks of each file are roughly in the same area of the disk. If not, unlink and copy in place to try to coerce them into the same allocation group.
Finally, it would create a small script or config file in a directory somewhere, one for each monitored program, listing the files in sorted order by their block positions on the disk. This file would be read by a system service that runs before login and occaisonally wakes up and reads those files, thus forcing them into the buffer cache. It would decide which file groups to read first based on the amount of time each parent exec process ran during the log interval examined (100% of the time, 50% of the time). A certain weight would be given to programs that are started repeatedly (since they may incur many disk IOs [page in AND page out] better to do it upfront).
The file service would constantly run, reading files aggresively when the IO load is otherwise low (sort of like the minimum and maximum transfer rates of the softraid kernel threads), but throttling back when in IO contention. It would wake up after short intervals, find the most "important" program it hasn't loaded files for that isn't already running, and work that file list. Then go to sleep for a time that keeps the average IO rate below the max threshold.
A side effect of this might be that the page flush kernel threads need not run so frequently since this program will put page-out pressure on old pages.
And the service would go to sleep for a long time when IO counters indicate less than a certain threshold of page-ins since the last time it ran (and collected said statistics)... this indicates that it can no longer improve any program's startup time.
Wow. This is intense. I wonder if the optimizer in OSX is anything like this, or the RedHat prefetch service.
Hahaha... yeah. Well, color me unimpressed.
.NET 1.1 can talk XMPP and has messaging APIs.
They extend the presence concepts (Jaber, XMPP, Google Talk, everybody's doin it) and notification APIs (what, on top of UPnP, right?). Never mind that you need to have apps that support it.
Basically, Office.
Oh, and Office on other OSs (2000/XP) will support the same workflow features.
So, what's so great about this? It's not like you can't bundle a simple API with your API to talk the talk. UPnP was available in XP Gold.
Big. Fucking. Deal.
when they fail to understand what 2LOT really means, or misinterpret the terms used in its definition.
:-/
Like what exactly is entropy, and what exactly is heat? About defining the boundary of a system. About local vs. global, pinning down the boundary of system, unseen or assumed sources and sinks of energy, even not accounting for the radiation of heat away into the ever-increasing space of the universe (ultimate limitless heat sink).
It could clear things up for a lot of people and save millions upon millions of keystrokes in forum replies and usenet posts.
And in any science, nothing is ever a done deal.
There are always so many facets of each theory to find support for, and more consequences that lead to more theories and questions and derivative truths that must be verified... and if stuff doesn't quite make sense, well then you need to go back and see what assumptions were wrong and fill in the gaps.
I mean, that IS the scientific process! There's always debate and uncertainty. That's not an indication of a wrong avenue of investigation, rather it's a good sign of a worthy field of inquiry.
Of course, we know enough to posit we're in the right ballpark with evolution. There are a lot of basic prinicples we know to be verifiable, but there's still a lot of questions. But we find places to hang the evidence on the framework and the picture is getting sharper all the time. And the theories have tangible derivative ideas that help us in biochemstiry and agriculture and environmental studies, so we have to be on the right track.
The dichotomy (if any exists), is thus:
* Lifeforms change over time to adapt to changing conditions.
* Lifeforms never change.
Note that this doesn't even begin to address how life came into being in the first place, nor even exactly what life is!
The researchers who study where life came from do not overlap with those who study the origin of species. This is because we have little to no evidence to make any claims to what happened before the fossil record, and we little left of the earth's surface that hasn't been turned into magma in the last half billion years. So the only we can posit how life might have began is to try different biochemical theories and try to duplicate it ourselves... then test to see if there any indicators that the earth could have those same conditions long ago.
So either we came from goo...
Or maybe life came from elsewhere in the solar system.
Or maybe the Christian god did it.
Or maybe we are all living in a computer simulation and the fauna and flora are the creation of a deranged ex-Disney employee.
This is a completely divorced concept from evolution.
I mean we could have the Genesis creation scenario, where all the animals appeared at once, and a false fossil record created... AND STILL HAVE EVOLUTION. You know, maybe animals evolved anyway and in 50,000 years we'll have slightly different or new furry friends.
Maybe there is a god. And evolution. Or maybe there isn't, and there's evolution.
Or maybe there is no god or evolution, and animals just spawn like in an MMORPG.
*shrugs*
http://sprite.student.utwente.nl/~jeroen/projects/ mouseeye/
I think you could get away with a 256x256 sensor (real cheap IC) that is hooked up with a plastic lens to read a 1/2" square area at roughly 300dpi.
It could break the image up into tiles, and autocorrelate them as you scan to build up the document on the fly in the onboard memory. An ARM core with a few meg of onboard RAM and flash, maybe a DSP, it shouldn't take much to make that possible in a mouse-sized, lightweight device.
Put a few LEDs on top that tell you where to move the "mouse" to get full coverage of the page since you don't have a realtime preview.
Instructions might say: "Move mouse in back and forth scanning motion over text you want to capture. Do not rotate mouse for best results."
Of course you could omit parts of the page that are blank or you don't want to copy.
What do you think about that?
After I posted this, I found even cheaper ways to hook up CD-ROMs... there's these IDEUSB converter dongles which are basically the guts of the enclosures. You can get 'em for half the price.
:-D
:-/
You don't have to spend more than a few hundred dollars. Set them up in some kinda lego tower with all the cables snakin out of it.
The cool part about this is being able to just insert CDs and have the software automatically rip and index it. The system would eject the drive when it can accept another.
Besides, I already have thousands of CDs. I'm not paying to have some kid manhandle them and rip them for his own personal use.
First:
:-D
1) Buy as many external USB2.0 5.25" enclosures that you possibly afford. They run anywhere from $20-$40. The main thing you're getting out of this is POWER ADAPTERS.
2) Buy an equal number of IDE CDROM drives. If you paid more than $20 for any of them, you paid too much.
I wouldn't spend more than $50 with tax and shipping for each pair of CD-ROM + enclosure. You can do it for $40 if you buy refurbed/OEM/surplus stuff.
If you managed to get more than 12 drives, then also buy a cheap, bus-powered 4-way USB 2.0 hub for every 4 drives. This should be $15 or less a piece, shipped. Make sure it comes with a short A-B cable. (some of the cheap one's don't)
Add up the total number of USB-2.0 connections you have to make with the host computer. If you have 14 drives, that's 3 + 2 = 5 (3 from the USB hubs that hold 4 each, and 2 left over). You'll need that many connections on your host computer.
Purchase an appropriate number of USB-2.0 expansion cards with at least 3 ports each. You may have some onboard, but you shouldn't plug all your drives into it because the southbridge becomes a bottleneck when you have a lot of USB endpoints behind it.
Try to put one hub on the onboard USB-2.0, and then 1 per expansion card. Once you put a hub on each expansion card, loop around at put another hub on the onboard USB, then visit all the expansion cards again. Finally, do the same procedure with the non-hub attached CDROMs.
This should balance your connections among the USB controllers in your system in such a way to minimize PCI and USB bus contention.
So let's say I bought 24 external CDROMs.
I would buy 6 USB2 4-way hubs, and 2 PCI USB-2.0 controllers (in addition to the one in my motherboard)
I would plug all 24 drives into the hubs, and then 2 hubs into each PCI card, and the remaining 2 into my onboard USB2.
Stack up all the external CDROMs into a couple of nice rows, and turn on your system.
Boom! You should detect 24 CDROM drives. You should be able to rip in parallel.
Note: You may have trouble ripping from a lot of CDROM drives simultaneously. If so, break your work into chunks that operate a few drives at a time, and go full tilt ripping and encoding. When one set is done, move onto the next set of drives. At least you don't have to run around changing CDs every 5 minutes.
Try different combinations of numbers of drives until you find your max throughput.
Note: Windows might not like having 20+ individual drives plugged in. At least, the shell might not give drive letters to all of them. You'll have to get creative with the volume manager and accessing them in other ways. In linux/BSD, it's a matter of starting a lot of ripping processes in parallel, appropriately niced.
Note: You might need a lot of powerstrips. Try the "Squid". It's $15 a pop but you'll use it for more than just this.
Example costs (all with 3 day shipping):
* 24 Samsung CDROM drives from CSO: $ 200
* 24 external 5.25" enclosures from NewEgg $ 700
* 6 USB2.0 hubs from NewEgg $ 90
* 2 USB2.0 controller cards from NewEgg $ 25
* 5 "Squids" from any etailer: $ 75
Total cost for 24 CDs AT ONCE: ~$1100
Now that's not bad at all. A lot less power draw and more managable than 8 PCs on your dining room table.
Plus you can probably get away with returning those CD-ROM enclosures. Better yet, you could probably net a profit reselling the assembled external CD-ROMs on ebay.
It's funny because I've done exactly that. I'll be at work and need a obscure bunch of tracks for a mix CD for someone in the office. Shit... my CDs are at home, of course. But sure enough, AllofMP3 has it. Do I pay a dollar to save the hassel of lugging around and flipping through a CD album? You bet I do, especially when I get to pick the encoding technique.
The day is saved! Huzzah!
I'm 16 and I like looking at pictures of the opposite sex of my own age.
Does this mean I like CP?
Costco is the only retailer besides Walmart that regularly gets vendors to specially package/distribute products exclusively for their benefit. Witness larger-than-usual boxes of diapers or laundry detergent with a costco label and item number on the packaging... Kirkland Signature "Starbucks Roasted" coffee beans, complete Dell computers in boxes, etc...
NO WAI!
Old winbond southbridge... no USB2.0 or firewire. :-(
Kinda necessary for a portable IMHO... USB1.1 is dismally slow.
Quantum electrofucking dynamics...
What the hell is electrofucking, and where can I sign up for it?
That should read d(t)/dt or dt/delta_t (imagine the delta_t is dt with the curvy d representing a partial derivative with respect to t).
In any case you are finding the derivative of the function f(t) -> t with respect to t, which by definition, is 1. Not because dt/dt cancels out. Same result, different reason.
Strictly speaking the partial derivative of the component t with respect to t (that is, d(t)/dt) is 1. But not because dt/dt = 1. It's d(t)/dt. There's a difference. :-)
Hell... x, y, z could be defined in terms of some parameter that isn't t, or is the application of an operator to t... in which case d(U)/dt (where U represents whatever the hell it is) isn't so simple anymore... and you need THE CALCULUS (dunh dunh dunh)
just like windows used to use FAT32 by default (and many OEMs still do)
Modern linux systems have MAC systems (SELinux, grsecurity, and a few others) and POSIX ACLs on disk (ext3, XFS, JFS and NFS v3/4 all support it).
I think the one thing that windows has that is interesting from a security perspecitve is the ACEs on registry entries and how this configuration API is system-level, cannot be bypassed, tied to the user/process, etc.
Unix apps have nothing as advanced as that and I would like to see some progress in configuration management and the administrative features thereof (security especially). I think GConf/dbus is a step in the right direction... but there should be something more basic, like a POSIX extension that enforces some semantics... something to be implemented in the kernel.
Maybe a virtual FS (configuration FS). Like sys or proc. Have it backed by a partition or network server or something and configured at boot time like initrd.
Plus side of scheduler: You can run tasks as domain users.
:-) You're just going to have to keep updating that job...
Minus side of scheduler: You can't run anything as a domain user without an existing token (i.e. parent process) or authenticating to Domain as said user.
Hence the built-in password.
Of course, protection of said password is only as good as machine protection, which isn't great if you can remove the HD and retrieve it from the job files.
So, that being said, since the supposed security of the running job is only as good as physical machine security, you might as well run the task as system because it isn't any more or less protected.
If you want to run it with reduced rights, create a local user who's password does not expire and pick a lengthy password that is unlikely to be broken. Also, remove all login rights EXCEPT login as a batch job, to avoid attempts to guess the password through logon attempts (local or network based).
If you need the rights of a Domain user (with resources that reside on machines on the domain), well you're SOL.
Applications which are happy enough to be installed in ~/bin can usually be configured (or built in such a fashion) to check ~/lib or something similar for their requisite libraries. You can get pretty fancy with a setup like that... multiple versions of apps and utilities and whatnot.
In fact, that proof (.999999... == 1) is a necessary property of decimal expansions that is integral to defining real numbers in terms of basic arithmetic axioms, see:t hereals/
http://www.math.vanderbilt.edu/~schectex/courses/
Chip.
On.
Shoulder.
But interesting none-the-less. Too bad it got modded into oblivion. Some of these "losers" could have learned a thing or two about industry. But then, you had to get all offensive.
You have to be _subtle_ with your barbs, so it flies over the heads of the moderators with PMS.
1) Most new servers will be damaged if you attempt to run them without their covers on (warnings are usually written inside the case)
2) If a server runs cooler with it's cover off than when it does with it on.... THROW IT OUT, GET A NEW ONE. That indicates shit-poor design and I'd replace it if you value the data stored therein, let alone the power savings going with a newer, well engineered system.
However I do second the box fan notion. It's lowtech but it can be the perfect solution for a less than perfect server room layout or AC design (often this is out of your hands...)
XFS and ext3 can have their metadata logs/journals on other physical devices, seperate from the actual filesystem blocks.
Sometimes filesystems are RAID aware, in that they choose to allocate blocks at the beginning of RAID strides and stuff like that, But that's about as flexible as filesystems get.