00:02:36 -!- crathman_ has quit (Read error: 113 (No route to host)). 00:04:11 -!- bsmntbombdood has joined. 00:06:34 Nevermind, found it. 00:06:40 Package browser; imagine that. 00:19:51 :) 00:33:00 * Pikhq is *attempting* to get his distro up and running 00:37:34 And failing horribly. 00:48:07 -!- calamari has joined. 00:55:10 -!- calamari has quit ("Leaving"). 00:58:36 I'm writing a farming roguelike. 00:58:50 (After spending 3 hours reading about magnetism/electricity.) 01:00:36 you mean the hero is a farmer 01:00:37 ? 01:01:11 No, it's a roguelike with inspiration from Harvest Moon. 01:01:11 Concept: 01:01:11 Are you going to farm magnetic carrots? 01:03:15 The Glorious Empire is waging war against the Evil Enemies of the Empire. The Empire has given a call to all of its citizens to help with the Empire's Exploits. Rather than taking to the frontlines, you have decided to help your Empire in the other way -- to farm. Each and every crop you harvest is distributed out to the Citizens and the Empire compensates your efforts. To aid your effort, the Empire allows you to purchase Indentured 01:03:15 Servants (prisoners of the Glorious War) to help out on the farm. In order to prove your worth to the Empire, you must successfully set up your own empire of farms. 01:03:43 that does not sound like a roguelike. 01:03:52 It does now, bub. 01:05:32 To further aid your exploits, Magical Engineers constantly perform research on technological Improvements. Of course, Research is accelerated with Donations. Use your money effectively to purchase Indentured Servants and place skillful Donations for the benefit of the Empire. 01:06:02 that sounds very much like an economic simulation and not at all like a roguelike. 01:06:16 But it's being done in curses. 01:06:20 so? 01:06:26 So. 01:06:33 that's just the interface 01:06:37 anything can be done in curses 01:06:41 Except that you actually interactively farm. 01:06:58 (Until you hire the indentured servants you need, of course.) 01:07:14 (Then you purchase another farm off struggling farmers.) 01:11:47 OH OH OH 01:11:50 I'll help. 01:12:01 ...you could make it online... and turn it into a MUD. :) 01:12:28 * SevenInchBread already has a big partially complete python library for MUDs 01:14:46 We're abandoning Abrasax, aren't we? 01:14:48 Count me in! 01:15:46 ...eh, it's possible/likely. 01:22:40 -!- calamari has joined. 01:25:13 ihope, eh.. but I'll try not to be cynical. 01:25:26 Hmm? 01:26:24 I think we'll be able to do Abrasax as long as we're willing to put in some work. 01:26:50 all else fails... we can go with the power of numbers and join up with an existing OS project that might be having problems. 01:26:52 Indeed we will. 01:29:06 * SevenInchBread is looking for a public domain microkernel 01:31:09 No, not MUD. 01:34:16 if we need to make our own kernel... 01:34:23 I say go with the minimalist of the minimal. 01:34:43 just a flimsy layer over the hardware... 01:35:06 -!- calamari has quit ("Leaving"). 01:36:39 And then have an "upper kernel" handle permissions and such? 01:36:59 basically just like.... talking to the MMU and dispatching interupts... and maybe some other stuff. 01:37:17 ihope, eh... not necessarily. But yeah... basically just breaking down all the functions into different parts. 01:38:12 Dividing into "lower kernel" and "upper kernel" doesn't really seem a bad idea. 01:38:54 Have the lower kernel handle all the dirty work, and then the upper kernel can do it "cleanly" by calling the lower one? 01:39:35 I was jsut thinking like.... a really small kernel... and then.... everything else in userville 01:40:48 So the lower kernel's division of privileges goes no farther than "this program can do anything at all" vs. "this program can only talk to other programs"? 01:43:21 ...what? 01:43:57 yeah... the security doesn't come till later. 01:46:05 You mean the lower kernel doesn't have division of privileges at all? 01:46:48 I can eat banannas? 01:46:51 So, about Pascal. 01:48:05 no... it basically sends interupts off to other places... and manages memory. Privledges wouldn't even make sense there. 01:48:19 Sends interrupts off to other places and manages memory... 01:48:41 So it's a library containing the OS's entry point? 01:48:51 Why not make a Forth OS? 01:49:05 Non-interactive programming is for nubs. 01:50:10 What's interactive programming? 01:50:24 it's just... the kernel. It just handles the most basic hardware stuff and delegates it to other software. 01:50:30 It's one huge... callback-thingy. 01:51:42 Callback-thingy? 01:52:00 that's the most basic function of the operating system... to assign crap as callbacks. All other functionality emerges from that. 01:52:21 So it provides some "system calls"? 01:54:11 So you dismiss it to non-interactive just like that? 01:54:14 You fiends. 01:54:23 Interactive programming, like a REPL. 01:55:12 no no... not system calls... those aren't callbacks - they're simply subroutines because they're always present. 01:55:27 Uggh, are you listening to me, you stupid piece of cake? :P 01:55:45 you can't do anything with system calls if there's nothing around to call them. You can't create anything to call systems calls without having an input device 01:55:58 Yes you can. 01:56:03 Sukoshi, THERE WILL BE NO INTERACTIVE. OUR OPERATING SYSTEM WILL BE LIKE A FRIDGID SEX PARTNER 01:56:11 * Sukoshi things of a clock to control current. 01:57:54 I'm probably thinking of the wrong side of the sex SevenInchBread. 01:59:59 SevenInchBread: subroutines? 02:00:06 So it's like a library or module? 02:00:54 Uggh, make it interactive. 02:01:15 Sukoshi: what do you mean? 02:01:21 Like, create a Forth-level interface to interrupts and just start building up the rest in Forth words. 02:01:57 You only need to implement a stack, some way to fetch memory, and some way to store words, plus interrupt-based words. 02:02:03 I think we want "the rest" to be very modular and easy to do in any programming language. 02:02:24 In any non-REPL language :( 02:02:37 You can compile to Forth words, you know? 02:03:18 What's REPL? 02:03:25 Read-Eval-Print-Loop. 02:03:48 ihope, system calls are like a library... yes 02:04:36 http://www.amresearch.com/v6/ 02:04:38 <-- Read there. 02:04:48 basically I just want to kernel to do things like "oh cool... an interrupt! CONTEXT SWITCH POWERS ACTIVATE!" 02:05:08 Compilers can compile to Forth words, which are basically supported by a barebones kernel. 02:05:34 Sukoshi: you seem a little Forth-obsessed lately. 02:05:44 Does it have closures, whatever they are? 02:05:45 ihope: Well, you seem very non-interactive obsessed. 02:06:11 Sukoshi: I... still don't get what you mean by "interactive". 02:06:21 ihope: Have you never played with a Lisp or a Forth before? 02:06:35 I've played with a Lisp or two. 02:07:16 Play with gForth. It's an experience. 02:07:42 -!- calamari has joined. 02:07:45 It's just a prompt that lets you type in Forth words, which are then just looked up. 02:07:48 ...might want to check Sukoshi's fanatic-o-meter 02:08:09 Sukoshi, so it's an.... interactive interpreter? 02:08:11 It doesen't have to be *Forth*, but you seem to be gearing this for a non-interactive base. 02:08:17 SevenInchBread: Yes. Crazy isn't it? 02:08:35 A barebones microkernel drops you into that. OpenBoot does something similar. 02:08:35 * SevenInchBread thought that was a common thing..... 02:08:39 Suddenly, I want to combine Thue with something roughly Forth-like. 02:09:06 I use python's shell interpreter all the time... it's nothing amazing. 02:09:21 It's sarcasm. 02:09:33 Commands are taken from the left and executed. Any results are put back on the left. 02:09:38 Plus Python's shell interpreter doesen't execute machine code directly. 02:09:52 "Other" computation is done with Thue-like replacement rules. 02:31:24 -!- iano_ has quit (Read error: 104 (Connection reset by peer)). 02:32:06 -!- iano has joined. 03:32:46 -!- ihope has quit (Read error: 110 (Connection timed out)). 03:35:31 -!- calamari has quit ("Leaving"). 03:58:05 -!- Sukoshi has left (?). 04:26:58 -!- Sgeo has joined. 05:09:10 -!- oerjan has joined. 05:37:02 -!- Sukoshi has joined. 05:38:33 -!- Sgeo has quit ("Ex-Chat"). 05:47:37 so 05:47:43 how do you run a process in the background again? 05:47:49 & 05:47:51 like... in Linux distros 05:47:56 hmmm... that doesn't seem to be working 05:48:05 is that on all linux distros? 05:48:15 & after the statement 05:49:10 oerjan: You said you used Pascal. 05:49:13 note that it must not read/write the shell std streams 05:49:18 once upon a time yes 05:49:27 Do you think it is better than C? 05:49:32 (Sort of curious.) 05:52:25 Uggh. Why doesen't Radio Shack give the Maximum Energy Product (or Magnetic Field) of their magnets? -_-'' 05:53:59 oerjan, anyway to prevent that without... recompiling the program? 05:54:27 yes, you use > and < to redirect I/O. 05:54:35 oerjan, example? 05:54:49 SevenInchBread: ``ls > grep -i hi'' 05:54:51 Errrr 05:54:55 ls | grep -i hi 05:55:11 ....what's the | 05:55:14 ... And that's not an example of IO rediirection .... 05:55:18 -!- GreaseMonkey has joined. 05:55:23 | is the piping character. 05:55:33 It pipes stdiout of the first application to stdin of the second. 05:55:44 so... how would I tell the program to redirect output to.... hmmmmm... /dev/null... or just nowhere 05:56:16 anyhow, i have little opinion on C/Pascal, they both seem old to me, C's advantage is that it has enormous support and libraries. 05:56:17 For that you use > 05:56:34 so.... dev/null > SomeApp? 05:56:39 Errr... 05:56:50 SomeApp >/dev/null 05:56:50 ``cat /dev/null | app'' 05:57:04 > redirects output to an FD. 05:57:12 SevenInchBread: ignore Sukoshi :) 05:57:21 .... -_-'' 05:58:02 on a shell line, file for stdout. 05:58:26 a friend is complaining about the shell window for a server app being unable to close without shutting the whole thing down 05:58:31 ...and the ampersand isn't working 05:58:42 It has to. 05:58:50 .....well it's not 05:58:50 ``xchat &,, 05:58:58 *``xchat &'' 06:00:31 ah yes, &>file takes both stdout and stderr, at least in bash 06:00:41 Does the same in ZSH. 06:01:19 on the other hand, the redirection may not be necessary for X commands. 06:01:31 they rarely write to the terminal, I think. 06:01:58 cannot check as i am on windows these days. 06:02:04 They do sometimes. 06:02:08 oerjan: O_O 06:02:20 人殺し！！！！ 06:02:20 yes, errors i guess. 06:02:45 * SevenInchBread just wants the shell window to go away without the MUD crashing 06:02:47 except for ssh'ing to my old unix account. 06:02:52 Yeah, like Firefox tells me (in Japanese, because I use that locale so my Japanese fonts are nice) that it can't find the 'hicolor' font every so often. 06:03:16 -!- Bigcheese has joined. 06:04:12 oh, i see. 06:04:36 You can tell him to write a mini-app that creates a little GUI window that forks the input to a shell. 06:04:39 i think something more than background might be needed for that. 06:04:47 my memory is hazy. 06:04:54 What WM does he use? 06:05:41 WM? 06:07:21 Window Manager .... 06:07:27 ...I don't know. 06:08:52 ..... 06:09:07 hm... try the daemon command. 06:09:21 .... What command is that oerjan ? 06:09:35 oh wait, it was a function 06:09:47 my eyes skipped that part 06:10:42 hmmm? 06:11:33 anyhow, have you tried "command &>/dev/null nope. 06:14:03 that's the closest i can think of, removing all connections to the terminal i hope 06:15:24 SevenInchBread: um, learn how to use a shell 06:15:25 that's not the problem though... it just needs to run without the shell being there 06:15:35 it did this normally with the & in the past 06:15:45 Your WM should have the feature in a ``run'' thing or whatever. 06:16:01 Or I'll bet you can find some small app written just for this purpose, if not write it yourself. 06:16:17 disown 06:16:28 >.> those all sound very... out of the way. 06:16:35 disown 06:16:41 Isn't there just a way to make it work with &? 06:16:45 Should I get a green fez? 06:16:50 nohup 06:17:12 ah, nohup. 06:17:32 i guess that's it. 06:18:39 yeah, disown too. 06:25:57 GregorR: maybe you could recolor your red fez picture to test... 06:26:22 What about semi-purple fez? 06:28:57 what's fez? 06:30:10 http://www.codu.org/hats/RedFez-med.jpg 06:31:48 My red fez picture is a uniquely bad picture of me XP 06:31:49 and that's GregorR unless he's fooling us. :) 06:33:21 so not only do you need to recolor it, you also need to graft it onto another picture of you :) 06:34:03 _might_ be simpler to get a physical sample, then. 06:35:09 but then, a new picture of the red one seems in order. 06:37:05 Well, I ordered it. 06:37:21 I think I'll take a picture of me in my new green fez and then recolor that X-P 06:38:01 I also ordered a tricorn. 06:38:37 ... 06:40:37 Mein Hut, es hat drei Ecken Drei Ecken hat mein Hut... 06:41:38 We have that saying, but in English. 06:41:46 Err, saying == song lyric IIRC 06:41:55 and in norwegian, but I think the German is original. 06:43:22 How is "drei" pronounced? 06:43:27 somewhat disturbing that the google hits all spell it differently... 06:43:32 lol 06:43:49 GregorR: dry 06:43:58 more or less 06:44:55 unless austrian, the y should be shifted somewhat towards a 06:49:29 basically, the rules for pronouncing ie and ei in English and German are approximately opposite of each other. 06:50:57 Noyce :-P 06:51:08 We can thank the Great Vowel Shift for that (probably) 06:51:49 i should think so. 07:00:28 we should all speak the same language 07:00:33 then build a tower to heaven 07:02:28 AND THAT LANGUAGE SHOULD BE ENGLISH 07:02:38 IF ENGLISH WAS GOOD ENOUGH FOR JESUS, IT'S GOOD ENOUGH FOR TEXAS 07:02:58 english is the language of god, because it's what the bible is written in 07:03:06 Egg-zactly. 07:03:10 X-P 07:04:53 and besides, the spelling of Hebrew seems to be even worse. 07:06:16 -!- iano has quit. 07:17:34 doubtful 07:29:24 i've read that beginners need to have vowel signs added, and it take years to be able to read anything without them. 07:29:44 the former is true; the latter isn't 07:29:53 you get used to it very quickly 07:30:29 Same with hieroglyphs :P 07:31:42 ic 07:32:42 Why can't I find a good skimmer for under $100 X_X 07:34:16 thank god for wikipedia disambiguation. 07:34:25 ? 07:35:03 allowing me to find out what "skimmer" may mean 07:35:37 Ah :P 07:36:43 although if it had been anyone but you i would _still_ not know :) 07:37:07 Well, y'know, I want a sea bird. 07:38:47 yeah yeah, and you have this nice bridge you have to sell. 07:40:14 are skimmers handmade perhaps? 07:40:23 I guess so. 07:40:43 It used to be a very popular style of hat, but I presume they're no longer made en masse. 07:41:30 lol hat 07:41:56 as i said, if it had been anyone but GregorR... :) 07:42:17 Well, I saw one at my usual online hat shop while looking for a tricorn. 07:42:23 And it cost $112 O_O 07:42:34 So I googled, and they're all that expensive >_O 07:54:53 -!- nooga has quit (Read error: 110 (Connection timed out)). 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:21:30 -!- SevenInchBread has quit ("haaaaaaaaaa"). 08:52:26 If soemone wants to buy me rare Earth magnets, they should. 08:57:04 Funny, I was JUST having the compulsion to buy rare Earth magnets for somebody I barely know online! 09:05:54 Just for these sorts of moments. 09:06:23 Look, people in hormone-filled teenage chatrooms buy clothes for people they barely know. 09:06:47 Why can your hormones cloud you to the same level of idiocy? :( 09:07:01 *can't 09:07:11 I have no hormones. I am an android. 09:12:26 hey, at least Sukoshi is not asking for fissible substances :) 09:13:22 Exactly. 09:19:38 but then, who knows what a denizen of #esoteric could do with a rare Earth magnet. 09:22:03 It was for a generator, but I could think of more sinister things 09:22:04 . 09:22:53 -!- nooga has joined. 09:45:03 -!- oerjan has quit ("leaving"). 10:26:49 -!- sebbu has joined. 10:31:58 -!- sebbu2 has joined. 10:33:20 -!- sebbu3 has joined. 10:49:48 -!- sebbu has quit (Read error: 110 (Connection timed out)). 10:53:15 -!- sebbu2 has quit (Connection timed out). 10:59:52 gnight everone 11:02:29 -!- sebbu3 has quit (Connection timed out). 11:02:59 -!- GreaseMonkey has quit ("My bot can beat up your bot. Wait, sorry, *I* can beat up your bot *through* my bot."). 11:07:00 -!- jix__ has joined. 11:07:44 -!- Sukoshi has left (?). 11:11:30 -!- sebbu has joined. 11:20:42 -!- nazgjunk has quit ("Bi-la Kaifa"). 11:25:33 -!- nazgjunk has joined. 12:08:24 -!- sebbu3 has joined. 12:26:48 -!- sebbu has quit (Connection timed out). 12:37:53 -!- sebbu has joined. 12:39:52 -!- sebbu2 has joined. 12:57:39 -!- sebbu3 has quit (Read error: 110 (Connection timed out)). 12:59:35 -!- sebbu has quit (Connection timed out). 13:14:26 -!- sebbu2 has quit (Read error: 110 (Connection timed out)). 13:19:36 -!- puzzlet_ has quit (Read error: 104 (Connection reset by peer)). 13:26:39 -!- sebbu has joined. 13:42:41 -!- jix__ has changed nick to jix. 14:09:50 -!- sebbu2 has joined. 14:10:52 -!- sebbu3 has joined. 14:29:36 -!- sebbu has quit (Read error: 110 (Connection timed out)). 14:31:45 -!- sebbu2 has quit (Connection timed out). 14:32:30 -!- sebbu3 has quit (Connection timed out). 14:48:02 -!- ihope has joined. 16:17:26 -!- sebbu has joined. 17:56:42 You know, if I want to write a kernel, I'm really going to have to learn more about x86. 18:25:00 Or write for a different architecture. 18:25:48 I hear that linux-linux-gnu makes for a useful one (Linux runs on it, at least). :p 18:33:13 -!- SevenInchBread has joined. 18:35:04 -!- calamari has joined. 18:35:38 ihope, hmmm 18:36:12 Pikhq: linux-linux-gnu? 18:36:34 the basic kernel should basically just... take hardware interupts and place them on a queue that can be accessed by like... a hardware-dispatch process of some kind 18:37:51 Still sounds like a kernel library/module. 18:37:54 I see privledges being arbitrary flags that can be set on processes. 18:38:22 they don't do anything on their own... other stuff just needs to check to see if certain flags are set. 18:40:37 ihope: Yes: GNU/Linux running on Linux. 18:40:47 (AKA Usermode Linux) 18:41:58 hmmm.... the kernel could also handle system call interupts.... it would handle some of the memory allocation calls... but most of the other ones would be delegated to some userland process 18:42:20 Would it also handle processes? 18:42:37 The kernel, I mean? 18:42:55 processes are basically just bits of code attached to interupts... and since the kernel will be handling interupts... probably. 18:43:00 at least at the most basically level 18:43:13 Bits of code attached to interrupts? 18:43:24 So they're subroutines run whenever you get an interrupt? 18:43:40 it won't -schedule- the processes or anything... it'll just provide the operations for moving them around in memory. 18:44:05 -nod- that's what interupts do. They're kind of like exceptions in the programming language universe. 18:44:17 So what does schedule the processes? 18:44:19 except most of them have nothing to do with errors 18:44:29 a process. :) 18:45:16 paradoxical, no? But definetely possible. 18:45:58 * ihope scribbles all over SevenInchBread 18:46:25 How about the kernel handles process scheduling, memory, and system calls, and then there aren't very many system calls? 18:46:47 And maybe interrupts too. 18:47:05 it would impossible to do the operating system if the kernel didn't handle interupts. 18:47:29 they're part of the hardware 18:47:33 (some of them) 18:48:26 I want the kernel only what it needs to do - which is interupts and memory. 18:48:32 -!- calamari has quit (Remote closed the connection). 18:48:52 -!- calamari has joined. 18:48:52 * ihope ponders 18:49:15 So it handles interrupts and contains the instructions for a couple system calls? 18:49:29 And the rest is left up to the "upper kernel"? 18:49:34 well... the system calls will be in kernel land. 18:49:41 so... yes 18:50:21 * SevenInchBread doesnt't like the "upper kernel" terminology... but whatever. The "upper kernel" is basically a bunch of processes 18:50:32 Try just 'userspace'. 18:50:45 That is what every other microkernel calls it. 18:50:48 So process scheduling and system calls will be handled by processes... 18:51:04 Pikhq: what every other microkernel calls what? 18:51:17 ihope: The set of processes which support the rest of the system. 18:51:24 well.... system calls are interupts... which go to the kernel... which then triggers some other process 18:51:42 SevenInchBread: hmm... 18:51:54 Could be done. 18:52:16 that's basically what makes a microkernel a microkernel.... it doesn't handle all the system calls 18:54:45 so... once the kernel receives a system call interupt... I think it should delegate to call to a list of programs that have associated themselves with the system call which get executed in some order of priority.... that way you can redefine the system calls any way you want. 18:55:13 SevenInchBread: A microkernel is a kernel design where almost everything is handled by userspace processes. 18:55:19 * SevenInchBread nods 18:56:28 Usually, a microkernel *will* handle all the system calls. . . The thing being, they have very, very few system calls (usually just things like exec(char *); and send_message(pid_t);). 18:56:31 What would you call a kernel that handles all the system calls but whose system calls are pretty basic? 18:56:43 That would be a microkernel. 18:57:02 That would be the usual form of a microkernel, in fact. 18:57:07 when we design the microkernel... we just need to make it as general as possible. Don't worry about the specifics... the microkernel should be pluggable into any kind of OS design. 18:57:20 Execute process and send message, eh? 18:57:32 How would things like hardware interaction be done? 18:57:50 interupts 18:58:07 which get put on like... a "hardware signal" queue or whatever 18:58:15 Depends upon the kernel. . . Mach, at least, provides a very, very basic interface to hardware via syscalls. Mach, though, is rather monolithic for a microkernel. . . 18:58:16 And how do you make sure not every process can interact with all hardware? 18:58:28 and a system call for checking out recent hardware signals 18:58:45 Pikhq: GNU Mach? 18:59:00 ihope: All the Mach variants, including GNU Mach. 18:59:01 Oh. The Mach microkernel. 18:59:15 (they all come from the same original project) 18:59:45 *GNU* Mach's hardware interface is a subset of the Linux module API. . . 19:00:46 ihope, don't need to worry about that till other stuff. I don't think the microkernel itself needs to worry about privledges 19:01:12 it does however... need an interface to allow other crap to worry about privledges for it. 19:01:44 So under the exec and send_message thing, does the kernel handle processes? 19:02:03 If so, surely some processes have permission to do things that other processes don't have the permission to do. 19:02:24 * ihope gets out his list of system calls 19:03:33 yeah.... you'll probably have to get used to me not worry about permissions at all.... since I don't really care about them either way. 19:03:39 *worrting 19:03:44 *worrying 19:05:02 Enter supervisor mode, switch to other process, end time slice, add permission to process, remove permission from process, check process for permission, invoke service, register service, unregister service, grab service, allocate memory, deallocate memory... 19:05:30 Oh, and create process. 19:05:56 That and some ways of interacting with process scheduling should do it. 19:05:59 ....probably don't need all of those 19:06:23 Get process permissions, set process permissions instead of those fancy ways of doing things? 19:06:34 -!- calamari has quit ("Leaving"). 19:06:41 I'd X out the permission stuff, the service stuff, aaaand... the switch-to-other-process... since you don't need it because of interupts 19:07:04 Switch-to-other-process can be done with interrupts? 19:07:17 ....that's -always- how processes are switched 19:07:48 The process invokes a certain interrupt which switches to the other process without help from the kernel? 19:08:19 no... the kernel handles the interupts. So it's like a system call in certain regards 19:08:47 the difference is kind of trivial anyways. system calls are interupts too 19:09:18 Well, if we want to be able to switch to another process manually, what ways are there of doing that besides a system call? 19:09:44 ...I don't know. 19:10:44 So system calls are needed? 19:11:04 ......of course they are. 19:11:13 Needed for manual process switching, I mean. 19:12:03 so.... alloc, deloc, talk, waik, and some sort of check-hardware system call(s) 19:12:09 *wait 19:12:30 The permission stuff is needed unless you want almost all permission stuff to be handled by another process, which means system calls being handled by another process. 19:12:37 you don't need enter supervisor mode... I don't think. 19:12:59 You don't need to let processes enter supervisor mode if you provide some other way of accessing hardware. 19:13:24 wrong... the kernel handles system calls... however it can still let another process check permissions for it 19:13:45 Is that in response to what I just said about hardware? 19:13:59 ...Well, no, obviously not. 19:14:00 no.. the permission response 19:14:13 you're right about the supervisor mode thing... 19:14:17 The kernel can indeed handle system calls, but it would need another process to do the permission thing. 19:14:36 I guess I can't argue either way about that. 19:15:00 Except that you still need some level of permissions in the kernel, even if it's just an omnipotence flag. 19:15:18 Services are for inter-process communication. How else are you going to do that? 19:15:49 Well... I guess you could share memory. 19:15:52 services are names... set to processes. Not too terribly kernel-required 19:16:23 What else is going to handle them? 19:16:32 ...guess. :) 19:16:40 How else will a process send a message to the process that handles them? 19:17:19 Will it send a message to the process telling it to send a message to itself? 19:18:28 you lost me. 19:18:34 How else will a process send a message to the process that handles them? 19:18:40 That handles messages, I mean. 19:20:00 -cough- well, if you gave processes names.... 19:20:53 And what handles those names? The kernel? 19:21:16 possibly 19:22:18 Can you think of a way it could be otherwise? 19:22:19 makes sense to me 19:22:56 either that... or you could just have a process that handles "services" 19:23:49 If names are handled by the kernel, and you let processes have multiple names, and then call the names services... 19:24:23 * ihope scratches "grab service" 19:25:05 * SevenInchBread refuses to call anything "sevice"... through sheet pig-headed dislike of the word. 19:25:10 *sheer 19:26:09 How about calling them interfaces, then? 19:26:31 ....reminds me of OO. even worse than service 19:26:34 -!- nooga has quit ("Lost terminal"). 19:26:39 I like "names". 19:27:43 Hey, that's a good idea! 19:28:25 or if we want to sound more intellectual... we can go with "memes" 19:28:43 Why would we do that? 19:28:59 same reason we'd call it any other name 19:29:02 * ihope wonders... 19:29:07 How about we call them vistas? 19:29:11 Or windows? 19:29:24 :-P 19:29:28 buttons? 19:29:37 -ahem- NAMES IT IS 19:29:37 Calling them names sounds fine. 19:30:13 So have we concluded that "invoke name, register name, unregister name" are kernel-worthy? 19:30:50 not sure about invoke name... isn't that the same as switch-process? 19:31:43 OH 19:31:46 here's an idea 19:31:59 Invoke name sends stuff to a process, switch switches to that process so it can handle the stuff. 19:32:04 And what's your idea? 19:32:12 permissions.... can be a set of programs that must return a success for a certain program. 19:32:19 and "flags" can be a totally different concept. 19:32:33 so a permission becomes a more like a check. 19:33:50 Permissions can be handled by having every process without the "omnipotent" flag invoke a name and switch instead of actually doing the system call. 19:34:40 so... invoke("canRead", 5, some/file) ...which shoots off a series of processes that either exit with success or failure 19:35:08 these processes could in turn.... do things like invoke("has flag", 5) ...and fail or succeed bassed on that 19:35:14