00:02:36 -!- crathman_ has quit (Read error: 113 (No route to host)).
00:04:11 -!- bsmntbombdood has joined.
00:06:34 <Pikhq> Nevermind, found it.
00:06:40 <Pikhq> Package browser; imagine that.
00:33:00 * Pikhq is *attempting* to get his distro up and running
00:37:34 <Pikhq> And failing horribly.
00:48:07 -!- calamari has joined.
00:55:10 -!- calamari has quit ("Leaving").
00:58:36 <Sukoshi> I'm writing a farming roguelike.
00:58:50 <Sukoshi> (After spending 3 hours reading about magnetism/electricity.)
01:00:36 <lament> you mean the hero is a farmer
01:01:11 <Sukoshi> No, it's a roguelike with inspiration from Harvest Moon.
01:01:11 <ihope> Are you going to farm magnetic carrots?
01:03:15 <Sukoshi> 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 <Sukoshi> 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 <lament> that does not sound like a roguelike.
01:05:32 <Sukoshi> 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 <lament> that sounds very much like an economic simulation and not at all like a roguelike.
01:06:16 <Sukoshi> But it's being done in curses.
01:06:33 <lament> that's just the interface
01:06:37 <lament> anything can be done in curses
01:06:41 <Sukoshi> Except that you actually interactively farm.
01:06:58 <Sukoshi> (Until you hire the indentured servants you need, of course.)
01:07:14 <Sukoshi> (Then you purchase another farm off struggling farmers.)
01:12:01 <SevenInchBread> ...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 <ihope> We're abandoning Abrasax, aren't we?
01:22:40 -!- calamari has joined.
01:26:24 <SevenInchBread> I think we'll be able to do Abrasax as long as we're willing to put in some work.
01:26:50 <SevenInchBread> 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:35:06 -!- calamari has quit ("Leaving").
01:36:39 <ihope> And then have an "upper kernel" handle permissions and such?
01:36:59 <SevenInchBread> basically just like.... talking to the MMU and dispatching interupts... and maybe some other stuff.
01:37:17 <SevenInchBread> ihope, eh... not necessarily. But yeah... basically just breaking down all the functions into different parts.
01:38:12 <ihope> Dividing into "lower kernel" and "upper kernel" doesn't really seem a bad idea.
01:38:54 <ihope> 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 <SevenInchBread> I was jsut thinking like.... a really small kernel... and then.... everything else in userville
01:40:48 <ihope> 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:46:05 <ihope> You mean the lower kernel doesn't have division of privileges at all?
01:48:05 <SevenInchBread> no... it basically sends interupts off to other places... and manages memory. Privledges wouldn't even make sense there.
01:48:19 <ihope> Sends interrupts off to other places and manages memory...
01:48:41 <ihope> So it's a library containing the OS's entry point?
01:49:05 <Sukoshi> Non-interactive programming is for nubs.
01:50:10 <ihope> What's interactive programming?
01:50:24 <SevenInchBread> it's just... the kernel. It just handles the most basic hardware stuff and delegates it to other software.
01:52:00 <SevenInchBread> that's the most basic function of the operating system... to assign crap as callbacks. All other functionality emerges from that.
01:52:21 <ihope> So it provides some "system calls"?
01:54:11 <Sukoshi> So you dismiss it to non-interactive just like that?
01:54:23 <Sukoshi> Interactive programming, like a REPL.
01:55:12 <SevenInchBread> no no... not system calls... those aren't callbacks - they're simply subroutines because they're always present.
01:55:27 <Sukoshi> Uggh, are you listening to me, you stupid piece of cake? :P
01:55:45 <SevenInchBread> 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:56:03 <SevenInchBread> 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 <Sukoshi> I'm probably thinking of the wrong side of the sex SevenInchBread.
01:59:59 <ihope> SevenInchBread: subroutines?
02:00:06 <ihope> So it's like a library or module?
02:00:54 <Sukoshi> Uggh, make it interactive.
02:01:15 <ihope> Sukoshi: what do you mean?
02:01:21 <Sukoshi> Like, create a Forth-level interface to interrupts and just start building up the rest in Forth words.
02:01:57 <Sukoshi> 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 <ihope> I think we want "the rest" to be very modular and easy to do in any programming language.
02:02:24 <Sukoshi> In any non-REPL language :(
02:02:37 <Sukoshi> You can compile to Forth words, you know?
02:04:36 <Sukoshi> http://www.amresearch.com/v6/
02:04:48 <SevenInchBread> basically I just want to kernel to do things like "oh cool... an interrupt! CONTEXT SWITCH POWERS ACTIVATE!"
02:05:08 <Sukoshi> Compilers can compile to Forth words, which are basically supported by a barebones kernel.
02:05:34 <ihope> Sukoshi: you seem a little Forth-obsessed lately.
02:05:44 <ihope> Does it have closures, whatever they are?
02:05:45 <Sukoshi> ihope: Well, you seem very non-interactive obsessed.
02:06:11 <ihope> Sukoshi: I... still don't get what you mean by "interactive".
02:06:21 <Sukoshi> ihope: Have you never played with a Lisp or a Forth before?
02:06:35 <ihope> I've played with a Lisp or two.
02:07:16 <Sukoshi> Play with gForth. It's an experience.
02:07:42 -!- calamari has joined.
02:07:45 <Sukoshi> It's just a prompt that lets you type in Forth words, which are then just looked up.
02:08:11 <Sukoshi> It doesen't have to be *Forth*, but you seem to be gearing this for a non-interactive base.
02:08:17 <Sukoshi> SevenInchBread: Yes. Crazy isn't it?
02:08:35 <Sukoshi> A barebones microkernel drops you into that. OpenBoot does something similar.
02:08:39 <ihope> Suddenly, I want to combine Thue with something roughly Forth-like.
02:09:06 <SevenInchBread> I use python's shell interpreter all the time... it's nothing amazing.
02:09:33 <ihope> Commands are taken from the left and executed. Any results are put back on the left.
02:09:38 <Sukoshi> Plus Python's shell interpreter doesen't execute machine code directly.
02:09:52 <ihope> "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:49:10 <Sukoshi> oerjan: You said you used Pascal.
05:49:13 <oerjan> note that it must not read/write the shell std streams
05:49:27 <Sukoshi> Do you think it is better than C?
05:52:25 <Sukoshi> Uggh. Why doesen't Radio Shack give the Maximum Energy Product (or Magnetic Field) of their magnets? -_-''
05:53:59 <SevenInchBread> oerjan, anyway to prevent that without... recompiling the program?
05:54:27 <oerjan> yes, you use > and < to redirect I/O.
05:54:49 <Sukoshi> SevenInchBread: ``ls > grep -i hi''
05:55:14 <Sukoshi> ... And that's not an example of IO rediirection ....
05:55:18 -!- GreaseMonkey has joined.
05:55:23 <Sukoshi> | is the piping character.
05:55:33 <Sukoshi> It pipes stdiout of the first application to stdin of the second.
05:55:44 <SevenInchBread> so... how would I tell the program to redirect output to.... hmmmmm... /dev/null... or just nowhere
05:56:16 <oerjan> 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:57:04 <Sukoshi> > redirects output to an FD.
05:57:12 <oerjan> SevenInchBread: ignore Sukoshi :)
05:58:02 <oerjan> on a shell line, <file tells to use file for stdin, >file for stdout.
05:58:26 <SevenInchBread> a friend is complaining about the shell window for a server app being unable to close without shutting the whole thing down
06:00:31 <oerjan> ah yes, &>file takes both stdout and stderr, at least in bash
06:01:19 <oerjan> on the other hand, the redirection may not be necessary for X commands.
06:01:31 <oerjan> they rarely write to the terminal, I think.
06:01:58 <oerjan> cannot check as i am on windows these days.
06:02:45 * SevenInchBread just wants the shell window to go away without the MUD crashing
06:02:47 <oerjan> except for ssh'ing to my old unix account.
06:02:52 <Sukoshi> 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:36 <Sukoshi> 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 <oerjan> i think something more than background might be needed for that.
06:09:07 <oerjan> hm... try the daemon command.
06:09:21 <Sukoshi> .... What command is that oerjan ?
06:09:35 <oerjan> oh wait, it was a function
06:09:47 <oerjan> my eyes skipped that part
06:11:33 <oerjan> anyhow, have you tried "command &>/dev/null </dev/null &" ?
06:14:03 <oerjan> that's the closest i can think of, removing all connections to the terminal i hope
06:15:25 <SevenInchBread> that's not the problem though... it just needs to run without the shell being there
06:15:45 <Sukoshi> Your WM should have the feature in a ``run'' thing or whatever.
06:16:01 <Sukoshi> Or I'll bet you can find some small app written just for this purpose, if not write it yourself.
06:25:57 <oerjan> GregorR: maybe you could recolor your red fez picture to test...
06:26:22 <Sukoshi> What about semi-purple fez?
06:30:10 <oerjan> http://www.codu.org/hats/RedFez-med.jpg
06:31:48 <GregorR> My red fez picture is a uniquely bad picture of me XP
06:31:49 <oerjan> and that's GregorR unless he's fooling us. :)
06:33:21 <oerjan> so not only do you need to recolor it, you also need to graft it onto another picture of you :)
06:34:03 <oerjan> _might_ be simpler to get a physical sample, then.
06:35:09 <oerjan> but then, a new picture of the red one seems in order.
06:37:21 <GregorR> I think I'll take a picture of me in my new green fez and then recolor that X-P
06:40:37 <oerjan> Mein Hut, es hat drei Ecken Drei Ecken hat mein Hut...
06:41:38 <GregorR> We have that saying, but in English.
06:41:46 <GregorR> Err, saying == song lyric IIRC
06:41:55 <oerjan> and in norwegian, but I think the German is original.
06:43:27 <oerjan> somewhat disturbing that the google hits all spell it differently...
06:44:55 <oerjan> unless austrian, the y should be shifted somewhat towards a
06:49:29 <oerjan> basically, the rules for pronouncing ie and ei in English and German are approximately opposite of each other.
06:51:08 <GregorR> We can thank the Great Vowel Shift for that (probably)
07:02:28 <GregorR> AND THAT LANGUAGE SHOULD BE ENGLISH
07:02:38 <GregorR> IF ENGLISH WAS GOOD ENOUGH FOR JESUS, IT'S GOOD ENOUGH FOR TEXAS
07:02:58 <bsmntbombdood> english is the language of god, because it's what the bible is written in
07:04:53 <oerjan> and besides, the spelling of Hebrew seems to be even worse.
07:06:16 -!- iano has quit.
07:29:24 <oerjan> 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 <lament> the former is true; the latter isn't
07:29:53 <lament> you get used to it very quickly
07:32:42 <GregorR> Why can't I find a good skimmer for under $100 X_X
07:34:16 <oerjan> thank god for wikipedia disambiguation.
07:35:03 <oerjan> allowing me to find out what "skimmer" may mean
07:36:43 <oerjan> although if it had been anyone but you i would _still_ not know :)
07:37:07 <GregorR> Well, y'know, I want a sea bird.
07:38:47 <oerjan> yeah yeah, and you have this nice bridge you have to sell.
07:40:14 <oerjan> are skimmers handmade perhaps?
07:40:43 <GregorR> It used to be a very popular style of hat, but I presume they're no longer made en masse.
07:41:56 <oerjan> as i said, if it had been anyone but GregorR... :)
07:42:17 <GregorR> Well, I saw one at my usual online hat shop while looking for a tricorn.
07:42:34 <GregorR> 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 <Sukoshi> If soemone wants to buy me rare Earth magnets, they should.
08:57:04 <GregorR> Funny, I was JUST having the compulsion to buy rare Earth magnets for somebody I barely know online!
09:05:54 <Sukoshi> Just for these sorts of moments.
09:06:23 <Sukoshi> Look, people in hormone-filled teenage chatrooms buy clothes for people they barely know.
09:06:47 <Sukoshi> Why can your hormones cloud you to the same level of idiocy? :(
09:07:11 <GregorR> I have no hormones. I am an android.
09:12:26 <oerjan> hey, at least Sukoshi is not asking for fissible substances :)
09:19:38 <oerjan> but then, who knows what a denizen of #esoteric could do with a rare Earth magnet.
09:22:03 <Sukoshi> It was for a generator, but I could think of more sinister things
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).
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 <ihope> You know, if I want to write a kernel, I'm really going to have to learn more about x86.
18:25:00 <Pikhq> Or write for a different architecture.
18:25:48 <Pikhq> 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:36:12 <ihope> Pikhq: linux-linux-gnu?
18:36:34 <SevenInchBread> 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 <ihope> Still sounds like a kernel library/module.
18:37:54 <SevenInchBread> I see privledges being arbitrary flags that can be set on processes.
18:38:22 <SevenInchBread> they don't do anything on their own... other stuff just needs to check to see if certain flags are set.
18:40:37 <Pikhq> ihope: Yes: GNU/Linux running on Linux.
18:40:47 <Pikhq> (AKA Usermode Linux)
18:41:58 <SevenInchBread> 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 <ihope> Would it also handle processes?
18:42:37 <ihope> The kernel, I mean?
18:42:55 <SevenInchBread> processes are basically just bits of code attached to interupts... and since the kernel will be handling interupts... probably.
18:43:13 <ihope> Bits of code attached to interrupts?
18:43:24 <ihope> So they're subroutines run whenever you get an interrupt?
18:43:40 <SevenInchBread> it won't -schedule- the processes or anything... it'll just provide the operations for moving them around in memory.
18:44:05 <SevenInchBread> -nod- that's what interupts do. They're kind of like exceptions in the programming language universe.
18:44:17 <ihope> So what does schedule the processes?
18:45:58 * ihope scribbles all over SevenInchBread
18:46:25 <ihope> How about the kernel handles process scheduling, memory, and system calls, and then there aren't very many system calls?
18:46:47 <ihope> And maybe interrupts too.
18:47:05 <SevenInchBread> it would impossible to do the operating system if the kernel didn't handle interupts.
18:48:26 <SevenInchBread> 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:49:15 <ihope> So it handles interrupts and contains the instructions for a couple system calls?
18:49:29 <ihope> And the rest is left up to the "upper kernel"?
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 <Pikhq> Try just 'userspace'.
18:50:45 <Pikhq> That is what every other microkernel calls it.
18:50:48 <ihope> So process scheduling and system calls will be handled by processes...
18:51:04 <ihope> Pikhq: what every other microkernel calls what?
18:51:17 <Pikhq> ihope: The set of processes which support the rest of the system.
18:51:24 <SevenInchBread> well.... system calls are interupts... which go to the kernel... which then triggers some other process
18:51:42 <ihope> SevenInchBread: hmm...
18:52:16 <SevenInchBread> that's basically what makes a microkernel a microkernel.... it doesn't handle all the system calls
18:54:45 <SevenInchBread> 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 <Pikhq> SevenInchBread: A microkernel is a kernel design where almost everything is handled by userspace processes.
18:56:28 <Pikhq> 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 <ihope> What would you call a kernel that handles all the system calls but whose system calls are pretty basic?
18:56:43 <Pikhq> That would be a microkernel.
18:57:02 <Pikhq> That would be the usual form of a microkernel, in fact.
18:57:07 <SevenInchBread> 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 <ihope> Execute process and send message, eh?
18:57:32 <ihope> How would things like hardware interaction be done?
18:58:07 <SevenInchBread> which get put on like... a "hardware signal" queue or whatever
18:58:15 <Pikhq> 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 <ihope> And how do you make sure not every process can interact with all hardware?
18:58:28 <SevenInchBread> and a system call for checking out recent hardware signals
18:59:00 <Pikhq> ihope: All the Mach variants, including GNU Mach.
18:59:01 <ihope> Oh. The Mach microkernel.
18:59:15 <Pikhq> (they all come from the same original project)
18:59:45 <Pikhq> *GNU* Mach's hardware interface is a subset of the Linux module API. . .
19:00:46 <SevenInchBread> 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 <SevenInchBread> it does however... need an interface to allow other crap to worry about privledges for it.
19:01:44 <ihope> So under the exec and send_message thing, does the kernel handle processes?
19:02:03 <ihope> 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 <SevenInchBread> 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:05:02 <ihope> 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 <ihope> Oh, and create process.
19:05:56 <ihope> That and some ways of interacting with process scheduling should do it.
19:06:23 <ihope> Get process permissions, set process permissions instead of those fancy ways of doing things?
19:06:34 -!- calamari has quit ("Leaving").
19:06:41 <SevenInchBread> 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 <ihope> Switch-to-other-process can be done with interrupts?
19:07:48 <ihope> The process invokes a certain interrupt which switches to the other process without help from the kernel?
19:08:19 <SevenInchBread> no... the kernel handles the interupts. So it's like a system call in certain regards
19:08:47 <SevenInchBread> the difference is kind of trivial anyways. system calls are interupts too
19:09:18 <ihope> 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:10:44 <ihope> So system calls are needed?
19:11:13 <ihope> Needed for manual process switching, I mean.
19:12:03 <SevenInchBread> so.... alloc, deloc, talk, waik, and some sort of check-hardware system call(s)
19:12:30 <ihope> 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 <SevenInchBread> you don't need enter supervisor mode... I don't think.
19:12:59 <ihope> You don't need to let processes enter supervisor mode if you provide some other way of accessing hardware.
19:13:24 <SevenInchBread> wrong... the kernel handles system calls... however it can still let another process check permissions for it
19:13:45 <ihope> Is that in response to what I just said about hardware?
19:13:59 <ihope> ...Well, no, obviously not.
19:14:17 <ihope> The kernel can indeed handle system calls, but it would need another process to do the permission thing.
19:14:36 <ihope> I guess I can't argue either way about that.
19:15:00 <ihope> Except that you still need some level of permissions in the kernel, even if it's just an omnipotence flag.
19:15:18 <ihope> Services are for inter-process communication. How else are you going to do that?
19:15:49 <ihope> Well... I guess you could share memory.
19:15:52 <SevenInchBread> services are names... set to processes. Not too terribly kernel-required
19:16:23 <ihope> What else is going to handle them?
19:16:40 <ihope> How else will a process send a message to the process that handles them?
19:17:19 <ihope> Will it send a message to the process telling it to send a message to itself?
19:18:34 <ihope> How else will a process send a message to the process that handles them?
19:18:40 <ihope> That handles messages, I mean.
19:20:53 <ihope> And what handles those names? The kernel?
19:22:18 <ihope> Can you think of a way it could be otherwise?
19:22:56 <SevenInchBread> either that... or you could just have a process that handles "services"
19:23:49 <ihope> 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:26:09 <ihope> How about calling them interfaces, then?
19:26:34 -!- nooga has quit ("Lost terminal").
19:27:43 <ihope> Hey, that's a good idea!
19:28:25 <SevenInchBread> or if we want to sound more intellectual... we can go with "memes"
19:28:43 <ihope> Why would we do that?
19:29:07 <ihope> How about we call them vistas?
19:29:37 <ihope> Calling them names sounds fine.
19:30:13 <ihope> So have we concluded that "invoke name, register name, unregister name" are kernel-worthy?
19:30:50 <SevenInchBread> not sure about invoke name... isn't that the same as switch-process?
19:31:59 <ihope> Invoke name sends stuff to a process, switch switches to that process so it can handle the stuff.
19:32:04 <ihope> And what's your idea?
19:32:12 <SevenInchBread> permissions.... can be a set of programs that must return a success for a certain program.
19:33:50 <ihope> 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 <SevenInchBread> so... invoke("canRead", 5, some/file) ...which shoots off a series of processes that either exit with success or failure
19:35:08 <SevenInchBread> these processes could in turn.... do things like invoke("has flag", 5) ...and fail or succeed bassed on that
19:35:14 <ihope> Why shoot off a series of processes when you can just invoke one name?
19:35:28 <ihope> One name which handles everything else?
19:36:23 <SevenInchBread> yeah... canRead can be registered to one process... which handles all the other processes... or whatever
19:37:01 <SevenInchBread> but yeah... my basic idea is to have flags... for putting values on processes and files.... but with a "permission check" being an operation that checks a number of registered processes for a success or failure
19:37:24 <SevenInchBread> so you could expand or decrease the meaning of certain permission checks
19:37:43 <ihope> Would this be part of the kernel?
19:37:49 <SevenInchBread> hehe, sorry, just finding any possible way to add potential play-around-ability.
19:38:17 <SevenInchBread> not really... the only part that's a system call would be the invoke-name part
19:38:26 <ihope> If not, you've nicely reduced the permission system calls to "get omnipotence flag" and "set omnipotence flag".
19:39:23 <ihope> Enter supervisor mode, create process, switch to other process, end time slice, get omnipotence flag, set omnipotence flag, invoke name, register name, unregister name, allocate memory, deallocate memory, create process?
19:39:35 <ihope> SevenInchBread: so that we can control the omnipotence flag?
19:40:33 <ihope> Is the kernel going to invoke a process in order to determine whether a process is omnipotent?
19:40:44 <ihope> Sounds easier to just have a flag for it.
19:41:02 <SevenInchBread> >.> makes sense to me. why do we need an omnipotence flag though?
19:41:42 <ihope> Do you want to make all processes omnipotent?
19:42:06 <ihope> Do away with permissions completely and let any process do anything.
19:43:13 <SevenInchBread> -shrug- sounds like we could integrate that into the rest of the permissions stuff....
19:44:04 <ihope> Well, the "big permission handler process" checks for permission and then makes the call, right?
19:44:34 <ihope> If we try to integrate that into the rest of the permission stuff, the call that the BPHP makes has to go through the BPHP.
19:44:53 <SevenInchBread> that execute a number of programs... to check for a certain condition.
19:46:27 <ihope> You mean the process says "yes" or "no" instead of making the call itself?
19:46:36 <SevenInchBread> and then the canread process executes a number of other programs that have been configured to it... the default one being something like invoke("hasflag", some/file, "readable")
19:47:46 <SevenInchBread> what the permission allows control of... is entirely dependent on when and where it is being checked
19:49:06 <SevenInchBread> ...it also gives you the option to make your own permissions... and use them as you please.
19:49:07 <ihope> Well, we may not want the process to have to exit every time it has to give a yes/no answer.
19:49:49 <ihope> Maybe we could have an "allow/deny" system call.
19:49:56 <SevenInchBread> that's true... I've been thinking of ways to give processes the ability to send replies to specific requests... instead of spitting out its answers to a single queue...
19:51:26 <ihope> Actually, "allow/deny/sdeny", sdeny denying the request but not telling the process that it's been denied.
19:52:13 <ihope> <ihope> Maybe we could have an "allow/deny" system call.
19:52:53 <SevenInchBread> I mean.. I don't see how allow/deny makes any sense as syscalls
19:53:11 <ihope> <SevenInchBread> that's true... I've been thinking of ways to give processes the ability to send replies to specific requests... instead of spitting out its answers to a single queue...
19:53:22 <ihope> allow/deny/sdeny is how you send the reply.
19:53:38 <SevenInchBread> no no... I mean... generic replies... not just allow or deny
19:54:04 <ihope> Maybe plain old allow/deny, and make the BPHP tell the process the result of the system call?
19:54:26 <SevenInchBread> like... if A send "ls" to B... then B will receive the message in its message box... and then be able to reply to that message with "hello \n world \n"
19:54:56 <ihope> That's what I've been saying.
19:55:44 <ihope> A makes the system call, B gets it, B allows or denies it, B sends the result back to A.
19:56:05 <ihope> We also need to be able to set an active/inactive flag on processes to make sure that they don't check the result of a system call before there is a result.
19:56:32 <ihope> Is what you said related to handling permissions, then?
19:56:48 <SevenInchBread> you can handle that with polling... and a "waitreply" ability (not necessarily a system call... but an option in the IPC api)
19:57:19 <SevenInchBread> I mean... the reply thing will be used to answer permission requests... but that's not its specific purpose.
19:57:24 <ihope> I'm starting to confuse myeslf.
19:58:06 <SevenInchBread> so "calling" a process is a combination of sending a message and then immediately waiting for its reply.
19:58:28 <ihope> Let's pick up on this later, shall we?
19:58:30 <SevenInchBread> not sure if the kernel should be responsible for replies though....
20:10:06 <oklopol> what's it called in math when something is part of a group or whatever they're called in math?
20:10:23 <oklopol> like x E R with a cool-looking e & r
20:11:49 <ihope> oklopol: being an element of a set?
20:11:54 <ihope> Or a member of a set.
20:13:01 <ihope> The set containment symbol in Unicode is ELEMENT OF, or U+2208.\
20:14:13 <oklopol> does the 'set containment symbol' have a _more official sounding_ name?
20:19:28 <ihope> Just like there's no "more official-sounding" name for the Unicode character INFINITY.
20:21:08 <oklopol> that's a lot more official
20:40:27 <SevenInchBread> so... I know how we can encapsulate permissions into all the kernel functions
20:40:29 <Bigcheese> Are we still on about microkernel?
20:41:23 <oklopol> lolzbig is much better that infzorz, i shall use that one from now on
20:41:51 <SevenInchBread> ihope, see... applications won't be system calls normally... operations like alloc and dealloc can be handled by userspace processes that have special access to the kernel.
20:42:09 <ihope> And what would that special access consist of?
20:42:13 <SevenInchBread> something like a "givemagichat" syscall... that gives a process access to the basic syscalls.
20:43:05 <SevenInchBread> so you have a process called "mm"... that handles memory allocation, and has the magic hat
20:44:39 <SevenInchBread> oh... and for the problem we've been having with our name: Abrasax can be the name of the entire operating system... and Sophia can be the name of the microkernel project.
20:45:34 <ihope> As long as there aren't any interfering trademarks on "Sophia".
20:47:28 <lament> actually, I have trademarked "Jesus Christ".
20:47:49 <GregorR> I've trademarked "NAME", SevenInchBread ... cease and desist.
20:48:04 <ihope> USPTO.gov has 129 trademarks matching "Sophia".
20:48:23 * SevenInchBread is so fed up with copyright stuff at this point... that he just disregards the cnocept all together.
20:49:12 <ihope> Multiple of them are for just "Sophia",.
20:50:02 <ihope> You ignore copyrights?
20:50:11 <Bigcheese> SevenInchBread: just like most ppl
20:50:36 <SevenInchBread> civil disobedience is the best way to bring about a change... if I want to get rid of copyright altogether - I stop obeying copyright laws.
20:50:43 <ihope> I often obey copyright law.
20:51:27 <Bigcheese> GNUHurd is the most compleet microkernel atm right?
20:51:39 <SevenInchBread> pretty soon... if everyone stops obeying copyright laws (which is happening more often)... then copyriight won't be around anymore.
20:51:45 <GregorR> Bigcheese: Mmmmmmm, doubtful ... but maybe.
20:52:05 <SevenInchBread> there's quite a few fully complete microkernels out there.
20:52:46 <Bigcheese> l4 is, thats what GNUHurd is bassed on
20:53:12 <ihope> Now, trademark and copyright aren't the same thing, naturally.
20:53:19 <ihope> Trademark is pretty much a good thing.
20:53:28 <Bigcheese> Unless it's used for retarted things
20:54:03 <ihope> Bigcheese: what do you mean, used for retarded things?
20:55:05 <ihope> Indeed, those can be annoying.
20:55:29 <Bigcheese> Same with pattents, just about every thing is pattented atm.
20:55:32 <lament> trademarks are highly annoying
20:55:39 <lament> the company i'm working for
20:55:45 <SevenInchBread> patents are retarded. They don't encourage competition at all.
20:56:07 <lament> has an online app that we wanted to call "Vista"
20:56:15 <ihope> Bigcheese: tabs on computers or actual tabs?
20:56:22 <lament> and then we were threatened to be sued by... Visa
20:56:29 <lament> and had to change the name
20:57:15 <ihope> Hmm. Trademark 74423619 is on "SOPHIA" as applied to "computers and computer programs", but it's dead.
20:57:19 <SevenInchBread> ihope, hmm.... with this layout... we can take names out of the kernel. Names are purely a userspace invention...
20:57:33 <SevenInchBread> ihope, the "syscalls aren't usually called directly by applications" layout
20:58:27 <ihope> There's also a trademark on "SOPHIA" as applied to "computer hardware, in-circuit emulators and computer software relating to microprocessor development systems".
20:58:32 <ihope> It's number 74148425.
21:00:25 <SevenInchBread> we've got alloc, dealloc, magichat, demagichat, kill, hmmmm.... what else do we need... fork?
21:00:57 <ihope> Either we use a different name or we risk trademark infringement.
21:01:04 <SevenInchBread> except I don't like the name kill... let's call it zap. It sounds more like wizardy than murder.
21:01:27 <ihope> SevenInchBread: maybe you could create a list of system calls and exactly what they do and show it to me.
21:01:36 <SevenInchBread> ihope, if we risk trademark infringement... then I'm fully liable. That sound good to you?
21:02:24 <ihope> Serial number 73501942 is for "SOPHIA" as applied to "Computer System Analyzers and Peripherals Therefor", and it's dead.
21:04:05 <SevenInchBread> ihope, the root process.... the one that first has magichat set can be called overmind... at PID 0
21:04:32 <SevenInchBread> PID 1 can be Mother... serving a purpose similar to init... as the parent of all top-level processes
21:05:22 <ihope> You could write a spec for this kernel.
21:13:44 <SevenInchBread> ... I've never used memory allocation manually... so I need to read up on it to learn how it's usually done through system call
21:15:37 -!- jix__ has joined.
21:18:15 <SevenInchBread> ihope, hmmmm... I wonder how alloc and dealloc should work... I think the mm process could handle a lot of the allocation algorithm... and maybe the kernel could provide the basic "create a block of memory within a certain range of memory addresses" syscall for it
21:19:57 <GregorR> That's the Windowsesque way.
21:20:11 <SevenInchBread> and mm could provide the actual interface that programs would use.
21:20:58 <SevenInchBread> GregorR, Any problems with it? I mean... I don't expect actual application programs to use that... just the mm process.
21:21:16 <GregorR> I don't have any positive or negative opinion on it *shrugs*
21:21:21 <GregorR> It certainly would work fine.
21:22:52 <GregorR> That extends the break. There is a single "line" in the memory space between "allocated" and "unallocated" memory.
21:23:53 -!- jix has quit (Read error: 110 (Connection timed out)).
21:25:33 <SevenInchBread> well... I'll leave it up to mm... and just have this one as the most fundamental mechanism.
21:25:42 <SevenInchBread> It's probably the most basic form of memory allocation I could think of.
21:27:58 -!- ihope has quit (Nick collision from services.).
21:28:32 -!- ihope has joined.
21:59:50 <SevenInchBread> ihope, hmmm.... I'm trying to organize stuff in a way that makes sense... like...
22:00:15 <SevenInchBread> I've got "address spaces" and "threads"... as different concepts.... with a process being a combination of the two.
22:01:42 <bsmntbombdood> what happens when a bunch of guys who know nothing about OS design try to design an OS
22:07:10 -!- calamari has joined.
22:08:33 -!- Sgeo has joined.
22:38:19 <SevenInchBread> ihope, hmmm... what kind of operations does Linux allow on threads?
22:41:20 <Bigcheese> But basicly start, stop, eatcheese
22:42:24 <Bigcheese> join gets the return value of a thread and frees it's memory
22:42:44 <SevenInchBread> >.> hmmm... threads have memory independent of the process?
22:42:51 <SevenInchBread> I thought all threads on a process shared the same memory.
22:43:40 <SevenInchBread> ah... you mean... "the memory containing information about the thread"
22:44:12 <Bigcheese> like if you declare an int in a function
22:44:32 <Bigcheese> (well, it could be in a register, but w/e
22:45:05 <Bigcheese> http://en.wikipedia.org/wiki/Stack-based_memory_allocation
22:49:38 -!- sebbu2 has joined.
22:57:29 -!- sebbu has quit (Read error: 60 (Operation timed out)).
23:13:32 <SevenInchBread> Bigcheese, ...hmmm... does the kernel need to deal with the threads stack... or is it something that could be implemented another way?
23:14:55 -!- nazgjunk has quit (Read error: 54 (Connection reset by peer)).
23:15:15 -!- nazgjunk has joined.
23:33:30 <ihope> bsmntbombdood: so you're saying we're probably going to create a terrible operating system?
23:35:07 <ihope> Bigcheese: do you know anything about operating system design?
23:37:21 <ihope> If so, I will... make some odd half-attempt at paying you to help us out!
23:43:57 -!- sebbu2 has quit (Client Quit).
23:55:12 -!- ihope__ has joined.