00:00:00 --- log: started forth/18.07.16 00:27:43 --- quit: dys (Ping timeout: 264 seconds) 00:39:39 --- quit: dave9 (Quit: one love) 01:19:19 --- quit: pierpal (Ping timeout: 240 seconds) 01:23:33 --- nick: koisoke_ -> koisoke 01:23:49 --- mode: ChanServ set -o koisoke 01:48:29 --- quit: proteus-guy (Remote host closed the connection) 02:15:48 --- join: proteus-guy (~proteus-g@cm-134-196-84-223.revip18.asianet.co.th) joined #forth 02:59:20 --- quit: hegemoOn (Remote host closed the connection) 03:22:38 Zarutian: UEFI caters to everybody's bloaty feature requirements 03:23:20 Like SecureBoot and BumGapeSubsystem and GUI so lusers can overclock and blow up their CPUs 03:24:10 OpenBoot should return on RISC-V. Forthers should try and get in quick while there's a new uprising of Free Software and Open Source. 03:47:57 --- quit: wa5qjh (Remote host closed the connection) 03:56:34 The main impression I've had of UEFI is that it makes it more hoop-jumpy to get Linux installed on a box. 03:56:55 I always figured it was a Microsoft ploy - making it as hard as they legally could to take Windows off of a box. 04:00:19 KipIngram: aye, that's been my default position on UEFI too, but I think there are two other, related motivations. 04:01:58 keeping to the theme of less-than-helpful motivations is the idea that "content" providers want locked-down systems in support of DRM 04:02:32 that it makes Linux installation more hoop-jumpy becomes more a side-effect, in that light. 04:03:38 the other part is that is the more above-board aspect of it really improving security. On this point I try to read mjg59's stuff with an open mind, though I often get lost in the jargon. 04:04:37 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:04:44 I'm all for a BIOS password. But a machine's *owner* should always be able to fully control it, and in as "user easy" way as possible. 04:05:13 in terms of broad principles, I have no argument with that. 04:05:59 I fully support the idea that no one *other* than the owner should be able to "redirect" a machine. 04:06:34 I tend to get tripped up in these discussions around the idea of what "easy" means. 04:07:27 given that for an increasing number of applications, the "user" isn't even aware that a computer is involved, let alone have working knowledge of anything even as ... traditional, let's say ... as a BIOS password. 04:07:41 I think a BIOS password that lets us lock and unlock the boot block should be adequate. 04:08:07 which is all well and good to say, but how do you unlock the BIOS password of a device that doesn't even have a physical keyboard? 04:08:49 Of course the "boot block" needs to be big enough to support secure methods. 04:09:18 Checking hash on what else is loaded etc. 04:12:09 Trying to learn Factor 04:12:30 the documentation is absolutely abysmal unless you're already a Factorer 04:16:22 --- join: dave9 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 04:16:36 Someone had the awful idea of taking out "emit" 04:20:18 Trusted Computing is actually really useful if you are the one in charge and not Microsoft. 04:21:51 Putting your cryptographic keys in a curtained memory area for instance https://github.com/rqou/tpm2-luks 04:33:56 TC and capabilities would have the potential to move us beyond whac-a-mole pretend security if we go at it from a free/open source perspective. If we don't, I guess we'll only get the proprietary perspective. 04:47:28 I don't see what you mean by whack-a-mole "pretend" security 04:59:15 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 05:07:42 --- quit: pierpal (Quit: Poof) 05:08:00 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 05:50:21 --- quit: pierpal (Quit: Poof) 05:50:38 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 06:10:53 To me the whole security question comes down to one thing, at that "base" level: don't execute stuff you don't mean to execute. 06:11:32 And I think hash-validated loading of the OS is adequate to achieve that. 06:11:47 I don't want to complicate it any more than it has to be complicated. 06:12:10 More sophisticated stuff should come at a higher level (i.e., in the operating system). The boot loader should stay SIMPLE. 06:13:41 I think it could be as simple as having a hash field in the BIOS we can fill in, and requiring that that "first loaded stuff" match that hash. 06:14:07 Sort of like that security key that used to be printed on Windows DVDs. 06:14:29 Though I know (I think) that that wasn't necessarily a hash. 07:02:31 --- quit: dave9 (Quit: one love) 08:36:45 --- quit: pierpal (Quit: Poof) 08:37:02 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 08:57:20 --- quit: pierpal (Read error: Connection reset by peer) 08:57:40 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 10:19:10 Found this: http://www.ultratechnology.com/forth.htm 10:19:50 Any suggestions on a good learning resource? I have started a few books/tutorials but never had time to get very deep. 10:26:11 probably worth reading, as jeff fox worked closely with chuck moore and had a lot of forthy knowledge, but tbh I gave up on jeff fox stuff. he's not a very good writer, imo, and I found his explanations of things to be very vague and leave the reader with a lot of questions unanswered as he takes several paragraphs to explain in excruciating detail stuff that should have been givens 10:26:43 for me, brad rodriguez's articles were probably more helpful than anything else I've read so far 10:27:48 rodriguez writes very technically. fox writes very religiously (which I've seen a good bit of in the forth community) 10:28:06 (e.g., "we do things this way because that's how it's supposed to be done" and very little technical explanation) 10:28:54 zy]x[yz: brad r. Then. Will check it out! 10:29:20 http://www.bradrodriguez.com/papers/moving1.htm 10:36:56 zy]x[yz: yep. got it! :) Thanks! I have started this one before and didn't mind it too much: https://www.forth.com/starting-forth/ 10:40:21 --- join: dys (~dys@tmo-121-14.customers.d1-online.com) joined #forth 11:03:40 My favorite two Forth books are Thinking Forth by Brodie and Forth Fundamentals (volume 1) by McCabe. 11:03:59 The first hits the "using Forth" front, and the second the "how does Forth work" front. 11:15:26 --- join: DocPlatypus (~skquinn@c-76-30-77-136.hsd1.tx.comcast.net) joined #forth 11:28:02 --- join: gravicappa (~gravicapp@h178-129-64-196.dyn.bashtel.ru) joined #forth 11:46:50 KipIngram: thanks! 11:58:40 --- quit: pierpal (Quit: Poof) 11:58:58 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 12:03:02 You bet. Thinking Forth is available online, as a pdf. 12:05:56 --- quit: Labu (Quit: WeeChat 2.0.1) 12:06:08 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 12:06:56 --- quit: pierpal (Quit: Poof) 12:07:13 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 12:10:19 --- quit: gravicappa (Remote host closed the connection) 12:21:50 --- join: johnnymacs (~user@2603:3023:a22:bb00:d131:a88a:52ab:f1df) joined #forth 12:22:03 An interesting puzzle: should my forth kernel have stack bounds 12:22:21 My gut says no. Someone who wants it 'easy' can simulate their own stack bounds 12:24:30 what's interesting or puzzling about that? 12:25:16 Well I am trying to decide if it is insanity to put no bounds on the stack or if I should trust the user to add their own stack bounds 12:25:35 For for someone to add the stack bounds for them in a library 12:25:52 no I understand the question 12:26:07 Perhaps I just haven't thought about it as much as you have. 12:26:08 A common approach is to check the stacks in the outer interpreter. 12:26:24 But not as you execute compiled words. 12:27:28 What I was thinking was in my byte interpreter which is written in c I could have one op code cause a loop to be triggered which loops over the exact same machine switch only with stack checking added and that same op code will terminate the loop 12:28:43 It would double the number of machine instructions in the kernel but it would eliminate a hook 12:37:49 fm 12:37:52 Ooops. 12:37:54 Sorry. 12:43:17 My heart and brain tell me no stack checking and that is what I'm going to do. If they want to have code that appears to be stack checked that is not they need to handle that somehow at compile time and then compile to non stack checked code. 13:14:28 Well, having the check in the outer interpreter costs you very little. 13:14:51 That loop is searching the dictionary for every word that it then executes, and the usual practie is to run a word called ?STACKS immediately after executing the word. 13:15:12 But the executed word might run a lot of stuff - and no checking is generally done within that executino process. 13:15:29 If you put stack checking in your INNER interpreter you'll torpedo your system's performance. 13:15:57 But I suspect checking in the outer interpreter would have way under 1% impact. 13:16:07 You won't notice it. 13:49:19 --- quit: X-Scale (Ping timeout: 240 seconds) 13:54:43 --- quit: johnnymacs (Ping timeout: 240 seconds) 14:07:47 --- join: pierpa (57043661@gateway/web/freenode/ip.87.4.54.97) joined #forth 14:14:17 --- join: wa5qjh (~quassel@175.158.225.219) joined #forth 14:14:17 --- quit: wa5qjh (Changing host) 14:14:17 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 14:17:14 --- join: X-Scale (~ARM@83.223.227.94) joined #forth 14:23:34 --- quit: pierpal (Quit: Poof) 14:23:56 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 15:19:54 --- quit: Zarutian (Read error: Connection reset by peer) 15:20:24 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 15:35:45 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 15:38:13 --- join: wa5qjh (~quassel@175.158.225.219) joined #forth 15:38:14 --- quit: wa5qjh (Changing host) 15:38:14 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 15:49:46 --- quit: dys (Ping timeout: 256 seconds) 17:18:17 --- quit: pierpal (Ping timeout: 256 seconds) 17:18:43 --- quit: fiddlerwoaroof (Read error: Connection reset by peer) 17:22:17 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 17:30:44 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 17:41:59 --- quit: jedb (Ping timeout: 248 seconds) 17:45:45 --- join: jedb (~jedb@199.66.90.209) joined #forth 18:43:17 --- quit: dddddd (Ping timeout: 256 seconds) 18:48:12 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 19:15:46 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 19:27:23 --- quit: pierpa (Quit: Page closed) 19:31:56 --- quit: dddddd (Remote host closed the connection) 19:34:19 --- quit: cheater (Ping timeout: 264 seconds) 19:36:00 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 19:37:36 --- join: johnnymacs (~user@2603:3023:a22:bb00:e3aa:5f21:a2ad:8434) joined #forth 19:49:10 --- quit: pierpal (Quit: Poof) 19:49:27 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 19:56:48 --- quit: pierpal (Read error: Connection reset by peer) 20:13:24 --- quit: fiddlerwoaroof (Read error: Connection reset by peer) 20:13:48 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 20:17:51 --- join: fiddlerwoaroof (~fiddlerwo@unaffiliated/fiddlerwoaroof) joined #forth 20:31:33 KipIngram: what I am saying is that I can have two copies of the inner interpreter in a finite state machine swtich style machine. One copy has no checks but has an OP code which causes another version of itself to be run which has stack checks in addition to a check to see if you want to re-enter the version of the machine with no checks 20:35:36 Yes, I understand. I've thought about something like that for profiling. 20:36:13 If you jump to your inner interpreter from each primitive (as opposed to having it inline) then you can re-vector it, and then there's no decision overhead. 20:36:17 That's what I'm planning to do. 20:36:27 OH shi 20:36:44 Just temporarily overwrite the first few bytes of your inner interpreter with a jump to the enhanced one. 20:37:10 Restore the original bytes when you want to turn it off. 20:37:13 jump works perfectly for my machine yes 20:37:19 I am writing mine in c 20:37:28 I dont have the chops currently to port it to asm 20:37:43 I did one in C a couple of years ago; doing the asm one now. 20:37:55 --- quit: pierpal (Ping timeout: 265 seconds) 20:37:57 It's not as hard as you might think; bet you could pick it up. 20:38:42 If I make mine small enough maybe I can reverse engineer the asm that gcc produces 20:38:57 My C one uses gcc, and uses gcc's "pointer to label" extension so that it actually works very much like an assembly implementation would. 20:39:16 The main shortcoming is that the important things I'd normally keep in registers (stack pointers, ip, etc.) are in variables. 20:39:28 Maybe the compiler optimizes some of it into regs, but I don't know for sure. 20:40:24 I don't understand enough about it. How can so many programs share the same registers? I thought there were only like 16 registers on x86 20:43:10 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 20:46:03 When the operating system switches between processes it saves the ending process's registers and loads the starting process's registers. 20:46:27 It does exactly what you'd do when you switch tasks - put these papers in their folder, open the next folder and spread out its papers. 20:46:41 It all has to be painfully explicit at the assembly level. 20:47:23 In a good Forth you devote a few registers to certain very important things, and they never hold anything other than that. 20:47:30 As long as you're inside your Forth. 20:47:44 If you call the OS for anything, either you or the OS has to save and restore them. 20:48:22 In Forth you usually want to register the data and returns tack pointers, the top element of the data stack, and the instruction pointer. 20:48:42 And then there are usually a couple of scratch registers you use in the inner interpreter to weave through the threading. 20:49:12 I have a few others - I keep the address of my inner interpreter routine in a reg so that I can just put jmp at the end of each primitive to get to it. 20:49:40 And it's a multi-threading Forth - the address of the current thread's "thread block" is in a register too. 20:50:26 So your process owns these registers all the time even when it is not currently in control of the processor? 20:51:02 No, not quite. If it's not in control then it's not doing anything to the registers - they can be used for something else. 20:51:14 But you have to save the values in them and put them back before you give control back to your process. 20:52:02 What you just said would be like saying that the sheets of paper in folder A still own the spots on the desktop they sit on (when you have them out) even when they're stowed away in their folder. 20:52:24 That only holds to the extent that you intend to put them back in the same spot the next time you open folder A. 20:52:51 So they end up getting stored in memory correct? 20:52:55 Yes. 20:53:11 In a data structure designed to hold non-current thread data. 20:53:28 So it is often optimized for fast retrieval and storage 20:54:08 Right - multi-threading performance is better if you can minimize the amount of stuff you have to save/restore on thread switches and if you can do the save/restore of the stuff you do have do that to fast. 20:54:58 If you have the stuff I listed above in regs, then you only have to save four registers, follow a link or something from that thread block to the next thread block, restore those four registers from it, and resume. 20:55:02 It can be quite fast. 20:55:14 A lot faster than saving all 16 registers every time. 20:55:28 Which is what a completely general assembly language program would have to do. 20:56:05 You could reduce the task switch work further by not keeping some of those things in registers, but then everything else would run more slowly. 20:56:15 So it's a tradeoff, and you're looking for the optimum arrangement. 20:56:39 Hey, I need to get to bed, but we can chat more tomorrow if you like. PM me so we don't bore everyone else with it. 20:56:43 And have a good evening. 21:43:13 --- quit: johnnymacs (Ping timeout: 240 seconds) 21:47:55 --- quit: pierpal (Quit: Poof) 21:48:13 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 22:08:42 --- quit: pierpal (Quit: Poof) 22:09:01 --- join: pierpal (~pierpal@host97-54-dynamic.4-87-r.retail.telecomitalia.it) joined #forth 23:27:52 --- quit: tadni (Remote host closed the connection) 23:28:00 --- join: tadni- (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #forth 23:45:26 --- quit: Zarutian (Ping timeout: 260 seconds) 23:59:59 --- log: ended forth/18.07.16