April 11, 2007 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
April 11, 2007 [00:08:04] *** MauriceK has quit IRC[00:21:41] *** [Katisu] has quit IRC[00:31:51] *** SamuelGZ has quit IRC[00:54:51] *** pikapika has quit IRC[00:58:45] *** guildencrantz has quit IRC[01:10:05] *** shackan has joined #haiku[01:10:47] *** [Katisu] has joined #haiku[01:11:12] *** snipe714 has joined #haiku[01:32:23] *** Stamrogh has quit IRC[01:33:25] *** kb7sqi has joined #haiku[01:48:36] *** ablyss has quit IRC[01:56:44] *** mmadia has joined #haiku[02:16:14] *** gotaku has joined #haiku[02:24:23] *** emitrax_ has quit IRC[02:26:52] *** eNGIMa has quit IRC[02:27:54] *** kb7sqi_ has joined #haiku[02:29:22] *** kb7sqi has quit IRC[02:32:20] *** the_faulkenator has joined #haiku[02:34:52] <_hugo> kokito: yes[03:04:52] *** Sloar has joined #haiku[03:06:16] *** snipe714 has quit IRC[03:14:54] <JamesB192> let's start at the very beginning, a very bad place to start. When you lie to the public you start F-O-X. When you kill and you lie you start C-I-A, C-I-A. C-I-A F-B-I A-T-F.[03:15:59] <kokito> _hugo, hmmm... strange.... it certainly does not crash, and it seems to connect to the server. but users and files are not listed. what server are you connecting to?[03:16:58] *** Hoern has quit IRC[03:20:46] *** meianoite|TV is now known as meianoite[03:23:09] *** meianoite is now known as meianoite|TV[03:23:16] *** Jin has quit IRC[03:30:08] *** meianoite|TV is now known as meianoite[03:30:27] <_hugo> kokito: the default one. what revision are you testing?[03:31:13] <kokito> _hugo, 20646[03:31:40] <kokito> in vmware (network works fine, btw).[03:31:45] *** M_199 has joined #haiku[03:31:46] <_hugo> kokito: when it starts, does it say "adding server x..."?[03:31:49] <_hugo> for multiple servers[03:31:51] <kokito> yes[03:32:13] <_hugo> kokito: how long are you waiting after trying to connect?[03:32:23] <kokito> and I tried with several servers; it looks like it has connected, but I do not see any users or files.[03:33:11] <kokito> _hugo, it does not look like it is trying to connect, but rather that it has connected[03:33:37] <kokito> _hugo, let me see what Beshare actually says. one moment[03:33:46] <_hugo> kokito: how is the cpu usage after connecting?[03:33:56] <kokito> normal (low)[03:34:37] <kokito> oh! I am connected![03:34:52] <kokito> it worked![03:34:57] <_hugo> getting the user list is not usually instant[03:34:59] <_hugo> it takes a bit[03:36:06] <kokito> don't know. I turned on my Win machine and fired up the vmware image, and it worked this time. :)[03:36:27] <_hugo> :-)[03:37:46] *** procton_ has joined #haiku[03:37:52] <kokito> hmmm... the party did not last long... BeShare lost connection to the server, and now it does not connect. :P[03:38:16] <_hugo> kokito: do you have wireshark/ethereal in windows?[03:38:31] <kokito> ethereal _hugo[03:38:56] <_hugo> kokito: can you make a network capture of the vmware interface you are using? while you try to connect with beshare[03:39:31] <kokito> don't know if that's possible. do you know how to do a capture, _hugo ?[03:40:09] <_hugo> kokito: fire up ethereal, go to Capture->Interfaces[03:40:10] *** M199 has quit IRC[03:40:39] *** meianoite is now known as meianoite|TV[03:41:06] *** meianoite|TV is now known as meianoite|away[03:42:54] *** procton has quit IRC[03:43:57] *** meianoite|away is now known as meianoite|tv[03:44:18] <kokito> _hugo, you have lost me. what do you mean by "fire up ethereal"?[03:44:27] *** meianoite|tv is now known as meianoite[03:44:32] <_hugo> kokito: launch it :-) start the application[03:45:13] *** meianoite is now known as justtestingsomet[03:45:24] <kokito> I am sorry: by ethereal, I thought you meant "wired ethernet" (as opposed to wireless)[03:45:27] *** justtestingsomet is now known as meianoite[03:45:32] <_hugo> ah[03:45:49] <_hugo> kokito: go to www.wireshark.org[03:46:07] <kokito> ok. hold on[03:46:12] <_hugo> kokito: wireshark is an application that allows you to do network captures[03:46:33] *** Sikosis has quit IRC[03:47:10] <kokito> I see _hugo; the screenshot seems quite intimidating to this non-dev. :)[03:47:19] <_hugo> kokito: dont worry, ill guide you[03:47:30] <_hugo> you just need to start/stop and save[03:47:48] <kokito> ok. hold on.[03:48:39] <kokito> downloading...[03:49:09] *** absabs has joined #haiku[03:49:18] <_hugo> kokito: seeing the packets haiku is generating/receiving will allow me to more easily debug why you arent being able to connect[03:49:39] <kokito> I am now connected...[03:49:56] <_hugo> but when it fails :-)[03:50:14] <kokito> yes, got you[03:50:51] <_hugo> kokito: wireshark is a safe application, but if you dont want to install it, let me know[03:51:02] <_hugo> im sure ill eventually see the same problem you are having[03:51:49] <kokito> _hugo, it's ok. it's a test machine I am playing on.[03:52:23] *** shackan has quit IRC[03:58:00] <kokito> _hugo, I think I can now consistently connect, as long as I wait long enough. in BeOS, the connection used to take a few seconds, but it is much longer in Haiku.[03:58:28] <_hugo> kokito: there are several TCP optimizations which still arent implemented[03:58:55] <kokito> I see. ok.[03:59:11] <kokito> would a capture still be useful to you?[03:59:20] <_hugo> kokito: if its working, not really :-)[03:59:28] <_hugo> thank you anyway, sorry for the lost time[03:59:42] <_hugo> if you bump into something not working let me know[03:59:59] <kokito> _hugo, my pleasure! I already did: queries do not seem to work in BeShare.[04:00:21] <_hugo> kokito: no? they did here. i even downloaded files[04:00:53] <_hugo> no results from the query then?[04:00:57] *** ul1984 has quit IRC[04:01:01] <kokito> right, no results[04:01:51] <_hugo> kokito: ill do more extensive testing tomorrow. i didnt have much time today[04:02:41] <kokito> that's ok _hugo. sorry, I really did not mean to put pressure on you. :)[04:03:13] <_hugo> no problem, pressure is good.[04:03:50] <_hugo> but to be honest after the last commit the tests i made were successful.[04:04:09] <_hugo> there is still an issue im aware of and need to fix, but shouldnt mess with your connections[04:08:14] <kokito> _hugo, it's interesting: wireshark shows two vmware virtual eth adaptors (when I am only running one vmware machine).[04:08:58] <_hugo> kokito: one of the interfaces it the bridged one and the other is the one who offers NAT[04:09:20] <_hugo> when in vmware you select either "bridged" or "nat" it uses either interface[04:10:08] <kokito> _hugo, I see. and how do I know which is which?[04:10:48] <_hugo> kokito: trial and error is probably the fastest way. just start capturing in either, do a ping from inside haiku, stop the capture and see if you have any entries in the list[04:10:54] <_hugo> if not, try with the other one[04:11:02] <kokito> ok[04:11:23] <_hugo> in linux "vmnet0" is usually the bridged one and "vmnet8" is the NAT one[04:11:30] <_hugo> im not sure the windows version of vmware uses the same names[04:12:41] <kokito> ok, this will have to wait. :)[04:12:46] <kokito> bbl[04:12:59] <_hugo> see you[04:33:42] <meianoite> hey, geist[04:33:51] <geist> meianoite: I also hate discussing stuff on email[04:33:59] <geist> it alway hate what I just wrote[04:34:08] <meianoite> np, I just have to get used to IRC again[04:34:24] <meianoite> and English in general[04:34:30] <meianoite> :)[04:34:56] <geist> i should probably read the actual job proposal[04:35:04] <geist> it' to write a O(1) scheduler? is that all it says?[04:35:07] <meianoite> I have no problem reading, but I always manage to express myself in a way people won't understand right away[04:35:31] <meianoite> do you have access to the administrative GSoC area for Haiku?[04:35:40] <geist> there are actually multiple problems with the current scheduler, and IMO, the biggest problem is that it doen't scale with SMP very well[04:35:50] <geist> which is very much a data structure thing, versus an algorithmic thing[04:36:04] <meianoite> right.[04:36:05] <geist> on the other hand, the general solution to SMP scalability can be rather gnarly[04:36:16] <geist> though i pretty much have already figured it out, I just haven't gotten around to it[04:36:25] <meianoite> hm[04:36:33] <meianoite> what's currently holding it back?[04:36:53] <meianoite> I mean, the last time I checked it (2004) it was just a big list of threads[04:36:57] <geist> well, for one the GSoC thing[04:37:12] <geist> in that if it's a job on the list, it'd be kind of lame for me to then go steal it back :)[04:37:29] <meianoite> pardon me?[04:37:42] <meianoite> you mean[04:37:43] <geist> also, there's nothing particularly wrong with the current design[04:37:50] <geist> it's almost a direct copy of the beos scheduler[04:37:51] <meianoite> there's this GSoC task[04:37:54] <geist> which served beos well[04:38:02] <meianoite> but you'd like to tackle it eventually[04:38:05] <geist> it just can be better[04:38:20] <geist> nah, I just have some ideas. there ar elots of things I'd like to eventually do, but I have to be realistic[04:38:30] <meianoite> well[04:38:41] <meianoite> you can surely take any code I produce and put it on NewOS[04:38:42] <geist> also, it wasn't until relatively recently that there' been enough of a working system to actually test the scheduler code[04:38:47] <meianoite> and you're more than welcome to[04:39:03] <geist> newos is dead for all practical purpose[04:39:08] <geist> i dont work on it anymore[04:39:15] <meianoite> hey, people still like booting their dreamcasts ;)[04:39:54] <geist> i've given up on being able to merge code back from haiku into the newos kernel[04:40:07] <geist> primarily becaue the first thing the haiku folks did when forking it is change everything[04:40:22] <geist> they reorganized the code, changed variable names, changed function names, etc[04:40:29] <geist> so that they're for the most part unmergable[04:40:34] <meianoite> and I don't think we necessarily have a conflict of interests. we can always discuss our ideas and well, whoever has time to implement them, may do so[04:40:37] <geist> i was a little unhappy about that but what the hey[04:41:04] <geist> if i was ever gonna really resurrect newos I'd probably just fork haiku back :)[04:41:06] <geist> anyway, schedulers[04:41:24] <geist> right now it's a single list, shared by all cpus[04:41:31] <meianoite> I suspected so.[04:41:47] <geist> it's extremely simple, so it's pretty efficient[04:42:04] <geist> except for the inefficies from the shared list and spinlock overhead[04:42:07] <meianoite> I suspected so as well :) except that it's inherently O(n) because of that very property[04:42:16] <geist> why is it O(n)?[04:42:23] <meianoite> order of complexity[04:42:32] <meianoite> scales linearly with the numbe of threads[04:42:43] <meianoite> big-O notation[04:42:45] <geist> sure, but where does it have the n alrithm?[04:42:49] <geist> i know about big O[04:43:02] <meianoite> ah[04:43:08] <meianoite> ok. sorry. duh.[04:43:27] <meianoite> (I tend to utter obvious stuff from time to time, just forgive me)[04:43:40] <meianoite> well[04:43:45] <meianoite> is the list sorted?[04:43:50] <geist> absolutely[04:43:50] <meianoite> by priority?[04:43:54] <meianoite> so.[04:44:12] <geist> there's a distinction there[04:44:13] <meianoite> when inserting something, it must be inserted at the right position[04:44:32] <geist> yes, by having an array of pointers, one per priority, that points 'into' the middle of the list[04:44:35] <meianoite> if it's low priority, it must walk the list to find where to insert that something[04:44:41] <meianoite> ok, that's a skip list[04:44:49] <geist> no[04:45:03] <meianoite> no??[04:45:17] <geist> it's the equivalent of a bunch of lists, one per priority, that is concatenated to each other[04:45:29] <geist> the fact that it's a single list or an array of lists is no importantce[04:45:40] <meianoite> ok, that works, too[04:45:45] <geist> it being a single list is an optimization so the selection process (find_thread) is o(1)[04:46:03] <meianoite> right.[04:46:10] <geist> end result is inserting into the list is O(1)[04:46:34] <meianoite> yeah, with the strange property that recently inserted threads are the first on the list[04:46:41] <geist> nope.[04:47:19] <geist> depending on the situation, it' either added to the front or the end of that particular priority[04:47:19] <meianoite> on their respective priority's list[04:47:19] <geist> which may or may not be at one end of the list[04:47:19] <meianoite> so it's double linked?[04:47:24] <geist> absolutely[04:47:31] <meianoite> hm[04:47:49] <meianoite> so you may find the tail by going to the next priority's list and walking back on the node[04:48:08] <geist> sure, but that is not something you'd ever want to do[04:48:28] <meianoite> ok, but then how do you add to the end of the list?[04:48:37] <meianoite> (without walking the whole list first)[04:48:50] <geist> end of what list? just that priority queue?[04:48:51] <meianoite> unless the array of pointers have a couple pointers per priority[04:48:55] <meianoite> head and tail[04:49:00] <geist> head and tail[04:49:04] <meianoite> "<geist> depending on the situation, it' either added to the front or the end of that particular priority"[04:49:26] <geist> mind you i need to double check all of this. it was implemented slightly differently in newos[04:49:35] <meianoite> no problem[04:49:41] <meianoite> it's probably essentially the same[04:49:42] <geist> in newos I had it as an array of queues, and it walk through the array[04:49:48] <geist> uses a bitfield to optimize the search[04:50:07] <geist> i think someone added the 'have it be one long list with head/tail pointers' thing later[04:50:22] <geist> and on newos I always use circular linked lists, so adding to the head and tail is easy[04:50:27] <geist> given a single 'head' pointer[04:50:54] <geist> but anyway, that's just details[04:51:07] <meianoite> jesus christ[04:51:20] <geist> there are a few different data structures that can handle the same algorithm[04:51:24] <meianoite> the newos design is extremely close to what I did, then[04:51:39] <meianoite> array of circular lists[04:51:40] <geist> yeah, it's a simple design. work reasonably well[04:51:48] <geist> yeah, I *love* circular lists[04:51:51] <meianoite> no, it's not simply "simple"[04:51:54] <meianoite> it's perfect ;)[04:52:06] <meianoite> it just explores the very property of round robin[04:52:15] <geist> that's something the haiku guys dont seem to be into, but i think it's becaue I did the circular list thing *after* they forked the code[04:52:27] <meianoite> well, travis, congrats[04:52:30] <meianoite> you're a genius :D[04:52:31] <geist> and they never took it forward. they have their own implementation of lists[04:52:50] <geist> previously I had kept rolling different linked list implementations again and again[04:53:00] <meianoite> there are a couple twists I added to my scheduler code[04:53:03] <meianoite> for instance[04:53:20] <geist> http://newos.org/WebSVN/filedetails.php?repname=extern&path=%2Flk%2Ftrunk%2Fkernel%2Fthread.c&rev=0&sc=0[04:53:26] <meianoite> it's not a hard "get the highest priority thread"[04:53:32] <geist> here's another little embedded kernel I wrote recently[04:53:44] <geist> which uses the array of circular linked list with bitmap[04:53:46] <meianoite> but instead I experimented with probabilistic modelling[04:54:29] <geist> it is easy because the ARM has a clz instruction[04:54:46] <geist> anyway, now I as sort of lying about the find_thread() on beos/newos/haiku being O(1)[04:54:55] <geist> this is probably the part folks were thinking of replacing with other logic[04:55:00] <geist> beos had a strange property[04:55:04] <meianoite> well[04:55:10] <geist> basically all threads are fixed priority (except via API control)[04:55:28] <meianoite> find_thread can't be O(1) without perfect hash and hashtable[04:55:33] <geist> so for the most part the algorithm is simply 'grab the highest priority thread', which is really just pop the head of the list[04:55:41] <geist> eh, hash tables?[04:55:49] <meianoite> but find_highest_prio_thread (hypothetical) can be[04:55:58] <meianoite> ain't find_thread the one that takes char*?[04:55:59] <geist> that's what I mean by find_thread()[04:56:02] <meianoite> thread name?[04:56:14] <geist> sorry, s/find_thread/next_thread[04:56:19] <geist> or whatever you want to call it[04:56:24] <geist> i mean 'select the next thread to run'[04:56:26] <meianoite> eh, there happens to be such a function on the BeBook[04:56:31] <meianoite> hence the confusion[04:56:33] <geist> yeah forget I said that[04:56:36] <geist> anyway, beos[04:56:41] <meianoite> ok.[04:56:49] <geist> instead of just picking the head of the list, which would be O(1)[04:56:56] <geist> it picks the head of the list, and then rolls a random number[04:57:05] <geist> and a certain percentage of teh time, skips the thread[04:57:17] <geist> which means the scheduler is basically O(r*n)[04:57:21] <geist> where r is some pretty small number[04:57:26] <meianoite> hm[04:57:32] <geist> yeah, it's odd[04:57:33] <meianoite> that's like doing random promotion[04:57:38] <meianoite> no, that's not odd[04:57:46] <meianoite> that's pretty much like what I did[04:57:53] <meianoite> except that it doesn't skip stuff[04:57:58] <geist> it's odd in that I know of no other production scheduler that works that way[04:58:18] <geist> and it' by nature not O(1) at selection time (which is probably the case that's worth optimizing more than anything else)[04:58:19] <meianoite> but jumps right into the midldle of the thread a probability function would choose[04:58:39] <geist> it probably is there to make up for the fact that the beos scheduler is completely static[04:58:40] <meianoite> consider a function that models that property[04:58:43] <meianoite> (skipping the head)[04:58:51] <meianoite> if you use an array of priorities[04:58:58] <geist> there i no thread promotion, no punishing cpu bound threads, etc[04:59:09] <meianoite> and choose the priority based on that probability function[04:59:12] <meianoite> you attain the same property[04:59:19] <meianoite> and it's again O(1)[04:59:48] <meianoite> I did one for the linear distribution case[04:59:52] <meianoite> worked pretty well![05:00:36] <geist> probably[05:01:02] <geist> but anyway, what I'm mostly concerned about is SMP scalability[05:01:16] <geist> which caues all sorts of stuff to change, though it's reasonably well understood[05:01:25] <meianoite> hm[05:01:45] <geist> and depending on the actual scheduler algorithm, it may or may not impact it that much[05:01:50] <meianoite> I initally thought about doing it in a somewhat naive way[05:01:56] <meianoite> having multiple queues, one per CPU[05:02:08] <geist> that's the usual strategy[05:02:09] <meianoite> add them round-robin[05:02:16] <meianoite> migrate them on contingency[05:02:30] <meianoite> unless explicitly affined to a given CPU[05:02:39] <geist> that's how virtually all of them work nowadays (not sure about the round robin part though)[05:03:02] <meianoite> yeah, that's very intuitive[05:03:12] <meianoite> no wonder that's how it's usually done[05:03:15] <geist> and you're probably aware of the advantages[05:03:34] <meianoite> if you care to list them...? ;)[05:03:40] <geist> okay[05:04:02] <geist> a) it keeps the lock contention low. for the most part only the owner cpu is messing with it's own data structures[05:04:27] <geist> you're basically running a seperate scheduler per cpu, so the owner cpu can keep the data structures in it's own cache, doesn't get evicted by other cpus[05:04:31] <meianoite> a) sure, mostly the only time you need to acquire a lock is on migration[05:04:36] <geist> which is actually b) really[05:04:42] <meianoite> b) definitely.[05:04:55] <meianoite> especially given today's large caches[05:05:00] <geist> c) it tends to keep the threads on the same cpu as they last run, which increases the chance of hitting the same cache[05:05:10] <geist> you get cpu affinity by default[05:05:12] <meianoite> moreso on embedded architectures with cache locking[05:05:41] <meianoite> c) indeed so, hence "migrte on contingency unless explicitly affined"[05:06:05] <meianoite> well, it feels good to be on the same page as you, then[05:06:10] <geist> i think this kind of thing starts to really kick in >4 or so[05:06:26] <geist> and of course there are now 8 core consumer system out there[05:06:37] <geist> though it's really 4 L2s[05:06:51] <meianoite> the AMD ones are supposed to be more integrated[05:07:03] <meianoite> and I have an AM2 machine[05:07:08] <geist> as do i[05:07:15] <meianoite> UP, but I'll eventually get a multicore one[05:07:32] <geist> the multicore AM2s have seperate L2 cache, the core2 duo do not[05:07:35] <meianoite> hopefully using the GSoC money ;)[05:07:45] <geist> the core 2 quad however is two core2 duos glued together[05:07:59] <gotaku> I think I'll wait for the Penryn.[05:08:04] <geist> anyway[05:08:19] <meianoite> well, Penryn ain't AM2, and I'm not changing mobos this soon.[05:08:30] <meianoite> so... Barcelona it is,for me[05:08:31] <geist> the primary reason no one has really rewritten the scheduler yet is there hasn't until pretty recently actually been enough load to test with[05:08:46] <geist> since tweaking schedulers without test cases is a total waste of time[05:09:00] <meianoite> definitely...[05:09:01] <gotaku> The Barcelona better be impressive or AMD is in trouble.[05:09:26] <meianoite> is penryn going to be S775 as well?[05:09:34] <gotaku> Yes.[05:09:49] <meianoite> the thing that ticks me off with Intel is that they ALWAYS require chipset and BIOS support[05:10:01] <meianoite> AMD feels more integrated and less troublesome[05:10:13] <meianoite> but Intel is the speeding daemon, I concede that.[05:10:20] <geist> i kind of feel bad about AMD lately. now that I have basically one of each high end cpu, i'm totally blown away by the core 2[05:10:30] <jali> Intel makes good processors. AMD makes affordable processors.[05:10:38] <geist> this core 2 on my laptop (macbook pro) still pretty much blows away my AM2[05:10:46] <meianoite> (and Pacifica seems more thought out than VT-x)[05:11:02] <gotaku> Intel's next microarch (Nehalem) is actually going with an integrated memory controller.[05:11:24] <meianoite> heard so, too... I usually visit Ars Technica ;)[05:11:42] <meianoite> even though I sometimes dislike John Stokes' writing[05:11:48] <gotaku> jali: That's the way it used to be a long time ago.[05:11:55] <jali> And continues to be.[05:11:56] <jali> :)[05:11:57] <geist> i was just sad he never finished the PPC article[05:11:57] <jali> The end.[05:12:06] <geist> those were good readin[05:12:13] <geist> he never wrote part 3[05:12:22] <gotaku> jali: There was a point during the NetBurst fiasco that AMD had the better chips.[05:12:25] <jali> I've never been impressed by AMD's offerings. I settled for an Athlon during the Pentium 4 fiasco.[05:12:50] <geist> I'd say through much of the P4 offerings, AMD had a better solution[05:12:51] <jali> But now that Intel is back on track. I see no reason to use an AMD chip.[05:13:02] <geist> it wasn't until the core2s that they really took it back[05:13:03] <geist> but anyway[05:13:08] <jali> Eh?[05:13:11] <jali> Core Duo rocked too.[05:13:13] <jali> :|[05:13:16] <jali> Pentium D rocked.[05:13:19] <jali> Pentium M rocked.[05:13:28] <jali> It's just that wicked wicked Pentium 4.[05:13:37] <geist> core duo was only on the market for a few months, and pentium D is the same thing[05:13:41] <gotaku> I once heard that Intel hoped the NetBurst could scale to 10Ghz.[05:13:45] <geist> pentium m, sure, but that was mobile[05:13:50] <meianoite> geist, what I intend to do[05:13:51] <jali> I'm an Intel fanboy and I disown everything that is Pentium 4.[05:14:01] <jali> :P[05:14:08] <meianoite> implement the array of prios + circular lists all over again[05:14:23] <geist> well, you know the pentium d was just a pentium 4[05:14:37] <jali> geist: My laptop has a Core Duo chip. Despite the laptop being a piece of junk.. the chip itself is very nice.[05:14:49] <meianoite> have a probability function to eventually skip hi-prio threads, O(1) way[05:14:56] <jali> geist: They did a lot of good work with the Pentium D.[05:15:00] <meianoite> have multiple prio_arrays per CPU[05:15:07] <jali> Even my Celeron D server is nice.[05:15:17] <geist> okay, whatever. not interested in dicussing history right now[05:15:35] <jali> geist: Didn't mean to come across that way. :)[05:15:44] <geist> no prob[05:15:48] <meianoite> replace the big linked list with pointers with some maintaining on the arrays[05:16:11] *** Grackle has joined #haiku[05:16:18] <meianoite> meaning I'll have every empty prio placeholder point to the next populated array[05:16:25] <geist> meianoite: what about RT threads? I personally disagree with axel on RT threads[05:16:36] <geist> i think they should work precisely the same way they do now[05:16:37] <meianoite> rt threads will be scheduled separately.[05:16:44] <geist> they should be hard selected over anything else[05:16:46] <gotaku> Is haiku-os.org down?[05:16:53] <meianoite> well, I tend to agree with Axel[05:17:09] <meianoite> if a RT thread eats straight 8 seconds of CPU, it should be preempted[05:17:18] <meianoite> it's probably stuck on an infinite loop anyway[05:17:27] <geist> define precisely what that means[05:17:41] <Grackle> Nope gotaku.[05:17:58] <geist> (to have a RT thread be 'preempted')[05:17:59] <meianoite> more precisely than "if a RT thread eats straight 8 seconds of CPU, it should be preempted"?[05:18:04] <jali> hmm[05:18:10] <meianoite> in the sense of letting something else run[05:18:15] <geist> lower priority?[05:18:21] <geist> or in the same RT priority class?[05:18:22] <jali> I want to use libpurple to make a native Haiku IM client.[05:18:25] <jali> :D[05:18:30] <meianoite> no, inversion. really.[05:18:36] <geist> if lower priority, what does that mean? it gets suspended, killed?[05:19:06] <meianoite> that, I still don't know. that's something we should discuss.[05:19:07] <geist> I still disagree, what this sounds like to me is some sort of mechanism, external to the cheduler, that watchdogs the system[05:19:23] <geist> and suspends or demotes RT threads that would otherwie 'lock up' the system[05:19:29] <geist> i dont think it has anything to do with the scheduler[05:19:46] *** JamesB192 has quit IRC[05:19:51] <geist> can just be a timer that goes off once a second that watchdog the system[05:19:56] <meianoite> well, it actually does not. but it could be integrated.[05:20:03] <geist> i dont think it should[05:20:04] <meianoite> a timer will ALWAYS go off.[05:20:16] <geist> absolutely[05:20:17] <meianoite> I just don't think it belongs to the timer interrupt handler[05:20:25] <geist> no no, it would be a kernel timer[05:20:39] <geist> as a bit of background, in haiku you can schedule a timer[05:20:49] <meianoite> lectures! lovely.[05:20:53] <geist> which is really just a callback somepoint in the future, in interrupt context[05:21:16] <geist> lot of stuff uses it[05:21:36] <geist> for example, to acquire a sem with a timeout (it just sets up a timer to go off in the future and hard release the sem)[05:22:16] <geist> anyway, no a biggie[05:22:20] *** jeremy_c has quit IRC[05:22:28] <geist> my point is the scheduler shouldn't need to worry about edge cases like that[05:22:37] <geist> if it's possible to implement outside of the scheduler to keep it simple, it should[05:22:50] <geist> and frankly, if a RT thread is fucking up the system, there's some major problem[05:22:57] <meianoite> agreed.[05:23:00] <geist> you shouldn't be creating RT threads unless you really really really need it[05:23:02] <meianoite> but shit happens[05:23:26] <meianoite> still[05:23:43] <meianoite> is it your opinion that RT threads in the same prio level should not preempt each other?[05:23:59] <meianoite> and be run round-robin fashion?[05:24:10] <geist> that's a different story[05:24:28] <geist> have to think about that a bit. it really depends on what the point of RT threads are[05:24:30] <meianoite> yeah, and that's something to tackle as well :)[05:24:46] <geist> oh nah, it's super simple, it'll alll boil down to 2 or 3 lines of code[05:25:12] <geist> it really depends on if a RT thread is considered to be for extremely special cases, and when you create one you really intend to keep the cpu[05:25:13] <meianoite> well, the point of RT threads is exactly what RT is: to be answered in expected time[05:25:29] <geist> right, in that case you shouldn't get preempted[05:25:36] <geist> and it's up to you to make sure you dont hog the thread[05:25:49] <meianoite> well...[05:25:54] <geist> either you yield every once in a whiel and/or you just dont work for more than a little bit[05:26:06] <geist> again, this should only be for extremely rare case[05:26:15] <geist> or stuff like interrupt processing[05:26:18] <meianoite> IF a thread hogs the CPU for more time than expected, my opinion is that it should be preempted[05:26:28] <CIA-17> bvarner * r20647 /haiku/trunk/src/add-ons/kernel/drivers/network/bcm570x/b57um.c: Small adjustment to reduce the number of comparisons when publishing devices.[05:26:40] <geist> sure, but since it's a RT thread it'll probably just get scheduled right away again[05:27:00] <meianoite> unless there's some other thread in the same prio level[05:27:00] <geist> the only case where it wouldn't is if you had enough thread in the same queue[05:27:13] <meianoite> is it that rare?[05:27:16] <geist> either way, that's a one line change[05:27:30] <meianoite> i'd think it's more common than you make it seem like[05:27:34] <geist> it had better be pretty rare, since if you're doing that much work in a RT thread you're clobbering responsiveness[05:27:52] <geist> a RT thread running for a quantum of time? that would blow[05:28:02] <meianoite> I meant RT threads in the same level[05:28:18] <meianoite> my point exactly, geist[05:28:18] <geist> oh sure, but the discussion is if one uses more than a quantum of time and should be preempted[05:28:33] <meianoite> if it blows the quantum time, it should be preempted, period[05:28:35] <geist> if there is RT threads doing that, that is a serious programming error[05:28:50] <geist> i nearly argue you should kill it[05:28:57] <geist> it's a really stupid scenario[05:29:13] <geist> and there's little point trying to fix the kernel for stupid situations[05:29:18] <meianoite> wether we decide RT threads should have different quantum than regular threads, that's doable too[05:29:29] <geist> but all in all it's just a single line of code[05:29:42] <meianoite> schedulers tend to be small, anyway[05:29:46] <geist> whether or not you start the quantum timer (or if it runs always, whetoer or not you let it preempt RT thread)[05:30:00] <meianoite> the cunning in those short line is what counts[05:30:09] <geist> i really actually dont care that much either way, since I consider the entire thing to be an extreme edge case[05:30:30] <geist> and if the thread is hogging that much cpu, the whole system is gonna suck[05:30:31] <meianoite> consider this[05:30:38] <geist> doesn't matter if other threads get a chance to run[05:30:43] <meianoite> you're a careful programmer[05:30:49] <meianoite> you know what happens inside the box[05:31:01] <meianoite> a good engineer, to sum it up[05:31:08] <meianoite> but you're dealing with PEOPLE[05:31:13] <meianoite> who will make mistakes[05:31:17] *** stargater has quit IRC[05:31:27] <meianoite> newcoming programmers love novelties[05:31:48] <meianoite> as Haiku becomes popular, there eventually will be someone who will misuse RT threads[05:32:03] <geist> sure, but like I said, the discussion is moot. if the RT thread hogs enough cpu that it's going to use a quantum, it's probably goiing to use more than that (it's runaway), in which case it doesn't amtter much at all if you let other RT threads at the same priority run[05:32:10] <meianoite> and Haiku is bound to become more popular than BeOS ever as[05:32:14] <geist> the system is gonna be locked up for all practical purposes (unless it's SMP)[05:32:36] <meianoite> well, then we gotta decide what to do[05:32:41] <meianoite> kill it, no questions asked[05:32:51] <geist> sure, but that's not the schedulers problem[05:33:06] <meianoite> suspend the thread and ask the user to do something, like allowing it or killing it[05:33:07] <geist> that's a yet-to-be-written watchdog's problem[05:33:22] <meianoite> could be the next task once the scheduler is done :)[05:33:29] <geist> absolutely[05:33:47] <meianoite> so I'm laying down some extra tasks as well, if you don't mind[05:34:03] <meianoite> since I'm diving into the kernel, why not get my hands dirty[05:34:08] <meianoite> heh[05:34:34] <meianoite> well, I'm relieved.[05:34:45] <meianoite> and honoured, may I add[05:35:12] <meianoite> to realise we would solve those problems the same way[05:35:19] <geist> the trouble i the per cpu thing is gonna be reasonably difficult[05:35:22] <meianoite> given I'm just a college student[05:35:31] <meianoite> and you're an accomplished kernel engineer[05:36:03] <geist> and then it adds some complexities such as when to load balance[05:36:12] <geist> what core new threads are started on, etc[05:36:27] <meianoite> that's just some math[05:36:35] <meianoite> and some book keeping[05:36:47] <geist> and no matter how good it is, unles everything gets resynced absolutely every time any queue is changed, it will never be quite as responsive[05:36:49] <meianoite> we DO have those statistics anyway, no?[05:37:17] <geist> the single queue like it is right now at least has the property of potentially being perfectly responsive[05:37:17] <meianoite> care to elaborate on that?[05:37:27] <geist> never being in a state where the cpus are unbalanced[05:37:49] <geist> i know it doen't precisely do that. I know of at least one spot where it fails that[05:37:50] *** kb7sqi_ has quit IRC[05:38:07] <meianoite> well[05:38:10] <geist> when a thread is woken up in the sem code, it doen't do a global rechedule across all cpus[05:38:29] <meianoite> if... hm.[05:38:35] <meianoite> well[05:38:36] <geist> which technically speaking it should do, since another cpu may actualyl sit idle with more than 1 cpu in the queue[05:38:47] <geist> however, global reschedules are very expensive[05:38:48] <meianoite> we may go the Mach route[05:38:57] <meianoite> global queues and local queues[05:38:59] <geist> s/1 cpu/1 thread[05:39:14] <meianoite> affined threads go to the local queues[05:39:30] <meianoite> unaffined ones, to the global[05:39:57] <geist> yeah, but that doen't actually solve the problem[05:40:10] <meianoite> I just lost you here.[05:40:10] <geist> and actually per cpu queues doen't olve it either[05:40:32] <geist> when you wake up a thread, you either do a global check and find the optimal cpu to run it on or you dont and let it get balanced later[05:40:55] <geist> right now it'll get balanced on the next quantum tick on the next cpu[05:41:13] <geist> which is less than optimal, but it at least works out relatively quickly[05:41:38] <geist> with per cpu queues, if you woke the thread up to toe local cpu you may end up with seriously imbalanced queues for a while[05:42:58] <meianoite> well... yeah. unless you're willing to cope with some priority inversion[05:43:06] <geist> right[05:43:20] <meianoite> which could work, actually[05:43:27] <geist> which of course beos has no mechanism to deal with[05:43:58] <meianoite> if we use the priority queues, it's just a matter of selecting the next one which is not locke[05:44:15] <geist> trouble is the beos mechanism is semaphores[05:44:22] <geist> which have no concept of ownership[05:44:38] <meianoite> so we do it with locks on Haiku, why not?[05:44:51] <geist> haiku follows the beos model[05:44:57] <geist> ergo it has no kernel level locks[05:45:00] <geist> it only has semaphores[05:45:20] <meianoite> and there's no way in hell we could implement locks in a timely frame?[05:45:43] <geist> and not be beos binary compatible[05:46:09] <geist> but whatever, it's no biggie[05:46:10] <meianoite> but must we be BC at the kernel level?[05:46:23] <meianoite> private API, whatever[05:46:40] <geist> oh absolutely, but that doen't change the fact that most of the code would still be using semaphores[05:46:49] <meianoite> well, no problem[05:46:57] <geist> in fact it doe have mutexes[05:46:58] <meianoite> that's just an optimization at the kernel level[05:47:28] <meianoite> well, mutexes should do it, no?[05:47:40] <geist> sure, but no one uses it[05:47:57] <meianoite> well! haven't we just found an use for it? :D[05:48:10] <geist> if you want[05:48:13] <geist> it's a moot point[05:48:20] <meianoite> if you agree to[05:48:32] <meianoite> why moot?[05:48:44] <geist> because the point of the project is to replicate beos[05:49:06] <meianoite> but that's one area where we can do it better[05:49:07] <geist> there are a bunch of fundamental problems with beos, IMO, but it's not now to chance it[05:49:27] <geist> sure, but no one will go for it. this is where I'm sort of ehh about the whole thing, but that's just me[05:49:46] <meianoite> we don't necessarily have to copy even the shortcomings when they can be addressed in a compatible way... do we?[05:50:11] <geist> you know, I've kind of lost track of what we're talking about here[05:50:59] <geist> anyway, need to grab something to eat[05:51:01] <meianoite> using locks on the scheduler at the aray_of_prios so more than one processor can access it[05:51:23] <geist> oh? that was probably why the confusion, because that's definitely not what I was talking about[05:51:30] <meianoite> lol[05:51:37] <geist> I was talking about fundamentally changing the locking primitives at a system level[05:51:41] <meianoite> go grab your pizza, we'll come back to it[05:51:51] <meianoite> no for christ sake, no[05:51:54] <geist> ones that are more traditionally suitable for priority inversion[05:52:04] <geist> mutexes, single count sems, etc[05:52:24] <meianoite> I'll get a glass of soda as well[05:52:34] <meianoite> see you in 2'[05:52:38] <geist> well, kind of need to go do something else for a bit[05:52:46] <geist> my hands are actually starting to hurt form typing on this keyboard[05:52:53] <meianoite> right.[05:53:00] <meianoite> I'll see if I can log in tomorrow[05:53:00] <geist> laptops are great for everything but typing for long periods of time[05:53:03] <geist> sure[05:53:04] <meianoite> it's almost 1am here[05:53:12] <meianoite> but I got so involved in the chat :)[05:53:19] <geist> hmm +4h from here?[05:53:26] <geist> brazil?[05:53:37] <meianoite> I'm almost BGA's neighbour[05:53:42] <geist> ah okay[05:53:43] <meianoite> (ever since he moved to my city)[05:53:45] <geist> anyway, talk to ya later[05:53:54] *** kb7sqi has joined #haiku[05:53:55] <geist> i'll try to reply to the list with at least something[05:53:59] <meianoite> ok[05:54:02] <geist> so folks quit asking me if I've read it :)[05:54:11] <meianoite> please forgive any stupidity I uttered there[05:56:58] <meianoite> g'night![05:57:05] *** meianoite is now known as meianoite|away[05:58:41] *** gotaku has quit IRC[06:06:26] *** rcjsuen has quit IRC[06:16:46] *** kb7sqi has quit IRC[06:29:19] *** kb7sqi has joined #haiku[06:37:22] *** JonathanThompson has joined #Haiku[06:37:30] * JonathanThompson throws a Thought Grenade into the chat room[06:42:29] *** mmadia has quit IRC[06:48:28] *** Jin has joined #Haiku[06:48:43] <Jin> can I dd the haiku.image onto a partition I have saved for it and boot it from the be boot loader?[06:49:07] <JonathanThompson> As long as the partition is at least as big as the image, sure, you should be able to do that.[06:49:33] <JonathanThompson> If the partition is bigger, it'll simply be wasteful, but it will still work.[06:50:08] <JonathanThompson> You could also mount the image as a virtual filesystem and then copy everything over to that partition.[06:50:19] <Jin> right[06:50:35] <Jin> now how can I format that partition into bfs in an easy manner?[06:50:44] <Jin> since it seems to be broken[06:50:50] <JonathanThompson> Justg one word of advice: don't mount any other partition under Haiku you can't afford to send through an incinerator, just in case.[06:51:07] <JonathanThompson> mkbfs.[06:52:06] <JonathanThompson> For utmost paranoia about things that can go wrong and often do in pre-alpha kernels, it'd be even better to not have another drive with valuable data powered on.[06:53:38] <Jin> well I have 0_0, 0_1, and 0_3 in my disk device, but I don't have any idea which is which partition[06:54:10] <JonathanThompson> Before you go on, youi'd better figure that out :)[06:54:18] <Jin> how?[06:54:27] <JonathanThompson> df shows all mounted filesystems.[06:54:38] <JonathanThompson> From there, /boot is what you've just booted from.[06:54:55] <Jin> aah[06:54:59] <JonathanThompson> The rest you'll have to figure out via other means, perhaps by booting into them, if possible.[06:55:59] <Jin> I understand now[06:56:48] <Jin> so then uh[06:56:53] <Jin> shouldn't there be a 0_2?[06:57:01] <JonathanThompson> Only if mounted.[06:57:16] <Jin> right, and in the case it cannot be mounted...?[06:57:17] <JonathanThompson> Not all filesystems that exist on a drive need to be mounted at once.[06:57:40] <JonathanThompson> Depends on why it can't be mounted: is it corrupted, unformatted, or doesn't have a working driver for that type?[06:58:37] <Jin> corrupted[06:59:00] <JonathanThompson> If you can't mount it on any system, it may be time to give up on what was there.[06:59:20] <Jin> nothing was there :)[06:59:21] <Jin> it's ok[06:59:26] <JonathanThompson> Unless, of course, you want to use low-level utilities to recover some data.[07:00:02] <JonathanThompson> Remember my statement about preferably running Haiku (which is still pre-alpha in all ways that matter) on a system that has no data of value on hard drives that are powered on? :)[07:01:01] <Jin> yes[07:02:07] <JonathanThompson> Even better (and more feasible for most) would be to run it within a virtualized environment, in case you don't actually have a single computer you can dedicate to an unstable OS by itself.[07:03:34] <Jin> I'm fine with the implications of running alpha software on this computer[07:03:42] <Jin> I just need to make sure I do it RIGHT[07:04:14] <JonathanThompson> Justg so long as you're aware that the most crucial thing that's pre-alpha of Haiku right now is the kernel, which can corrupt the hard drive without a single warning while running it.[07:04:26] <Jin> there I fixed the partition[07:04:35] <JonathanThompson> *Anywhere* on the hard drive, partition mounted or not.[07:04:55] <Jin> I have nothing of value on this computer anymore[07:04:56] <JonathanThompson> If there's a driver for accessing the hard drive, it can potentially be corrupted.[07:05:01] <JonathanThompson> Then have fun :)[07:05:39] <JonathanThompson> What are the chances of that corruption? I don't think anyone can say accurately.[07:05:51] <JonathanThompson> It may be rather low at this point.[07:06:51] <Jin> the partition corruption was my mistake[07:07:02] <Jin> which was thankfully easily corrected using DriveSetup[07:07:29] <JonathanThompson> I have a 250 gig drive in this machine that can only understand 128 gigs via BIOS :)[07:07:32] <JonathanThompson> (at least for IDE)[07:07:49] <JonathanThompson> This system is too old to expect to be viable much longer.[07:08:31] <JonathanThompson> It's been surprisingly reliable overall, especially in the context that in 2003, it suffered a direct lightning strike on the house when it was powered on.[07:09:28] <JonathanThompson> I've had in mind to get a modern system, but employment hasn't been as predictable as desired.[07:09:31] *** petterhj has quit IRC[07:09:48] <JonathanThompson> So I'm using a computer that's about 8 years old still :)[07:09:55] <Jin> I see[07:09:59] *** kr1stof has joined #haiku[07:10:08] <Jin> I can understand the lightning strike, the same has happened to me[07:10:19] <Jin> which caused me to replace a few things, but it all still works, I got this machine in about '04[07:10:22] <Jin> oh yeah[07:10:34] <JonathanThompson> That fried the ethernet card I had installed in there that replaced the built-in NIC that got fried earlier by an indirect strike :P[07:10:49] <Jin> when I am finished compiling the haiku.image, how do I mount it virtually? and by just copying everything from image to partition, that will be enough for it to boot in the beloader?[07:10:54] <JonathanThompson> It overloaded the system enough to turn it off.[07:11:14] <JonathanThompson> The boot loader needs to know about it.[07:11:31] <Jin> it already does[07:11:38] <Jin> it knows that the partition can be booted from[07:11:43] <Jin> there is just nothing on the partition...yet[07:11:45] <JonathanThompson> Have you run "makebootable" on it? (I think that's it)[07:11:55] <Jin> no[07:12:05] <JonathanThompson> It's been awhile for me doing that.[07:12:20] <Jin> so then how do I mount virtual drives?[07:12:35] <JonathanThompson> My plans are that once I have saved 6 months of cash worth of living expenses, I'll replace this as my main machine.[07:12:55] <JonathanThompson> The same way via the commandline you'd mount regular drives, really.[07:13:15] <Jin> I don't usually use the command line to mount drives[07:13:19] <kr1stof> I can only tell how to install on hdd[07:13:26] <JonathanThompson> Instead of the /dev/drive path, you use the path of the image including the filename.[07:14:16] <kr1stof> I need another BeOS partition / install for it[07:14:27] <JonathanThompson> type "mount" in a terminal, and note what it says.[07:14:30] <Jin> so mount /path/to/image, but what about the directory?[07:14:45] <JonathanThompson> In the case of a virtual volume, you use the pathname of the image as the device.[07:14:58] <JonathanThompson> You create a directory where you want to mount it.[07:15:09] <JonathanThompson> From then on, going into that directory gets you into that partition.[07:15:12] <Jin> is that what /dev/disk/virtual is for then?[07:15:42] <Jin> or is that just a device link to the virtual mount[07:15:43] <JonathanThompson> In the case of your image, it would be the full path/filename of your image.[07:15:44] <Jin> ?[07:15:47] <kr1stof> It could be "mountimage" /path to virtual image[07:16:35] <JonathanThompson> Heck, my BeOS 5.03 system is slightly Haikued with the Screen preferences application, so I can set my monitor to run at 2048*1536 :)[07:16:56] <JonathanThompson> (BeOS 5.03 has no clue above 1600*1200 natively)[07:17:30] <kr1stof> Uh - my old graphic wouldn't even allow this :-)[07:17:33] <JonathanThompson> <--uses plain-sight encryption of screen data by running at a resolution that most people can't read beyond 2-3 feet[07:17:58] <Jin> hah[07:18:05] <Jin> ingenious[07:18:17] <Jin> and I wouldn't be able to read that with my face plastered to the screen with a magnifying glass :P[07:18:26] <kr1stof> 1280*1024 within haiku[07:18:34] <JonathanThompson> My 19" monitor surprised me by running at 61.1 Hz at that resolution, and I have a GeForce FX 5500-based card with 256 megs, PCI slot (I think my AGP slot got fried)[07:19:50] <kr1stof> I could switch to higher res., but I guess I would blow my 19" monitor[07:19:52] <JonathanThompson> Until last year, except for a very brief period of using an AGP slot nVidia TNT2, this machine had a 2 meg Matrox Millenium, not 2....[07:20:01] <JonathanThompson> Depends on your monitor.[07:20:14] <JonathanThompson> And what you set it to: it may complain politely and tell you that it won't do it.[07:20:31] <JonathanThompson> If it's a really old monitor, it might let the smoke out instead, if you leave it like that too long :P[07:20:42] <kr1stof> no flat, just an old monitor and a cheap nvidia with 128 MB[07:21:36] <kr1stof> I get Vision and Romashka running on haiku. I just cannot find a working browser[07:21:48] <JonathanThompson> What's funny is I (at this time) have a printer hooked up (well, I need to get it out of the box, since I've not used it since I moved) and a video card that have as much RAM as my main system :)[07:22:08] <kr1stof> :-)[07:22:47] <JonathanThompson> Except for something dying, otherwise I'd have a hard time justifying spending money on this machine.[07:23:20] <JonathanThompson> After all, the P3's were only warranted for 3 years, and if you consider the abuse they've had, and probably being on 90% of the hours I've owned them...[07:24:39] *** meianoite|away has quit IRC[07:26:25] *** guma has joined #haiku[07:27:11] <Jin> hmmm[07:27:20] <Jin> will Haiku read my USB key? I know BeOS won't :/[07:27:33] <Jin> I have some packages I grabbed earlier I need to get on here[07:27:33] <JonathanThompson> I don't know.[07:29:17] <Jin> if not I guess I Can use the network somehow[07:29:39] *** mmu_man has joined #haiku[07:29:39] *** ChanServ sets mode: +o mmu_man[07:31:17] <kr1stof> I don't know how to mount an USB stick within haiku[07:31:47] <kr1stof> Doesn't work here[07:32:37] <Jin> well it looks like I can use Samba with beos[07:32:40] <Jin> so I should be ok[07:36:39] <mmu_man> plop[07:36:56] *** mmu_man has quit IRC[07:38:00] *** kr1stof has quit IRC[07:42:37] <Jin> finally haiku is done building :P[07:43:13] <Jin> bbiab[07:43:15] *** Jin has quit IRC[07:55:45] *** Jin has joined #Haiku[07:55:49] <Jin> I'm impressed[07:55:52] <Jin> very impressed[07:55:57] <Jin> that booted and ran very well[07:56:08] <Jin> and we're talking like 10-12 seconds in boot time[07:58:04] <geist> it boots faster if the serial debug stuff is turned off[07:58:17] <geist> a substantial portiuon of the time is waiting for characters to go out the serial port[07:59:33] <Jin> now I have a beos question[07:59:38] <Jin> how do I access network shares?[08:01:26] <Jin> oh[08:01:30] <Jin> and DHCP worked perfect on haiku[08:01:33] <Jin> that was surprising[08:05:08] *** Jin has quit IRC[08:06:03] *** sheldonc_ is now known as sheldonc[08:06:05] *** Jin has joined #Haiku[08:06:06] <Jin> oops[08:23:25] *** Jin has quit IRC[08:24:25] *** jali has quit IRC[08:31:51] *** Jin has joined #Haiku[08:31:56] <Jin> got USB mass storage working :)[08:38:00] *** Jin has quit IRC[08:42:18] *** mmu_man has joined #haiku[08:42:18] *** ChanServ sets mode: +o mmu_man[08:44:35] *** Jin has joined #Haiku[08:44:47] <Jin> hmm, what can I use to burn this ISO file?[08:51:29] <kokito> Jin, you got USB mass storage working in Haiku?[08:51:49] <Jin> kokito, no, in beos, haha, sorry, didn't mean to scare anyone like that[08:52:06] <kokito> :)[08:59:00] *** kokito has quit IRC[09:01:12] *** tombhad-AC has joined #haiku[09:03:18] *** Jin has quit IRC[09:13:02] *** slaine_ has joined #haiku[09:14:48] *** tombhadAC has quit IRC[09:19:07] *** rhu has quit IRC[09:21:33] *** mmu_man has quit IRC[09:32:03] *** PulkoMandy has joined #haiku[09:33:41] *** tombhad-AC has quit IRC[09:33:58] *** tombhadAC has joined #haiku[09:34:19] *** Ingenu has joined #Haiku[09:47:06] *** JBurton has joined #haiku[09:47:07] *** ChanServ sets mode: +o JBurton[10:00:59] <JBurton> hi all[10:16:12] *** mmu_man has joined #haiku[10:16:12] *** ChanServ sets mode: +o mmu_man[10:18:49] *** Sloar has quit IRC[10:34:52] <raph_ael> hello[10:36:00] *** mmu_man has quit IRC[10:37:21] *** GreyGhost has joined #haiku[10:43:21] *** eNGIMa has joined #haiku[10:51:58] *** emitrax has joined #haiku[11:03:21] *** _delta_ has joined #haiku[11:07:17] *** emitrax_ has joined #haiku[11:10:15] *** miqlas has quit IRC[11:10:17] <CIA-17> axeld * r20648 /haiku/trunk/src/add-ons/translators/raw/ (RAW.cpp RAWTranslator.cpp): Improved progress report, the update message now gets a proper "what" field.[11:15:40] *** emitrax has quit IRC[11:23:35] <CIA-17> axeld * r20649 /haiku/trunk/src/add-ons/translators/raw/ (RAW.cpp RAWTranslator.cpp):[11:23:35] <CIA-17> * Fixed a few large memory holes (Dano even crashes on low memory...).[11:23:35] <CIA-17> * Removed printing progress updates to stdout.[11:25:37] *** emitrax__ has joined #haiku[11:25:59] <CIA-17> axeld * r20650 /haiku/trunk/src/apps/showimage/ (5 files):[11:25:59] <CIA-17> Implemented a progress window: it will be shown after one second in case the translator[11:25:59] <CIA-17> supports it - currently, only the RAW image translator does this (as it needs about 10[11:25:59] <CIA-17> seconds to open a 6 mio. pixel RAW image on a 2.6 GHz P4).[11:31:08] *** GreyGhost has left #haiku[11:33:52] *** emitrax_ has quit IRC[11:35:30] *** emitrax__ has quit IRC[11:54:38] *** ul1984 has joined #haiku[12:17:26] <CIA-17> axeld * r20651 /haiku/trunk/src/add-ons/kernel/network/stack/net_buffer.cpp:[12:17:26] <CIA-17> * init_data_node() is now called init_first_data_node(), and also sets[12:17:26] <CIA-17> data_header::first_node to that node. It will also remove some of the[12:17:26] <CIA-17> burden of the callers with regard to setting its members correctly.[12:17:26] <CIA-17> * Minor cleanup.[12:21:29] *** _delta_ has left #haiku[12:43:28] *** Ingenu has quit IRC[12:48:31] *** Ingenu has joined #Haiku[12:51:50] *** arikato has quit IRC[12:56:32] *** eNGIMa has quit IRC[12:57:22] *** slaine_ has quit IRC[12:57:57] *** slaine_ has joined #haiku[12:59:06] *** arikato has joined #haiku[13:04:13] *** absabs has quit IRC[13:33:16] *** rcjsuen has joined #haiku[13:34:07] *** Mazon is now known as mazon[13:37:30] *** LiquidQuartz has joined #haiku[13:40:21] *** mazon is now known as Mazon[13:41:19] *** genkie has joined #haiku[13:41:58] *** JBurton has quit IRC[13:58:09] *** LiquidQuartz has quit IRC[14:07:15] *** guma has left #haiku[14:07:36] *** jevin has quit IRC[14:11:56] <TTRanger> yawn, stretch[14:11:59] <TTRanger> good morning[14:18:50] *** DigitallyStoned has quit IRC[14:19:47] *** Sloar has joined #haiku[14:30:23] *** Mazon is now known as mazon[14:31:56] *** mazon is now known as Mazon[14:39:08] *** emitrax has joined #haiku[14:41:22] *** StylusEater_Work has joined #haiku[15:03:52] *** emitrax_ has joined #haiku[15:04:18] *** emitrax has quit IRC[15:12:58] *** arikato has quit IRC[15:14:16] *** emitrax__ has joined #haiku[15:14:43] *** emitrax_ has quit IRC[15:16:01] *** arikato has joined #haiku[15:23:14] *** jevin has joined #haiku[15:24:20] *** Cererus has joined #haiku[15:24:37] *** Hiko has joined #haiku[15:26:18] *** Cererus has left #haiku[15:26:18] *** Cererus has joined #haiku[15:26:38] *** Cererus has left #haiku[15:26:43] *** [Katisu] has quit IRC[15:33:36] *** Hiko has left #haiku[15:39:47] *** petterhj has joined #haiku[15:39:54] *** [Katisu] has joined #haiku[15:39:58] <[Katisu]> join #teamhaiku[15:40:18] <[Katisu]> sorry typo[15:43:33] *** wildur has joined #Haiku[15:45:12] *** emitrax_ has joined #haiku[15:45:51] *** kb7sqi_ has joined #haiku[15:46:05] *** kb7sqi_ has quit IRC[15:50:17] *** guildencrantz has joined #haiku[15:50:46] *** fyysik has joined #haiku[15:53:34] *** emitrax__ has quit IRC[16:02:34] *** wildur_ has joined #Haiku[16:03:19] *** wildur has quit IRC[16:08:13] *** Sil2100 has joined #haiku[16:11:40] <CIA-17> axeld * r20652 /haiku/trunk/src/libs/icon/IconUtils.cpp: Fixed build under BeOS.[16:12:56] *** rhu has joined #haiku[16:13:22] *** wildur_ has quit IRC[16:13:33] *** wildur_ has joined #Haiku[16:18:44] *** dr_evil has joined #haiku[16:21:18] *** Mazon is now known as mazon[16:21:20] *** jevin has quit IRC[16:27:25] *** Teknomancer has joined #haiku[16:30:28] *** jevin has joined #haiku[16:43:12] *** MrRagga has joined #haiku[16:44:54] *** absabs has joined #haiku[16:45:45] *** guma has joined #haiku[16:48:38] *** kr1stof has joined #haiku[16:52:21] *** GreyGhost has joined #haiku[16:55:34] *** doppeljot has joined #haiku[16:58:18] *** nathanw has joined #haiku[16:58:49] <CIA-17> hugosantos * r20653 /haiku/trunk/src/add-ons/kernel/network/protocols/tcp/TCPEndpoint.cpp: non-writeable states are always non-blockable from a write() POV.[17:00:24] *** kb7sqi has quit IRC[17:05:02] *** PORDO has quit IRC[17:11:51] *** mazon is now known as Mazon[17:19:24] *** jevin has quit IRC[17:21:58] *** doppeljot has left #haiku[17:28:23] *** arikato has quit IRC[17:30:10] *** arikato has joined #haiku[17:33:37] *** doppeljot has joined #haiku[17:36:44] *** slaine_ has quit IRC[17:40:27] *** _stippi_ has joined #haiku[17:40:43] *** Pulko_Mandy has joined #haiku[17:47:59] *** absabs has quit IRC[17:48:59] *** PulkoMandy has quit IRC[17:50:13] <CIA-17> axeld * r20654 /haiku/trunk/src/system/kernel/vm/vm_cache.c:[17:50:13] <CIA-17> The busy page could also be in another cache that is layered upon the merged one,[17:50:13] <CIA-17> so we can't easily check if the remaining mappings are valid - therefore I disabled[17:50:13] <CIA-17> the check completely.[17:51:27] *** Ingenu has left #Haiku[17:52:00] *** emitrax_ has quit IRC[17:52:31] *** emitrax_ has joined #haiku[17:58:28] *** rcjsuen has quit IRC[18:00:26] *** arikato has quit IRC[18:01:10] <CIA-17> axeld * r20655 /haiku/trunk/src/ (21 files in 3 dirs):[18:01:10] <CIA-17> * Moved the network status replicant into its own application, similar to what[18:01:10] <CIA-17> ProcessController and PowerStatus are doing.[18:01:10] <CIA-17> * Currently polls for info only - later, the stack should support listeners for[18:01:10] <CIA-17> interface related changes.[18:01:10] <CIA-17> * Also works under BONE (although it doesn't make much sense to use it there).[18:01:59] *** Ingenu has joined #Haiku[18:02:41] *** Teknomancer has quit IRC[18:07:59] <CIA-17> axeld * r20656 /haiku/trunk/build/jam/HaikuImage:[18:07:59] <CIA-17> * Added telnetd (does not work yet for whatever reason), and NetworkStatus to[18:07:59] <CIA-17> the image.[18:07:59] <CIA-17> * Moved "nc" to the alphabetically ordered position.[18:15:45] *** kokito has joined #haiku[18:24:19] *** arikato has joined #haiku[18:28:18] *** kr1stof has quit IRC[18:28:41] *** MauriceK has joined #haiku[18:30:32] * DeadYak pets MauriceK[18:30:41] <MauriceK> hey DeadYak[18:31:59] *** raph_ael has quit IRC[18:32:22] *** jevin has joined #haiku[18:33:07] <DeadYak> how's it going?[18:33:29] *** raph_ael has joined #haiku[18:33:59] *** _stippi_ has quit IRC[18:36:06] <MauriceK> fine, and on your side of the ocean :)[18:37:13] <DeadYak> rainy :P[18:37:45] <MauriceK> oh really? We'he finest spring weather here...[18:37:54] <MauriceK> :)[18:39:49] <DeadYak> hah[18:41:18] <CIA-17> hugosantos * r20657 /haiku/trunk/ (8 files in 8 dirs):[18:41:18] <CIA-17> some NetBufferUtility revamp.[18:41:18] <CIA-17> - introduced base NetBufferFieldReader which deals with obtaining a continuguous field to deal with.[18:41:18] <CIA-17> - renamed Detach() to Sync() to better express the fact that we may be writing to the buffer.[18:41:18] <CIA-17> - Fixed IPv4's and ICMP's checksum calculation as it assumed the underlying header was contiguous.[18:41:19] <CIA-17> - ICMP is now able to reply to ICMP Echo Requests which were split across data nodes.[18:41:24] <CIA-17> - in split_buffer(), make sure we were able to trim() the new buffer before damaging the original one.[18:42:16] *** nathanw has quit IRC[18:48:59] *** fyysik has quit IRC[18:54:13] *** meianoite has joined #haiku[18:55:14] <_hugo> telnetd doesnt work because our syslog facility right now uses ports instead of sockets[18:55:44] <_hugo> hm, that should be in a mail :-)[18:56:38] *** guma has quit IRC[18:57:11] *** meianoite has quit IRC[18:58:25] *** meianoite has joined #haiku[18:58:51] *** Euver has joined #haiku[18:59:48] <DeadYak> _hugo: well, as soon as you implement AF_LOCAL... :P[19:03:26] <meianoite> Heya[19:03:46] *** meianoite is now known as meianoite|away[19:09:51] <_hugo> DeadYak: eheh[19:10:08] <_hugo> actually my statement is wrong, its telnetd which expects to be run by inetd[19:10:30] <_hugo> ill check if it works in a bit, bbl[19:10:46] *** Karina` has joined #haiku[19:11:19] *** Pulko__Mandy has joined #haiku[19:11:34] *** doppeljot has left #haiku[19:11:48] *** Pulko_Mandy has quit IRC[19:13:43] *** stargater has joined #haiku[19:15:30] <stargater> hi[19:20:14] *** Karina`` has quit IRC[19:20:28] *** arikato has quit IRC[19:20:51] *** kr1stof has joined #haiku[19:23:44] *** meianoite|away has quit IRC[19:24:38] *** Karina` has quit IRC[19:25:14] *** Karina` has joined #haiku[19:32:58] *** MikeW has joined #haiku[19:40:56] *** meianoite has joined #haiku[19:42:02] *** arikato has joined #haiku[19:44:12] *** emitrax_ has quit IRC[19:44:34] *** emitrax_ has joined #haiku[19:45:51] *** meianoite is now known as meianoite|in_cla[19:46:10] *** meianoite|in_cla is now known as meianoite[19:46:58] *** meianoite is now known as meianoiteInClass[19:53:38] *** meianoiteInClass has quit IRC[19:53:39] *** dr_evil has quit IRC[19:53:43] *** dr_evil has joined #haiku[19:57:10] *** Ingenu_ has joined #Haiku[19:57:34] *** cherrypie__ has joined #haiku[20:06:45] *** Karina` has quit IRC[20:08:56] *** rcjsuen has joined #haiku[20:27:48] *** ghost has joined #haiku[20:33:04] *** DaaT has joined #haiku[20:34:33] *** GreyGhost has left #haiku[20:36:13] *** Begasus has joined #haiku[20:43:15] *** dr_evil has quit IRC[20:46:30] *** avkig has joined #haiku[20:50:34] *** Pulko__Mandy has quit IRC[20:50:34] *** PulkoMandy has joined #haiku[20:52:56] <CIA-17> axeld * r20658 /haiku/trunk/src/apps/networkstatus/NetworkStatusView.cpp: Got fooled by operator precedence - it's now working as expected.[20:53:04] *** rcjsuen has quit IRC[20:54:27] *** rcjsuen has joined #haiku[20:56:50] *** oco has joined #haiku[20:57:49] <kokito> hello MauriceK[20:58:05] *** Begasus has quit IRC[20:58:24] *** Begasus has joined #haiku[21:16:03] <DaaT> kokito![21:18:07] *** emitrax_ has quit IRC[21:20:33] *** stargater has quit IRC[21:26:55] *** siarzhuk has joined #haiku[21:27:33] *** kr1stof_ has joined #haiku[21:28:37] *** kb7sqi has joined #haiku[21:28:40] <kokito> hey DaaT :)[21:29:02] <DaaT> how goes it?[21:30:17] <kokito> slowly, but going DaaT :)[21:30:20] <kokito> and you>[21:30:22] <kokito> ?[21:30:34] * DeadYak pets kokito[21:30:39] * DeadYak shuns DaaT[21:30:49] <kokito> hey DeadYak[21:32:05] <DaaT> doing ok thanks[21:32:10] * DaaT kicks DeadYak[21:32:40] <DeadYak> I read "licks" at first glance.[21:33:53] <_hugo> no licking on my watch[21:34:35] * DeadYak licks _hugo[21:34:46] * _hugo assimilates DeadYak[21:34:48] <_hugo> borg![21:35:27] *** kr1stof has quit IRC[21:35:29] * JonathanThompson kicks DeadYak in the shins in welcome[21:35:41] *** rgb has joined #haiku[21:35:55] * _hugo converts rgb into hsv[21:35:57] <DaaT> you wish DeadYak (sorry for the delay)[21:36:02] <DaaT> hey _hugo and JonathanThompson[21:36:06] <_hugo> hello DaaT[21:36:14] * JonathanThompson hands DaaT a cloned sheep, a clone of Dolly[21:36:24] <_hugo> a dead sheep then[21:36:37] <DaaT> a sheep's a sheep[21:36:40] * DeadYak hides[21:36:42] <_hugo> i have a sheep[21:36:43] <JonathanThompson> A mutton for punishment that won't think it's all baaaaad[21:38:05] * _hugo can't get enough of battestar galactica's OST[21:38:11] * _hugo hums to the colonial anthem[21:39:56] *** MikeW has quit IRC[21:39:57] * DaaT read that *humps*[21:40:20] <_hugo> i do that too. synchronized humping[21:40:32] <DaaT> humping cylons?[21:40:46] <_hugo> you see, the colonial anthem has a climax and a calm ending[21:41:01] <_hugo> sometimes i wish i was humping cylons[21:41:09] <_hugo> well, some of them[21:41:11] <DaaT> sad...[21:41:12] <DaaT> :P[21:41:15] <_hugo> 0:-)[21:41:37] <_hugo> my beard is not as thick as baltar's, i guess that's why im not[21:41:50] <DaaT> :)[21:45:14] *** ghost is now known as dr_evil[21:45:16] *** ChanServ sets mode: +o dr_evil[21:48:21] * JonathanThompson marvels at DaaT "Sheep-lady killer" commenting on what's "sad" :)[21:48:40] <DaaT> :P[21:48:45] <DaaT> you're just jealous[21:49:00] <JonathanThompson> What, that I don't have a warm lady to cuddle with? :)[21:49:08] <JonathanThompson> Even if her skin conditioner is lanolin?[21:49:09] <DaaT> neither lady nor sheep[21:49:10] <DaaT> :P[21:50:26] <JonathanThompson> Well, time for me to wander back to the office.[21:50:36] <DaaT> fun[21:50:46] <JonathanThompson> Yup, battle the build beast.[21:51:02] <DaaT> yay[21:51:41] *** Euver has quit IRC[22:02:33] *** dr_evil has quit IRC[22:02:37] *** dr_evil has joined #haiku[22:03:18] *** MrRagga has quit IRC[22:07:53] *** Sil2100 has quit IRC[22:12:27] *** rgb has quit IRC[22:14:10] *** Begasus has quit IRC[22:15:55] *** MYOB has joined #haiku[22:18:32] *** kb7sqi has quit IRC[22:19:39] *** kb7sqi has joined #haiku[22:19:40] *** siarzhuk has quit IRC[22:26:56] <PulkoMandy> +++[22:26:58] *** PulkoMandy has quit IRC[22:34:50] *** _hugo has quit IRC[22:35:20] *** _hugo has joined #haiku[22:35:33] *** StylusEater_Work has left #haiku[22:35:40] *** ghost has joined #haiku[22:35:46] *** dr_evil has quit IRC[22:36:12] *** bamboo has joined #haiku[22:36:30] *** PORDO has joined #haiku[22:39:51] *** ghost is now known as dr_evil[22:39:59] *** dr_evil is now known as ghost[22:40:13] *** pikapika has joined #haiku[22:40:32] *** ghost is now known as dr_evil[22:40:34] *** DigitallyStoned has joined #haiku[22:40:58] *** SiCuTDeUx has joined #haiku[22:41:02] <SiCuTDeUx> hi all![22:41:09] <pikapika> hello[22:41:15] <SiCuTDeUx> anyone knows a client to muscle or beshare for linux?[22:41:25] <MYOB> unizon[22:41:30] <MYOB> unizone*[22:41:46] <SiCuTDeUx> :D[22:41:50] <SiCuTDeUx> thanks MYOB[22:44:58] <SiCuTDeUx> nah MYOB just for windows.[22:45:15] <MYOB> SiCuTDeUx no, just binaries for windows. source compiles on any QT platform[22:45:20] <MYOB> ask Monni on beshare about it[22:46:00] <SiCuTDeUx> lol!, how i'm going to do it? (connect to beshare)[22:46:11] <MYOB> use BeOS? :P[22:46:45] *** genkie has quit IRC[22:46:52] <SiCuTDeUx> lol[22:47:55] *** bamboo has quit IRC[22:48:47] <SiCuTDeUx> if only BeOSMax had cardbus support[22:49:32] <MYOB> it does[22:49:39] <MYOB> all versions of BeOS since 4.5 do[22:49:41] <SiCuTDeUx> uh?[22:49:44] <MYOB> however theres very very few supported cards[22:49:59] <MYOB> BeOS Urban Myth #234: BeOS Doesn't Do PCMCIA[22:50:02] <MYOB> it has since 1999....[22:50:09] <SiCuTDeUx> mine is not... last time i tryed didnt work[22:50:32] <MYOB> no, I guarantee you the controller works[22:50:36] <MYOB> the cards don't have drivers[22:50:40] <MYOB> simple as that[22:50:45] <SiCuTDeUx> probably[22:50:59] <MYOB> I have one working 10Mbit PCMCIA card (out of about 5) and one wireless (also out of about 5)[22:51:44] <kokito> SiCuTDeUx, you should try this > http://www.bebits.com/app/601[22:52:03] <MYOB> I used to be able to 'make' BeOS run on anything, but I appear to have lost the skill[22:52:06] <MYOB> :([22:52:22] * kokito thinks MYOB is getting old... :P[22:52:31] <SiCuTDeUx> xD[22:52:33] <MYOB> kokito *I* think I'm getting old :P[22:53:23] <MYOB> my Toshiba still hasn't run a BeOS or BeOS-alike off its HDD[22:53:44] <SiCuTDeUx> i have an ibm thinkpad 600e[22:54:06] <SiCuTDeUx> the pcmcia card doesnt have nec2000 support thow[22:55:13] <MYOB> ah, the 600s are a special case[22:55:19] <MYOB> the controller in them is WEIRD[22:55:39] <MYOB> if you talk to me when I'm drunk I can tell you what to to get it to work :P[22:59:56] <SiCuTDeUx> i'm so tired of using linux and windoss..[23:00:01] <SiCuTDeUx> *windows[23:00:30] <SiCuTDeUx> cant wait for haiku to be ready[23:01:53] <MYOB> hey, I'm stuck using zeta :P[23:02:26] <Ingenu_> I'm stuck using Windows Vista x64[23:04:12] <SiCuTDeUx> uhh... zeta doesnt have cardbuss either...[23:04:15] <SiCuTDeUx> i think[23:04:34] <MYOB> yes, yes it does[23:04:39] <SiCuTDeUx> oh, wait...[23:04:42] <MYOB> ALL BeOS derivatives since 4.5 have PCMCIA support[23:04:47] <SiCuTDeUx> zeta is pirated soft now![23:04:53] <MYOB> 16 and 32 bit[23:05:01] <SiCuTDeUx> MYOB: for MY cardbus card! :p[23:05:14] <MYOB> so is BeOS for all but the people who paid for it or use R5 PE from the installer directly...[23:05:19] <MYOB> (I paid for R5 Pro)[23:06:15] <SiCuTDeUx> MYOB: dont be mad, just joking![23:06:36] <CIA-17> jackburton * r20659 /haiku/trunk/src/preferences/mouse/ (MouseWindow.cpp SettingsView.cpp SettingsView.h):[23:06:36] <CIA-17> Patch by Lucasz Zemczak which fixes font sensitiveness issues in Mouse[23:06:36] <CIA-17> preflet. Thank you![23:07:13] *** BuildFactory has quit IRC[23:07:41] *** dr_evil has quit IRC[23:07:44] *** dr_evil has joined #haiku[23:08:50] *** pikapika has quit IRC[23:10:55] *** sarcas has joined #haiku[23:12:48] <SiCuTDeUx> pleeeaasseee MYOB dont be mad...[23:13:22] <MYOB> eh?[23:24:26] *** PORDO has quit IRC[23:34:37] *** kokito has quit IRC[23:34:52] *** MauriceK has quit IRC[23:37:34] <MYOB> just had to re-auth gmails SSL cert in Beam[23:37:35] <MYOB> must have changed[23:43:54] *** dr_evil has quit IRC[23:58:53] *** DaaT has quit IRC[23:58:54] *** Ingenu_ has quit IRC[23:59:18] *** MYOB has quit IRC