00:00:00 --- log: started forth/03.06.14 00:32:43 --- quit: kc5tja ("[x]chat") 01:20:16 --- quit: a7r_ (Read error: 110 (Connection timed out)) 02:47:21 --- quit: fridge (Remote closed the connection) 02:58:18 --- quit: ianni (Read error: 60 (Operation timed out)) 02:58:36 --- join: ianni (ian@inpuj.net) joined #forth 06:14:43 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 06:28:47 grr...bloody smpeg 09:00:03 Hey tathi 09:19:47 Hi Robert 09:24:12 * tathi is trying to get SDL/smpeg to stop playing MPEGs with the red and blue swapped. 09:24:40 unsuccessfully :( 09:26:44 oops, lunchtime 09:30:48 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth 09:30:48 --- mode: ChanServ set +o kc5tja 10:11:54 --- quit: tathi ("leaving") 11:37:05 --- join: crc (~crc@AC929643.ipt.aol.com) joined #forth 11:38:18 --- quit: crc (Client Quit) 11:55:26 --- join: mur (jukka@baana-62-165-189-65.phnet.fi) joined #forth 12:31:13 Yay! Block storage support is almost done for FS/Forth. 12:31:29 Well, I suppose it's "done" from the point of view that it supports one and only one block buffer. :) 12:32:09 Next up: supporting four block buffers, then writing LOAD. 13:56:40 --- join: crc (~crc@AC8E4BA9.ipt.aol.com) joined #forth 14:23:25 --- join: TheBlueWizard (TheBlueWiz@pc5fdn1d.ppp.fcc.net) joined #forth 14:23:25 --- mode: ChanServ set +o TheBlueWizard 14:23:31 hiya all 14:24:09 hi tbw 14:24:43 hiya crc 14:25:38 Hi. 14:27:02 hiya Robert 14:31:29 hehe 14:56:08 re 14:58:14 hiya kc5tja 14:58:51 * kc5tja orders pizza 14:58:58 FS/Forth supports a single block in memory now. 14:59:11 * kc5tja needs to rewrite the block code to support having four blocks cached in memory though. 14:59:17 It's not nearly as easy as I thought it would be. 15:21:42 --- join: fridge (~matt@dsl-203-33-160-181.NSW.netspace.net.au) joined #forth 15:22:13 hiya fridge 15:26:31 * fridge tips his hat 15:29:24 This is bizarre. I haven't received my confirmation e-mail from Papa Johns yet... :/ 15:39:04 Heh -- just got it. And pizza is here... :) 15:39:11 --- join: thin (~thin@stu01165.cariboo.bc.ca) joined #forth 15:39:11 --- mode: ChanServ set +o thin 15:39:17 re thin 15:39:18 hiya thin 15:39:21 Where've you been? 15:39:26 heh re: pizza delivery 15:39:28 heh, i've been offline 15:39:34 I've been *boring* these poor people with the trials and tribulations of my pizza ordering experience. 15:39:42 :) 15:39:54 at least you're keeping them entertained while i'm away ;) 15:40:17 I did some minor work on the #forth site. 15:40:31 Clicking on the Forum tab brings up an apology, while .../forum doesn't exist anymore. 15:41:00 I noticed 15:41:39 the forum is at forum.forth.bespin.org now 15:41:52 that's the phpBB 15:42:25 I'm not going to be online very often for the next week or so, so I don't think I'll have the time to figure out the CMFForum 15:42:45 Yeah, I played with it for a bit, and all it did was choke on me. :( 15:43:42 well you can log into the account and go into the CMFForum directory and read the installation.. 15:43:55 the shell account 15:43:56 It appears as just an empty directory to me. 15:44:02 Oh, the shell. 15:44:06 Nahh, I don't think it's really worth it. 15:44:23 okay, well i'm going to point the forums link to the new url 15:44:38 * kc5tja nods 15:44:47 * kc5tja has been hacking on block I/O support in FS/Forth today. 15:45:18 what time is it? 3:45 or 2:45 ? 15:45:27 I have 3:47 on my clock. 15:45:29 ok 15:50:45 --- join: a7r_ (~a7r@206.72.82.135) joined #forth 15:50:53 --- nick: a7r_ -> a7r 15:50:57 hey 15:53:02 kc5tja: so what have you decided for FS/Forth with files vs blocks ? 15:53:10 hiya a7r 15:54:22 blocks 15:55:21 TheBlueWizard: what's up? 15:58:51 currently chatting with my buddy in another channel...it is a regular Saturday chat 15:59:06 I think he's about to be laid off soon... 8-P 15:59:35 burn. 15:59:52 I got called with an emergency from a client, who was trying to send a 26 meg powerpoint document, over email. 16:00:13 * TheBlueWizard shakes his head.... 16:00:14 outlook makes me want to hurt myself. 16:00:19 hehehe :) 16:00:20 nice spam-sized email 16:00:33 I spent 3 hours debugging SMTP problems w/ Outlook. 16:01:13 --- nick: TheBlueWizard -> Martha-Stweart-w 16:01:30 --- nick: Martha-Stweart-w -> TheBlueWizard 16:02:21 --- quit: thin ("byebye") 16:09:47 That was your first mistake -- 3 hours with Outlook. ;) 16:10:25 heh 16:10:36 kc5tja: can't beat the check I left with. ;> 16:10:55 I know... :) 16:10:59 I wouldn't ever deploy Windows at a client site, unless they absolutely needed it. 16:11:12 I've been pushing OpenBSD servers, and Macintoshes on the desk. 16:11:26 Interesting. 16:11:31 for the 500 bucks they spend on a day with Outlook, they could buy a Mac. 16:11:39 (added to the cost of the desktop box they bought from Dell) 16:12:58 Dell is another mistake. :D 16:13:16 Whoever your clients are, they're being sucked in hard by the advertising. 16:13:25 dude, these are run of the mill small business people. 16:13:32 yup 16:13:37 it's depressing. 16:13:55 This is the market I'm targeting actually. 16:14:23 OpenBSD is working great for my group,.. I've been trying to stay away from Linux. 16:14:41 I personally push Linux because that's what I'm familiar with. 16:14:49 it's kind of interesting explaining the difference between Linux and OBSD, now that all the business people know about Linux. 16:14:54 I've tried the various BSDs in the past, and have found them to be very difficult to use. 16:15:02 s/use/administer/ 16:15:07 really? how so? 16:15:45 The partition requirements, the lack of lots of virtual consoles (I'm sure it's configurable, but. . .), etc. 16:15:55 Just tiny things, which combined, left a really bad taste in my mouth. 16:16:12 yeah.. I can see how that would annoy. 16:16:40 the partitioning stuff makes sense, if you squint your eyes, and think like a UNIX workstation developer. 16:16:51 i.e. sidestep MBR bullshit all together. 16:17:08 I've never run into an MBR issue with Linux. 16:17:17 yeah, but how many partitions do you run? 16:17:22 7. :) 16:17:39 * TheBlueWizard is back 16:17:44 you can get away w/ extended partitions now days, but when the BSDs started, that shit was sketchy. 16:17:55 * TheBlueWizard is curious about kc5tja's disdain for Dell 16:18:00 I have DOS, Windows XP, Linux, QNX Real Time Platform, GEM (another DOS install), and BeOS. 16:18:12 oh, but those are Linux partitions. 16:18:20 I'm talking partitions devoted to your Linux install 16:18:26 s/are/aren't/ 16:18:49 like.. my OBSD installs usually have a minimum of 5 partitions 16:18:49 TheBlueWizard: In my experience, Dells have had lack-luster PCI bus implementations. Slots close to the northbridge chip work great, but gets increasingly sketchy as you move away from the chip. 16:19:22 a7r: But that's *exactly* what I'm talking about. 16:19:28 My Linux installation requires ONE partition. 16:19:35 one partition isn't a good idea. 16:19:40 I don't need the minimum of three that BSD requires. 16:19:40 for a couple reasons.. 16:19:56 a7r: I've run two ISPs off of single-partition Linux boxes, and had zero complaints. :-) 16:19:57 there's the issue of filling up the disk, hosing the machine.. there's the issue of being able to control where files can execute. 16:20:10 --- quit: mur (""Greed has shitty end" --finnish proverb") 16:20:20 OBSD gives you really great granularity for being specific about what a filesystem can and can not do. 16:20:30 Linux allocates 20% of the disk's total capacity to root "overflow" storage, so the system never gets hosed. 16:20:46 haha, it get s hosed if root is what fucked it up in the first place. ;) 16:20:50 The latter issue doesn't seem like a partition issue. 16:21:14 a7r: Then don't run your critical services as root. Any sane system administrator will tell you that much. :) 16:21:35 If you run services as root, you're seriously asking for trouble. 16:21:43 I don't, I'm talking about having a compiler flip out, and dump a 2 gig core. 16:21:53 * TheBlueWizard hmms re: kc5tja's comments...his expeiences with two Dell boxes at work (one a 486 [I maintain a DOS app for my agency; it is expected to go away in 3 months, finally] and one a 2 years old one) seem to do quite fine 16:21:57 OBSD has the least root usage of any operating system. 16:22:05 ... hands down. 16:22:17 TheBlueWizard: When I worked for Hifn, we had continual problems. These were newer boxes, Pentium-class and higher. 16:22:47 a7r: Again, if you have a need to log in as root, you don't run gcc or whatever. Root is for emergency use only. 16:23:04 kc5tja: let me paint a picture.. 16:23:41 you're doing a build, you think everything is fine.. you go to sudo make install, something fucks up, and g++ coredumps (this has happened to me compiling KDE) 16:23:55 Yet another reason not to use KDE. 16:24:12 my point is: there's a benefit to more than one partition. 16:24:19 My first question is why g++ is running during a make install operation. 16:24:19 but it's a matter of preference. 16:24:34 It has no business being there. 16:24:46 kc5tja: because for some reason it missed a dependency on the first pass, and that error didn't get caught by the make environment (like, someone stuck a -k in there or something) 16:24:53 it was bullshit 16:24:59 * kc5tja shrugs 16:25:26 All I know is that properly administering Linux to be a safe, reliable environment does not require the setup requirements that BSD does. 16:25:34 BSD doesn't take much to setup. 16:25:37 I'm not saying that BSD is a bad system. 16:25:55 it's a faster install than any Linux environment out there so far, and it comes hardened in its default state. 16:26:01 But I'm more comfortable with Linux. If I want triple partitions, I can do it. If I don't, I don't have to. 16:26:17 my little brother dave did an OBSD install for the first time, on his own, yesterday, in 10 minutes. 16:26:21 I can harden a Linux box down in about two hours of time. 16:26:26 (Debian install) 16:26:29 yeah, but you don't need to w/ OBSD. 16:27:08 And lose that two hours worth of pay? 16:27:11 OBSD does priv seperation on almost every daemon that runs, starting w/ OBSD 3.2 16:27:20 Linux does that stuff too. 16:27:29 it only started to recently. 16:27:31 The hardening I'm talking about is securing down file permissions and such. 16:27:36 No, sorry. . . :) 16:27:40 dude, trust me. 16:27:47 the priv sep I'm talking about was a recent development. 16:27:54 like OpenSSH's sshd privsep. 16:28:01 My Linux servers have been doing privilege separation at least since 8 years ago, back when I first installed my first Linux server in AxisInternet. 16:28:12 what are you defining as priv sep? 16:28:15 Define privsep then. 16:28:17 haha 16:28:57 I'm talking about setting up a really limited API for 'root level' calls, and make a completely unprived process do the grunt work of talking to the network, and only using the API to get super-user-type stuff done. 16:29:04 .. and I'm not talking about priv dropping. 16:29:04 To me, privsep is when you have a central server waiting on a socket, usually as root. When a connection comes it, the first thing it does is fork, then reduces the child process' privileges to a well-known user. 16:29:17 yeah, I'm not talking about that. 16:29:43 also, OBSD was the first OS to do systrace, allowing you to effectively chroot, on a syscall by syscall basis. 16:29:46 * kc5tja doesn't see the value in that -- that's what sockets already does. 16:30:05 the improvement is that no process with super-user access is ever talking to anyone on the outside. 16:30:23 I stand by my observation. 16:30:35 You do not need to be root to use a socket. 16:30:52 you need to be root to handle something like remote shell logins. 16:31:05 how would sshd work without some mechanism being super-user? 16:31:45 It can't. 16:31:51 yeah, that's my point. 16:31:51 It has to be able to change to the user who's logging in. 16:32:04 But if you're not super-user, then you just can't to do that. 16:32:09 privsep adds another layer of security to allow for that. 16:32:17 Unless you introduce a backdoor in the system, which is what OBSD sounds like it's doing. 16:32:28 it's not a back door, so much as an API for requesting services. 16:32:49 * kc5tja really doesn't trust it. It sounds really fishy to me 16:33:02 you should look at the code before you speculate about it, it's quite well done. 16:33:23 every OpenSSH sshd install out there ships default with it now, on Linux, OBSD, HPUX, Solaris, etc. 16:33:28 I have every right to not trust it, with or without looking at the code. 16:33:36 you're probably running it right now. :D 16:33:37 It's *trusting* it without looking at the code that gets people into trouble. 16:34:05 .. but it started w/ OBSD, and OBSD is using that technique w/ everything now: X, Apache, etc. 16:34:15 My sshd is running as root right now. 16:35:03 here's an example: 16:35:12 /usr/sbin/sshd 16:35:18 sshd: a7r [priv] (sshd) 16:35:24 sshd: a7r@ttyp1 (sshd) 16:35:30 the priv process being run as root. 16:35:35 as well as the first sshd. 16:35:44 I only have one sshd running. 16:35:51 Nobody is logged in right now. 16:35:54 * kc5tja is at console. 16:36:07 nod 16:36:34 How did you generate the above listing? 16:36:42 just ps 16:37:18 This is what I get when running ps awfux: 16:37:20 root 200 0.0 0.1 2748 172 ? S May18 0:00 /usr/sbin/sshd 16:37:20 root 23742 3.3 1.1 3064 1504 ? S 16:34 0:00 \_ /usr/sbin/sshd 16:37:20 kc5tja 23745 0.0 0.3 1360 416 pts/1 S 16:35 0:00 \_ grep sshd 16:37:30 As you can see, both instances of sshd are running as root. 16:37:35 yeah, you aren't running privsep then. 16:37:50 Now 16:37:54 How do you configure privsep? 16:38:07 How does it enforce who does and does not access root-level services? 16:38:47 the only one that can access the super-user API is sshd child depending on the provider of the service. 16:39:08 i.e. the [priv] process has root, and the non-[priv] process communicates its needs. 16:39:11 That doesn't answer my question, though. 16:39:34 yeah it does, it's a 1-to-1 process mapping. 16:39:35 What is to stop me from writing any ol' hack that takes advantage of that communication? 16:39:49 how would you do that? you'd have to get access to the communication mechanism. 16:40:08 which if you can do that, you have bigger problems than privsep issues. :) 16:40:18 See, that's my point. 16:40:21 uh. 16:40:30 we're talking basic IPC integrity here. 16:40:43 I really don't see why privsep is needed. My second sshd instance is just as protected as the first. 16:40:50 a7r: Yes, I know. 16:40:57 it's not just as protected 16:41:01 How so? 16:41:10 What can be exploited in the child that cannot be exploited in the first? 16:41:29 with non-privsep, if you buffer overflowed (or integer overflow, or whatever) you'd be doing it in a process with super-user privs. 16:42:03 which means any potential exploit gives you root. 16:42:04 So we need a semi-custom API to prevent buffer overflows, instead of investing the time to fix the core software itself. 16:42:10 no. 16:42:33 it is a stop gap in that it isn't a magic bullet, but it constrains where buffer overflows can come from, to a VERY small set. 16:43:04 ummm 16:43:04 like, for example.. let's say you need to do 3 things as root, with 37 other things you can do as a regular user. 16:43:28 why would you take the chance of running all 40 things as root, when you could setup an API to run those 3 things, through IPC 16:43:53 imagine if it's 1 thing as root, and 200 as not.. it's all a matter of ratios. 16:44:08 Because if those same services are tested and known secure for individual users, there should be little to no fear of running it as root. 16:44:20 but software has bugs. :) 16:44:25 Mine doesn't. 16:44:29 okay, whatever then. 16:44:36 when did you implement sshd last? :) 16:44:45 I take great pains to *ALWAYS* use n-variant string and buffer functions, instead of uncounted. 16:44:51 OBSd does too. 16:45:00 I take great pains to thoroughly unit test all my software. 16:45:11 they've removed str* from all their code as of the latest CVS head. 16:45:16 didnt forth.ru used to be english 16:45:18 including their kernel. 16:45:30 * kc5tja wrote a COM implementation for Amiga, Inc. a few years ago. It was delivered on time, under budget, and zero bugs. I invite you to contact Fleecy Moss, CTO of Amiga, for verification. 16:45:31 well, all of their base libraries.. and most of the application code. 16:45:49 kc5tja: 0 bugs that you know about.. did you check for all potential of integer overflow bugs? 16:46:02 a7r: Integer overflows were not possible. 16:46:20 kc5tja: okay, in your code they weren't.. but they've been used as a valid attack against a lot of software lately. 16:46:29 * TheBlueWizard didn't know there is a COM implementation for Amiga 16:46:43 kc5tja: or take for instance, all manner of formatting string bugs 16:46:52 e.g. printf(somestrIgotfromthenet); 16:46:52 TheBlueWizard: It's not as complete as Windows', and it's not shipped. But that's what they paid me for, so they got one. 16:47:05 a7r: Again, unit testing catches all those kinds of bugs. 16:47:11 You stress the software *before* you ship it. 16:47:23 ah...interesting....must be an interesting project writing COM stuff 16:47:40 TheBlueWizard: It was quite fun, actually. 16:47:53 kc5tja: I'm not going to argue with you about it anymore if that's your opinion.. I would put money on the fact that there have been more eyes on all of the OBSD source tree than on your code, and there are still problems. 16:48:09 kc5tja: I'm not going to disagree that there might be too much code for their own good, and bugs creep in that way 16:48:25 but OBSD has the best security record of any OS out there right now, and they find bugs. 16:48:59 a7r: My point is, I follow a very rigorous methodology of developing software. Unit tests provides a formal (yes, *formal*, as in mathematical proof) verification of the code. 16:49:31 Actually, OBSD's security is lack-luster compared to some of the capability-based operating systems in existance. It is a shame that capabilities are not more often used. 16:50:02 I wouldn't call it lacklaster, look at the number of OBSD installs deployed. 16:50:06 The highest rating for security I've seen in any Unix (a BSD variant) was B1. 16:50:13 I could care less. 16:50:19 I could write an OS, never use it for anything, and then declare it secure! 16:50:24 Rotary engines are worlds superior to boingers, but look how many boingers there are. 16:50:25 because there've been no breakins! :) 16:50:53 Tell me: if you have a pointer to a region of memory, you can write to it, right? 16:50:57 you're taking my statement the opposite direction than the way I meant it.. I'm saying capability OSes haven't been used enough 'in-the-wild' to say they're any better than OBSD as far as security. 16:51:03 a7r: um... don't confuse the number of installations with security...c.f. Windows :) 16:51:04 If you *don't* have a pointer to memory, then you cannot write to it. 16:51:09 That's the principle of capability-based systems. 16:51:17 Don't trust the code? Don't give it references to sensitive info. 16:51:21 And it works amazingly well. 16:51:25 No ACLs, no nothing. 16:51:45 what OSes do you know if, that are used en masse, that support that, and have good security records? 16:51:51 KeyKOS 16:51:53 hahah 16:52:07 KeyKOS? 16:52:13 I love KeyKOS' ideas, and EROS, but that shit is not used anywhere. 16:52:24 that's exactly the type of example I'm talking about. 16:52:32 Well, if you're going to be close-minded about it, and so violently pro-BSD that all other alternatives are, by default, inferior, then I see no reason to continue this conversation. 16:52:38 what? 16:52:48 I already explained: whether it's used or not is immaterial. 16:53:07 The fact is, capability-systems *ARE* *KNOWN* to be more secure than Unix-style security. 16:53:14 Yet, they're not used. 16:53:15 Actually, OBSD's security is lack-luster compared to some of the capability-based operating systems in existance. It is a shame that capabilities are not more often used. 16:53:28 you're calling OBSD's security lack luster, and then comparing it to OSes that aren't deployed for real work. 16:53:32 which isn't fair. 16:53:39 KeyKOS was very much so deployed. 16:53:42 where? 16:53:48 It ran Tymnet, on which the initial Internet was frigging built. 16:54:05 But, whatever. 16:54:10 I give up. 16:55:14 I'm not trying to get in your face about it, but I'm not going to back up my tools as being better than what's out there, and provide statements that back up my claims. 16:55:28 er not going to not 16:55:41 I'm not pro-BSD in all cases.. OBSD doesn't do SMP. 16:55:46 it doesn't do DRI 16:56:00 it doesn't have in-kernel support for live video. 16:56:05 it doesn't support Firewire. 16:56:20 Then how can we ever discuss alternatives if 99% of the alternatives were never deployed, and therefore, are not valid? 16:56:32 I'm not saying you can't build a better mouse trap. 16:57:03 That's very much how I'm interpreting it. 16:57:40 that's not what I meant at all. how could I be asking you about doing routing w/ Forth code, and then think that OBSD is the be all end all? :) 16:58:38 Well, here's the deal: my Dolphin OS, which tbw probably remembers me developing from a few years back, is going to be capability based. 16:58:44 And it'll be open source, and freely distributed. 16:58:51 werd, I'd like to check it out. 16:59:06 I will even openly invite people to try and break it. 16:59:29 I looked at EROS for a while, but I didn't like the way their development was progress from academic to reality, and I don't have time to participate. 16:59:30 Because I know my capabilities as a programmer, and I'm willing to offer the challenge. 16:59:40 EROS is dead. 16:59:47 It's a useless environment that can't even self-boot. 16:59:53 self-host rather. 16:59:58 That's their first mistake. 17:00:00 * TheBlueWizard does remember kc5tja developing DolphinOS; has seen a webpage or two about it, but never saw a released version ;) 17:00:01 yup, but they were pushing it as the successor to KeyKOS. 17:00:12 which I thought would be cool. 17:00:27 TheBlueWizard: That's because none was released. It's always been a personal project of mine. But I've refined the architecture enough to warrent a public release, once code is actually written. 17:00:45 ok 17:01:00 TheBlueWizard: I didn't have any time to finish it back then, and I don't have time to finish it now. Hopefully, FS/Forth will enable me to pick the pace up a bit. 17:01:25 Also, Dolphin was originally designed around assembly and C back then. Not any more -- now it'll be an OS written in Forth. 17:01:35 werd. 17:02:01 It will also be an exokernel. 17:02:10 ah...cool 17:02:28 Which means that user-level processes have direct hardware access; the exokernel serves only to offer *protection* to resources. 17:03:21 sounds good. 17:03:31 That leaves an interesting question open too -- what is a user-level process? 17:03:50 'exokernel' sounds cool 17:04:13 oh...I have been thinking about this VGA situation...it seems you have two choices: (1) write a code to set up a temporary 16-bit code (real mode) and then drops into it and call BIOS to set up VGA mode then return back to protected mode, or (2) hack GRUB to do a VGA setup using BIOS call before switching to prot. mode 17:04:37 * kc5tja wants to investigate the possibility of running everything in ring 0 as much as possible, for performance reasions. I doubt I'll be able to pull it off, but some research in so-called no-kernels seem to imply that it's possible with careful design. 17:05:25 TheBlueWizard: If I wanted to be "politically correct" about it, yes. :) 17:06:21 heh...trying to guess the settings for non classic VGA cards is real hard.... 8-P 17:06:22 * kc5tja has considered not using grub after all, though, because of that possibility. 17:08:23 The only problem I would have with doing things that way is that the boot-code for floppy and for hard disk is completely different. 17:08:24 if I am in your shoes, I'd pick the "hack the GRUB" route 17:08:57 completely different? I find that rather hard to believe 17:09:13 With harddrives, you have to interpret the partition table. 17:09:17 Floppies do not have a partition table. 17:09:40 Also, floppies do not support logical block addressing, which means its load-loop will have to loop differently. 17:10:22 There is enough of a difference to warrent two independent boot-block programs. 17:10:34 Especially if you're trying to keep things small. 17:10:38 yes...but the MBR code's job is to load in PBR code on a hard drive...maybe I will have to look at the LILO and GRUB code (maybe cuz of that infernal 528 Mbyte limitation) 17:10:59 The MBR loads in the PBR, but jumps to the PBR code as if it was the original boot-sector. 17:11:07 yes 17:11:08 That is, it reads only one sector of code. 17:11:43 That sector has to learn where the beginning of its partition is in, and how far it extends, to be able to call INT 13h services with the correct block addresses. 17:12:14 Unfortunately, there is no communication between the MBR and PBR that I have seen, to make this easier. 17:12:16 * TheBlueWizard nods, remembering that one 17:12:23 Everything is all very static in the PC. 17:12:32 nope...AFAIK no communication at all 17:12:59 partly cuz of braindamaged BIOS / M$ design 17:13:18 One way to do this is to make two-stage boot on a floppy. Have one cylinder dedicated to the first stage, and the next N cylinders dedicated to the actual Forth image, itself multi-boot compliant. 17:13:35 This way, on a floppy, I won't need the overhead of GRUB, but on the harddrive, it'd be able to use grub just fine. 17:14:21 * TheBlueWizard nods 17:14:28 But, I don't want to hack grub, because I'd like to use a version of grub that everyone else is using too. Otherwise, it kind of defeats its utility. 17:15:02 besides, I doubt anyone would want to have multiple OSes on a floppy (high geek point, sure, but so what?) 17:15:21 Actually, I did get Linux to recognize a partition table on the floppy. :) 17:15:45 I couldn't mount them (the device driver wouldn't let me MKNODE them), but fdisk saw it, and was quite happy with it. :) 17:15:49 kc5tja: I would post a hacked version...if it proves popular enough, it might get integrated...who knows? 17:16:23 really? interesting that Linux can get tricked into seeing partitions on a floppy 17:16:48 It was the smallest harddrive I ever partitioned. :D 17:16:56 LOL 17:17:01 Of course, I had to reformat the floppy to use it normally again, but still. 17:17:09 ext2fs floppies are possible, of course. I've done that before. 17:17:41 * TheBlueWizard nods...though he hasn't played with floppies in these manners....not enough time at hand 17:18:09 It was an extreme case of sneakernet, and the requirement to preserve both file permissions and long filenames. This was back in the Linux 1.3 days. :D 17:18:43 ah...makes sense 17:18:56 Now-a-days, I use ssh and scp. :) 17:19:24 nowadays, create ram disk image and put it on a floppy...no problem 17:19:41 Well, that's basically how ColorForth kind of works. 17:19:48 hmm 17:19:58 When it boots, it just copies the first N cylinders into RAM, then starts executing code. 17:20:11 It never touches the floppy again, until you issue the SAVE command, which saves those N cylinders back. :) 17:21:03 I see...very simple...and in its own way, elegant...but it doesn't scale well, or can be set up well on a hard drive 17:21:16 Well, that depends. 17:21:44 Consider that it's effectively equivalent to an orthogonally persistent operating system, which maps the entire boot device as the computer's memory store, treating RAM only as a cache for it. 17:22:04 What's lacking is the continuous and periodic write-backs. 17:22:32 or write throughs, for that matter 17:22:47 In a harddrive environment, only the minimum of the harddrive partition and RAM size is read/written. 17:23:03 To support a larger address space, the blocks would have to be implemented as a cache again. 17:23:38 yeah...it just doesn't scale up that well (unless you're willing to add more RAM...) 17:24:05 I don't understand what you mean by scale up. 17:24:16 * kc5tja already offered how one would handle harddrives with capacities in excess of RAM 17:24:28 using traditional Forth, without CPU paging support. 17:25:35 I mean that if you have small system with a very large HD, much HD space would be wasted 17:25:53 Not if you implement the block system as a cache, instead of an image. 17:26:00 s/be wasted/go unused/ 17:26:11 ok 17:26:13 kc5tja: exactly. 17:26:29 That's why I kept repeating that point. :) 17:26:29 blocks on disk, ram as cache.. single-level store style 17:27:04 Consider: 32-bit Forth can address 2^32 blocks, each of which is 2^10 bytes in size. Total virtual addres space: 2^42. 17:27:04 :) 17:27:10 Not 64-bit, I admit, but . . . that's big. :) 17:27:19 That's something like 40TB. :) 17:27:49 Most database servers don't even have that kind of storage capacity. :-) 17:28:35 when I started reading about KeyKOS, I determined that if I ever designed an OS, it'd have a single-level store 17:29:06 a7r: You know, ColorForth is *sweet* in this respect. Magenta words are variables, and the contents of those variables are stored right in the blocks themselves. 17:29:16 So when you SAVE, and later reload, all those variables are still in the same state. 17:29:17 :) 17:29:32 yeah, that's pretty elite. 17:29:40 Granted you have to reload applications and otherwise explicitly manage memory, but you can't argue, that's *damn* convenient to have. :D 17:29:59 :) 17:30:10 * TheBlueWizard never have played with ColorForth 17:30:17 Chuck also said that he uses this occasionally when debugging background tasks: he'll start a background task, then he'll drop into the editor to watch the variables change in real-time. :) 17:30:57 Well, my Forth environment is a MachineForth environment, not a ColorForth environment. 17:31:10 So I won't have all these nifty features that pre-parsed source will bring with it. 17:31:40 But, we'll see what happens. I do intend on implementing a Color source editor for my Forth environment, but it still won't support pretokenization. 17:32:49 Besides, that kind of functionality really does require (near-)orthogonal persistence. 17:33:17 Since my block addresses can potentially change between BLOCK invocations, it can't handle saving variable contents in blocks, unless I code things explicitly. 17:33:26 : V@ n BLOCK offset + @ ; 17:33:35 : V! n BLOCK offset + ! UPDATE ; 17:33:35 etc. 17:35:09 hmm....it seems to be a case of either having to state things explicitly, or use another approach (shadowing??? I haven't even formed a thought on that :P) 17:36:19 What do you mean by shadowing? 17:37:23 I suppose I could create a pseudo-defining word to create the variables: 17:37:48 like shadowing the Forth code with comments...analogously, shadow the variable with the block variable version....I hope it is clear somehow 17:37:55 : PERSISTENT R> DUP @ SWAP CELL+ @ BLOCK + UPDATE ; 17:38:19 : V1 PERSISTENT [ 0 , 0 , REVEAL 17:38:32 : V2 PERSISTENT [ 4 , 0 , REVEAL 17:38:33 etc. 17:39:09 Hmm, unfortunately that can't be done because the physical address of the block, when loaded, will change in a cached implementation. 17:40:03 well, it is a food for thought in your project 17:40:11 have fun :) 17:40:41 Taking off? 17:41:20 no...I will be here for a bit....hmm...I might as well hop to another irc net :) 17:42:37 Heheh 17:42:55 ok...gotta zoom...I hope I don't bore you :) 17:42:59 Never. 17:43:11 bye all...and bye kc5tja :) 17:43:16 But it's good to think about things like these, because I'm still unused to a persistent system. :) 17:43:30 Even having used my Palm Pilot for so long. 17:43:30 :) 17:43:45 yeah...persistent stuff is still rather exotic stuff...but great for PDA stuff 17:43:55 I insist it can be good for PCs too. 17:44:07 *idea* 17:44:28 Perhaps this can be Forth's "killer app" for the PC -- persistent operating systems. 17:44:42 agreed...no question...imagine: fast startup, with apps still waiting for you to finish (rather than having to open files again for editing...ugh) 17:45:12 maybe...we'll see...good luck :) 17:45:30 well, bye for now 17:45:39 --- part: TheBlueWizard left #forth 17:49:01 --- quit: crc ("I was using TinyIRC! Visit http://www.tinyirc.net/ for more information.") 17:56:27 OK, back to work for me... I want to finish block support at least within an hour or two. 18:53:05 --- quit: a7r (Read error: 110 (Connection timed out)) 19:54:41 --- quit: Robert (Read error: 104 (Connection reset by peer)) 19:54:47 --- join: Robert (~snofs@h138n2fls31o965.telia.com) joined #forth 21:11:33 --- join: a7r (~a7r@206.72.82.135) joined #forth 21:14:35 wb 23:29:21 :) 23:40:14 --- join: Klaw (chuck@ip68-99-187-95.oc.oc.cox.net) joined #forth 23:59:59 --- log: ended forth/03.06.14