00:05:32 so it's just a name? 00:06:16 More or less. 00:07:02 !daemon omfg bf ,+++++++++++++[.,+++++++++++++] 00:07:10 omfg i 00:07:27 ....is that a service? 00:07:38 objects 00:08:30 !omfg i 00:08:38 !ps 00:08:40 5 SevenInchBread: ps 00:10:05 bf default is 16-bit, so you would be hard pressed getting either a halt or a newline out of that 00:10:35 i.e. nothing will be printed until buffer overflows, i think. 00:11:09 ihope, oh alright... so with my idea I'm basically saying every process is a service... and the organizational structure is kind similar to a filesystem hierarchy. 00:11:17 right? 00:12:49 SevenInchBread: I'm thinking letting processes offer more than one service or none at all would add a little versatility. 00:13:16 Why should every process be a service? 00:13:20 hmmm.... how would it know which service it's doing? 00:13:30 if you're just feeding it input. 00:13:33 How would it know which service it's doing? 00:13:48 A process pretty much chooses what services to provide. 00:14:01 Oh, you mean...? 00:14:22 The process is told what service has been called with what data. 00:14:24 yeah... if one process was registered as two services with two fundamentally different tasks... and you used one - how would the process know which one it's handling. 00:14:34 Pretty simple. 00:14:37 you could have the process register streams at different addresses. 00:15:19 What's this about streams? 00:15:20 ah... that's a good idea. Except the stream part. :) I think Erlang "mailbox"-ish IO mechanisms would work nicely. 00:15:47 instead of having just stdin and stdout as interface, which i think is what is confusing here 00:16:02 aaaah... I see what you mean. 00:16:15 Why be mailboxish when you can have your processes provide procedures that can be called directly? 00:16:29 (I'm talking Pascal now for some reason, aren't I?) 00:16:46 this leads then to the conclusion that procedures should also be placed in the filesystem 00:16:48 ihope, asynchronousness. 00:16:59 but... that could be an option. 00:17:26 SevenInchBread: if you provide procedures like that, the program can handle mailboxes by itself. 00:17:31 and before long we have arbitrary objects (in a general sense) 00:17:47 oerjan: placing procedures in the filesystem? 00:17:48 I was just saying... instead of the stream of bytes... you have a queue of.... stuff. 00:18:16 the data gets partitioned... instead of jumbled alltogether in a huge chain. 00:18:39 Did I say something to the contrary? 00:18:43 given that each service should have at least one spot in the filesystem, if i understand SevenInchBread correctly 00:19:00 Services need not be invoked with plain old bits and bytes. 00:19:08 oerjan: but I haven't agreed to that. :-P 00:19:18 Putting services in the filesystem isn't a bad idea, though. 00:19:30 well... kinda. Maybe not -literally- in the filesystem... but I was much wanting processes to be organized in a structure that resembled a filesystem. 00:19:34 But that's a job for the filesystem handler, not for the kernel. 00:20:19 Having processes arranged in trees is... well, what's the reason behind that? 00:20:41 basically... it's an implication of giving processes names. 00:20:58 Apart from its use in rationing CPU time. 00:21:10 if we gave them names and didn't organize the names into some kind of scope... it would have all the problems of a flat filesystem. 00:21:46 Couldn't you just put slashes in there or something? 00:22:02 slashes? 00:22:26 We can still have foo/bar/baz isn't if it's not baz inside bar inside foo. 00:22:42 well... in my examples... I just used spaces... ala-Smalltalk message-passing (which is a similar concept). 00:22:53 Your examples? 00:23:00 "fs cd" except 00:23:03 er... etc 00:24:51 Why not just have another service called fs/cd and/or have cd be part of the message to the fs service? 00:25:16 -shrug- it could work. 00:25:22 oh 00:25:24 it is 00:25:29 What is? 00:25:38 the "cd" part is literally just a string being passed to fs 00:25:45 fs can choose to do whatever the hell it wants with it. 00:27:22 Indeed. 00:27:25 if you like your names nice and flat... making some macros wouldn't be too impossible. 00:27:39 macro set (cd, fs cd) 00:28:19 Indeed. 00:28:40 So is there really any reason to put services in a tree like that/ 00:28:41 ...or you could borrow another concept from file hierarchies and do "current processes" 00:28:58 -shrug- not really... it's not really all that necessary. 00:29:17 Indeed. 00:29:38 By the way, how's the SourceForge coming? 00:30:01 no word as of yet. 00:30:41 how about representing time? 00:30:54 it can all be done with ObjC distributed objects! 00:31:04 I notice that Google Groups does offer some storage space? 00:31:07 oh, and another benefit of microkernels is that we have no obligation to write everything in one language. 00:31:11 What about representing time? 00:31:17 Indeed, that's true. 00:31:29 the code behind fs or any other process major OS process could be any language. 00:31:59 well... it would be kind of stupid to do time like all the major OSes... since it's going to run out of ticking power by 2032 00:32:31 ...or whatever the year is. 00:32:48 Make it 64-bit? 00:33:10 what about bignum? 00:33:14 variable length. 00:33:51 64-bit won't go bad for a while. 00:34:02 you could do like.... a base-256 numeral system... in reverse order (the smallest place values come first) 00:34:08 Though bignums aren't bad. 00:34:18 and terminate with a null. 00:34:30 so the length can be arbitarry... and you won't ever have to worry about it. 00:34:56 "(2^64) seconds = 5.84554531 * 10^11 years" 00:35:12 We won't be the ones to worry about it. 00:35:22 eh... sure 00:35:26 terminate with a null? then it would be buggy 00:35:40 not if its in reverse order. 00:35:49 sure it would 00:35:51 hmmm... well yeah 00:36:24 maybe have a special byte for the terminator... and have do base-255. but for the OS, 64-bit should be enough. 00:36:52 If we use 256 bits, we'll be good until all protons in the universe have decayed. 00:37:07 Time Error: Date is beyond Universe Heat Death 00:37:25 ....actually... let's go with a 230-bit integer. 00:37:34 ...just cause. 00:38:14 ... 00:38:29 how long do red dwarf stars live again, hm... 00:39:12 I sometimes wonder what the computer world would be like if we could specify the size of our bytes. 00:39:13 64 bits. 00:39:17 That'll be enough. 00:39:21 ah, 64 bit won't be enough for that then. 00:40:02 In 500,000,000,000 years, somebody'll have invented a way to translate everything up to 128 bits. 00:40:37 I doubt Abrasax/YAOS/Sophia will still be in use by then, anyway. 00:40:48 ....pretty sure the Earth or at the very least humans will be gone by that time. 00:41:08 ...good riddance, I say. 00:41:39 Pff. 00:41:55 ah, a misanthrope. or a misgean? 00:42:29 How about we stay on topic, eh? 00:42:52 We can always take this into #off-topic. 00:43:05 Now, just how will we compile our kernel? 00:44:02 ...I don't want to ride your topics. 00:44:04 oh 00:44:08 we will load it into the atmosphere of a red dwarf. 00:44:15 erm.... I don't know. I've never actually used a compiler before. 00:45:11 oerjan, kinda. I have a love-hate relationship with humanity. 00:45:28 I suggest we steal the "Multiboot example". 00:46:03 anything specific about memory management we want to do? What about paging? 00:46:14 See http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Example-OS-code 00:46:30 The kernel will probably have to handle memory management. 00:46:35 Or at least some of it. 00:46:46 It can't leave loading processes up to a process it can't load. 00:47:18 yeah yeah... one of the main jobs of the kernel is memory management. 00:47:24 no way to process-ify that. 00:48:00 I'm not that familiar with how memory works. 00:48:08 I know a little bid. 00:48:16 What do you know? 00:48:20 buddy system allocation, paging files, etc.... the usual stuff. 00:48:30 I don't know how processes work... 00:48:34 Buddy system allocation? 00:49:13 I know a little bit about processes. 00:49:29 http://en.wikipedia.org/wiki/Buddy_memory_allocation 00:49:52 I don't know how processes interact with the kernel to get memory though... I just know bits and pieces of HOW the kernel can go about handing out memory. 00:50:42 Wouldn't that be done via system calls? 00:51:22 guess so... I've never used realloc and malloc in C. 00:51:29 but I'm assuming that's what they exist for. 00:52:39 memory management is kind of weird... you've got to find the best way to package a bunch of little blocks so that they can be picked up quickly 00:53:05 We may have to find an expert. 00:53:32 paging is probably the way to go.... all the big OSes use it... so its tried and testing 00:53:34 er.. tested 00:54:33 actually... the hardware kinda handles paging for us. 00:54:46 expert? 00:54:49 who needs em 00:54:53 we just need to write the program that reacts to a page fault. 00:55:35 I think you know more than I do on the subject. 00:56:09 http://en.wikipedia.org/wiki/Paging 00:57:31 a large amount of OS performance relies on a good paging algorithm. 00:59:01 Think you can handle it? 01:00:07 .....I don't know a thing about how to do it. 01:00:13 ....I just know like... what it's supposed to do. 01:00:53 probably the other factor in the performance of this OS will be how quickly it can handle IPC... which is a bit more important to a micro kernel. 01:01:13 Indeed. 01:04:59 Think we should recruit an expert, then? 01:05:05 but... IPC doesn't mean shit if the process isn't scheduled to execute at the proper time. 01:05:11 so... scheduling will be the other thing. 01:05:22 ihope, nah.. 01:05:29 Why not? 01:05:36 to learn how to mess up. :) 01:05:36 Why do processes need to be scheduled to run at the right time? 01:06:11 Indeed, failure results in learning. 01:06:18 well... one of the OSes jobs is to schedule which processes get to run and at one time. There's only so many processes that can run at any given time. 01:07:33 You mean multiple processes can run at the same time? 01:07:36 http://en.wikipedia.org/wiki/Process_scheduling 01:08:01 well... I mean... there's only so many processes that can be "active" at any given time. 01:08:17 Why? 01:08:25 ....forgot why. 01:08:25 Just what is being "active", now? 01:08:37 I suggest you remember, seeing as how I have doubts. 01:08:46 http://en.wikipedia.org/wiki/Process_states <--LOL MORE LINKS 01:08:59 * SevenInchBread is researching as he goes. 01:09:23 process swapping. 01:10:03 Argh, process swapping. 01:10:21 How about we leave *that* up to a process? 01:10:52 well... to a certain extent OSes do... Windows for example lets me set the process priority. 01:11:21 Indeed, failure results in learning, but aren't we aiming for success? 01:11:27 ....so... I can set "firefox.exe" to realtime... and then it'll take me a good hour to try to move my mouse back to set it back to normal. 01:11:43 ihope, we can fail, and then correct our mistakes. 01:12:49 I'd rather succeed the first time around. :-) 01:12:59 Unless we can go faster by learning. 01:13:28 see... the problem is that if you set the priority of a process extremly high, but keep all the processes that it accesses at normal... then the high-priority process will be spending most of its time waiting for its dependencies to become active. 01:14:00 so... probably the best priority scheme is one based on a combination of reaction time as well as independence. 01:14:06 We could let processes switch to other processes. 01:14:16 the mouse... for example... should be highly responsive... 01:14:41 Invoke a service provided by a process, then switch to that process. 01:15:09 hmmm? 01:15:48 it's not quite that simple. 01:15:51 It's not? 01:16:04 because processes are fairly asynchronous... there is no "return value". 01:16:43 There's no return value? 01:16:49 What do you mean? 01:17:33 I mean... processes don't wait for the results of other processes... they're all running at the same time. 01:18:04 the simplest scheduling algorithm is an equal time algorithm... which ensures that each processes gets a chance to execute... 01:18:23 we can start with that one... and then find one that finds more efficient uses of time later. 01:18:24 -!- sebbu has quit ("@+"). 01:19:36 the only real reason equal-time scheduling doesn't work is because not all processes need an equal share. 01:19:38 They're not all running at the same time. 01:20:09 What's keeping us from adding a system call saying "spend the rest of this time slice on that process"? 01:20:11 an HTTP server - which spents most of its time waiting for something to send it a request... doesn't need near as much time as a video game. 01:20:32 ihope, that's just a specific situation... it doesn't solve the whole problem. 01:21:02 Couldn't the HTTP server end its time slice early? 01:22:46 nope 01:23:18 well, while it's blocking, the OS needs to put an entry in the ptable that says it's not available for scheduling 01:24:26 Blocking is something I'm going to have to understand, isn't it? 01:25:16 yeah 01:25:26 blocking is when a proccess waits for some external input 01:25:42 it seems to me that the HTTP server problem is if a process has two "states" - one where it does immediate work in response to a request, and one where it does occasional work while otherwise waiting. 01:25:44 obviously, when a proccess is blocking, the scheduler shouldn't give it any proc time 01:26:00 ihope, yeah that works fine... but you can't expect the process to handle itself... programmers don't want to have to think about time slices. 01:26:04 then they may need different priorities. 01:26:24 SevenInchBread: so how do we know whether it's blocking or not? 01:26:39 eh... blocking is explicit. 01:26:45 only blocking system calls can block 01:27:08 Blocking can only be the result of a system call? 01:27:14 yeah 01:27:51 you could of course have a system call that did nothing but end the current time slice 01:27:54 if my program splits off a subprocess... I can explicitly say "wait for this process to return a result" 01:28:28 Well then, the HTTP server invokes a service that waits for an incoming connection. The process that handles the service does all the work--right? 01:28:33 like waitpid(2)? 01:28:52 yeah 01:28:57 except.... with names. :) 01:29:02 Wait for process termination? 01:29:06 yep 01:29:09 that's a block 01:29:20 Or "wait for service to return a result"? :-) 01:29:31 SevenInchBread: names are ugly 01:29:34 either one works... 01:29:39 bsmntbombdood, ................................. 01:29:46 Where do you come up with the names? 01:29:51 SevenInchBread: single words (ints) are much nicer 01:29:54 alright then.... in Sophia the file system shall reference files by number. 01:29:59 Indeed, they're pretty convenient. 01:30:09 SevenInchBread: let's not violate WP:POINT here. 01:30:15 ... 01:30:18 YOU WIKINERD 01:30:20 Not that this would be a WP:POINT violation even if this were Wikipedia. 01:30:34 Rather, let's not use slippery slope arguments or whatever they're called. 01:31:05 ....I just can't fathom how numbers are more convient than names. 01:31:08 that's just inodes isn't it? 01:31:21 When I create a file, I usually have a name in mind for it. If I don't have a name in mind, I might choose a number. When I create a process, I usually don't have a name in mind for it. 01:31:25 indeed... we have DNS because names are more convient than numbers. 01:31:37 SevenInchBread: it's easier to store a name than it is to store a number. 01:31:45 Names are for things that persist. 01:31:47 no it's not 01:31:54 Erm. 01:32:00 an int will always be one word 01:32:04 ihope, ...why is that important though? 01:32:05 s/name/number/ and vice verse. 01:32:11 s/verse/versa/ :-P 01:32:17 SevenInchBread: why is what important? 01:32:23 naturally the name would be optional, and initialized like a temporary file name if not provided 01:32:31 ints being easier to store than names. 01:32:33 (Alternatively: s/easier/harder/) 01:32:48 system calls are numbers, file descriptors are numbers, permissions are numbers... 01:32:57 Oh, names are fine. 01:33:01 pids are numbers... 01:33:02 But why have them? 01:33:05 ...in UNIX 01:33:10 yes, in unix 01:33:40 but why? A number has no referential meaning to a human... they're only convient for the computer - which is fine in some cases. 01:33:44 however if the OS supports process persistence (and otherwise, why go to all this trouble?) then you might run out of numbers. 01:34:08 er... 01:34:14 SevenInchBread: humans are stupid 01:34:33 unfortunately. 01:34:35 It's not especially often you need to refer to a process by ID. 01:34:36 that's why we have OSes 01:34:46 to help the stupid computers work with the stupid humans. 01:35:17 I could say "the process providing the 'fs' service" or "the process that's an instance of /foo/bar" or "the process that's using all the CPU time". 01:35:51 heh... I've been referring conceptually to fs being the actual process. 01:36:15 If the process that's using all the CPU time is the only instance of the executable, we refer it to is as "the process that's an instance of /foo/bar". Otherwise, how do we come up with names for all the instances? 01:36:33 If you let the processes name themselves, you end up with things like processes named "_________________________". 01:36:51 And processes named "ø". 01:37:06 names are useful for persistance of any kind.... fs will always remain fs each time it is around... that way we have a quick and global reference to it. 01:37:18 fs is the name of the service, not the name of the process. 01:37:24 ihope, is that any more troublesome than "the process 242" 01:37:31 ihope, maybe to you. 01:37:43 SevenInchBread: well, you have to copy and paste the underscores rather than typing them by hand. 01:37:59 Can you tell how many underscores there are without doing something tedious? 01:38:13 I can copy "242" much more easily. 01:38:15 ....that's a stupid example. :P 01:38:24 My example or yours? 01:38:28 yours. 01:38:35 Why is it stupid? 01:38:49 yes indeed... someone could name their process "asfkjskdljdklgjdlkgjlkdgkldfjgkljdfg".... but then they're fucking retarded. 01:39:04 Well, there are people in the world who are fucking retarded. 01:39:05 and you probably don't want whatever that process does. 01:39:15 And that means you need to kill it. 01:39:22 pwnt. 01:39:35 ...hahahahaha 01:39:35 I'd rather type 242 than copy-and-paste that thing. 01:39:43 * SevenInchBread dies. 01:39:51 oh - that was fucking brilliant. 01:39:56 good job. 01:40:50 okay... so then you can simply have numbers AND names. like file descriptors and file names. 01:41:06 same like unix 01:41:13 a proccess's "name" is its path 01:41:17 Why have process names, again? Service names, sure, but why process names? 01:41:25 but with unix the process names aren't unique. 01:41:38 same reason we have file names. 01:41:45 the pids are, though 01:41:52 -nod- right. 01:42:06 I'm talking about a unique reference name and a unique ID number. 01:42:35 basically... a service IS a process.... a process with a name in front of it. 01:42:36 I'm thinking giving every process a name is like giving every inode or whatever you call it a name. 01:42:51 maybe not in UNIX... in UNIX the service name -creates- a new process each time it's referred to. 01:43:06 Well, yes. The services act as the names, so what reason is there to give each process another name? 01:43:10 but I don't think we're doing that... unless we want to spawn a process each time we refer to "fs" 01:43:20 Indeed. 01:44:12 not proccesses, just objects 01:44:13 hmm.... alright... 01:44:24 bsmntbombdood, NO. We are not going all fucking OO 01:44:26 Users and application developers need to know "fs", the service name. They don't need to know the name of the process. 01:44:40 SevenInchBread: what you describe is message passing OO 01:44:46 no matter what you try to call it 01:45:05 proccesses have private data and can be sent messages. they are objects. 01:45:11 ...I just don't like the concept of the service. I just like... the concept of "a name for a process"... the name can optional sure, but it's not a separate entity from the process itself. 01:45:38 Well, that's pretty much what a service is, really. 01:45:54 Except that you can attach multiple services to a process. 01:45:59 bsmntbombdood, what I described is the desktop metaphor... it's also a good bedtime story and makes for a damn good sexual joke. Is that an apple or a red fruit? 01:46:06 And not every process needs a service at all. 01:46:17 wtf? 01:46:21 ...I'm still not sure how that would work. 01:46:29 How what would work? 01:46:51 having multiple names for a process... each doing something different. 01:47:07 argv[0]? 01:47:16 When the service is invoked, the process is told what service it was. 01:47:21 ah. 01:48:10 Well, I should get to bed. There's school tomorrow. 01:48:17 :( 01:48:23 ...I think I'd just like there to be a persistent name for processes. A service does this nicely... but then how difficult does it become to create a new name for your process? 01:48:54 [And then somebody yells "Let's get going!", and "Walking On Sunshine" by Katrina and the Waves starts playing.] 01:49:57 bsmntbombdood, the weird apple-red-fruit thing was referring to the notion of identity. 01:50:07 Something is only OO if we decide to refer to it as such. 01:50:12 SevenInchBread: the process requests permission to use that service name, something grants permission, and the process registers that service name. 01:50:30 Or the process already has permission, in which case it simply registers it. 01:50:41 ihope, across multiple OS runs? 01:55:04 rebooting is for wimps 01:56:05 booting is for rewimps 02:02:34 SevenInchBread: services aren't preserved when rebooting, but permissions may be. 02:03:19 * SevenInchBread thinks they should. :( 02:03:24 See "'default' permissions". 02:03:38 SevenInchBread: well, indeed, services could be preserved when rebooting. 02:03:49 But that would mean processes being preserved when rebooting. 02:03:55 We all know that's iffy. 02:04:29 yeah that's yucky 02:07:29 "Default" permissions are stored in along with the executable, somehow, and therefore preserved when rebooting. 02:07:55 with record-based filesystems 02:07:59 that's not too hard to do 02:08:22 Record-based filesystems? 02:08:38 yeah... instead of storing files as streams you store them as hash-table-like things 02:08:53 that makes no sense 02:09:05 ...what? 02:11:06 ...I like the idea. 02:11:15 What's this about hash tables? 02:11:30 I think it makes a shitload more sense than cramming all the info into a stream and having to parse out all the data 02:12:09 So the filesystem handler does all the parsing instead of the client? 02:13:01 eh... sorta kinda.... depends on how its stored on the disc 02:13:05 but, essentially, yes. 02:13:17 Depends on how it's stored on the disk? 02:13:44 yeah... instead of using bytes to delimit record entries you can use some physical property of the disk sector or something... 02:13:56 but, generally speaking, the filesystem does all the work for you. 02:14:49 We could always have a "hash table handler". 02:15:10 http://en.wikipedia.org/wiki/Record-oriented_file 02:15:48 there's also sequantial access... which works something like a linked list instead of a hash table 02:16:07 so... data that's split up into lines could give each line a record. 02:16:45 Time for me to go to bed. 02:16:51 'Night. 02:19:38 'Ook 02:36:15 -!- ihope has quit (Connection timed out). 03:03:03 Mmkay. . . 03:03:20 I friggin' hate glibc. 03:03:29 frodo:/source/glibc-build# /source/glibc-2.5/configure --prefix=/usr --disable-profile --enable-addons --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc 03:03:30 configure: error: cannot find install-sh or install.sh in scripts /scripts 03:11:12 that's why you don't try to compile glibc 03:16:42 I'm making a distro. What else am I supposed to do? 03:16:51 . . . Use uclibc? 03:17:16 Actually, that's a pretty decent thought. 03:20:58 Maybe make this sucker use really, *really* small packages. 03:22:29 use "make the lazy bastards code it themselves"libc 03:22:40 Hahah. 03:25:43 Screw it. 03:25:59 I'm using buildroot to create the initial root tree. . . 03:26:25 I'll then use the buildroot environment to compile my own packages, overwriting everything eventually. 03:50:28 -!- SevenInchBread has quit (Read error: 110 (Connection timed out)). 05:02:02 -!- ShadowHntr has quit ("End of line."). 05:22:19 -!- oerjan has quit ("ZZZ"). 07:50:27 -!- wooby has joined. 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:02:04 -!- Sgeo has quit ("Ex-Chat"). 08:30:55 -!- nazgjunk has joined. 08:33:29 bsmntbombdood: Hey! 08:33:42 How about a cellular automata VM? 09:34:19 -!- sebbu has joined. 10:36:27 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)). 10:36:55 -!- nazgjunk has joined. 10:48:52 -!- puzzlet has joined. 10:59:10 -!- sebbu2 has joined. 11:09:00 -!- ihope_ has joined. 11:09:20 -!- ihope_ has changed nick to ihope. 11:18:41 -!- sebbu has quit (Read error: 110 (Connection timed out)). 11:18:41 -!- sebbu2 has changed nick to sebbu. 13:11:04 -!- jix__ has joined. 13:20:46 -!- jix__ has changed nick to jix. 13:24:52 -!- jix has changed nick to jix____. 13:27:09 -!- jix____ has changed nick to jix. 14:28:19 Sukoshi: what would that be? 15:09:53 -!- falseep has joined. 15:18:54 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)). 15:19:16 -!- nazgjunk has joined. 15:40:21 -!- falseep has quit (Read error: 104 (Connection reset by peer)). 16:11:09 -!- jix__ has joined. 16:19:24 -!- jix has quit (Read error: 110 (Connection timed out)). 16:41:36 -!- jix__ has changed nick to jix. 17:19:19 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)). 17:19:53 -!- nazgjunk has joined. 18:01:54 bsmntbombdood: Dunno, we'd have to reduce every simple cellularo automota to VM commands. 18:13:13 -!- jix has quit (Read error: 104 (Connection reset by peer)). 18:16:02 -!- jix__ has joined. 18:24:41 -!- ihope has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09"). 18:31:07 -!- calamari has joined. 18:33:50 -!- ShadowHntr has joined. 18:37:43 -!- digital_me has joined. 19:16:46 -!- atrapado has joined. 19:25:08 -!- jix__ has changed nick to jix. 19:55:59 -!- calamari has quit ("Leaving"). 20:32:02 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)). 20:33:31 -!- nazgjunk has joined. 20:42:49 -!- Sgeo has joined. 20:50:38 -!- calamari has joined. 20:58:22 -!- ShadowHntr has quit ("End of line."). 21:01:43 -!- nazgjunk has quit (Dead socket). 21:02:37 -!- nazgjunk has joined. 21:06:32 -!- atrapado has quit (Read error: 60 (Operation timed out)). 21:06:43 -!- dub_ has joined. 21:07:09 -!- dub_ has changed nick to atrapado. 21:11:54 -!- ihope has joined. 21:12:32 Yarr! 21:12:36 I be an IRC pirate! 21:15:44 -!- ihope_ has joined. 21:15:58 Yarr! 21:16:04 I be a disconnected IRC pirate! 21:16:53 Heh 21:21:22 Anyway, I half-officially declare the name of "the operating system project" to be Abrasax, 21:21:25 s/,/./ 21:21:45 We could have trademark issues with Sophia. 21:22:05 And the half-official IRC channel is #abrasax. 21:23:22 Whassisnow? 21:25:19 http://groups.google.com/group/AbraSophia 21:26:18 * GregorR nods as if he has an effing clue what's going on. 21:26:33 It's an operating system project, 21:26:35 s/,/./ 21:26:42