File Location Madness...eXtreme!
Jun. 6th, 2009 10:02 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
le_bebna_kamniIt's like a video game, except inode entries are getting bumped around instead of pinballs. Yay! :D
I'm a little goofy at the moment, because I've been trying like crazy to get Bespin running on a server under a hybrid custom application that I'm slapping together so that Matt and other members of the CREM development team can edit, test, and make commits to the repository from the web.
Don't ask me how I'll do it...I'm not even sure it will work. Perhaps some of you will be visiting me in a local insane asylum in a week or two.
However, while I take a break and ponder the futility of my undertaking, I wanted to share a thought regarding file location (or relocation), which seems to be the bulk of my troubles for the particular part of the task I'm working on.
You see, whenever you compile or install or configure anything, once you put it in place you really can't move it. Oh, you can sometimes set things up with relative paths, but that just allows you to move the root folder around -- you still can't move individual files.
So my idea is this: what if computers had the equivalent of a DNS server for their file system, but slightly smarter? Files have inode numbers, which might be likened to IP addresses, and folders could be 'zones', and in some other respects it kind of works like DNS already.
But here's how it might work differently: let's say that you have a file with inode number [4435] located at /usr/bin/test.sh and you move it to /usr/local/bin/test.sh. The inode 'DNS server' would first modify the reverse lookup to match the new location (i.e., looking up [4435] returns '/usr/local/bin/test.sh'). Then it would keep the old forward lookup ('/usr/bin/test.sh' returns [4435], until a new '/usr/bin/test.sh' file is created) and add an additional new lookup ('/usr/local/bin/test.sh' also returns [4435]).
There are definitely some drawbacks to this -- for example, simply moving a file won't stop a program from accessing it. However, if such a system were created, the applications that used it could be made inode-DNS-aware: the 'mv' command might have a '-d' option to move the file *and* delete the old forward lookup.
Yeah, I know, it's probably got a ton of other issues that I haven't considered. Perhaps it would put a huge strain on the system, create huge security holes -- who knows? But at 11:02 pm when I'm fighting with trying to figure out which config files need to be changed, DNS sounds fantastic! ;P
I'm a little goofy at the moment, because I've been trying like crazy to get Bespin running on a server under a hybrid custom application that I'm slapping together so that Matt and other members of the CREM development team can edit, test, and make commits to the repository from the web.
Don't ask me how I'll do it...I'm not even sure it will work. Perhaps some of you will be visiting me in a local insane asylum in a week or two.
However, while I take a break and ponder the futility of my undertaking, I wanted to share a thought regarding file location (or relocation), which seems to be the bulk of my troubles for the particular part of the task I'm working on.
You see, whenever you compile or install or configure anything, once you put it in place you really can't move it. Oh, you can sometimes set things up with relative paths, but that just allows you to move the root folder around -- you still can't move individual files.
So my idea is this: what if computers had the equivalent of a DNS server for their file system, but slightly smarter? Files have inode numbers, which might be likened to IP addresses, and folders could be 'zones', and in some other respects it kind of works like DNS already.
But here's how it might work differently: let's say that you have a file with inode number [4435] located at /usr/bin/test.sh and you move it to /usr/local/bin/test.sh. The inode 'DNS server' would first modify the reverse lookup to match the new location (i.e., looking up [4435] returns '/usr/local/bin/test.sh'). Then it would keep the old forward lookup ('/usr/bin/test.sh' returns [4435], until a new '/usr/bin/test.sh' file is created) and add an additional new lookup ('/usr/local/bin/test.sh' also returns [4435]).
There are definitely some drawbacks to this -- for example, simply moving a file won't stop a program from accessing it. However, if such a system were created, the applications that used it could be made inode-DNS-aware: the 'mv' command might have a '-d' option to move the file *and* delete the old forward lookup.
Yeah, I know, it's probably got a ton of other issues that I haven't considered. Perhaps it would put a huge strain on the system, create huge security holes -- who knows? But at 11:02 pm when I'm fighting with trying to figure out which config files need to be changed, DNS sounds fantastic! ;P
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
on 2009-06-07 02:12 pm (UTC)no subject
on 2009-06-07 06:41 pm (UTC)It's an app that lets you store a project online and then manually work on it in a text editor that runs in your browser. All the changes are done/saved online, and you don't have to keep or use any development files on your own personal computer -- I could log in from a public library computer and work on my code without ever having to download anything.
While this is spiffy in itself, it's meant to help out some of our developers who for one reason or another have had trouble getting their development environments working. It really sucks to have good coders who can't even touch the source code on a regular basis.
Additionally, I'm thinking of hacking together some scripts that will allow a developer to make CREM subversion commits on the code that they work on in Bespin (provided I can get it working). Then, using virtual environments on the server, they can click another button and see what the code they just edited looks like running in CREM.
Difficult, very difficult -- I haven't found an app out there that does all this, although Bespin does the hardest part for me. I'm not sure yet if it's possible under my current level of expertise (which is minimal in regards to servers). Ah, well. One configuration error at a time... ;)