MacResearch Introduces OpenMacGrid
Drew McCormack writes "MacResearch.org has just introduced OpenMacGrid. It is a distributed computing grid similar to SETI@home, but unlike other networks, it is built up entirely of Macs utilizing Xgrid, and access is unrestricted. Anyone with Mac OS X 10.4 can donate cycles, and any scientist with a reasonable project can burn cycles."
This only works in a LAN. Every single frame of a modern movie requires gigabytes of texture data etc. etc... It's not something you can send over the Internet.
.: Max Romantschuk
So, Xgrid-experts, what kind of permissions does an application like this have? Is it sandboxed somehow?
/tmp or ~/Public/Drop Box or whatever with garbage until you run out of disk, or some other annoying things. I won't say "nothing major", because that depends on what you've got that's readable or writable by others. I'm also not wearing my expert hat, so it's entirely possible that I'm unaware of some way that Xgrid jobs could 0wnz0r you.
Xgrid jobs run as user 'nobody', which is decently safe, with process limits so it can't forkbomb you to death. A rogue job could fill up
You still need to trust OpenMacGrid to keep these bad jobs off the grid.
Don't become a regular here -- you will become retarded.
"...and access is unrestricted."
Well, kind of. Except for the fact that you need a proprietary OS to access it. And proprietary hardware to go with it. It seems if you do not have the correct hardware and try to run this, Apple will sue the shit out of you. Why don't they make this compatable with all versions of FreeBSD, then call it unrestricted?
How useful can it be to be locked into one OS? How hard is it to make a commandline program and then a Cocoa interface, that way you can get everyone and still have a pretty window and widget for OS X users.
OpenMacGrid uses Xgrid, which is Mac-only. It isn't something new they've made: it's built-in to Mac OS X. You ask "how hard is it...", and the answer is "A lot harder than just using what's already available."
Also, the Xgrid agent doesn't have a pretty window. It's a background daemon.
Don't become a regular here -- you will become retarded.
"Laziness is an optimisation protocol"
Do they ever. The disk image mounting in OS X makes Linux's loopback devices look like crap. While you can make an image containing only a filesystem you can also make one containing a full disk image (including MBR and everything). When mounted it will for example show up as /dev/disk2 (whole disk), /dev/disk2s1 (first partition), /dev/disk2s2 (second partition) and so on. Makes disk recovery of an imaged disk a shitload easier because you don't have to go through the laborious task of calculating offsets based off the partition table. The kernel does it for you like it would with any other "disk".
Traditionally the "nobody" user has been used by various daemons that need only read-only disk access (and often which can accept strict ulimits). It's generally not possible to log in as nobody, and nobody usually does not own any files, but it's still useful as daemon account.
It's becoming more common to assign each daemon its own user, but so long as your process doesn't write any files there's not much security benefit to having your own user, and there is a convience aspect to having fewer users to manage. In particular, it can become a hassle to ensure that each of 25 different daemon users has an account that prevents logins and owns no files; having fewer such accounts makes security verification simplier.