00:03:37 -!- ihope has quit (Read error: 60 (Operation timed out)).
00:37:28 <bsmntbombdood> http://bsmntbombdood.mooo.com/hyper4_imag1_2big.png
00:38:11 -!- ihope__ has changed nick to ihope.
00:39:19 -!- pikhq has joined.
00:49:19 <ihope> Yay, we have a kernel spec thingy!
00:51:58 <ihope> Close enough, anyway.
00:52:19 <ihope> What you posted on AbraSophia some while ago.
00:55:57 <SevenInchBread> if problems come up or if something was unaddressed (like hardware)... I'll just add it later.
00:57:33 <SevenInchBread> hardware interupts will probably be handled by the kernel via an immediate context switch to a driver or something.
00:58:12 <SevenInchBread> ...maybe not immediately... hardware is important, but you don't want to freeze up everything because of a slow hardware operation.
00:59:24 <SevenInchBread> spaces handle pretty much any information about memory you could want...
01:01:29 <SevenInchBread> ....but... I have no clue how to implemetn all of this into low-level registers.
01:05:39 <SevenInchBread> some of the system calls I'm thinking of are alloc, dealloc, context switch... and maybe some kind of interrupt/hook setting thing.
01:07:04 <SevenInchBread> ...but hooks can be done in processes. you could register hardware interupts to a handler... which, in the case of abrasax, will probably delegate behavior to a hook process. (...if that's cool with you)
01:19:46 -!- Bigcheesegs has quit (Read error: 104 (Connection reset by peer)).
01:20:22 -!- Bigcheese has joined.
01:20:51 -!- Bigcheese has changed nick to Bigcheesegs.
01:34:23 <GreaseMonkey> it's called BrassMonkey but it has the UnBot nick to save reregistration
01:47:55 <SevenInchBread> hmmm... files aren;t though? I thought all the data in a file was right close together.
01:48:18 <pikhq> Although some filesystems try to avoid fragmentation.
01:50:38 <SevenInchBread> but wait... isn't fragmentation only a problem when you read the data sequentially?
01:50:59 <pikhq> And when you try to write more to a file. . . (that's how fragmentation occurs)
01:52:09 <SevenInchBread> no no, I know the -cause-... but does it really matter that much if you're not reading the data sequentially?
01:52:39 <SevenInchBread> yeah... will probably go with a swap partition though... simply because it avoids fragmentation altogether I guess.
01:52:51 <pikhq> Unfortunately, sequential data reads is rather common.
01:54:12 <pikhq> SevenInchBread: If you've got large programs, make that large sequential strips.
01:54:58 <SevenInchBread> yeah okay... I'm out of arguments... for something I don't really think would make sense.
01:55:02 <pikhq> I recommend that you try using a filesystem which avoids fragmentation. . .
01:55:19 <pikhq> In addition to a swap partition.
01:56:39 <pikhq> (most Unix filesystems. ;))
02:01:38 <pikhq> I'll port ext2 sometime later, so you can get a decent quality filesystem.
02:02:10 <pikhq> . . . If I( care enough to.
02:02:11 <SevenInchBread> sure... if all goes right the filesystem wouldn't be hard at all to change.
02:02:39 <SevenInchBread> ....still haven't written a single program for this OS though... I need to practice assembly/C
02:05:22 <SevenInchBread> probably one of the best ways to figure out how to prevent fragmentation is to take a sample of general trends in file sizes and directory location.
02:05:58 <SevenInchBread> the elphant-sized files... your images, audio, video stuff.
02:06:19 <SevenInchBread> will usually be close together in a directory tree.... usually. I have no empircal evidence to back that up.
02:06:28 <SevenInchBread> but I assume people put there music together in one place.
02:09:53 <SevenInchBread> ...you could even get fancy with it and have the OS "remember" how files tend to be accessed.
02:15:23 <ihope> How about system calls that don't require a magic hat are called "hatless" and those that do require one are called "hatful"?
02:15:46 <ihope> Unless you have a compelling argument against it, that's what we'll do, okay? :-)
02:19:28 <ihope> I have three hatless system calls here...
02:19:43 <ihope> And two of them may be unnecessary.
02:20:58 <ihope> Actually, every system call I've put down so far except one are probably unnecessary.
02:21:09 <ihope> Maybe two are necessary.
02:23:15 <lament> the only needed system calls are 's', 'k', and 'i'
02:23:20 <lament> and 'i' is just for optimization.
02:23:41 <ihope> Don't you want a ` system call as well?
02:24:15 <ihope> Really, all you need is * and i... or 0 and 1.
02:24:24 <ihope> Depends on whether you want your kernel to be Iota or Jot.
02:25:00 <pikhq> I prefer the system call "Lambda".
02:25:10 -!- Sgeo has joined.
02:28:50 <SevenInchBread> ihope, well... I do kind of have an objection. The purpose of the hat thing is so that you use processes to build the API,.
02:29:20 <ihope> SevenInchBread: what are you saying?
02:29:38 <SevenInchBread> the kernel provides the low-level details... but rarely will those low-level details be directly called by anything other than a select few processes. mem will call memory allocation stuff, etc.
02:29:53 <ihope> How will processes communicate?
02:30:12 <ihope> And sending a message isn't a system call?
02:31:45 <SevenInchBread> addd that to the spec... with a brief explaination of why.
02:32:22 <SevenInchBread> so far the only hatless one is the message passing... but I'm sure there are a few more.
02:33:16 <SevenInchBread> the other reason for a hat level is... well... the microkernel doesn't use any other form of privledges... the API handles all of that.
02:33:39 <SevenInchBread> it's a prviledge flag on processes that determines whether or not they can use certain system calls.
02:33:54 <SevenInchBread> originally it was ALL system calls... but I forgot that certain calls are pretty much necessary.
02:34:12 <SevenInchBread> the full term is "magic hat"... simply because it sounds cool.
02:35:39 <SevenInchBread> ihope, and I think the filesystem should recognize file types... like osx does now.
02:36:17 <SevenInchBread> file extension associates work fine for recognizing file types on the top level.... but they really can't assist the filesystem in preventing things like fragmentation.
02:37:31 <SevenInchBread> if the filesystem recognizes content types... then it can be smart about handling them. audio is typically large, and edited infrequently... while a swap file stays roughly the same most of the time, but will be written and read from frequently.
02:39:27 <SevenInchBread> ...images, on the other hand... are generally read, decompressed to bitmap, edited, and then saved back all in one huge write.
02:45:23 <SevenInchBread> ....text will change size and byte value often... but the reads and writes will be along the same pace as image writes.
02:47:55 <SevenInchBread> http://en.wikipedia.org/wiki/Delayed_allocation <-- this is an interesting technique
04:06:16 -!- calamari has quit ("Leaving").
04:07:16 -!- pikhq has quit (Read error: 54 (Connection reset by peer)).
04:07:46 -!- pikhq has joined.
04:08:12 -!- ShadowHntr has joined.
04:32:09 -!- SevenInchBread has quit (Read error: 113 (No route to host)).
06:10:12 -!- Sgeo has quit (Success).
06:14:22 -!- pikhq_ has joined.
06:16:47 -!- pikhq has quit (Read error: 113 (No route to host)).
06:37:37 -!- pikhq_ has quit (Read error: 110 (Connection timed out)).
06:40:16 -!- ShadowHntr has quit ("End of line.").
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
10:20:53 -!- GreaseMonkey has quit ("feel the power of a dynamic bot: http://rafb.net/p/xUFMl288.html | line buffer code: http://rafb.net/p/2JIiTz98.html").
10:36:08 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
10:36:38 -!- nazgjunk has joined.
13:10:57 -!- Bacta has joined.
13:11:20 <Bacta> Hi I'm developing an OS in Brainfuck ... any advice?
13:12:14 -!- Bacta has left (?).
13:16:07 -!- pikhq has joined.
13:48:59 -!- oerjan has joined.
14:38:19 -!- jix has joined.
15:54:21 -!- ihope__ has joined.
15:55:22 -!- ihope___ has joined.
16:10:03 -!- ihope has quit (Success).
16:12:47 -!- ihope__ has quit (Connection timed out).
16:44:36 -!- sebbu has joined.
16:54:19 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
16:54:53 -!- nazgjunk has joined.
17:06:02 -!- RodgerTheGreat has quit.
17:18:47 -!- crathman has joined.
17:48:23 -!- pikhq has quit (Read error: 60 (Operation timed out)).
18:02:47 -!- oerjan has quit ("Later").
18:26:30 -!- Izzy7 has quit (Read error: 101 (Network is unreachable)).
20:01:49 -!- alex89ru has joined.
20:03:28 -!- alex89ru has left (?).
20:06:33 -!- atrapado has joined.
20:07:28 -!- Izzy7 has joined.
20:42:09 -!- oerjan has joined.
20:58:13 -!- Bigcheesegs has quit ("isoGames - The New Leader In Online Spectator Sports - /server -m irc.isoGames.com").
21:02:47 -!- SevenInchBread has joined.
21:07:26 -!- ihope___ has changed nick to ihope.
21:13:40 <SevenInchBread> ihope, there won't be a read permissions for files. All files are readable by anyone.
21:15:40 <SevenInchBread> ....why not? how can you have something that's public domain and read-protected?
21:15:56 * oerjan smacks SevenInchBread with a hammer.
21:16:36 <SevenInchBread> and reading can't corrupt the data in the file... so it's a pretty safe operation compared to writing and executing.
21:18:01 <SevenInchBread> the ONLY reason... you would set a read-protect... is to prevent something from seeing something. ...but right now I can't think of any good purpose for wanting to do that.
21:18:43 <oerjan> anti-chinese government propaganga?
21:19:13 <SevenInchBread> oerjan, ...that's actually a good point. I guess privacy would be nice.
21:19:45 <oerjan> i guess you _could_ get away from it with a good encryption system.
21:19:56 <SevenInchBread> Does linux have password protection built into its filesystem?
21:20:04 <oerjan> which might actually be safer in case someone stole your harddisk. hm...
21:20:52 <oerjan> linux has ownership protection, and various ways of authorizing logins.
21:20:54 <SevenInchBread> well... not a stego filesystem... but... a filesystem that lets you hide the existence of something.
21:21:21 <SevenInchBread> I think password protection would be a good addition to the filesystem. (haha... talk about a change of heart)
21:21:31 <oerjan> i've never really looked into encryption filesystems other than knowing they exist.
21:21:59 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
21:22:21 <oerjan> actually passwords are pretty weak. i am almost thinking having _just_ encryption and no read permissions is an improvement.
21:22:50 <SevenInchBread> if you hide porn in the least signifigant bits of family photos... you can easily deny that you ever put it there, in the rare case that someone would event attempt to look for it.
21:23:45 <SevenInchBread> I don't like read permissions... but passwords (for locking stuff away from people) and encryption (for locking stuff away from machines) would be nice.
21:24:31 <oerjan> passwords -> passphrases for encryption
21:24:48 <SevenInchBread> -nodnod- but they're succeptable to brute-force searches.
21:25:02 <oerjan> they should be long passphrases.
21:25:36 <SevenInchBread> heh... my universal password for everything consists of five letters...
21:25:51 <SevenInchBread> there... you now have pretty much have access to everything I do.
21:26:54 <oerjan> well mine are about 8-10, but i am somehow assuming the important ones are not available for brute-force search.
21:28:09 <SevenInchBread> some global mode type things would be useful too... so you know how to optimize.
21:28:46 <oerjan> like "keep this file compressed"?
21:29:14 <SevenInchBread> a system with low-memory can have a generic "low-memory" flag set... or a "high-memory" for the opposite. If the system has a lot of memory, then the filesystem stuff can afford to do more caching of file reads/writes, for example.
21:29:38 <SevenInchBread> ...but it's a pain in the ass to do the check every time.
21:30:43 <SevenInchBread> since what "low memory" is... varies from application to application.
21:30:53 <oerjan> well, you could have a process that could register requests to know if memory went low, with limits given by the requesting process
21:31:15 <SevenInchBread> -nod- yeah, include it into some sort of "stats" process...
21:31:47 * SevenInchBread wants to add a lot of nifty gadgets... even at the expense of simplicity.
21:32:01 <SevenInchBread> a simple interface is important... a simple implementation not so much.
21:33:31 <ihope> I'd say read permissions are essential.
21:34:04 <oerjan> why not go with a full capability system? It seems to me they are all the rage over at Lambda the Ultimate
21:36:11 <ihope> For protecting data.
21:36:28 <ihope> Anything that needs protection.
21:36:38 <oerjan> of course it goes with the Principle of Least Authority, so it's fairly heavy security
21:36:59 <SevenInchBread> well... the only reason I would use a read permission is privacy... HOWEVER.
21:37:23 <SevenInchBread> it doesn't protect the file.... write permissions protect a file. You can't hurt a file by looking at it.
21:38:00 <ihope> Privacy isn't endangered by changing a file.
21:38:38 <SevenInchBread> read - privacy. write - protection. execute - non-fuck-up-your-computer-acy
21:38:42 <ihope> If you want to store passwords, you need read permissions.
21:39:30 <SevenInchBread> it is, linguistically speaking, a permission to read. but it's not a "unix read permission".
21:40:03 <SevenInchBread> passwords, methinks... are also easier to manage than read permissions for privacy.
21:40:21 <oerjan> encryption can do most of the read protection, but you need somewhere to store the system's initial codes...
21:40:27 <SevenInchBread> now instead of having to add a new user the read permission... you can just tell her the password.
21:40:51 <ihope> What if she doesn't want to remember the password?
21:40:58 <ihope> Or type it in all the time?
21:41:26 <ihope> I guess all you need is one password.
21:41:30 <oerjan> i mean if you want the system to be able to startup without user interaction, it must have access to at least one unencrypted password or code
21:41:43 <SevenInchBread> I would also say a password is more secure from people than a user permission.
21:41:52 <SevenInchBread> if you leave your computer... someone can't sneak up and look at the file.
21:42:07 <ihope> That's why operating systems have a "lock" feature.
21:42:14 <SevenInchBread> not from computers though... most passwords can be cracked with a brute-force search. ...for that you use full-blown encryption of the data.
21:42:59 <SevenInchBread> passwords ensure that the password is entered each time.... or (optionally) once in a certain span of time.
21:43:22 <ihope> SevenInchBread: it could well be more convenient to hit a key every time you leave the computer than to type in a password every time you... do certain things.
21:43:41 <ihope> I guess theoretically you only need one password.
21:43:47 <oerjan> seriously, no one wants to enter passwords all the time.
21:43:52 <SevenInchBread> people rarely make something private out of convience.
21:44:31 <ihope> Now, if you're the only one with access to a computer, passwords aren't needed at all.
21:44:42 <SevenInchBread> if you don't want to type in a password... then don't give it a password.
21:44:48 <ihope> Push the button and boom, you're logged in already.
21:44:54 <oerjan> i had this idea of a program that could check your typing patterns and lock the computer if it changed...
21:45:02 <ihope> If you don't give it a password, then other processes will be able to get at it.
21:45:21 <ihope> You want to keep things safe from other processes if not other users.
21:46:05 <SevenInchBread> I don't know of anyone who wants to be lazy about keeping something hidden.
21:46:34 <ihope> Even if being lazy has no effect on security?
21:47:00 <ihope> Now, if read permissions are implemented, you could always disable them.
21:47:09 <SevenInchBread> there's no way you can convince me that user-based permissions are of equal security to read-based password locks.
21:47:51 <SevenInchBread> ...of course... this little squabble has a fairly simple compromise. Both are possible at the same time. :P
21:48:00 <ihope> I keep forgetting why encryption is more secure than user-based stuff...
21:48:41 <ihope> I didn't say passwords.
21:48:57 <SevenInchBread> -nodnod- I was just saying... not necessarily in opposition.
21:49:37 <ihope> My conclusion is that they're equal, since one can easily simulate the other.
21:50:00 <ihope> As long as you don't let every process read every other process's memory.
21:50:02 <oerjan> they are not equal if someone can get direct read access to your disk
21:50:03 <SevenInchBread> I see a huge difference.... but I also see the comparitive benefits and drawbacks of both.
21:50:50 <ihope> If there are user-based or process-based permissions, that doesn't stop you from encrypting everything.
21:51:15 <ihope> And the lack thereof doesn't keep you from simulating them, as long as you can supply a password.
21:51:47 <SevenInchBread> if you want to be lazily private (somehow...).. use read permissions. If you want full-blown guaranteed privacy from most humans... use password protection.
21:52:47 <oerjan> no, if you are insanely paranoid, you would encrypt your entire hard disk and insist on a 256 character passphrase. or something like that.
21:53:02 <ihope> Are you saying that everyone who uses both is insanely paranoid?
21:53:41 <SevenInchBread> well... I think it makes sense for user file permissions to be set on the file.... and process-based permissions to be set on the process (...the default permissions values being set on the executable that originated the process)
21:54:34 <ihope> So if you use both and don't have a huge secret, you're paranoid.
21:54:46 <SevenInchBread> mainly because PIDs aren't persistent... so it wouldn't make any sense to set a "PID 5 can't write on me" on a file.
21:55:56 <ihope> So we couldn't just offer read permissions and let the non-paranoids without huge secrets choose between those and encryption?
21:56:36 <ihope> I see this boiling down to "read access can be restricted" vs. "read access can't be restricted", though encryption naturally has to be taken into account.
21:57:49 <SevenInchBread> >.> I thought we decided to do both? but it seems like we're still debating for some reason...
21:58:22 <ihope> Offer them but don't force them, in other words?
21:59:05 <SevenInchBread> <SevenInchBread>I see a huge difference.... but I also see the comparitive benefits and drawbacks of both.
21:59:26 <ihope> Indeed. We'll offer them.
22:00:07 <SevenInchBread> password-protect write and execute too? Might as well have the option to use it.... even though I see them being comparatively less useful.
22:01:23 <SevenInchBread> the most complicated part of designing the filesystem, I think, will be version control.
22:02:32 <SevenInchBread> but basically I see two operations for that... reverting a file modification... or reverting a data modification.
22:02:55 <SevenInchBread> like the difference between ctime and mtime in unix... but with versioning.
22:03:41 <SevenInchBread> ...and then a way to associate names/numbers to certain snapshots.... like tags in svn.
22:15:56 <SevenInchBread> I also like the whole "filesystem macro" thing... so you could define a macro on the fs process... when the macro operation fails, the entire thing is reverted - thus making it fully atomic.
22:40:07 -!- sebbu2 has joined.
22:53:59 -!- sebbu2 has quit ("@+").
22:59:14 -!- sebbu has quit (Connection timed out).
23:21:13 -!- crathman has quit ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]").