< 1176768217 0 :ihope!unknown@unknown.invalid QUIT :Read error: 60 (Operation timed out) < 1176770204 0 :ihope__!unknown@unknown.invalid PRIVMSG #esoteric :SevenInchBread! < 1176770243 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :http://bsmntbombdood.mooo.com/hyper4_imag.png < 1176770248 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :http://bsmntbombdood.mooo.com/hyper4_imag1_2big.png < 1176770253 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :http://bsmntbombdood.mooo.com/hyper4_imag0_2.png < 1176770256 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :super coolness < 1176770291 0 :ihope__!unknown@unknown.invalid NICK :ihope < 1176770359 0 :pikhq!n=pikhq@c-75-70-225-157.hsd1.co.comcast.net JOIN :#esoteric < 1176770829 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :!!!! < 1176770959 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Yay, we have a kernel spec thingy! < 1176771065 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :....we do? < 1176771118 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Close enough, anyway. < 1176771139 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :What you posted on AbraSophia some while ago. < 1176771233 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION thought that it failed
< 1176771341 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :yeah... basically that's the entire spec. < 1176771345 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :extremely basic for now. < 1176771357 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :if problems come up or if something was unaddressed (like hardware)... I'll just add it later. < 1176771453 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :hardware interupts will probably be handled by the kernel via an immediate context switch to a driver or something. < 1176771492 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...maybe not immediately... hardware is important, but you don't want to freeze up everything because of a slow hardware operation. < 1176771564 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :spaces handle pretty much any information about memory you could want... < 1176771689 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :....but... I have no clue how to implemetn all of this into low-level registers. < 1176771939 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :some of the system calls I'm thinking of are alloc, dealloc, context switch... and maybe some kind of interrupt/hook setting thing. < 1176772024 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...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) < 1176772786 0 :Bigcheesegs!unknown@unknown.invalid QUIT :Read error: 104 (Connection reset by peer) < 1176772822 0 :Bigcheese!n=blah@adsl-152-31-127.asm.bellsouth.net JOIN :#esoteric < 1176772851 0 :Bigcheese!unknown@unknown.invalid NICK :Bigcheesegs < 1176773578 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :bsmnt: working on a modular C bot :D < 1176773595 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :oh boy < 1176773646 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :it's currently on #botpark < 1176773663 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :it's called BrassMonkey but it has the UnBot nick to save reregistration < 1176773683 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric : $reload all < 1176773683 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric : Reloading ALL modules < 1176773683 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :* UnBot inserts shells and cocks < 1176773811 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :j00 r teh clevar! < 1176773855 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :ihope, swap file? or swap partition? < 1176773863 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :file sounds more painless to me. < 1176773871 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :but I might be wrong. < 1176773998 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :no < 1176774002 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :files get fragmented < 1176774412 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :partitions don't? < 1176774422 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :no... < 1176774430 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :partitions are continguous on the disk < 1176774475 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :hmmm... files aren;t though? I thought all the data in a file was right close together. < 1176774487 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :no < 1176774498 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :Although some filesystems try to avoid fragmentation. < 1176774638 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :but wait... isn't fragmentation only a problem when you read the data sequentially? < 1176774659 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :And when you try to write more to a file. . . (that's how fragmentation occurs) < 1176774729 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :no no, I know the -cause-... but does it really matter that much if you're not reading the data sequentially? < 1176774753 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :Not really. < 1176774759 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :yeah... will probably go with a swap partition though... simply because it avoids fragmentation altogether I guess. < 1176774771 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :Unfortunately, sequential data reads is rather common. < 1176774775 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :are, even. < 1176774785 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :>.> on a swap file? < 1176774791 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :No, in general. < 1176774815 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :I imagine a swap file being read at random chunks. < 1176774824 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :small sequential strips < 1176774828 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :SevenInchBread: doobey foober, dlong dop < 1176774834 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric ::) < 1176774852 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :SevenInchBread: If you've got large programs, make that large sequential strips. < 1176774866 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :ah < 1176774898 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :yeah okay... I'm out of arguments... for something I don't really think would make sense. < 1176774902 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :I recommend that you try using a filesystem which avoids fragmentation. . . < 1176774919 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :In addition to a swap partition. < 1176774999 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :(most Unix filesystems. ;)) < 1176775217 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION shall make his own... just for the hell of it.
< 1176775242 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :Why not use ext2? < 1176775257 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :....because I'd like to try making my own < 1176775273 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :*shrug* < 1176775282 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :sheesh, if I wanted UNIX I'd just use it. < 1176775298 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :I'll port ext2 sometime later, so you can get a decent quality filesystem. < 1176775330 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :. . . If I( care enough to. < 1176775331 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :sure... if all goes right the filesystem wouldn't be hard at all to change. < 1176775359 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :....still haven't written a single program for this OS though... I need to practice assembly/C < 1176775522 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176775558 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :the elphant-sized files... your images, audio, video stuff. < 1176775579 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :will usually be close together in a directory tree.... usually. I have no empircal evidence to back that up. < 1176775588 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :but I assume people put there music together in one place. < 1176775793 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...you could even get fancy with it and have the OS "remember" how files tend to be accessed. < 1176775816 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :so you have different behaviors for different files. < 1176775894 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION doesn't necessarily care about simple.
< 1176776095 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Oh, also... < 1176776123 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :How about system calls that don't require a magic hat are called "hatless" and those that do require one are called "hatful"? < 1176776146 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Unless you have a compelling argument against it, that's what we'll do, okay? :-) < 1176776317 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :? < 1176776368 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :I have three hatless system calls here... < 1176776383 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :And two of them may be unnecessary. < 1176776458 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Actually, every system call I've put down so far except one are probably unnecessary. < 1176776469 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Maybe two are necessary. < 1176776595 0 :lament!unknown@unknown.invalid PRIVMSG #esoteric :the only needed system calls are 's', 'k', and 'i' < 1176776600 0 :lament!unknown@unknown.invalid PRIVMSG #esoteric :and 'i' is just for optimization. < 1176776613 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric ::-) < 1176776621 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Don't you want a ` system call as well? < 1176776641 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :hehe :D < 1176776655 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Really, all you need is * and i... or 0 and 1. < 1176776658 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :though SII(SII) causes an infinite loop < 1176776664 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Depends on whether you want your kernel to be Iota or Jot. < 1176776700 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :I prefer the system call "Lambda". < 1176776710 0 :Sgeo!n=Sgeo@ool-18bf68ca.dyn.optonline.net JOIN :#esoteric < 1176776930 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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,. < 1176776960 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :SevenInchBread: what are you saying? < 1176776978 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176776991 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :it serves as an abstraction barrier of sorts. < 1176776993 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :How will processes communicate? < 1176777004 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :>.> messages? < 1176777012 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :And sending a message isn't a system call? < 1176777038 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :.....got me there. < 1176777051 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :okay.... hatful and hatless... :) < 1176777059 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION didn't think about that.
< 1176777105 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :addd that to the spec... with a brief explaination of why. < 1176777142 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :so far the only hatless one is the message passing... but I'm sure there are a few more. < 1176777181 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :what is a hat? < 1176777196 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176777219 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :it's a prviledge flag on processes that determines whether or not they can use certain system calls. < 1176777234 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :originally it was ALL system calls... but I forgot that certain calls are pretty much necessary. < 1176777252 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :the full term is "magic hat"... simply because it sounds cool. < 1176777339 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :ihope, and I think the filesystem should recognize file types... like osx does now. < 1176777377 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176777451 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176777567 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...images, on the other hand... are generally read, decompressed to bitmap, edited, and then saved back all in one huge write. < 1176777923 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :....text will change size and byte value often... but the reads and writes will be along the same pace as image writes. < 1176778075 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :http://en.wikipedia.org/wiki/Delayed_allocation <-- this is an interesting technique < 1176782776 0 :calamari!unknown@unknown.invalid QUIT :"Leaving" < 1176782836 0 :pikhq!unknown@unknown.invalid QUIT :Read error: 54 (Connection reset by peer) < 1176782866 0 :pikhq!n=pikhq@c-75-70-225-157.hsd1.co.comcast.net JOIN :#esoteric < 1176782892 0 :ShadowHntr!i=sentinel@wikipedia/Shadowhntr JOIN :#esoteric < 1176784329 0 :SevenInchBread!unknown@unknown.invalid QUIT :Read error: 113 (No route to host) < 1176790212 0 :Sgeo!unknown@unknown.invalid QUIT :Success < 1176790462 0 :pikhq_!n=pikhq@c-75-70-225-157.hsd1.co.comcast.net JOIN :#esoteric < 1176790607 0 :pikhq!unknown@unknown.invalid QUIT :Read error: 113 (No route to host) < 1176791857 0 :pikhq_!unknown@unknown.invalid QUIT :Read error: 110 (Connection timed out) < 1176792016 0 :ShadowHntr!unknown@unknown.invalid QUIT :"End of line." < 1176796799 0 :clog!unknown@unknown.invalid QUIT :ended < 1176796800 0 :clog!unknown@unknown.invalid JOIN :#esoteric < 1176805031 0 :GreaseMonkey!unknown@unknown.invalid PRIVMSG #esoteric :gonna sleep now, gnight < 1176805253 0 :GreaseMonkey!unknown@unknown.invalid QUIT :"feel the power of a dynamic bot: http://rafb.net/p/xUFMl288.html | line buffer code: http://rafb.net/p/2JIiTz98.html" < 1176806168 0 :nazgjunk!unknown@unknown.invalid QUIT :Read error: 104 (Connection reset by peer) < 1176806198 0 :nazgjunk!n=htitan@wikipedia/Nazgjunk JOIN :#esoteric < 1176815457 0 :Bacta!n=t@203-173-137-174.bliink.ihug.co.nz JOIN :#esoteric < 1176815480 0 :Bacta!unknown@unknown.invalid PRIVMSG #esoteric :Hi I'm developing an OS in Brainfuck ... any advice? < 1176815534 0 :Bacta!unknown@unknown.invalid PART #esoteric :? < 1176815767 0 :pikhq!n=pikhq@c-75-70-172-117.hsd1.co.comcast.net JOIN :#esoteric < 1176817739 0 :oerjan!n=oerjan@hagbart.nvg.ntnu.no JOIN :#esoteric < 1176820699 0 :jix!n=jix@dyndsl-080-228-183-221.ewe-ip-backbone.de JOIN :#esoteric < 1176820730 0 :bsmntbombdood!unknown@unknown.invalid PRIVMSG #esoteric :ha, #esoteric trolls < 1176825261 0 :ihope__!n=ihope@c-71-205-100-59.hsd1.mi.comcast.net JOIN :#esoteric < 1176825322 0 :ihope___!n=ihope@c-71-205-100-59.hsd1.mi.comcast.net JOIN :#esoteric < 1176826203 0 :ihope!unknown@unknown.invalid QUIT :Success < 1176826367 0 :ihope__!unknown@unknown.invalid QUIT :Connection timed out < 1176828276 0 :sebbu!n=sebbu@ADijon-152-1-22-119.w83-194.abo.wanadoo.fr JOIN :#esoteric < 1176828859 0 :nazgjunk!unknown@unknown.invalid QUIT :Read error: 104 (Connection reset by peer) < 1176828893 0 :nazgjunk!n=htitan@wikipedia/Nazgjunk JOIN :#esoteric < 1176829562 0 :RodgerTheGreat!unknown@unknown.invalid QUIT : < 1176830327 0 :crathman!n=chatzill@69.15.198.171 JOIN :#esoteric < 1176832103 0 :pikhq!unknown@unknown.invalid QUIT :Read error: 60 (Operation timed out) < 1176832967 0 :oerjan!unknown@unknown.invalid QUIT :"Later" < 1176834390 0 :Izzy7!unknown@unknown.invalid QUIT :Read error: 101 (Network is unreachable) < 1176840109 0 :alex89ru!n=opinion@p5B12AE1B.dip0.t-ipconnect.de JOIN :#esoteric < 1176840208 0 :alex89ru!unknown@unknown.invalid PART #esoteric :? < 1176840393 0 :atrapado!i=opened@153.Red-81-47-1.staticIP.rima-tde.net JOIN :#esoteric < 1176840448 0 :Izzy7!i=senji@cleopatra.thy.me.uk JOIN :#esoteric < 1176842529 0 :oerjan!n=oerjan@hagbart.nvg.ntnu.no JOIN :#esoteric < 1176843493 0 :Bigcheesegs!unknown@unknown.invalid QUIT :"isoGames - The New Leader In Online Spectator Sports - /server -m irc.isoGames.com" < 1176843767 0 :SevenInchBread!n=CakeProp@wikipedia/The-Prophet-Wizard-of-the-Crayon-Cake JOIN :#esoteric < 1176844046 0 :ihope___!unknown@unknown.invalid NICK :ihope < 1176844420 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :ihope, there won't be a read permissions for files. All files are readable by anyone. < 1176844476 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Why? < 1176844540 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :....why not? how can you have something that's public domain and read-protected? < 1176844556 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION smacks SevenInchBread with a hammer.
< 1176844586 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :NEXT! < 1176844596 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :and reading can't corrupt the data in the file... so it's a pretty safe operation compared to writing and executing. < 1176844681 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176844690 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :passwords? < 1176844723 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :anti-chinese government propaganga? < 1176844724 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :passwords sounds good. :) < 1176844731 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :*propaganda? < 1176844753 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :oerjan, ...that's actually a good point. I guess privacy would be nice. < 1176844785 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :i guess you _could_ get away from it with a good encryption system. < 1176844796 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :Does linux have password protection built into its filesystem? < 1176844804 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :which might actually be safer in case someone stole your harddisk. hm... < 1176844815 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :oerjan, steganograpic file system. < 1176844852 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :linux has ownership protection, and various ways of authorizing logins. < 1176844854 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :well... not a stego filesystem... but... a filesystem that lets you hide the existence of something. < 1176844860 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :rather than simply garbling it up. < 1176844881 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :I think password protection would be a good addition to the filesystem. (haha... talk about a change of heart) < 1176844891 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :i've never really looked into encryption filesystems other than knowing they exist. < 1176844904 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :steganography is really interesting. < 1176844919 0 :jix!unknown@unknown.invalid QUIT :"Bitte waehlen Sie eine Beerdigungnachricht" < 1176844941 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :actually passwords are pretty weak. i am almost thinking having _just_ encryption and no read permissions is an improvement. < 1176844970 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176844984 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :yeah. < 1176845025 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176845071 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :passwords -> passphrases for encryption < 1176845088 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :-nodnod- but they're succeptable to brute-force searches. < 1176845093 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :which machines can easily do. < 1176845102 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :they should be long passphrases. < 1176845106 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :it is however... pretty effective against people. < 1176845136 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :heh... my universal password for everything consists of five letters... < 1176845151 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :there... you now have pretty much have access to everything I do. < 1176845214 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :well mine are about 8-10, but i am somehow assuming the important ones are not available for brute-force search. < 1176845289 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :some global mode type things would be useful too... so you know how to optimize. < 1176845306 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :hm? < 1176845326 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :like "keep this file compressed"? < 1176845354 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176845378 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...but it's a pain in the ass to do the check every time. < 1176845381 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :unless you just have to. < 1176845431 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...but, that may be too general. < 1176845443 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :since what "low memory" is... varies from application to application. < 1176845453 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :well, you could have a process that could register requests to know if memory went low, with limits given by the requesting process < 1176845475 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :-nod- yeah, include it into some sort of "stats" process... < 1176845507 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION wants to add a lot of nifty gadgets... even at the expense of simplicity.
< 1176845521 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :a simple interface is important... a simple implementation not so much. < 1176845611 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :I'd say read permissions are essential. < 1176845638 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :for what? I've never seen a use for them myself. < 1176845644 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :why not go with a full capability system? It seems to me they are all the rage over at Lambda the Ultimate < 1176845695 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :eh... doesn't sound fun. < 1176845771 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :For protecting data. < 1176845779 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Passwords, etc... < 1176845788 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Anything that needs protection. < 1176845798 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :of course it goes with the Principle of Least Authority, so it's fairly heavy security < 1176845819 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :well... the only reason I would use a read permission is privacy... HOWEVER. < 1176845824 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :read permission offers no protection. < 1176845840 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :No protection? < 1176845843 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :it doesn't protect the file.... write permissions protect a file. You can't hurt a file by looking at it. < 1176845880 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Privacy isn't endangered by changing a file. < 1176845897 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :-nod- I know. two different purposes. < 1176845918 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :read - privacy. write - protection. execute - non-fuck-up-your-computer-acy < 1176845922 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :If you want to store passwords, you need read permissions. < 1176845943 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :not in the typical unix sense of read permission. < 1176845948 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :No? < 1176845961 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :What do you mean? < 1176845970 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :it is, linguistically speaking, a permission to read. but it's not a "unix read permission". < 1176846003 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :passwords, methinks... are also easier to manage than read permissions for privacy. < 1176846021 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :encryption can do most of the read protection, but you need somewhere to store the system's initial codes... < 1176846027 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :now instead of having to add a new user the read permission... you can just tell her the password. < 1176846046 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :iniital codes? whatcha mean? < 1176846051 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :What if she doesn't want to remember the password? < 1176846057 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :.......... < 1176846058 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Or type it in all the time? < 1176846063 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Or something? < 1176846067 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :.....hahahaha < 1176846079 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :"AAAARGH REMEMBERING A PASSWORD - GOD DAMNIT" < 1176846086 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :I guess all you need is one password. < 1176846090 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :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 < 1176846103 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :I would also say a password is more secure from people than a user permission. < 1176846111 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :How? < 1176846112 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :if you leave your computer... someone can't sneak up and look at the file. < 1176846127 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :That's why operating systems have a "lock" feature. < 1176846134 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :not from computers though... most passwords can be cracked with a brute-force search. ...for that you use full-blown encryption of the data. < 1176846145 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :ihope, not everyone does that. < 1176846179 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :passwords ensure that the password is entered each time.... or (optionally) once in a certain span of time. < 1176846202 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176846221 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :I guess theoretically you only need one password. < 1176846227 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :seriously, no one wants to enter passwords all the time. < 1176846232 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :people rarely make something private out of convience. < 1176846235 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :they'd like to keep it that way. < 1176846271 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Now, if you're the only one with access to a computer, passwords aren't needed at all. < 1176846282 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :if you don't want to type in a password... then don't give it a password. < 1176846285 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :right... < 1176846288 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Push the button and boom, you're logged in already. < 1176846294 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :i had this idea of a program that could check your typing patterns and lock the computer if it changed... < 1176846299 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION is on a one-man computer
< 1176846302 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :If you don't give it a password, then other processes will be able to get at it. < 1176846321 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :You want to keep things safe from other processes if not other users. < 1176846344 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :right... so? < 1176846365 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :I don't know of anyone who wants to be lazy about keeping something hidden. < 1176846394 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Even if being lazy has no effect on security? < 1176846420 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Now, if read permissions are implemented, you could always disable them. < 1176846429 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :there's no way you can convince me that user-based permissions are of equal security to read-based password locks. < 1176846471 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...of course... this little squabble has a fairly simple compromise. Both are possible at the same time. :P < 1176846480 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :I keep forgetting why encryption is more secure than user-based stuff... < 1176846511 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :passwords are by no means crytographically secure. < 1176846521 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :I didn't say passwords. < 1176846537 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :-nodnod- I was just saying... not necessarily in opposition. < 1176846552 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :er... I mean... it wasn't a rebuttal. < 1176846577 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :My conclusion is that they're equal, since one can easily simulate the other. < 1176846600 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :As long as you don't let every process read every other process's memory. < 1176846602 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :they are not equal if someone can get direct read access to your disk < 1176846603 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :I see a huge difference.... but I also see the comparitive benefits and drawbacks of both. < 1176846606 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :so.... I'm all for both. < 1176846650 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :If there are user-based or process-based permissions, that doesn't stop you from encrypting everything. < 1176846675 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :And the lack thereof doesn't keep you from simulating them, as long as you can supply a password. < 1176846707 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :if you want to be lazily private (somehow...).. use read permissions. If you want full-blown guaranteed privacy from most humans... use password protection. < 1176846713 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :if you're insanely paranoid, use both. < 1176846767 0 :oerjan!unknown@unknown.invalid PRIVMSG #esoteric :no, if you are insanely paranoid, you would encrypt your entire hard disk and insist on a 256 character passphrase. or something like that. < 1176846782 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Are you saying that everyone who uses both is insanely paranoid? < 1176846821 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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) < 1176846835 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :no... either paranoid... or has a huge secret. < 1176846874 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :So if you use both and don't have a huge secret, you're paranoid. < 1176846886 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176846956 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :So we couldn't just offer read permissions and let the non-paranoids without huge secrets choose between those and encryption? < 1176846996 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176847062 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Do you disagree? < 1176847069 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :>.> I thought we decided to do both? but it seems like we're still debating for some reason... < 1176847074 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :<.< < 1176847078 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Do both? < 1176847102 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Offer them but don't force them, in other words? < 1176847122 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :If so, I'm happy. < 1176847122 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :of course. I never even mentioned forcing them. O.o < 1176847145 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric : I see a huge difference.... but I also see the comparitive benefits and drawbacks of both. < 1176847146 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :so.... I'm all for both. < 1176847166 0 :ihope!unknown@unknown.invalid PRIVMSG #esoteric :Indeed. We'll offer them. < 1176847207 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :password-protect write and execute too? Might as well have the option to use it.... even though I see them being comparatively less useful. < 1176847283 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :the most complicated part of designing the filesystem, I think, will be version control. < 1176847352 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :but basically I see two operations for that... reverting a file modification... or reverting a data modification. < 1176847375 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :like the difference between ctime and mtime in unix... but with versioning. < 1176847421 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...and then a way to associate names/numbers to certain snapshots.... like tags in svn. < 1176847435 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :python.exe@2.1 < 1176848156 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :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. < 1176848449 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :fs defmacro (move, (x, y), copy (%x, %y); del (%x)) < 1176848454 0 :SevenInchBread!unknown@unknown.invalid PRIVMSG #esoteric :...or something. < 1176849607 0 :sebbu2!n=sebbu@ADijon-152-1-71-113.w83-203.abo.wanadoo.fr JOIN :#esoteric < 1176850439 0 :sebbu2!unknown@unknown.invalid QUIT :"@+" < 1176850754 0 :sebbu!unknown@unknown.invalid QUIT :Connection timed out < 1176852073 0 :crathman!unknown@unknown.invalid QUIT :"ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]"