[00:00:55] <cyan-Q6600> Might even beat a single 6502 =P
[00:01:06] *** franxico has quit IRC
[00:01:12] *** franxico has joined #haiku
[00:01:44] <DeadYak> eric_j: 4004, 8008, 8080, 8086 iirc
[00:01:59] <DeadYak> and 8088 but meh
[00:04:03] *** SDr has quit IRC
[00:04:06] *** SDr has joined #haiku
[00:04:21] <jevin> i meant the 8008, silly me
[00:05:55] <cyan-Q6600> Why on earth did that rubbish have to take over the world? The 68k is the only good processor architecture.
[00:06:38] <DeadYak> I'm kinda partial to MIPS myself
[00:07:17] <geist> 8008 was a real beast
[00:07:21] <umccullough> would have been neat if MIPS stayed around
[00:07:24] <geist> damn hardware stack with no way of knowing if you blew it
[00:07:44] <geist> 8 entries deep
[00:08:04] <cyan-Q6600> Ouch. Sounds like the PIC architecture.
[00:08:15] <geist> and iirc, you can only do memory ops via the HL registers
[00:08:19] *** axeld has joined #Haiku
[00:08:20] *** ChanServ sets mode: +o axeld
[00:08:20] *** umccullough has left #haiku
[00:08:21] *** SDragon has quit IRC
[00:08:23] * dr_evil has a bunch of unsued microcontrollers with a 2 entries deep stack
[00:08:25] <DeadYak> axeld!
[00:08:32] <dr_evil> unused
[00:08:33] <axeld> Hi DeadYak!
[00:08:37] *** SDragon has joined #haiku
[00:08:40] <geist> ie, 'memory' was treated as a special register, which was the address made up of the H + L register
[00:08:58] <jevin> ARM anyone? conditional instructions sound cool, but ive never used them yet
[00:09:06] <axeld> Hi dr_evil
[00:09:08] <axeld> Hi geist
[00:09:55] <geist> jevin: it's very handy
[00:10:01] <cyan-Q6600> I've not really looked at ARM much. Seems like of DSP-like in a sense. Maybe that will become the next shader architecture...
[00:10:02] <geist> sadly arm is basically moving away from that with thumb2
[00:10:24] <geist> but the ARM instruction set is by far the most fun modern cpu to write assembly for
[00:10:33] <DeadYak> thumb2?
[00:10:41] <geist> being an expert in ARM is basically my current bread & butter
[00:10:55] *** BGA has joined #haiku
[00:10:56] *** ChanServ sets mode: +o BGA
[00:10:59] <geist> DeadYak: thumb2 is an extension of the old thumb instruction set to basically bring it up to par with ARM
[00:11:00] <DeadYak> BGA!
[00:11:07] <DeadYak> geist: I've never heard of thumb before
[00:11:21] <BGA> DeadYak!
[00:11:23] <jevin> 16-bit opcodes, right?
[00:11:40] <geist> right. no where nearly as flexible but tends to produce smaller code
[00:11:53] <geist> which in most embedded stuff makes it a win
[00:11:58] <geist> faster, smaller, etc
[00:12:18] <geist> thumb2 is an extension that lets it mix 16/32 bit instructions, filling in a lot of the gaps that are left out of the old thumb
[00:12:23] <cyan-Q6600> I think CISC might make a comeback on the desktop too, given that memory is such a bottleneck now.
[00:12:42] <DeadYak> make a comeback? it's already the dominant force
[00:13:04] <franxico> BGA!
[00:13:07] <cyan-Q6600> Really? Most of the instructions added since the 486 have been to make the x86 more RISC-like...
[00:13:12] <jevin> kinda, it all gets compiled into RISC microops on the proc though
[00:13:13] <BGA> franxico: Hey!
[00:13:16] <franxico> :D
[00:13:20] <DeadYak> cyan-Q6600: not really, the CISC-RISC decode layer is pretty much hidden from the programmer
[00:13:32] <MYOB> the current processors are VLIW pretending to be CISC? I thought?
[00:13:39] <geist> anyway, the biggest restriction of thumb is 8 vs 16 registers, loss of conditional instructions (all instructions are condition on ARM), and the loss of the barrel shifter (ARM lets you arbitrarily shift one of the operands to any math op)
[00:13:45] <DeadYak> MYOB: that's Transmeta
[00:13:49] <DeadYak> MYOB: and IA64
[00:14:03] <MYOB> DeadYak I thought Intel had gone down that road on ia32 too...
[00:14:11] <DeadYak> MYOB: nope.
[00:14:16] <MYOB> they're all pretending to be CISC anyway
[00:14:20] <MYOB> I miss my Transmeta :(
[00:14:28] <DeadYak> well yeah, they've been pretending to be CISC since the PPro
[00:14:29] <cyan-Q6600> What's Alpha? Athlons are based around that architecture...
[00:14:41] <geist> DeadYak: not technically true. all cpus since about the K6 or so have been transcoding into smaller internal ops
[00:14:42] <DeadYak> cyan-Q6600: Athlons are based on the Alpha's bus architecture, not its core
[00:14:55] <geist> yeah, what you just said
[00:14:56] <DeadYak> geist: that's not VLIW though is it?
[00:14:59] <MYOB> cyan-Q6600 Athlon's are based on NexGen 5nx86's, not Alpha
[00:15:00] <geist> nope, not at all
[00:15:06] <cyan-Q6600> The 68000 transcodes into smaller internal ops too. Isn't that true of all CISC CPUs to some degree?
[00:15:14] <geist> 68k did not
[00:15:19] <geist> 68k was microcoded
[00:15:19] <DeadYak> geist,: I think he means microcode
[00:15:23] <geist> different thing
[00:15:57] <cyan-Q6600> That's what I mean. With VLIW you don't really need any kind of microcode ROM at all...
[00:16:03] <geist> right
[00:16:26] <DeadYak> but you need one hell of a compiler and you need to pray the code you're working with can be parallelized well
[00:16:26] <geist> on the other hand with the amount of transistors available, the cost of decoding and scheduling complex instructions is pretty low
[00:16:36] <geist> so you may as well compress the instruction set
[00:16:40] <geist> ie, eventually CISC wins
[00:17:17] *** stippi has joined #haiku
[00:17:17] *** ChanServ sets mode: +o stippi
[00:17:49] <cyan-Q6600> Yeah, not to mention cache efficiency. If the inside loop can't fit inside the L1 cache, it's basically game-over now.
[00:17:54] <geist> that's what I mean
[00:18:09] <geist> since cpus are racing so far ahead of the memory speed
[00:18:19] <geist> not the cast 20 or 30 years ago
[00:18:22] <geist> case
[00:18:53] <geist> that cache efficiency problem is *major* in most ARM embedded systems
[00:18:58] <cyan-Q6600> Why is cache size still so small? This CPU has over 400 million transistors, yet only 8MB of SRAM cache... that doesn't sound right to me.
[00:19:19] <geist> calculate how many transistors 8MB needs
[00:19:26] * jevin dreams of 4GB SRAM
[00:19:27] <MYOB> my CPU has nowhere near 8MB of cache...
[00:19:30] <geist> at the bare minimum that's already 8 million transistors
[00:19:53] <geist> and you probably need something like 20 transistors per bit for super high speed ram there
[00:19:55] <franxico> cache is *very* expensive
[00:20:10] <geist> basically of that 400 million transistors, probably 90% of it is the cache
[00:20:17] <MYOB> its also not that old or slow
[00:20:28] <cyan-Q6600> Are more transistors required for speed? I thought SRAM was pretty much the same thing, just speed limited by the process size...
[00:20:29] <MYOB> anyway, nnight
[00:20:32] *** MYOB has quit IRC
[00:20:38] *** petterhj has quit IRC
[00:20:41] <geist> cyan-Q6600: oh I forgot that's in megabytes
[00:20:49] <geist> 8MB == 64megabits
[00:20:54] *** DaaT has joined #haiku
[00:21:14] <geist> so that's 64 million transistors *minimum*, if you could somehow theoretically use a single transistor per bit (which you can't)
[00:21:29] <DeadYak> geist: I'm guessing error correction's part of the reason?
[00:21:46] <geist> no, you just need multiple transistors per bit for a SRAM
[00:21:58] * DeadYak looks up SRAM architecture
[00:21:59] <geist> that's the primary reason you dont have massive SRAMs
[00:22:19] <geist> DRAM is far more space efficient, but you have to continually refresh it or it'll lose it's state over time
[00:22:47] <cyan-Q6600> Hmm. But still, I've fitted 4MB of SRAM to my Megadrive, and that didn't cost very much at all; about 1/10th of the cost of this processor. Also, the L1 cache size has remained pretty much unchanged since the Pentium Pro...
[00:23:10] *** flyinghippo has joined #haiku
[00:23:30] <geist> cyan-Q6600: not really, it's something like 16 times the size of the ppro's L1
[00:23:44] <geist> iirc, ppro had like 8/16 instruction/data
[00:23:49] <geist> and modern core2s and athlons have like 128/128
[00:23:55] <cyan-Q6600> I'm pretty sure this only has 16K...
[00:24:09] <cyan-Q6600> Actually, might be 32K; let me check
[00:24:22] <geist> well, depends on what 'this' is
[00:24:26] <DeadYak> this = ?
[00:24:44] <geist> but anyway, it's extremely hard to make super fast cache controllers, that stuff all has to work within a cycle
[00:24:45] <CIA-5> bonefish * r22401 /haiku/trunk/ (3 files in 2 dirs):
[00:24:45] <CIA-5> Addressed a deadlock race condition: Acquiration of condition variable
[00:24:45] <CIA-5> and thread spinlock was reverse in Wait() and Notify(). The thread lock
[00:24:46] <CIA-5> is now the outer lock -- this way it is still possible to call Notify()
[00:24:46] <CIA-5> with the thread lock being held.
[00:24:51] *** SDr has quit IRC
[00:24:55] <geist> gets expontentially harder to double the size
[00:25:03] *** SDr has joined #haiku
[00:25:08] <geist> which is why they're adding more layers of cache
[00:25:08] *** Sikosis has joined #haiku
[00:25:08] *** ChanServ sets mode: +o Sikosis
[00:25:09] <cyan-Q6600> Core 2 Quad.
[00:25:18] <geist> i think that's 64/64
[00:25:23] <geist> *per core*
[00:25:56] <geist> 32/32 it seems
[00:26:10] <cyan-Q6600> Yeah, that sounds about right. I noticed it was actually smaller than my old Athlon.
[00:26:13] <geist> though it is 8 way, that's pretty good for something that fast
[00:26:23] <DaaT> cyan-Q6600, new rig?
[00:26:34] <DeadYak> yeah, 128KB total on a C2 Quad.
[00:26:37] <geist> athlons have had pretty massive L1s for a while, though it's usually a lower nway
[00:26:42] <DeadYak> + 8MB L2
[00:26:50] <DeadYak> geist: what does n-way mean in the context of cache?
[00:26:51] <cyan-Q6600> DaaT: Yeah, just finished assembling it
[00:27:04] <DaaT> nice. Other than the Q6600, what are the specs?
[00:27:08] <DeadYak> I've seen "4-way set associative" before, but never really understood what that meant
[00:27:16] <geist> DeadYak: pretty complicated but basically as far as 'bad' to 'good' you get like
[00:27:44] <geist> direct mapped -> lower n way -> high n way -> fully associative
[00:27:57] <cyan-Q6600> DaaT: 512MB RAM (this is a BeOS-only system), Matrox G550 PCIe, and a bunch of stuff carried over from my old machine (SB Live, SCSI card, HDD, etc.)
[00:28:11] <geist> direct mapped means for any given address there is only one possible 'slot' it can go into the cache (say you chopped off the bottom n bits)
[00:28:16] <DaaT> cool
[00:28:28] <DaaT> though isn't the Q6600 a bit overkill? :)
[00:28:40] <geist> fully associative means any address can be stuck in any slot of the cache (and the tag ram will let it find it)
[00:28:50] <DaaT> and which beos version are you running on it?
[00:28:51] <DeadYak> geist: interesting
[00:28:56] <cyan-Q6600> geist: Is that culprit for pushing up the transistor count then?
[00:28:56] <CIA-5> bonefish * r22402 /haiku/trunk/src/system/kernel/condition_variable.cpp:
[00:28:56] <CIA-5> * Increased condition variable hash size.
[00:28:56] <CIA-5> * Renamed condition variable debugger commands to cvar and cvars.
[00:28:57] <geist> n way means for any given address you have that many slots it can fit into
[00:29:21] *** SDragon has quit IRC
[00:29:24] <geist> has to do with how much hardware you put into in parallel searching the tag ram for eveyr access
[00:29:32] *** SDragon has joined #haiku
[00:29:35] <jevin> geist: but you have tradeoffs between those cache types. it has to do with the efficiency of the mapping, right?
[00:29:43] <geist> yes
[00:29:48] <DeadYak> geist: the tag ram tells the cache what part of physical RAM that portion of the cache correlates to, yes?
[00:29:56] <cyan-Q6600> DaaT: R5+BONE; also works with R5 net_server. I guess it's a bit overkill, but upgrading is such a hassle, I aim to do it every 7 years or less. Also, the new quad core is pretty much bug-free; the older Core 2s had some nasty issues.
[00:30:08] <geist> fully set associative is extremely hard to do fast, you'll only really see that in TLB caches (which only have 32 or 64 entries usually)
[00:30:19] <DaaT> cool
[00:30:27] <geist> DeadYak: right
[00:30:33] <DeadYak> geist: interesting
[00:30:40] <geist> though if you're direct mapped you dont need that, it's very easy to make direct mapped caches
[00:30:53] <DeadYak> I guess that makes sense, I'd never really thought about how the actual cache lookups worked in the case of those low level caches
[00:31:11] <geist> yes, and remember for really high speed caches very close to the cpu it's running at gigahertz speed
[00:31:17] <geist> has a single clock to look all that up
[00:31:30] <DeadYak> ouch.
[00:31:44] <DeadYak> it's not possible for the CPU to stall waiting for the cache then?
[00:31:51] <DeadYak> i.e. either it finds it in one cycle or it's a miss?
[00:31:56] <geist> oh it is, the performance would just suffer
[00:32:03] <cyan-Q6600> Wouldn't that defeat the point?
[00:32:10] <geist> looking here at core2 specs it seems that L1 data cache has a bit of a latency
[00:32:12] <DaaT> ah, if only they ran at ludricous speeds
[00:32:16] <geist> 3 cycles for load, 2 cycles for store
[00:32:26] * DeadYak paints DaaT in plaid
[00:32:37] <geist> 14 cycle latency for a L2 lookup
[00:32:52] <geist> that's why you schedule for load latencies, etc when writing code
[00:32:57] * DaaT takes away DeadYak's dolls
[00:33:29] <DeadYak> geist: writing in asm presumably?
[00:33:31] <cyan-Q6600> I've never really seen why processor manufacturers put so much emphasis on the L2 cache personally. I've always found it very hard to measure the difference between L2 and memory, but really easy to see the difference between L1 and L2...
[00:33:38] <geist> DeadYak: or writing a compiler to generate it
[00:33:43] <DeadYak> geist: right
[00:34:03] <geist> looks like on a modern athlon it's 64/64 L1 (but only 2 way, versus core2s 8way)
[00:34:05] *** aphedox_ has quit IRC
[00:34:10] <geist> 3 cycle latency
[00:34:27] <geist> but the L2 is 16 way (nice) but has a 20 cycle latency
[00:34:39] <geist> you can see where they both have their advantages and disadvantages
[00:34:40] <cyan-Q6600> Even the Athlon 64s? That's the same as my old Athlon (original version)...
[00:34:41] <DeadYak> is that Barcelona or A64 X2?
[00:34:47] <geist> A64
[00:34:57] <geist> sandpile.org doesn't have barcelona specs up yet
[00:35:09] <geist> I'm looking at http://www.sandpile.org/impl/k8.htm and http://www.sandpile.org/impl/core.htm
[00:35:45] <DeadYak> ah
[00:36:00] <DeadYak> don't think ars technica has a detailed writeup on K8L yet either
[00:36:11] <geist> hmm, I thought barcelona was K10?
[00:36:24] <geist> that's what I assumed at least
[00:36:35] *** petterhj has joined #haiku
[00:36:38] *** Atomozero has quit IRC
[00:37:03] <DeadYak> geist: afaik Barcelona goes under the codename K8L
[00:37:07] <DeadYak> unless that changed
[00:37:43] *** fyysik has joined #haiku
[00:37:46] <geist> makes sense
[00:37:56] <DeadYak> we are both talking about the chip they just released right?
[00:37:57] <geist> K10 must be something else
[00:38:40] <DeadYak> geist: looks like K8L == K10 unofficial name
[00:38:55] <cyan-Q6600> I imagine AMD are working on some kind of next-generation chip by now, especially after the ATi stuff. I don't know if anything has been announced about what they're doing though...
[00:39:10] * DaaT waits for AMD to launch the special "K9 Tom Hanks" edition
[00:39:31] <DaaT> no, wait.. K9 was with.. Belushi?
[00:43:02] <cyan-Q6600> Have AMD mentioned anything about shaders on CPUs yet?
[00:43:25] <DeadYak> no, the main thing AMD's been going on about it is GPUs in cHT sockets
[00:44:07] <cyan-Q6600> That seems like a pretty strange idea to me. Ultimately they belong on the CPU.
[00:44:23] <DeadYak> not necessarily, cHT has a massive amount of bandwidth
[00:44:36] <DeadYak> so it'd allow to the CPU and GPU to coordinate as needed pretty easily
[00:45:17] <cyan-Q6600> But making it socketed assumes the shaders will only be used for GPU applications. If the shaders were actually part of the CPU, then it becomes possible to use them in all software, and the OS can even schedule threads to them.
[00:45:30] *** SDr has quit IRC
[00:47:01] <CIA-5> bonefish * r22403 /haiku/trunk/src/system/kernel/thread.cpp:
[00:47:01] <CIA-5> Fixed a race condition on thread exit: There was a gap between releasing
[00:47:01] <CIA-5> the death stack and reacquiring the thread lock in which another thread
[00:47:01] <CIA-5> could snatch our stack that we were still going to use for the
[00:47:01] <CIA-5> scheduler. Now we've got a second spinlock that we can hold while
[00:47:02] <CIA-5> releasing a semaphore.
[00:47:19] <geist> should kill that death stack stuff
[00:47:28] <geist> that was IMO a failed design
[00:48:08] *** _DaaT_ has joined #haiku
[00:48:48] <cyan-Q6600> What's that for?
[00:49:17] <geist> i was trying to avoid having a worker thread have to clean up the last remnants of dead threads
[00:49:19] <franxico> go bonefish!
[00:49:25] <geist> since it was a bottleneck on beos
[00:49:52] <DeadYak> geist: you mean psycho_killer?
[00:50:09] <geist> so i added this complex system whereby a thread can switch to an alternate stack and free it's own kernel stack before going through a final reschedule (which will put the stack back on a queue)
[00:50:18] <geist> yeah, psycho_killer used to be backlogged
[00:50:48] <DeadYak> would that have anything to do with the creation of charles_manson() or was that for a different reason?
[00:51:01] <geist> no idea, did someone add that?
[00:51:04] <DeadYak> freston
[00:51:14] <geist> heh
[00:51:21] <DeadYak> afaik he split psycho_killer into two functions for some reason, never did find out why
[00:51:27] <DeadYak> but that was the second one
[00:51:47] <DeadYak> I've had it show up in kernel panics on Dano before though :)
[00:52:12] <geist> ah, yeah, he may have tried to fix it in dano
[00:52:31] <geist> it was probably not that much work, just some way to scale it so that the queue doesn't grow too large
[00:52:40] <DeadYak> gotcha
[00:52:45] <DeadYak> it was amusing in any case :)
[00:52:54] <geist> there were some pathological cases where you could create a destroy threads faster than psycho_killer could kill them, I believe
[00:53:02] <geist> and it would eventually run the kernel out of memory
[00:53:26] <cyan-Q6600> Ouch. How fast does that need to happen?
[00:53:30] <geist> the simplest solution would probably be to just have a new dying thread wait until the queue is below a certain size
[00:54:37] <DeadYak> geist: interesting
[00:54:41] <cyan-Q6600> Wouldn't that exhaust the thread limit, with threads sticking around after they've been destroyed and another is spawned?
[00:55:07] <DeadYak> cyan-Q6600: you're not going to hit the system-wide thread limit *that* easily I don't think
[00:55:09] <geist> well, in this case the threads are actually dead, but there are some remains that the psycho killer cleans up
[00:55:20] <geist> most notabily their kernel stack
[00:55:29] <geist> which uses up kernel address space and real memory
[00:55:30] <DeadYak> geist: so what would you do instead of the death stack approach?
[00:55:39] <cyan-Q6600> DeadYak: Even if threads are being spawned/deleted thousands of times per second?
[00:55:53] <DeadYak> cyan-Q6600: what kind of app does thousands per second in practice?
[00:56:04] <geist> DeadYak: same thing as psycho killer, but with some sort of strategy to keep it from getting backlogged
[00:56:09] <DeadYak> besides I don't think spawn_thread() is fast enough for you to manage thousands per sec in the first place :)
[00:56:12] <DeadYak> geist: ah.
[00:56:21] <cyan-Q6600> DeadYak: Not many yet, but things should be more multithreaded. How about spawning a thread for each soundcard buffer that needs filling?
[00:56:23] <DeadYak> geist: would it be feasible to have several running in parallel?
[00:56:42] <geist> perhaps but it wouldn't make much sense
[00:56:50] <DeadYak> geist: not even on SMP?
[00:56:55] <geist> since they're mostly just freeing resources and would be piling up against the same locks
[00:56:58] <DeadYak> ah.
[00:57:09] <DeadYak> wasn't sure if the locking could be fine-grained enough for that to benefit from parallel ops
[00:57:45] <geist> this is all pretty fast stuff mind you, it's just that psycho killer was kind of stupid
[00:57:53] <DeadYak> hehe
[00:57:57] <geist> I was just trying to temporary stack thing as an experiment
[00:58:11] <geist> it works, but I think the unnecessary complexity isn't worth it
[00:58:25] <geist> and it's probably not faster, since I believe it introduces an extra context switch as part of it
[00:58:41] <geist> i felt a little dirty when i implemented it
[00:58:48] <DeadYak> hah :)
[00:58:49] <cyan-Q6600> Has the thread limit been raised at all in Haiku?
[00:59:01] <DeadYak> cyan-Q6600: the resource limits in Haiku are quite different in general afaik
[00:59:43] <geist> yes, beos tended to favor hard coded tables of stuff, and newos at least favors doing all of that dynamically
[01:00:10] <geist> I hate writing code that adds arbitrary restrictions like that
[01:01:14] <cyan-Q6600> Yeah, that seems like a really legacy part of BeOS. It's low enough to rule out some interesting software structures, like having each object exist in its own thread.
[01:02:28] <geist> i dont think it was for any particular reason, just done that way and never really fixed
[01:02:46] *** oco has quit IRC
[01:02:53] <geist> there was a lot of that in the beos kernel. there was a real resistance to 'unnecessary' changes unless there was a good reason for it
[01:03:16] <BGA> geist: I actually heard about that kind of stuff... :)
[01:03:21] <cyan-Q6600> Why was such a modern operating system using fixed limits everywhere in the first place though?
[01:03:40] <geist> here's a dirty little secret
[01:03:55] <geist> it's not that modern. it was just small and direct to the point
[01:03:57] <DeadYak> cyan-Q6600: it was originally designed for fixed hardware.
[01:04:07] <DeadYak> cyan-Q6600: the BeBox had a fixed set of limits you could upgrade it to
[01:04:25] <DeadYak> cyan-Q6600: so catering to arbitrary machine configs didn't really make sense
[01:04:38] <cyan-Q6600> DeadYak: But I'm sure the BeBox is perfectly capable of managing hundreds of thousands of threads, for instance...
[01:04:49] <DeadYak> cyan-Q6600: on a pair of 66MHz PPC 603s?
[01:05:00] <DeadYak> cyan-Q6600: have fun with the scheduler overhead on that
[01:05:08] <geist> also it was a very small team. for the most part folks attacked the lowest hanging fruit
[01:05:18] <geist> so there wasn't a huge amount of polish
[01:05:33] *** _DaaT_ has quit IRC
[01:05:37] *** DaaT has quit IRC
[01:05:54] <cyan-Q6600> DeadYak: It'd just run slower, surely? How slow is too slow?
[01:06:37] <DeadYak> cyan-Q6600: bear in mind it also had no L2 cache
[01:07:16] <DeadYak> cyan-Q6600: in any case, definitely slow enough that hundreds of thousands of threads would not be a scalable approach :)
[01:07:42] <DeadYak> the scheduler may have been O(1) but you're still going to kill yourself on context switching overhead
[01:07:59] <DeadYak> unless only a small handful of those was runnable at any one time
[01:08:12] <cyan-Q6600> DeadYak: I'm pretty sure it could manage 4096 without any problems though? Also 5000, but that'd blow the thread limit...
[01:08:29] <geist> 4096 is fine, hundreds of thousands is a different story
[01:08:36] <geist> though at 4096 you're probably pushing it
[01:08:47] <cyan-Q6600> Well, yeah, obviously most of them would be sleeping on semaphores or snoozes. Otherwise it's not going to run very fast anyway...
[01:08:48] <DeadYak> plus I don't know how large the kernel-side structures for thread bookkeeping are
[01:09:11] <geist> not too bad, but it does burn 4 or 8k (dont remember) of ram per thread for the kstack
[01:09:12] <DeadYak> hundreds of thousands of threads would probably be introducing enough overhead there that you're using a good chunk of RAM just on tracking threads
[01:09:42] *** DaaT has joined #haiku
[01:09:47] <geist> otherwise i think it was just the thread struct and a few semaphores per thread
[01:09:49] *** franxico has quit IRC
[01:09:54] <geist> actually you'd probably hit the semaphore limit first
[01:09:56] <cyan-Q6600> I suppose that's the nearest thing to a hard limit that exists...
[01:10:05] <DeadYak> geist: semaphore limit was scaled to sysram size, no?
[01:10:16] <DeadYak> geist: iirc when I upgraded RAM on my box the max sems went up too
[01:13:37] <pyCube> hmm.. for some reason I seem to be more productive code wise when listening to Frank Zappa
[01:15:04] *** fyysik has quit IRC
[01:15:32] *** SDragon has quit IRC
[01:15:35] *** SDr has joined #haiku
[01:16:20] *** phadi has joined #haiku
[01:20:22] *** petterhj has quit IRC
[01:20:23] <Sikosis> http://xkcd.com/323/
[01:21:24] <DaaT> lol
[01:22:09] <cyan-Q6600> XD
[01:22:25] *** Stargater has quit IRC
[01:23:15] *** fyysik has joined #haiku
[01:23:58] *** fyysik has quit IRC
[01:24:47] <cyan-Q6600> Hmm, looking through the repo, it seems like there are no SCSI drivers for Adaptec cards yet?
[01:25:38] *** stargater has joined #haiku
[01:25:40] <stargater> re
[01:26:30] *** BGA has quit IRC
[01:29:43] *** nielx has quit IRC
[01:36:14] *** DaaT has quit IRC
[01:36:48] *** fyysik has joined #haiku
[01:41:14] *** flyinghippo|AWAY has joined #haiku
[01:45:44] *** AnEvilYak has quit IRC
[01:50:52] *** flyinghippo has quit IRC
[02:01:22] <CIA-5> axeld * r22404 /haiku/trunk/src/system/kernel/vm/vm_store_anonymous_noswap.cpp:
[02:01:22] <CIA-5> The no-swap store shouldn't fool the page writer into believing that its pages
[02:01:22] <CIA-5> could be written back. This should stop the page thief from stealing active
[02:01:22] <CIA-5> pages that cannot be recreated easily :-)
[02:09:21] <geist> you go axeld!
[02:10:05] <dr_evil> hello geist
[02:10:08] <axeld> geist: nice, huh? :-))
[02:10:27] <dr_evil> have a look at this: http://overhagen.de/screen17.png
[02:11:12] <dr_evil> after compiling with gcc 2.95.3, haiku runs stable on my core 2 duo 2.4 GHz, booted from AHCI SATA
[02:11:55] <DeadYak> so some gcc4 optimizations breaking it maybe?
[02:11:56] <cyan-Q6600> dr_evil: What chipset is that?
[02:12:04] <dr_evil> intel 975
[02:12:08] <DeadYak> or maybe performance difference that's making it harder to hit the race?
[02:12:51] *** reallyjoel has joined #haiku
[02:13:08] <cyan-Q6600> dr_evil: I'm using the P965 here, with the Core 2 quad 2.4GHz. I think the two chipsets are largely the same.
[02:13:38] <DeadYak> dr_evil: very nice :)
[02:13:41] <dr_evil> I opened a couple of bug reports today, but all those bugs only appear when compiled with gcc4, not with the older
[02:13:54] *** stippi has quit IRC
[02:14:27] <cyan-Q6600> dr_evil: Are there any known bugs in gcc 4's code generation, or is gcc producing thread safety problems?
[02:14:29] <dr_evil> DeadYak remaining problem is the nvidia driver no supporting my card, so I'm running vesa which doesn't offer the native resolution of the screen
[02:14:40] <dr_evil> cyan-Q6600 I don't know
[02:14:56] <DeadYak> dr_evil: what chipset?
[02:15:06] <DeadYak> dr_evil: Euan's working on some issues with my radeon on his driver too
[02:15:16] <DeadYak> dr_evil: supported but the DMA engine is um...very broken on my chipset
[02:15:21] <DeadYak> so that's disabled for now
[02:15:26] <DeadYak> had interesting graphics with it on though
[02:15:31] <DeadYak> for some definition of interesting
[02:15:33] <cyan-Q6600> DeadYak: What Radeon do you have? I've been trying to work out some problems with mine too...
[02:15:45] <DeadYak> cyan-Q6600: R430 aka X800
[02:16:17] <dr_evil> DeadYak
[02:16:17] <dr_evil> 458 	PCI:   vendor 10de: nVidia Corporation
[02:16:18] <dr_evil> 459 	PCI:   device 0141: NV43 [GeForce 6600]
[02:16:21] <DeadYak> ah.
[02:17:19] <cyan-Q6600> DeadYak: Ah. I've got an X300SE here (currently using a Matrox though), but the second head doesn't work.
[02:17:42] <geist> hmm, wonder if I can try to boot haiku on this 8 core mac I have here
[02:17:53] <DeadYak> geist: can Haiku boot on EFI?
[02:17:53] <geist> that'll definitely be the highest number of cpus it's ever seen.
[02:18:03] <geist> bootcamp makes it look like a peecee
[02:18:06] <DeadYak> ah.
[02:18:10] <DeadYak> cool then
[02:18:29] <DeadYak> that's 8 cores with 2 hyperthreads each or?
[02:18:32] <geist> though i was thinking newos/haiku has an artificial 4 cpu limit
[02:18:37] <cyan-Q6600> geist: Have you tried R5 on that?
[02:18:46] <DeadYak> I'd be surprised if R5 booted
[02:18:51] <geist> two core2 quads
[02:18:58] <DeadYak> geist: ah
[02:19:01] <cyan-Q6600> DeadYak: Intel killed hyperthreading in the Core2, thankfully.
[02:19:04] <geist> you can actually build a machine about like this for around $800 or so
[02:19:06] <DeadYak> didn't know that
[02:19:23] <geist> need two quad xenon cpus and a workstation mobo
[02:19:27] <DeadYak> *blink* C2Q's are that cheap?
[02:19:35] <DeadYak> I would've thought $800 would buy you just the CPUs
[02:19:38] <geist> oh no
[02:19:45] <geist> you can get a c2q here for about $250
[02:19:48] <dr_evil> hyperthreading would be nice with core2
[02:19:48] <cyan-Q6600> I payed 170 (UK pounds) for this one.
[02:19:56] <geist> yeah, that's about right
[02:20:07] <DeadYak> damn, been too long since I looked at CPU prices
[02:20:13] <geist> though to run in a dual socket config you need a c2 xenon
[02:20:22] <geist> which is quite a bit more expensive for the same clock rate
[02:20:25] <cyan-Q6600> I don't really like hyperthreading; it complicates the scheduler's job. No longer are things balanced...
[02:20:36] <geist> if you're willing to take a clock rate hit you can still get one for $250 or so, plus a $250 mobo
[02:21:11] <dr_evil> 240 EUR: Intel Core 2 Quad Q6600 95W, 4x 2.40GHz, 266MHz FSB, 2x 4MB shared Cache, boxed
[02:21:17] <DeadYak> o.0
[02:21:49] <geist> yep, the Q6600 is a nice price point
[02:21:52] <dr_evil> it's about 100 EUR cheaper than what I payed for my dual core
[02:21:57] <dr_evil> half a year ago
[02:22:00] <geist> the gotcha is it's only 1066 FSB
[02:22:04] <cyan-Q6600> The "95W" part is extremely important. The older parts (with higher dissipation) had some very serious bugs.
[02:22:17] <geist> there is a dual core at around the same speed and price but with a 1333 fsb
[02:22:35] <geist> intel is for now holding the quads at the lower fsb
[02:22:36] <cyan-Q6600> geist: That's almost a positive thing -- there isn't much performance difference, and the slower bus lets you use more mature chipsets...
[02:22:48] <geist> though i also hear the q6600 can be overclocked like crazy :)
[02:22:55] *** kennyjb402 has quit IRC
[02:22:56] <geist> ie, just drive it up to 1333 anyway
[02:23:43] <reallyjoel> 1337
[02:24:19] <pyCube> b@d@$$
[02:25:01] <pyCube> q6600?
[02:25:34] <pyCube> ah
[02:25:37] <pyCube> nm
[02:26:21] <cyan-Q6600> It's about the only chip which is fast enough to run Firefox at a usable pace. =P
[02:27:14] <dr_evil> nope, firefox is effectively single threaded
[02:28:31] <cyan-Q6600> It slams two cores at a time pretty heavily here; the other thread seems to be app_server doing some drawing. Plus you have two spare cores to keep the system responsive while Firefox is grinding away...
[02:29:52] <dr_evil> I see, you win
[02:31:03] <cyan-Q6600> It's not a complete fix to the browser problem, but it really impressed me at first, how it ran almost as quickly as Netpositive.
[02:31:37] <pyCube> i dont see how thats a firefox problem
[02:33:28] <cyan-Q6600> Well, Firefox is too heavy to be responsive. Necessary though it is for some sites, we definitely need something pretty quick (e.g., Webkit) for Haiku, even if it can't render all sites perfectly.
[02:34:14] <DeadYak> firefox on linux is imo on the sluggish side too
[02:36:51] <pyCube> no it isnt
[02:36:51] <kad77> firefox is dog slow. I'm using a heavily optimized w32 build, which will still slow to a dead crawl with a few tabs open
[02:37:54] *** kennyjb402 has joined #haiku
[02:38:01] <cyan-Q6600> Isn't what?
[02:38:41] <DeadYak> pyCube: it crawls compared to FF on windows
[02:39:09] <DeadYak> I find most GTK apps on the sluggish side though, not just FF
[02:39:39] *** reallyjoel has quit IRC
[02:39:39] *** cyan-Q6600 has quit IRC
[02:39:39] *** pyCube has quit IRC
[02:39:39] *** DocBB has quit IRC
[02:39:40] *** jevin has quit IRC
[02:39:40] *** insomnia has quit IRC
[02:39:41] *** MrSunshine has quit IRC
[02:39:42] *** Deffy_Lappy has quit IRC
[02:39:43] *** Zaranthos has quit IRC
[02:39:43] *** Thom_Holwerda has quit IRC
[02:39:44] *** replore has quit IRC
[02:39:44] *** Yaroze has quit IRC
[02:39:44] *** cmang has quit IRC
[02:39:49] *** Hodapp has quit IRC
[02:39:49] *** IcePic has quit IRC
[02:39:50] *** zeeke has quit IRC
[02:40:49] *** reallyjoel has joined #haiku
[02:40:49] *** cyan-Q6600 has joined #haiku
[02:40:49] *** pyCube has joined #haiku
[02:40:49] *** DocBB has joined #haiku
[02:40:49] *** jevin has joined #haiku
[02:40:49] *** insomnia has joined #haiku
[02:40:49] *** MrSunshine has joined #haiku
[02:40:49] *** Deffy_Lappy has joined #haiku
[02:40:49] *** Zaranthos has joined #haiku
[02:40:49] *** Thom_Holwerda has joined #haiku
[02:40:50] *** replore has joined #haiku
[02:40:50] *** Yaroze has joined #haiku
[02:40:50] *** cmang has joined #haiku
[02:40:50] *** Hodapp has joined #haiku
[02:40:50] *** IcePic has joined #haiku
[02:40:50] *** zeeke has joined #haiku
[02:42:43] *** dr_evil has quit IRC
[02:42:46] *** dr_evil has joined #haiku
[02:43:21] <cyan-Q6600> Well, it differs between users. Some people are far more sensitive to responsiveness of applications; for me, Linux and Windows are basically unusable in that regard. Firefox is very measurably slower than Netpositive though, and that can make a big difference to some people...
[02:43:50] *** cmang has quit IRC
[02:44:08] *** cmang has joined #haiku
[02:45:39] <pyCube> yeah.. because n+ and ff are comparable
[02:47:00] <cyan-Q6600> I never said they were. I use both Netpositive and Firefox on a daily basis -- Netpositive renders most sites well enough to read, and is extremely fast. Sometimes I need to start Firefox up though. Ultimately that's the best way to browse if responsiveness is a concern.
[02:47:33] <geist> n+ foreva!
[02:48:49] <pyCube> weird
[02:49:31] <cyan-Q6600> Net+ on quad core is almost the fastest browsing experience I've had. The absolute fastest was Wagner -- how they made that thing so fast I'll never know. But it was also the fastest trip to KDL.
[02:50:06] * dr_evil needs a browser that *works*
[02:50:28] <DeadYak> Firefox also still leaks like crazy here
[02:50:54] <DeadYak> leave it idle with a bunch of tabs open, especially on AJAX pages and it's using a few hundred megs more RAM by the end of the day
[02:50:55] * dr_evil also needs a graphics driver that works, unfortunately
[02:51:01] <pyCube> i cant remember the last time i even bothered to look at my system ram usage
[02:51:17] <cyan-Q6600> DeadYak: Is it definitely a leak? Firefox really does use huge chunks of RAM, even in Windows...
[02:53:02] <DeadYak> cyan-Q6600: if it's several hundred megs a few hours later without me touching it, I'd say yes.
[02:53:10] <DeadYak> several hundred megs more*
[02:53:24] <DeadYak> pyCube: if it's using up enough to start paging out my other stuff at 1GB usage, it's an issue.
[02:53:25] <DeadYak> err
[02:53:28] <DeadYak> 1GB phy RAM
[02:54:27] <cyan-Q6600> DeadYak: Hmm. I've seen Firefox happily consuming 100-200MB during normal usage. Can't really say if it's a leak though. I'm not even sure if the usage report is accurate... only way to tell is when you end up in KDL when it reaches 500+MB
[02:54:30] <pyCube> my other machine here has had eclipse, 2 firefox instance each with a couple tabs, and several terms open continuously for the past week, at least
[02:54:55] <pyCube> it still works fine
[02:55:55] <pyCube> i am not saying your are imagining issues.. just that I havent had anything similar to that happen to me
[02:56:14] <DeadYak> pyCube: it's mostly an issue with heavy AJAX pages like GMail
[02:56:19] <cyan-Q6600> What version(s) of Firefox?
[02:56:22] *** RAVTUX has joined #haiku
[02:56:28] <DeadYak> 2.0.0.whateverthelatest is
[02:56:59] <pyCube> one of the ff instances is perpetually on an ajax filled site.. the project i work on for work
[02:57:42] <cyan-Q6600> Wouldn't it have to be doing something in a loop in order to make the memory usage continue to rise, such as a periodic refresh?
[02:57:45] *** ChanServ sets mode: +o dr_evil
[02:58:00] <DeadYak> cyan-Q6600: that's what things like GMail do
[02:58:12] <DeadYak> cyan-Q6600: they send out XML requests to the server periodically to get new mail and stuff
[03:00:14] <cyan-Q6600> DeadYak: I guess that'd explain it. I don't really use any sites that do that, so the memory usage stays pretty fixed (but very high).
[03:01:08] <CIA-5> axeld * r22405 /haiku/trunk/src/add-ons/kernel/drivers/network/stack/kernel_stack.cpp:
[03:01:08] <CIA-5> If opening the net_stack driver failed because there was no stack, opening it
[03:01:08] <CIA-5> a second time would magically work, as it skipped its initialization then...
[03:06:33] *** reallyjoel has quit IRC
[03:15:58] *** dr_evil has quit IRC
[03:17:44] *** axeld has quit IRC
[03:26:23] <pyCube> heh.. this pixar film trailer for "Wall-E" has that creepy music from Brazil
[03:27:46] <pyCube> or maybe its creepy *because* it was in Brazil
[03:31:18] *** Ketsuban has quit IRC
[03:31:33] *** Ketsuban has joined #haiku
[03:38:13] *** flyinghippo|AWAY has quit IRC
[03:41:18] *** M199 has joined #haiku
[03:44:40] *** Darknesss has quit IRC
[03:53:54] *** fyysik has quit IRC
[03:55:15] *** M_199 has quit IRC
[04:00:54] <RAVTUX> hey everybody!
[04:00:56] *** kennyjb402 has quit IRC
[04:01:09] <RAVTUX> anybody home?
[04:01:19] <RAVTUX> ;)
[04:01:49] <cyan-Q6600> Hey
[04:02:00] <RAVTUX> cyan-Q6600: whats up?
[04:02:14] <cyan-Q6600> Not much. You?
[04:02:47] <RAVTUX> I have been in discussion about making a Haiku Builder Live CD
[04:03:58] <RAVTUX> A Linux live CD with Haiku pre-built to run in QEMU and easily install on the hard drive
[04:04:12] <RAVTUX> what do you think?
[04:04:40] <cyan-Q6600> Would the LiveCD include development tools for Haiku?
[04:04:56] <RAVTUX> of course
[04:04:58] <RAVTUX> ;)
[04:05:54] <cyan-Q6600> Seems like a pretty good plan, if you can get it to work (not sure how easy it'd be to make the dev tools work on a read only filesystem?).
[04:06:20] <RAVTUX> it is worth a try atleast
[04:06:34] <RAVTUX> it would help in Haiku development over all
[04:07:36] <cyan-Q6600> Yeah. Getting AHCI drivers ported to R5 would also help with Haiku development, but I can't seem to convince anyone to try that =P
[04:09:25] <RAVTUX> I am glad you like the idea
[04:17:08] <kokito> hey RAVTUX
[04:17:16] <kokito> that's a good idea
[04:24:27] <RAVTUX> kokito: hey
[04:24:40] *** umccullough_home is now known as umccullough
[04:24:46] <RAVTUX> I have some developers together
[04:25:01] <RAVTUX> we so far plan to use Debian as a base
[04:25:08] <RAVTUX> with a Fluxbox DE
[04:25:27] <RAVTUX> please join the discussion at ##cafelinux
[04:27:53] <umccullough> RAVTUX, you've heard of fluxbuntu?
[04:28:11] <RAVTUX> umccullough: yes
[04:29:06] <joejaxx> RAVTUX: what are you tring to do?
[04:29:35] <joejaxx> oh nevermind i see it
[04:30:02] <joejaxx> interesting
[04:30:26] <umccullough> oh, i didn't even realize joejaxx was here :D
[04:30:51] <joejaxx> RAVTUX: what are the target computer specs :P
[04:30:56] <joejaxx> umccullough: :P
[04:30:58] <joejaxx> :)
[04:31:20] <RAVTUX> http://ubuntuforums.org/showthread.php?t=565115
[04:33:41] <RAVTUX> I need to install Haiku to my harddrive this weekend
[04:50:01] <DeadYak> cyan-Q6600: AHCI driver won't work on R5, the driver architecture for disk controllers is different
[04:51:22] <cyan-Q6600> DeadYak: Yeah, I heard it wouldn't work unchanged, but I was wondering about what would be involved to port it.
[04:53:45] <RAVTUX> DeadYak: I want to install Haiku this weekend
[04:54:00] <RAVTUX> hopefully some one can help me out
[04:54:13] <RAVTUX> I will check in later, I have to go now
[04:54:18] <RAVTUX> good night
[04:54:22] *** RAVTUX has left #haiku
[04:59:00] <umccullough> cyan-Q6600, i have a feeling nobody is going to put effort into it... in fact I think i heard that mentioned
[05:02:37] <cyan-Q6600> Are there any driver developers who use R5? If not, I can imagine why...
[05:03:25] <umccullough> don't think so :(
[05:03:28] <umccullough> maybe axel
[05:03:56] <umccullough> most of the developers have moved to linux
[05:07:10] <cyan-Q6600> Probably because R5 doesn't support AHCI? =P
[05:07:38] <geist> because it builds about 10x faster
[05:09:10] <cyan-Q6600> geist: On identical hardware, on a variety of different filesystems?
[05:09:31] <geist> yes
[05:09:34] <pyCube> linux is slow, and evrything every be engineer ever did was perfect
[05:09:54] <geist> oh yeah, except for that part
[05:11:28] <cyan-Q6600> There must be a rational reason why it shows such an unusual speedup, even when building onto a FAT partition or something. Disk cache?
[05:12:06] <pyCube> could have something to do with one os being new and the other being all old
[05:14:36] <cyan-Q6600> Yeah, Linux is really old; perfect clone of a 1970s OS. But that still doesn't answer it.
[05:15:04] <pyCube> dunno about you, but i dont know many people using an os from the 70's
[05:15:42] <pyCube> i dont know anybody using linux from the 90's, let alone something older
[05:15:47] <cyan-Q6600> Nor do I; everyone I know runs Windows, Mac OS or BeOS.
[05:16:24] <cyan-Q6600> Linux from the 90s? There's no such thing. The entire system is a 70s design.
[05:16:24] <pyCube> i dont hink geist was suggesting using an ancient linux either
[05:18:31] <pyCube> just curious.. do you view a 2007 porsche 911 gt-2 through the lens of "late 19th century design"?
[05:20:11] <joejaxx> lol
[05:21:13] <geist> the beos disk cache is extremely slow
[05:21:16] <cyan-Q6600> I don't think the situation with Linux is in any way comparable. The whole thing is designed to be a clone of Unix. The world revolves around the 80 column teletype terminal. If you want a GUI, you have to use the (equally "modern") X.
[05:21:29] <geist> process creation/teardown is pretty slow too. a few orders of magnitude slower than linux
[05:21:32] <geist> it adds up
[05:21:39] <pyCube> cyan-Q6600: says you
[05:22:06] <cyan-Q6600> geist: Interesting; thanks for some actual info =P
[05:22:17] <cyan-Q6600> geist: Isn't thread creation/destruction said to be extremely quick, conversely?
[05:22:40] <geist> and as ancient as the linux design may be, building something is a decidedly unixy task, which linux does far better than beos
[05:22:48] <geist> beos has posix, but it's not the primary goal
[05:23:18] <geist> whereas everything about a unix kernel is all about creating/tearing down processes and file io
[05:23:27] <cyan-Q6600> pyCube: Cut+paste, interapplication messaging, video overlays, etc. Oh, and Linux is the only OS I've ever used where the mouse pointer actually skips and freezes... haven't the developers heard of this fancy new feature called an ISR? =P
[05:24:16] <pyCube> youre right
[05:24:26] <pyCube> linux is slow and old, and evrything every be engineer ever did was perfect
[05:24:38] <cyan-Q6600> Yeah, process spawning performance makes sense. It's not really a priority in a modern desktop system, as it's just needless thrashing of the system.
[05:24:48] <geist> the advantage that linux has over beos (and most other kernel implementations nowadays) is an infinite number of monkeys that optimize every single code path to the point of being unrecognizable, but very very fast
[05:25:23] <cyan-Q6600> geist: Does that include the freezing mouse pointer issues, choppy window dragging, etc. too? =P
[05:25:38] <pyCube> i think a lot of people confuse "could probably be better" with "complete shit"
[05:25:41] <geist> I have no idea what you're talking about
[05:26:03] <geist> your experiences are not necessarilly the same as everyone else
[05:26:10] <geist> and anyway, linux is a kernel
[05:26:18] <geist> linux is not X, linux is not libc, etc
[05:26:27] <geist> the shit people pile on it is pretty amazing
[05:27:07] <pyCube> its the ordinary kid to pick on.. all the cool people that arent sheep pick on it
[05:29:07] <cyan-Q6600> The scheduler has never been very desktop-friendly in Linux, and that's the root of a lot of trouble. The whole Unix philosophy isn't very desktop-friendly either, hence why we have X, window managers, layers upon layers of crud that'd make Microsoft ashamed, etc.
[05:29:38] <geist> *shrug* when you decide to get a clue we can continue the conversation
[05:30:42] <cyan-Q6600> If Linux is so great, why does Haiku exist at all? And how come it's not using the Linux kernel?
[05:30:58] <geist> beats me
[05:31:01] <pyCube> to taunt you
[05:31:40] <geist> nor have I said linux is so great
[05:31:46] <pyCube> nobody said linux is so great.. rather, linux isnt the complete turd you claim it is
[05:31:49] <geist> but I'm not spouting large rants of bile
[05:33:51] <cyan-Q6600> I didn't claim it to be a complete turd, merely an operating system based on obsolete design ideas, with major performance problems for many common applications (e.g., desktop use). The layers of crud involving X, KDE/Gnome, etc. are terrible too, but that is getting a bit off-track.
[05:34:49] <pyCube> while those might be your opinions, none of it is actually true
[05:34:52] <pyCube> :-p
[05:35:33] <geist> well, opinions are great, you were just getting prett far off into rant territory
[05:35:58] <geist> which pretty much shuts down my desire to participate further
[05:36:35] <cyan-Q6600> There's an awful lot of people who feel this way, so I'm definitely not the minority. As for how true it is, it's subjective; how can it really be proven? Total size in bytes for a powerful desktop system? Typical Linux setups fail. Responsiveness to real-time requirments? Fail again. As for other technical aspects, who knows.
[05:36:58] <DeadYak> size in bytes on disk is a pretty meaningless measure of anything
[05:37:05] <umccullough> huh? anti-linux rant?
[05:37:10] <geist> anyway, ahci driver in good shape?
[05:37:17] <pyCube> then the real magic is why people keep using such a clearly incapable os
[05:37:21] <umccullough> geist, i hear it's functional!
[05:37:24] <geist> excellent
[05:37:29] <DeadYak> geist: looks like it, Marcus had it fully booted with gcc 2.x playing videos and everything
[05:37:33] <cyan-Q6600> Total size on disk becomes a problem when you can't fit the system on a disk any more, especially a flash drive or a LiveCD. It's also one possible way of measuring efficiency.
[05:37:38] <umccullough> geist, sounds like maybe some new SMP-related race conditions exist somewhere in new code :(
[05:37:48] <geist> probably
[05:37:59] <DeadYak> umccullough: actually all the weirdness Marcus was running into was when building with gcc4, almost all of it went away with 2.x
[05:38:21] <cyan-Q6600> pyCube: They keep using it either because they need its specific advantages (server applications, possibly development), or they just need a mainstream alternative to Windows.
[05:38:22] <umccullough> strange, cuz some people reported the same problems with downloaded images (presumably 2.x
[05:38:22] <umccullough> )
[05:38:32] <umccullough> similar problems anyway DeadYak
[05:38:43] <DeadYak> umccullough: I'm getting weird crashes in Tracker and Deskbar on startup on a single proc sys since about 2 days
[05:38:48] <DeadYak> umccullough: only on startup though
[05:38:51] <umccullough> DeadYak, yes, stuff like that
[05:38:59] <umccullough> i gather that's mostly a new issue
[05:39:04] * JT-sleeping lobs a thought grenade into the channel, "Linux was never trying to be all things to all people, and no single OS has tried or succeeded"
[05:39:09] <DeadYak> umccullough: considering the amount of new VM code in the past week?
[05:39:14] <DeadYak> umccullough: not surprising :)
[05:39:16] <umccullough> DeadYak, precisely ;)
[05:39:17] *** JT-sleeping is now known as JonathanThompson
[05:39:42] * geist takes off, nukes the channel from orbit
[05:40:45] <JonathanThompson> I don't use any single OS exclusively.
[05:40:56] <JonathanThompson> They all suck at something :)
[05:41:00] <DeadYak> JonathanThompson: what about OSes in relationships?
[05:41:27] <JonathanThompson> Linux works well as a server OS, and BeOS works fairly well as a desktop OS, so complement each other fairly well.
[05:41:43] <JonathanThompson> But BeOS has distinct limitations even as a desktop OS with how I do things, personally.
[05:41:56] <cyan-Q6600> That's certainly true. Though like most users, I do use a single OS exclusively; I've just decided to live with the disadvantages to gain the advantages. I don't find any show-stoppers here, hence why one OS is enough for me.
[05:41:59] <JonathanThompson> Hopefully, Haiku fixes those issues as much as is possible with being backwards compatible.
[05:42:18] <cyan-Q6600> Limitations as a desktop OS? Moreso than other platforms?
[05:42:27] <JonathanThompson> Frankly, some of the oops in BeOS are deep design issues.
[05:42:43] <JonathanThompson> Yes, cyan-Q6600, as much as it seems unlikely you'd believe such an assertion.
[05:43:13] <umccullough> geist, still around?
[05:43:14] <JonathanThompson> With how I use GUI's, BeOS shows a distinct "SPLAT" factor when I hit the limits, that Windows 95 doesn't have a problem with.
[05:43:20] <cyan-Q6600> I don't believe BeOS to be perfect. But having had experience with the mainstream alternatives, I can't really see much that they do better, when it comes to the desktop.
[05:43:33] <DeadYak> cyan-Q6600: simple one: try opening more than 192 windows at once.
[05:43:34] <cyan-Q6600> Huh? In terms of window management, or performance?
[05:43:57] <umccullough> geist, if i see you this Sunday - you still interested in a commodore plus/4?
[05:43:58] <JonathanThompson> When it hits limits, it hits them hard, and without grace, cyan-Q6600.
[05:43:59] <DeadYak> cyan-Q6600: or 192 windows + offscreen bitmaps
[05:44:05] <cyan-Q6600> Yes, that's a definite shortcoming, and I've come close to that with Net+ windows before (I browse very messily).
[05:44:06] <DeadYak> which is much easier to hit
[05:44:16] <JonathanThompson> And I hit such things personally quite often.
[05:44:44] <JonathanThompson> And by design, there's absolutely no way to detect or prevent it that's not a full-fledged race condition in the attempt.
[05:44:56] <cyan-Q6600> DeadYak: There aren't many apps that use offscreen bitmaps in R5, surely? I know that kind of (memory intensive) trick is used in some systems like OS X to gain smoother window manipulation...
[05:45:04] <DeadYak> cyan-Q6600: want to bet?
[05:45:13] <JonathanThompson> HA HA  HA HA HA
[05:45:15] <DeadYak> cyan-Q6600: it's more or less a requirement for flicker free drawing
[05:45:33] <DeadYak> cyan-Q6600: a *lot* of stuff draws stuff to an offscreen bitmap, then DrawBitmaps that to the actual view.
[05:45:34] <JonathanThompson> A lot of applications keep hidden BFilePanel's in the background, too, which count towards that limit.
[05:45:39] <cyan-Q6600> And how many R5 apps do flicker-free drawing? The amount of flickering is practically blinding... everything flickers and tears (no vsyncing) everywhere...
[05:46:08] * JonathanThompson goes across the street to get dinner while the debate rages on
[05:46:11] <pyCube> that must be a result of all that 'designed for desktop"ness
[05:46:59] <cyan-Q6600> Well, to be fair, offscreen bitmaps are simply out of the question on a machine with 32MB of RAM. Even today, I'd be extremely nervous about doing it even on a modern system, especially if the window needs resizing. It seems the flickering could be fixed by correct synchronization with the vertical retrace...
[05:47:21] <DeadYak> there's a lot more to flickering than vsync
[05:47:26] <DeadYak> that'll only prevent tearing, nothing more
[05:48:36] <cyan-Q6600> If you perform the erase and redraw within the blanking period, then the flickering can't be seen. Obviously for massive redraws, that requires that the window redraw take place in thin horizontal strips...
[05:49:55] <DeadYak> good luck
[05:51:08] <cyan-Q6600> Does that mean it's impractical in Haiku?
[05:51:57] <DeadYak> it means it's impractical in general if you're not the only app controlling the screen
[05:53:12] <cyan-Q6600> What if there were some kind of intelligent queue that could tell the difference between erase and draw operations, and the app server scheduled the commands such that draws were never pending while erases had completed, during active scan?
[05:54:02] <geist> the newer way to do it is to let the 3d hardware do the window compositing
[05:54:13] <geist> double buffer everything, looks great, works like a champ
[05:54:47] <cyan-Q6600> Why 3D specifically? I've never understood what the rush was about that. The 2D blitter is good enough unless you're doing transparency or distortion effects, surely?
[05:55:02] <geist> note that i said '3d hardware'
[05:55:11] <cyan-Q6600> My concern with double buffering is memory usage, and also what happens when you resize a window. Surely that'll create a bunch of calls to malloc?
[05:55:19] <geist> yes it does
[05:55:30] <DeadYak> cyan-Q6600: that's why OSX for instance allocates a bitmap the size of the entire desktop for each window
[05:55:41] <DeadYak> also simplifies the compositing algorithm
[05:55:56] <cyan-Q6600> That sounds like a serious performance pain, depending on how quick the allocator is... Can it allocate a whole page at a time for speed?
[05:56:09] <cyan-Q6600> Ouch!!! No wonder OS X is such a memory hog...
[05:56:14] <geist> yup
[05:56:43] <DeadYak> eventually you'll see all those bitmaps allocated directly in graphics mem, but not yet
[05:57:00] <DeadYak> not sure if Quartz 2D Extreme does that or not
[05:57:17] <geist> i think they do
[05:57:22] <pyCube> isnt that what ram is for...space to do stuff in?
[05:57:29] <geist> or at least a copy of them in graphics mem
[05:57:48] <DeadYak> geist: I'd assume it'd have to in order to be able to accelerate the drawing ops to each bitmap
[05:58:00] <cyan-Q6600> Personally I'd hold off allocating stuff in VRAM until the direction of the industry becomes clearer. There's still a lot of small RAM cards (this one has 32MB), and AMD+ATi may be doing something interesting eventually, to make video cards obsolete...
[05:58:02] <geist> righto
[05:58:23] <pyCube> using all the ram available nowadays as an excuse to write leaky code is one thing.. but using ram to do neat stuff doesnt seem like a bad thing
[05:58:24] <geist> umm, i think it's pretty clear that video cards are going to be around
[05:58:38] <DeadYak> I don't think any modern graphics card has < 128MB lately
[05:58:43] <geist> yeah
[05:58:44] *** scanty has joined #haiku
[05:58:51] <cyan-Q6600> Matrox G550 PCIe. Bought it about a week ago...
[05:58:52] <DeadYak> the last time I had 32MB on a card was like...my G400 8 years ago
[05:58:58] <geist> and of course there are old machines around, but why design for that?
[05:59:14] <geist> why the hell did you buy that? what a total waste of money
[05:59:31] <cyan-Q6600> What will memory usage do if I have 30+ Netpositive windows open though? That's an awful lot of bitmaps.
[05:59:38] <geist> yup
[06:00:10] <geist> but also note that running old machines is not what new stuff is designed for. if you waited until every old machine was out of circulation we'd still be hacking code for c64s
[06:00:13] <cyan-Q6600> geist: Because it's the only card where the BeOS / Haiku drivers work properly for. Though I'm still ironing out a minor bandwidth issue related to the CRTC FIFO, that's a minor issue compared to the other cards...
[06:00:20] <DeadYak> cyan-Q6600: uhhhhhhhh
[06:00:27] <DeadYak> cyan-Q6600: works great on my Geforce
[06:00:30] <geist> cyan-Q6600: so do you not agree that that is an unusual situation?
[06:00:37] <DeadYak> cyan-Q6600: and my Radeon
[06:00:37] <umccullough> geist, want a commodore plus/4?
[06:00:38] <cyan-Q6600> DeadYak: PCIe Geforce? With video overlay?
[06:00:43] <geist> umccullough: yeah i guess
[06:00:50] <DeadYak> cyan-Q6600: video overlay, yes, PCIe Geforce, no
[06:00:57] <DeadYak> cyan-Q6600: PCIe Radeon, yes, Overlay, yes.
[06:01:02] <umccullough> geist, i could probably part with a c64 if you'd rather have that ;)
[06:01:10] <geist> nah, i have one of those
[06:01:14] <umccullough> ok
[06:01:19] <umccullough> i also have a vic-20
[06:01:23] <geist> though it doesn't work...
[06:01:24] <cyan-Q6600> DeadYak: Anything except PCIe is dead now. I needed a card that can go in today's slots, and give me overlay. And dual head -- the Radeon drivers can't do that.
[06:01:29] <scanty> do you have that C64 handy?
[06:01:32] <DeadYak> cyan-Q6600: yes they can
[06:01:33] <umccullough> not sure if mine works either :P
[06:01:35] <scanty> I want to know the serial number of the 6581
[06:01:41] <cyan-Q6600> DeadYak: Not for me they can't. The other head outputs no signal at all...
[06:01:42] <DeadYak> cyan-Q6600: are you stuck 6 years in the past or something?
[06:01:47] <DeadYak> works here.
[06:01:51] <umccullough> scanty, where do i find that?
[06:01:52] <geist> cyan-Q6600: but do you see the point here? because you have some highly specialized reason you have to buy old hardware doesn't mean that anyone else does
[06:01:56] <cyan-Q6600> DeadYak: What card are you using?
[06:02:01] <DeadYak> cyan-Q6600: X800
[06:02:06] <scanty> it's on the chip itself.
[06:02:07] <geist> any new card is 3d + a lot of ram
[06:02:10] <scanty> so you'd probably have to open up the bitch.
[06:02:18] <cyan-Q6600> DeadYak: I'm using the X300SE. I don't know why it isn't working, but it definitely isn't...
[06:02:21] <geist> therefore it'd be silly to actively assume it wont exist
[06:02:38] * umccullough opens the bitch
[06:02:39] <geist> and old hardware is not what new software is designed for anyway. most likely you wont get any revenue out of those machines anyway
[06:02:54] <scanty> umccullough, cool, thanks!
[06:02:55] <umccullough> looks like someone already pulled this apart, it's missing a screw
[06:03:09] <cyan-Q6600> How much memory are we talking, anyway? Has anyone actually made any ballpark guesses as to how much VRAM would be needed for typical heavy desktop use with double buffering?
[06:03:23] <scanty> umccullough, dont' worry, we're all missing a screw :)
[06:03:34] <geist> 64 or 128 will get you a decent way there
[06:03:54] <geist> my laptop here as 128 and it seems to be able to deal with heavy double buffered desktop usage
[06:04:11] <umccullough> scanty, mine says 6581 0384
[06:04:14] <cyan-Q6600> geist: What happens if the memory becomes exhausted? Can it roll back to single buffering, start swapping, etc.?
[06:04:21] <geist> yup
[06:04:25] <geist> that's what OSX does
[06:04:42] *** rcjsuen has quit IRC
[06:04:50] <geist> you dont generally notice when you exhaust the vram until you hit expose and it has to move all the windows simultaneously
[06:04:58] <geist> it'll slow down a bit, use the cpu some
[06:05:09] *** stargate1 has joined #haiku
[06:05:15] <geist> otherwise it's 'free' as far as the cpu is concerned. no hit at all
[06:05:15] <cyan-Q6600> I'm hoping Haiku won't end up another OS X clone, especially in terms of performance and memory usage. Though I guess if the windows are only as big as they need to be, that gets rid of most of the trouble...
[06:05:33] <geist> memory is cheap, go buy some more
[06:05:34] <DeadYak> making them as big as they need to be reintroduces the malloc issue.
[06:05:50] <DeadYak> that's precisely why that's *not* the way it's done
[06:05:55] <scanty> umccullough, what else is written on the chip there?
[06:06:06] <scanty> I'm looking for a revision number
[06:06:07] <umccullough> that it :P
[06:06:09] <scanty> Rn.
[06:06:20] <umccullough> i didn't pull it out - maybe something underneath?
[06:06:27] <scanty> nah, it should be on the chip itself.
[06:07:04] <cyan-Q6600> DeadYak: But if the memory is allocated a whole page at a time, free pages are kept on a linked list, and the MMU is used to make the pages appear contiguous, mallocing may not be a problem at all...
[06:07:15] <umccullough> nada
[06:07:22] <geist> sure, that's how VMs work
[06:07:41] <umccullough> you want the 6567R8 number?
[06:07:50] <DeadYak> there's still the issue of mem fragmentation for instance
[06:07:59] <geist> 64bit removes that problem
[06:08:10] <cyan-Q6600> Surely that's irrelevant for a system with an MMU, where a whole page is allocated at a time?
[06:08:16] <DeadYak> cyan-Q6600: um no.
[06:08:29] <geist> cyan-Q6600: he's talking about address space fragmentation
[06:08:43] <geist> ie, chopping up the 32bit address space enough tat you can't find a free run
[06:08:50] <scanty> umccullough, ah I guess it's unmarked then
[06:08:52] <geist> but like i was saying 64bit solves that
[06:08:53] <DeadYak> suppose you have 8MB. you alloc 3MB, then 1MB, then another 3MB, and then free that 1MB. if you then try to allocate 2MB, you will fail.
[06:08:56] <DeadYak> even though you have 2MB free.
[06:08:57] <scanty> probably an R2 or R3
[06:09:09] <umccullough> scanty, on the bottom it says AH024550
[06:09:11] <DeadYak> because you don't have a 2MB contiguous block in the virtual address space to alloc.
[06:09:15] <cyan-Q6600> Oh, fragmentation of the user address space, rather than physical memory?
[06:09:20] <DeadYak> yes.
[06:09:29] <scanty> 03 84 is the datecode.
[06:09:41] <DeadYak> the MMU can't magically make that go away
[06:10:02] <cyan-Q6600> Fair enough, but in the case of double buffering windows, I doubt that'd be a problem. You could just allocate virtual space for an entire 32768x32768 window, and bring real pages into that area as required...
[06:10:19] <DeadYak> cyan-Q6600: which is exactly what actually happens.
[06:10:46] <geist> thugh you should do that math
[06:10:59] <geist> 32768*32768*4
[06:11:15] <cyan-Q6600> A perfect fit =P
[06:11:45] <scanty> umccullough, thanks anyways :)
[06:12:32] <DeadYak> yeah, 32768x32768 would be kinda ow.
[06:13:21] <cyan-Q6600> That does go to show that we need to be pretty careful about memory usage until the 64 bit transition is over, though. Now we're in the unfortunate position where it's pretty affordable to fill the entire address space with physical RAM.
[06:16:39] *** stargater has quit IRC
[06:20:36] <cyan-Q6600> In any case, what about vsyncing? Once the windows are double-buffered, it surely becomes very easy to make sure the redraws occur at the correct time. Yet the only OS I've ever seen that vsynced was Mac OS 8/9, and possibly OS X (it's sometimes hard to tell with the latter).
[06:27:02] <geist> it's easy if you double buffer
[06:27:23] <geist> what you're seeing is probably not vsync
[06:27:28] <cyan-Q6600> Sure, but any idea if it's done in Haiku yet? I've not checked lately...
[06:27:29] *** scanty has quit IRC
[06:28:02] <cyan-Q6600> The "tearing" occurs in R5, which definitely doesn't vsync. Seems a very common theme with most GUIs...
[06:28:29] *** umccullough_lap has joined #haiku
[06:28:42] <geist> yes, guis that dont just draw the screen in the 3d accellerator (like OSX and vista does)
[06:29:08] <geist> if you let the app essentially draw directly on the screen you can't really control when it happens
[06:29:31] <JonathanThompson> Sure you can, geist: make the entire system cooperative multitasking! :)
[06:29:50] <cyan-Q6600> I usually put calls to WaitForRetrace() before doing something critical on-screen, but it seems that manually dragging a window in almost all OSs produces tearing; that's surely an easy one to fix...
[06:30:07] * JonathanThompson awaits cyan-Q6600's fixes
[06:30:21] <geist> are you sure you mean tearing and not the invalidated window bits?
[06:30:37] <cyan-Q6600> JonathanThompson: Maybe that's why Mac OS 9 was so good about vsyncing, ironically. If you didn't mind the entire system pausing when you click the mouse button, that is. =P
[06:30:37] <geist> because the latter is almost always far more of a nuisance
[06:30:54] <JonathanThompson> Quite possibly, cyan-Q6600.
[06:30:56] <JonathanThompson> Everything has a price.
[06:31:06] * geist fires up some more TF2
[06:31:11] <cyan-Q6600> Actual yearing, where the window is chopped in two, each in a different horizontal position due to updating during active scan.
[06:31:14] <cyan-Q6600> *tearing
[06:31:34] <geist> well, dunno then
[06:31:40] <geist> i think is a lot harder to solve than it sounds
[06:33:02] <pyCube> if i had to code while moving a window around, i might care more about things like tearing
[06:33:03] <cyan-Q6600> Maybe so; perhaps there's some kind of show-stopper issue with typical app server designs. It's pretty easy to vsync everything when programming games or demos though, and it's also quite effective to make sure video players and other GUI apps call vsync where required...
[06:33:44] *** DC1 has joined #haiku
[06:33:52] <geist> yeah, i could really care less about tearing
[06:34:03] *** DC1 has quit IRC
[06:34:17] <cyan-Q6600> pyCube: It's mostly an aesthetic issue; it's just ugly, similar to single-buffer flickering. That doesn't mean it shouldn't be fixed if it's easy to do so though.
[06:34:30] <geist> well think we've beat this dead horse
[06:34:39] <pyCube> heh
[06:36:07] *** pyCube has quit IRC
[06:36:08] *** umccullough_lap has quit IRC
[06:36:08] *** umccullough has quit IRC
[06:36:30] *** umccullough_lap has joined #haiku
[06:36:48] *** umccullough has joined #haiku
[06:37:18] *** umccullough_lap has quit IRC
[06:38:11] *** scanty has joined #haiku
[06:41:08] *** umccullough_lap has joined #haiku
[06:41:38] *** pyCube has joined #haiku
[06:46:40] <scanty> hey pyCube
[06:46:56] <pyCube> hi
[06:47:01] <scanty> what's new
[06:47:53] <pyCube> not much
[06:48:12] <scanty> i just got my camera to automagically mount
[06:48:16] <pyCube> trying to figure out where I want to move to
[06:48:17] <scanty> so I'm trying to get my photos from summer
[06:48:22] <pyCube> cool
[06:48:32] <scanty> http://ttl.nonlogic.org/eli/scanturkey.jpg
[06:49:02] <scanty> oh yeah, I remember you mentioned something about moving.
[06:49:05] <scanty> definitely don't come to NY :)
[06:49:08] <scanty> it's toxic.
[06:49:21] <pyCube> heh
[06:50:08] <umccullough_lap> scanty:  what's in the glass there?
[06:50:21] <scanty> tea
[06:50:53] <scanty> thought maybe some guys here would get a kick outta my shirt
[06:50:54] <scanty> :)
[06:51:04] <pyCube> the tea is way more interesting :-p
[06:51:05] *** Begasus has joined #haiku
[06:51:13] <pyCube> was it minty?
[06:51:35] <scanty> nope, I didn't get mint
[06:51:47] <scanty> it's funny though, the glasses are so tiny
[06:51:52] <scanty> you have to order like 4 teas
[06:52:06] <Begasus> morning peeps
[06:52:08] <scanty> but they cost about 50 cents.
[06:52:19] <scanty> hi Begasus
[06:52:28] <Begasus> hi scanty
[06:52:43] <Begasus> how's life there? ;)
[06:52:52] <scanty> Begasus, OK more or less.....
[06:52:55] <scanty> how about you?
[06:53:05] <cyan-Q6600> Hey Begasus
[06:53:09] <Begasus> things are finaly falling into place ;)
[06:53:18] <Begasus> hi cyan-Q6600  ;)
[06:53:21] <scanty> Begasus, that's good to hear.
[06:53:47] <Begasus> yeah .. it's been almost a year .. so looking forward to having a normal life again ;)
[06:54:06] * umccullough_lap isn't sure what "normal" is...
[06:54:23] <Begasus> 'lo umccullough ;)
[06:54:27] <DeadYak> umccullough_lap: I'm guessing "not sick"
[06:54:37] <umccullough_lap> hi Begasus
[06:54:40] * DeadYak pets Begasus
[06:54:48] <scanty> pyCube, good sheesha too... http://ttl.nonlogic.org/eli/scantsheesh.jpg
[06:54:51] <Begasus> not sick is not an option DeadYak ...
[06:54:59] <scanty> I think it was orange flavour.
[06:55:04] <Begasus> but maybe some regular live ;)
[06:55:05] <pyCube> heh
[06:55:46] <Begasus> meep ;)
[06:56:39] <scanty> I will upload more turkey pics tomorrow
[06:57:23] <scanty> i noticed GNOME is really slow at doing thumbnails.
[06:59:14] <umccullough_lap> what? gnome is slow?
[06:59:20] <umccullough_lap> ;)
[06:59:23] <scanty> hehe ^_^
[06:59:37] * umccullough_lap is using ubuntu on this laptop
[06:59:50] <scanty> i was using ubuntu for a while
[06:59:51] <umccullough_lap> the 1gb RAM helped significantly actually
[06:59:54] <scanty> but then i moved to gentoo.
[07:00:05] <umccullough_lap> i have no patience for gentoo
[07:00:18] <scanty> understandable.
[07:00:23] <pyCube> gutsy is nice..
[07:00:27] <scanty> whenever I ahve problems, I just let my buddy ssh in and fix them :)
[07:00:30] <umccullough_lap> my internet connection is crap here
[07:00:41] <scanty> where are you located?
[07:00:59] * Begasus is using ubuntu also on the laptop ;)
[07:01:18] <DeadYak> gentoo at work here
[07:02:07] <scanty> I don't know, I kind of like gentoo
[07:02:14] <scanty> no nonsense.
[07:02:53] <Begasus> never really try'd gentoo ..
[07:02:59] <Begasus> ubuntu will do for now ;)
[07:03:32] <cyan-Q6600> 'No nonsense'?
[07:05:05] <umccullough_lap> scanty: i live in a rural part of california
[07:05:15] <scanty> ah
[07:06:25] <scanty> umccullough, is there any way I can install BeOS to a new PC (meaning it needs new IDE drivers)?
[07:06:50] <Begasus> define 'new pc' ;)
[07:07:00] <umccullough_lap> scanty: eh?
[07:07:05] <cyan-Q6600> That sounds familiar. Non-native supported IDE controllers?
[07:07:16] <scanty> P4 with IDE controller that is not supported by a BeOS CD
[07:07:38] <umccullough_lap> SATA?
[07:07:45] *** BePower has joined #haiku
[07:07:45] <scanty> nono, regular IDE.
[07:07:46] <cyan-Q6600> Old enough where the IDE replacement drivers might support it?
[07:07:52] <umccullough_lap> scanty: try beos max
[07:07:55] <scanty> IDE replacements do support it.
[07:07:58] <umccullough_lap> it uses the ide replacement driver
[07:08:03] <scanty> but I don't want BeOS max!
[07:08:06] <scanty> I want regular R5
[07:08:08] <umccullough_lap> bah!
[07:08:09] <Begasus> hehe
[07:08:09] <scanty> or dano maybe
[07:08:10] <umccullough_lap> ;)
[07:08:21] <cyan-Q6600> Do you have access to another machine with natively supported controllers?
[07:08:27] <umccullough_lap> mmadia has a website with boot floppies
[07:08:34] <scanty> I don't own a floppy drive :(
[07:08:40] <Begasus> tsss ...
[07:08:47] <umccullough_lap> ok, you're options are slowly depleting
[07:08:48] <scanty> cyan-Q6600, sort of.... it needs a power supply.
[07:09:20] *** BePower has quit IRC
[07:09:21] <umccullough_lap> beos max can be cleaned up enough that it runs kinda like regular R5
[07:09:49] <cyan-Q6600> scanty: I usually find Personal Edition pretty useful in situations like this; the files can be copied from the Pro CD to "upgrade" it afterwards. Stick the IDE replacements onto the "virtual" partition, get the image file across somehow (CD, etc.), boot it up and then install...
[07:10:01] <Begasus> how's progress on that? ... haven't seen vasper in a while ...
[07:10:18] <scanty> hmm I will have to figure out something.
[07:10:25] <scanty> I want to bring my NES emulator up to speed for BeOS people
[07:10:28] <scanty> before releasing all the code
[07:10:48] <umccullough_lap> scanty, you can make your own bootable cd using an image from here: http://mmadia.zelect.org/files/boot_archive/
[07:10:49] <Begasus> w00t ;)
[07:11:10] <scanty> oh, cool
[07:11:13] <scanty> then I will have to try that.
[07:11:30] <Begasus> scanty, if you have something to post in regard of the emulator let me know ;)
[07:11:45] <scanty> will do.
[07:11:49] <umccullough_lap> for the "image.be" track you could use a PE image
[07:11:57] <scanty> soon as I get BeOS running, I will update the port.
[07:12:04] <Begasus> ;)
[07:12:05] <stargate1> i hate BColumnListView
[07:12:06] <scanty> (assuming BeOS libstdc++ is recent enough)
[07:12:28] <scanty> that's probably going to be the biggest hurdle.
[07:12:29] <umccullough_lap> scanty:  there's a newer one with the latest gcc 2.95.3 on bebits
[07:12:35] <umccullough_lap> fixes some issues
[07:12:38] <scanty> ah
[07:12:49] <scanty> we use STL and friends heavily.
[07:12:50] <Begasus> where have you been these last years? :P
[07:12:57] <umccullough_lap> instructions are in the archive
[07:13:04] <scanty> who, me?
[07:13:07] <Begasus> yeah ;)
[07:13:14] <scanty> not using BeOS.... that's the problem
[07:13:15] <scanty> :^)
[07:13:27] <Begasus> ^^
[07:13:35] <scanty> last winter, my BeOS drive died
[07:13:38] <scanty> with all my projects on it.
[07:13:50] <scanty> only thing saved was the emulator since it was in my friends cvs server
[07:14:33] <Begasus> yeah you told that ... to bad you couldn't save anything from the hd
[07:15:37] <scanty> eh, such is life.
[07:15:40] <scanty> or my life, at least ^_^
[07:16:43] <scanty> cyan-Q6600, are you this (http://www.emulationzone.org/projects/cyan/mainp.htm) cyan?
[07:17:04] <cyan-Q6600> Yep. Why's that?
[07:17:38] <scanty> I remember your site from a long time ago (I like the design a lot)
[07:17:42] <scanty> and I was just wondering if it was you.
[07:18:46] <cyan-Q6600> Cool, thanks. Yeah, that site's been around a while, though mostly neglected =P
[07:18:47] *** stargate1 has quit IRC
[07:20:11] <scanty> i finally got some webspace and have been super reluctant to put my site back up
[07:20:17] <scanty> eh, more like lazy :)
[07:21:43] <cyan-Q6600> Heh, websites can be such a hassle, can't they? =P
[07:22:05] <Begasus> indeed ;)
[07:23:29] <scanty> yeah
[07:24:22] <cyan-Q6600> Say, has anyone ever seen a problem in BeOS where windows can't be brought to the foreground? It's just this second kicked in for me again...
[07:25:05] <cyan-Q6600> I guess that's why blogs are so popular, "Web 2.0" and all...
[07:25:17] <scanty> yeah, because you don't have to do anythign really.
[07:25:24] <scanty> although my website is fairly template-ish
[07:26:41] * scanty would move back to BeOS in a heartbeat if gnubg ran natively :)
[07:26:58] <cyan-Q6600> gnubg?
[07:27:01] <umccullough_lap> what is gnubg?
[07:27:02] <umccullough_lap> ;)
[07:27:19] <scanty> http://ttl.nonlogic.org/eli/incoming/whooping_gnu_ass_2.png
[07:28:16] <umccullough_lap> oh, backgammon
[07:28:49] <cyan-Q6600> Aah, killer app. =P
[07:29:15] <scanty> yeah :)
[07:29:18] <cyan-Q6600> Are those SVG icons in the "dock"?
[07:29:54] <scanty> yeah
[07:31:06] <Begasus> probly gtk app scanty
[07:31:07] *** umccullough_lap has quit IRC
[07:31:21] <scanty> it sure is :)
[07:31:50] <Begasus> makes it hard to port ;)
[07:31:51] <cyan-Q6600> Crikey, so Gnome now draws on Windows, Mac OS X and Haiku? =P
[07:32:35] <cyan-Q6600> Has anyone ever attempted a gtk wrapper?
[07:33:06] <Begasus> probly ;)
[07:33:17] <scanty> given the ugliness of GTK.... I dunno.
[07:33:40] <scanty> programming really isn't as fun for me without BeAPI
[07:33:48] <scanty> so I've been dorking with my NES mostly these days.
[07:34:58] <Begasus> I'm still focused on porting the games ;)
[07:35:05] <cyan-Q6600> I'd actually like to see a C API for coding BeOS apps, specifically to make it more fun. Though yeah, it's hard to beat coding for consoles =P
[07:35:42] <scanty> yeah
[07:36:35] <scanty> linux is nice though, since you can do direct IO
[07:36:44] <scanty> well, actually you can do it in BeOS too now that I recall
[07:37:30] <cyan-Q6600> Direct IO? I thought Linux throws a protection exception if you use stuff like that, like BeOS does?
[07:37:58] <scanty> well, in linux, if you're root you can do a iopl() or ioperm()
[07:38:09] <scanty> in BeOS you can use the undocumented read_isa_io() and write_isa_io()
[07:38:17] <scanty> although when I was nesdevving in BeOS, I used a driver
[07:38:20] <cyan-Q6600> For in / out instructions?
[07:38:35] <scanty> yeah
[07:39:10] <cyan-Q6600> Aah. How does that relate to NES development? Hooking up development boards via the parallel port?
[07:39:21] <scanty> you could do something like uint8_t ret = read_isa_io(0x0, 0x378, 1); (or something like that)
[07:39:28] <scanty> cyan-Q6600, yeah, my devkit is parallel port based
[07:39:48] <scanty> http://ttl.nonlogic.org/eli/incoming/devshit.jpeg
[07:39:51] <scanty> you can kind of see there.
[07:40:28] <cyan-Q6600> Homebrew?
[07:40:35] <scanty> and if you have an emulator handy, you can run my very first NES demo from 3 or 4 years ago http://ttl.nonlogic.org/eli/incoming/belogo.nes
[07:40:37] <scanty> yep
[07:40:47] <cyan-Q6600> Cool!
[07:40:56] <scanty> http://ttl.nonlogic.org/eli/incoming/copynes_proto.png
[07:40:57] <scanty> that's the proto.
[07:41:12] <scanty> friend of mine designed the kit
[07:41:22] <scanty> soon after I built the proto, he did a PCB run
[07:41:26] <scanty> so that's what you see in the first pic
[07:41:31] <scanty> (it all fits into the NES case)
[07:41:55] <scanty> the cart's "custom" too.
[07:42:07] <scanty> removed the ROMs and put SRAMs instead, with some minor rewiring
[07:42:55] <scanty> here you can see me running SMB1 off the RAM cart in linux http://ttl.nonlogic.org/eli/incoming/copynes_linux.jpeg
[07:43:41] *** cyan-Q6600-2 has joined #haiku
[07:44:05] <cyan-Q6600-2> Sorry, disconnected...
[07:44:23] <scanty> <scanty> http://ttl.nonlogic.org/eli/incoming/copynes_proto.png
[07:44:24] <scanty> <scanty> that's the proto.
[07:44:24] <scanty> <scanty> friend of mine designed the kit
[07:44:24] <scanty> <scanty> soon after I built the proto, he did a PCB run
[07:44:24] <scanty> <scanty> so that's what you see in the first pic
[07:44:25] <scanty> <scanty> (it all fits into the NES case)
[07:44:26] <scanty> <scanty> the cart's "custom" too.
[07:44:28] <scanty> <scanty> removed the ROMs and put SRAMs instead, with some minor rewiring
[07:44:31] <scanty> <scanty> here you can see me running SMB1 off the RAM cart in linux http://ttl.nonlogic.org/eli/incoming/copynes_linux.jpeg
[07:44:34] <scanty> oops, sorry I meant to priv that
[07:44:35] <scanty> :(
[07:44:44] <Begasus> hehe
[07:45:24] <cyan-Q6600-2> Have you hit any trouble with games trying to write to ROM?
[07:46:29] *** DeadYak has quit IRC
[07:46:43] <scanty> well, I tie the write enable to ground.
[07:46:49] <scanty> so nobody can touch the contents of the RAMs
[07:47:06] <scanty> but tbh, I've not had the need to go for a more fancy cart where writing to ROM space is necessary for bankswitching.
[07:47:37] <scanty> or was it /WE to Vcc.
[07:47:40] <scanty> no matter
[07:47:57] * JonathanThompson notes scanty needs a Data Diaper
[07:48:08] <scanty> hi JonathanThompson
[07:48:13] <JonathanThompson> Wassup, scanty?
[07:48:26] <scanty> not too much -- BeOS in Turkey: http://ttl.nonlogic.org/eli/scanturkey.jpg
[07:48:44] <scanty> in the process of getting my pics off my digicam
[07:48:51] <JonathanThompson> That's you?
[07:48:52] <scanty> how've you been?
[07:48:56] <scanty> yeah
[07:49:11] <JonathanThompson> Oh, working at the local Yahoo! office, eating cake, doing SDET work, it seems...
[07:49:34] <scanty> sounds fun.....
[07:49:37] * JonathanThompson remembers he must always insert a random comment about reality into descriptions
[07:49:40] <cyan-Q6600-2> Aah. I've not really had any similar problems with my Megadrive dev board either, but I've written a few programs that assume ROM is really read-only before. I see you've point-to-point wired that proto; do you find that works out better than stripboard?
[07:49:43] <JonathanThompson> Even though the random comment today was true.
[07:50:10] <scanty> cyan-Q6600, yeah, I like point to point better because it allows greater flexibility in layout.
[07:50:48] <scanty> f.ex. something like this http://ttl.nonlogic.org/eli/incoming/nixpsu_board.png (a SMPSU,which is layout sensitive) probably wouldn't work out well on a stripboard.
[07:51:16] <scanty> and even that layout could be optimised.
[07:51:23] <cyan-Q6600-2> It's pretty neatly done. I can't seem to avoid things becoming a huge rat's nest that way...
[07:51:24] <scanty> but I'm netting about 75-80% efficiency as is.
[07:51:43] <scanty> if I don't do it neatly, I have no chance of debugging.
[07:51:52] <scanty> that's something I learned early on.
[07:51:55] <cyan-Q6600-2> What's the PSU for?
[07:52:09] <scanty> NIXIE tube clock
[07:52:25] <scanty> http://ttl.nonlogic.org/eli/incoming/nixproto_running.jpg (proto)
[07:52:46] <scanty> "production" driver board: http://ttl.nonlogic.org/eli/incoming/nixie_board_new.png
[07:53:36] <cyan-Q6600-2> Cool! What kind of supply rails does that need? Something other than rectifying the power line?
[07:53:56] <scanty> I expect the clock to be completely done by next monday.
[07:54:10] <scanty> it needs three supply rails (though I could've gotten by with two)
[07:54:15] <scanty> +5V for the MCU
[07:54:24] <scanty> +12V for those PLCC devices
[07:54:31] <scanty> (whcih are 32-channel open-drain shift registers)
[07:54:36] <scanty> and 180V for B+ on the tubes
[07:54:46] <scanty> the SMPSU generates the 180V
[07:54:53] <scanty> from +15V in
[07:55:41] <cyan-Q6600-2> Where does the 12V actually go, after those chips? To grids in the tubes?
[07:56:07] <scanty> nope, the 12V is used exclusively as supply voltage for the shift registers.
[07:56:14] <scanty> they're some weird kind of CMOS.
[07:56:32] <scanty> so I used a CD4504B level shifter to interface them to the MCU
[07:56:35] <cyan-Q6600-2> Weird. They actually demand 12V, rather than just running up to that?
[07:56:53] <scanty> welll, I have read in places that people have successfully run them at +5V
[07:57:00] <scanty> but the datasheet says 12C
[07:57:02] <scanty> 12V*
[07:57:09] <scanty> so I like to follow the datasheets
[07:57:46] <cyan-Q6600-2> Yeah, me too, at least in terms of hardware design. It's software's job to violate the specs. =P
[07:58:01] *** cyan-Q6600 has quit IRC
[07:58:04] <scanty> hehe
[07:58:22] <scanty> there must be a reason why the datasheet specifies 12V.
[07:58:30] <scanty> so IMO, if you're running at 5V, then y ou're being silly
[07:59:34] <cyan-Q6600-2> Maybe it's some kind of rebellion against the low voltage 1.8V movement. =P
[07:59:44] <scanty> hehe
[08:00:00] <scanty> I'm going to start getting into programmable logic (FPGAs) where everything is 3.3V.
[08:00:15] <scanty> I have a spare NOS NES CPU, so I'm going to make a hardware NSF player
[08:00:22] <cyan-Q6600-2> They still run at 3.3V?
[08:00:25] <scanty> and use the FPGA for all the glue logic.
[08:00:32] <scanty> well, maybe not all of them
[08:00:44] <scanty> but the particular one I'm getting a devkit for runs at 3.3V
[08:00:54] <scanty> so I'm going to need a couple of bus switches to interface to the NES CPU
[08:00:55] <cyan-Q6600-2> Cool... better make sure the FPGA is small enough, otherwise you could just suck the CPU into it...
[08:01:14] <scanty> yeah, I mean, I could do the NES CPU on the FPGA as well
[08:01:21] <scanty> but this will be my first foray into FPGA stuff
[08:01:25] <scanty> so iw ant to try and keep it simple.
[08:01:29] <scanty> as possible.
[08:01:41] <cyan-Q6600-2> Ah. Any idea if the FPGA has 5V-tolerant inputs?
[08:01:50] <scanty> and then I don't have to worry about debugging the CPU, and doing the sound hardware too.
[08:01:58] <scanty> it is definintely not 5V tolerant.
[08:02:08] <scanty> except the devkit has got a PS2 port, but that's open collector
[08:02:13] <scanty> so you can use 5V with that.
[08:02:27] <scanty> (not really much help to me)
[08:03:36] <cyan-Q6600-2> Maybe a resistor array and some diodes (to the 3.3V rail) would be sufficient to clamp things down...
[08:04:26] <scanty> yeah, it's possible, but it seems like such a hack if I can use a bus switch instead
[08:04:36] <scanty> I'm goin to be building it around this: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=39&No=14
[08:04:47] <scanty> entry-level Altera cyclone-1 devkit
[08:04:50] <scanty> does video and audio out
[08:04:52] <scanty> and has a CF slot
[08:04:57] <scanty> so that's how I will load the NSFs
[08:05:16] <cyan-Q6600-2> I usually prefer the discrete approach for stuff like level matching, mainly because it's such a hassle to keep enough parts on hand for every possible scenario...
[08:05:55] <scanty> yeah, but I'm thinking a proper level shifter will need at least one transistor and a resistor for each channel
[08:06:05] <scanty> whereas I can get 10 channel bus switch in one IC
[08:06:09] <cyan-Q6600-2> Ah, FPGA already soldered, too. That looks like it'll save a huge amount of hassle all by itself...
[08:06:17] <scanty> yep
[08:06:36] <scanty> and you interface to it with those 40-pin hard-drive type connectors
[08:07:52] <scanty> was thinking to interface it to a nice VFD display, or maybe a small colour LCD
[08:07:55] *** phadi has quit IRC
[08:08:08] <cyan-Q6600-2> Does anyone make an FPGA that's viable to solder at home (without involving the kitchen oven), perhaps in a more coarse package?
[08:08:36] <scanty> nope, but you can get CPLDs in PLCC packages
[08:08:44] <cyan-Q6600-2> You could probably get VGA out of it pretty easily, with a simple resistor array DAC...
[08:08:58] <scanty> it can already drive VGA
[08:09:20] <scanty> and you could use through-hole PLCC sockets
[08:09:26] <scanty> (like I did in my nixie driver board)
[08:09:37] <scanty> they're a bit annoying to solder because there's a high pin density.
[08:09:39] <scanty> but I use 30awg
[08:09:40] <cyan-Q6600-2> Aren't CPLDs quite a bit less dense though?
[08:09:42] <scanty> so it wasn't too bad
[08:09:47] <scanty> yeah, they are
[08:09:57] <scanty> if you want density, you're limiited to QFP packages.
[08:10:01] <scanty> which are not fun to solder
[08:10:31] *** phadi has joined #haiku
[08:11:02] <cyan-Q6600-2> Yeah, I just can't see how to do it without ruining hundreds of devices. It's difficult enough making boards accurate enough let alone soldering it...
[08:11:22] <scanty> I never really worked with SMT devices yet
[08:11:29] <scanty> but from what I read, it's a lot to do with surface tension
[08:11:36] <scanty> and good amounts of flux
[08:11:43] <scanty> and the solder will kind of flow where it should
[08:12:20] <cyan-Q6600-2> Yeah, I've heard stories about the devices magically aligning themselves when heated, but for me it seems to do exactly the opposite, and the device ends up with exactly four very wide pins, one on each side =P
[08:12:41] <cyan-Q6600-2> I guess flux could be the answer. Sounds messy...
[08:14:00] <cyan-Q6600-2> How dense is this FPGA?
[08:14:49] * JonathanThompson hands cyan-Q6600-2  a bunch of quantum flux capacitors
[08:15:10] <scanty> yeah, a dab of flux helps
[08:15:19] <scanty> and if you bridge the pins, it's ntoa big deal because you can fix it later
[08:15:36] <scanty> I'm not sure exactly how many LEs it has
[08:15:45] <JonathanThompson> As long as you don't turn it on first and let the magic smoke out for certain situations? :)
[08:16:12] * JonathanThompson has seen op-amps explode from incorrect wiring
[08:16:31] <cyan-Q6600-2> Cool =P
[08:16:34] <cyan-Q6600-2> High current supply?
[08:16:42] <JonathanThompson> That was a LONG time ago.
[08:16:44] * scanty seen MOSFETs explode
[08:16:50] <scanty> and regular transistors too
[08:17:07] <JonathanThompson> Electrolytic capacitors have that weird indentation on top for the sake of blowing up in a known way :P
[08:17:12] <cyan-Q6600-2> Yeah, those are always fun. I lost a motherboard that way once.
[08:17:21] <scanty> in my SMPSU during prototyping, I blew up a few transistors and two FETs
[08:17:29] <scanty> since I use a push-pull amp to drive the FET harder....
[08:17:38] <scanty> it requires a PNP and NPN transistor
[08:17:39] <JonathanThompson> Pencil leads between enough voltage is an entertaining heater.
[08:17:41] <scanty> and I hoooked them up wrong
[08:17:52] <scanty> (PNP was where NPN should have been, and vice versa
[08:18:00] *** MrSunshine has quit IRC
[08:18:01] <JonathanThompson> (Until a fire breaks out if left long enough)
[08:18:04] <scanty> and as soon as I turned it on, they started cooking
[08:18:20] <scanty> but you learn.
[08:18:33] <scanty> if you hook up a FET wrong, the only "bad" thing that could happen is the diode body will conduct
[08:18:36] <cyan-Q6600-2> JonathanThompson: I found that tends to happen pretty quickly with standard pencils...
[08:18:42] <scanty> so you just flip it round, and should be OK
[08:19:01] * etteyafed wonders what makes the true hw monkies tick.
[08:19:08] <scanty> anyways, I gotta get some sleep
[08:19:14] <scanty> I'll catch up with you guys tomorrow
[08:19:17] <cyan-Q6600-2> I guess with bipolar transistors you've also got the worry about the time taken to get out of saturation, though I think you need to be running pretty quick for that to be a problem...
[08:19:23] <JonathanThompson> Yeah, I need to get ready for bed, and I'm several timezones west :)
[08:19:26] <JonathanThompson> Seeya, scanty.
[08:19:31] <scanty> 'nite
[08:19:40] <JonathanThompson> That, and hope they take their meds, cyan-Q6600-2.
[08:19:40] <cyan-Q6600-2> Seeya
[08:19:50] <scanty> if you bias your transistors properly, shouldn't run into many problems.
[08:19:58] <scanty> unless you do what I did and misread part numbers
[08:20:05] <JonathanThompson> POOF!
[08:20:12] <scanty> smelly poof to boot
[08:20:32] <scanty> anyways nite guys.
[08:20:33] <scanty> nice chattting
[08:20:37] * JonathanThompson can't wait until room temp superconductors are common
[08:21:04] <JonathanThompson> I imagine they could be used as explosive devices, if done (in)correctly.
[08:21:13] <cyan-Q6600-2> Bye!
[08:21:20] *** scanty has quit IRC
[08:21:46] <cyan-Q6600-2> JonathanThompson: Even when there's no heating involved?
[08:21:58] <etteyafed> I just allways that engineers designed hw in a CAD like computer program and machines built it.
[08:22:14] <JonathanThompson> cyan-Q6600-2, once you have a way to dissipate the current through something else, and it can put a large enough voltage through it to generate a high current, sure.
[08:22:57] <JonathanThompson> For example, a wrench could become one heck of a weapon like that.
[08:23:14] <JonathanThompson> It could become a wrench-grenade, in theory.
[08:23:20] *** judgen has joined #haiku
[08:23:30] <etteyafed> A wrench can be a pretty good weapon if anyway it it is big enough.
[08:23:35] <JonathanThompson> (Just make sure it has a timer before the current goes through so you can throw it before it starts)
[08:23:36] <judgen> Howdy
[08:23:41] <cyan-Q6600-2> What, if you drop it into a machine that's using superconductors and high currents?
[08:23:45] <JonathanThompson> Greetings, judgen.
[08:23:56] <JonathanThompson> Get out of the area quickly, cyan-Q6600-2 :)(
[08:24:15] <JonathanThompson> If you're lucky, it won't complete a circuit.
[08:24:58] <judgen> cyan-Q6600-2 put it in cold oil, and youll not have any conduction.
[08:25:09] <JonathanThompson> Fortunately, it seems unlikely most of us will have such a hazard to deal with :)
[08:25:18] <cyan-Q6600-2> That could get really interesting. It's already pretty exciting with switching supplies running on the bleeding edge, and CPUs drawing over 100A of current. Could be really great when they're drawing a few tera-amps...
[08:25:44] * JonathanThompson suspects cyan-Q6600-2 has been watching too much Star Trek
[08:25:58] <judgen> cyan-Q6600-2 i want my stuff to use as little power as possible compared to the performance...
[08:26:22] <judgen> btw anyone looked into the new Pa Semi dualcore PPC CPU?
[08:26:33] <JonathanThompson> Not really, judgen.
[08:26:37] <cyan-Q6600-2> But the voltage is constantly dropping; surely the current is just going to keep rising? When they get down to 1nm process size, it'll probably need 0.1V or something...
[08:27:01] <JonathanThompson> It takes bulk for current, cyan-Q6600-2.
[08:27:16] <JonathanThompson> That's why power transmission tends to be done as at high of a voltage as possible.
[08:27:26] <etteyafed> I heard something about IBM running a research CPU at 300Ghz cooled to near-absolute zero.
[08:27:39] <cyan-Q6600-2> But if the chip were superconducting, they could have currents that high on a small die pretty easily...
[08:27:45] <JonathanThompson> If the power generators only output 120 volts, the current would be huge, and it'd need thick bars of metal to transmit it.
[08:28:18] <JonathanThompson> Also, the power loss would be huge, assuming non-superconductors.
[08:28:20] <cyan-Q6600-2> etteyafed: Did they mention current requirements?
[08:28:45] <etteyafed> I Can't recall actually, sorry.
[08:28:57] * JonathanThompson notes etteyafed isn't good for much tonight :)
[08:29:42] <judgen> etteyafed ibm has ran their blades in 3000ghz, but not on a single cpu.
[08:29:46] <judgen> just as a cluster
[08:30:46] <cyan-Q6600-2> judgen: I thought they were playing around with other semiconductor technologies, like GaAs, to reach those frequencies?
[08:31:53] <JonathanThompson> If they were running at 3 THz, were they using in-order execution cores, like the SPE's of the Cell?
[08:32:29] <etteyafed> The thing i am talking about was on a single die
[08:32:49] <JonathanThompson> Even so, was it an in-order execution processor core?
[08:33:23] <cyan-Q6600-2> I would imagine at this stage, the CPU would be as simple as possible to prove the ability of the transistors to operate at that frequency at all...
[08:33:31] *** cyrann has quit IRC
[08:33:46] <JonathanThompson> That's why I'm thinking an in-order core, to reduce the stages of pipeline.
[08:34:09] <JonathanThompson> Besides, how much RAM could they feed even the most inefficiently designed core with, running at that speed?
[08:35:05] <judgen> http://www.top500.org/system/8372
[08:35:08] <judgen> look at this cray
[08:35:54] <cyan-Q6600-2> It'd probably have to be directly on the die to make it possible at all... perhaps the system RAM would be a few MB of local storage, and external DRAM would be used almost like a swap file.
[08:36:13] <judgen> that cray computer is 60,8712mhz =)
[08:36:23] <judgen> oh i ment 60,8712GHZ!
[08:36:44] <JonathanThompson> And around 50 TB of physical RAM :P
[08:36:49] <judgen> hehe
[08:37:10] <JonathanThompson> (Might be enough to work on part of the Yahoo! search data at once)
[08:37:27] <cyan-Q6600-2> You'd need some pretty nicely multithreaded code to make any use of that =P
[08:37:35] <etteyafed> http://jo-san.it/blogs/denis/archive/2006/06/21/4586.aspx a transistor.
[08:37:42] <judgen> actually JonathanThompson its 92,064gb of memory
[08:38:12] * JonathanThompson wonders how judgen did his math
[08:39:14] <judgen> en> actually JonathanThompson its 92,064gb of memory
[08:39:15] <judgen> * JonathanThompson wonders how j
[08:39:31] <judgen> 11,706 with 8 gb each is 92,064gb
[08:39:34] * JonathanThompson still wonders
[08:39:43] * JonathanThompson now sees how judgen made the mistake
[08:39:52] <JonathanThompson> Only part of those have that much RAM.
[08:39:59] <judgen> oh
[08:40:06] <judgen> still amazing power
[08:40:10] <cyan-Q6600-2> Yeah, only the I/O nodes have the full 8GB.
[08:40:25] <judgen> im impressed that they run suse on it.
[08:40:26] * JonathanThompson wouldn't want to pay the electric bill for that bastard and its facilities
[08:40:31] <judgen> hehe
[08:40:50] <judgen> wonder if it would be fast enough to run compiz-fusion =P
[08:40:52] <judgen> haha lol
[08:41:31] <JonathanThompson> It might do a decent job at computing a complex neural net :)
[08:41:33] <cyan-Q6600-2> What's the fastest supercomputer for single-threaded code? This thing would actually perform worse than this machine if hit with a single thread...
[08:42:05] <JonathanThompson> Certainly not x86-based, cyan-Q6600-2.
[08:42:32] <judgen> http://www.top500.org/system/7747
[08:42:43] <judgen> BlueGene/L boasts a peak speed of over 360 teraFLOPS, a total memory of 32 tebibytes, total power of 1.5 megawatts, and machine floor space of 2,500 square feet. The full system has 65,536 dual-processor compute nodes. Multiple communications networks enable extreme application scaling:
[08:42:46] * JonathanThompson leaves that as a research question for cyan-Q6600-2 to figure out if he desires
[08:42:46] <judgen> WHACK!
[08:43:21] <JonathanThompson> Definitely don't want to pay that power bill :)
[08:43:35] <judgen> now were talking megawatts!
[08:43:44] <cyan-Q6600-2> Ooh, 1.5MW. I bet ACPI will come in handy for taming the power demands there. =P
[08:43:58] <JonathanThompson> Imagine how long it'd take it to power back up :P
[08:44:34] <cyan-Q6600-2> I guess you could bring up all nodes at the same time, if you didn't mind collapsing the supply voltage to the entire nation for 20 seconds or so...
[08:44:41] *** kr1stof has joined #haiku
[08:45:01] <JonathanThompson> I don't think it'd take down THAT much of a grid, at least in the US.
[08:45:26] <JonathanThompson> You need to keep in mind what sort of power usage happens in large factories.
[08:45:49] <JonathanThompson> Still, starting that up while providing stable power rails to all the nodes would be interesting.
[08:46:14] * etteyafed is still drooling over judgen's link
[08:46:18] <JonathanThompson> I'm betting there's a friggin' huge battery system for UPS and averaging out such demands in place.
[08:46:55] * JonathanThompson remembers being in KMart's world headquarters in their computer room in the late 80's on a field trip
[08:47:24] *** cyrann has joined #haiku
[08:47:25] <JonathanThompson> Far larger than 2500 square feet, and much less online storage, despite all the washing machine-sized banks of winchester hard drives, etc.
[08:47:30] <cyan-Q6600-2> Actually, 1.5MW sounds like a pretty low power consumption considering how many nodes there are...
[08:47:59] <judgen> it seems that nowdays linux actually is the operating system of 80% of all the worlds top 500 super computers
[08:48:37] <etteyafed> not much else
[08:48:42] <cyan-Q6600-2> The previous one used Linux on the I/O nodes, but some kind of microkernel for the actual clusters...
[08:48:43] <JonathanThompson> The Linux on that Jaguar is only for interfacing with humans, it appears: every compute node uses Unicos.
[08:48:48] <etteyafed> maybe aix is the next up
[08:48:58] <JonathanThompson> I'm not certain Unicos is a microkernel.
[08:49:16] <cyan-Q6600-2> I think the article mentioned a microkernel; not sure if it's accurate.
[08:49:35] <judgen> UNICOS is not a microkernel. UNICOS MAX is a microkernel
[08:49:36] <JonathanThompson> If they're interested in minimizing system overhead, not likely to be accurate :)
[08:49:52] <etteyafed> Catamount microkernel on the compute nodes. Catamount is designed to minimize system overhead, thus allowing scalable low-latency global communication.
[08:50:41] <etteyafed> I love software and massive computers
[08:50:59] <etteyafed> better than a good beer
[08:51:02] <cyan-Q6600-2> I'm not sure it'd make a much difference in an application like that... if a node needs to communicate with another node, then performance basically goes out the window anyway. You'd probably need to write it so that each thread stays as self-sufficient as possible...
[08:51:10] * JonathanThompson sees if wikipedia has useful stuff on it
[08:51:11] <judgen> An no Cray computer is using a UNICOS microkernel anymore afaik. They use catamount and the mono UNICOS.
[08:52:06] <JonathanThompson> catamount is distinctly not usefully listed in Wikipedia for the OS.
[08:53:07] <judgen> JonathanThompson http://www.cs.sandia.gov/~smkelly/SAND2005-2780C-CUG2005-CatamountArchitecture.pdf
[08:53:25] <etteyafed> I wonder how much something like that would cost
[08:54:04] <cyan-Q6600-2> The actual hardware?
[08:54:07] <judgen> etteyafed the Cray or the eServer?
[08:56:44] <cyan-Q6600-2> Yikes, Catamount uses 2MB pages. Looks like they're sparing no expense...
[08:57:49] *** phadi has quit IRC
[08:58:20] <cyan-Q6600-2> It'd be great to see something like that on the desktop, using shaders as the computing engine.
[08:58:38] *** kokito has quit IRC
[09:00:21] <judgen> haha
[09:00:50] <judgen> no need at all for a t&l unit to render anything with that kind of flops.
[09:02:29] <JonathanThompson> A modern x86 processor has no problem with using 2 MB VM pages, but the OS must be setup to handle that.
[09:02:34] <cyan-Q6600-2> Yeah, I think that's ultimately where the industry is going to go. Some tasks are inherently single-threaded, while others can be parallelized almost beyond limit. So the ideal architecture would have a couple of high performance cores, and hundreds (thousands?) of very simple cores, to cover both tasks...
[09:02:49] <JonathanThompson> That also (if that's the only size used) reduces the paging hardware overhead a lot.
[09:03:31] <JonathanThompson> It seems Catamount is about as minimal as they could figure out how to do, short of having nothing :)
[09:03:42] <cyan-Q6600-2> I guess so, but 2MB is enough for a complete system really =P
[09:04:21] <JonathanThompson> The less RAM and cache space the OS itself uses, the more the intended application has to use.
[09:04:41] <JonathanThompson> And the fewer pages that exist, the less likely that the TLB will be thrashed.
[09:05:13] *** AlexForster has quit IRC
[09:05:39] <cyan-Q6600-2> Wouldn't it cause greater fragmentation and suchlike though?
[09:05:46] <JonathanThompson> No.
[09:06:06] <JonathanThompson> The minimum memory allocation would likely be in 2 meg increments.
[09:06:16] <JonathanThompson> That's not a real problem, though.
[09:06:59] <cyan-Q6600-2> Hmm. I suppose if each node is largely running one process it's no real issue. Though 2MB is a lot for a single application on a desktop system.
[09:07:26] <JonathanThompson> The impression I get from reading that pdf is that each node is most likely going to have exactly 1 process on it.
[09:07:38] <JonathanThompson> This is a supercomputer system :)
[09:08:11] *** Sikosis_ has joined #haiku
[09:08:12] <judgen> yes very likely
[09:08:26] <cyan-Q6600-2> It'd make a pretty cool desktop system though, you have to admit. =P
[09:08:35] <JonathanThompson> I'd wager that most supercomputer problems have a known static set amount of RAM required on each node that's allocated at the start.
[09:08:42] *** Sikosis has quit IRC
[09:08:49] *** Sikosis_ is now known as Sikosis
[09:09:04] <JonathanThompson> Only if you think using Linux terminal applications is a cool desktop system :)
[09:09:40] <cyan-Q6600-2> Naturally the first thing that needs to be done is porting app_server to it, and then writing GUI applications to use that power in really unusual ways...
[09:10:16] * JonathanThompson shakes head at cyan-Q6600-2
[09:10:51] <judgen> JonathanThompson i could use it to render complex math... maybe i should make a seventeenorbust client for super computers and pump it on to one of those =)
[09:10:58] <JonathanThompson> You know what NUMA is, correct, cyan-Q6600-2?
[09:11:17] <JonathanThompson> That'd be an appropriately super-computery type of application, judgen :)
[09:11:24] <cyan-Q6600-2> Yeah
[09:11:34] <JonathanThompson> Well, that system is NUMA in spades.
[09:11:41] <judgen> and teamhaiku would rise in notime =)
[09:11:55] <JonathanThompson> You'd have a hellish issue of getting all that possible memory bandwidth to a display card :)
[09:12:13] <JonathanThompson> (You couldn't do it)
[09:13:03] <umccullough> eh?
[09:13:04] <umccullough> teamhaiku?
[09:13:06] <umccullough> :)
[09:13:13] <cyan-Q6600-2> Desktop PCs are already sliding down that slippery slope though... RAM is so remote to the processor that it could almost be considered some kind of add-on card. Writing to VRAM also has really high latency, so it needs to be done in one burst. I think things will just become more and more like that as things progress...
[09:13:16] <JonathanThompson> It may also have a notable latency between a user action and results, due to overhead.
[09:13:24] <judgen> why would you want a displaycard? isnt bitchx, nano, lynx and the other fabulous CLI apps just all we need?
[09:13:37] <umccullough> seventeenorbust is a waste of super-computer-power ;)
[09:13:44] <JonathanThompson> Well. he's talking of a GUI, judgen :)
[09:13:50] <judgen> and for games there is zork, zork2, zork3 and nethack!
[09:14:03] <JonathanThompson> Ala BeOS, Haiku, but massively parallel hardware.
[09:14:08] <judgen> umccullough but it would be fun to see what it would do with it
[09:14:24] <umccullough> judgen, i'd rather throw it at another project ;)
[09:14:29] * JonathanThompson imagines running POV-Ray on it
[09:14:30] <cyan-Q6600-2> Sure, there'd be a latency, but as long as it's below a single video frame (~10ms; a century in computing terms), nobody'd ever notice...
[09:14:37] <judgen> umccullough it would be amazing to send all the data to the same server too... and see them fall, one by one =)
[09:14:39] <umccullough> one of the other 50-60 that team haiku participates in :D
[09:14:58] <JonathanThompson> judgen, you'd likely have an internet bandwidth issue :P
[09:15:15] <umccullough> yeah, basically you'd want the super computer to *be* the server ;)
[09:15:41] <JonathanThompson> umccullough, tomorrow, YOU be the computer :P
[09:15:51] <umccullough> at that point, it's not distributed computing... it's just massively parallel computing
[09:16:37] <judgen> hehe
[09:17:02] <umccullough> if you look at it from that perspective, the server is just a scheduler
[09:17:08] <umccullough> doling out tasks
[09:19:37] *** eric_j has quit IRC
[09:19:59] <umccullough> i'm gonna fire up this C2D E6750 soon on some distributed computing projects...
[09:20:04] <JonathanThompson> A computer with that many nodes would be the equivalent of a large city having all its personal computers being applied to the task at once, with the data all concentrated for I/O.
[09:20:30] <cyan-Q6600-2> It's hard to imagine where desktop computing will be in another 20 years or so. Traditionally development in that field has followed mainframe/supercomputer design, but with all the large supercomputers parallel clusters now, I think desktops may end up going a similar way.
[09:20:49] <JonathanThompson> There are practical limits, though.
[09:21:10] <JonathanThompson> I think the CPU architecture will need to change in a major way from what it is now to make effective use of the transistor budget.
[09:21:22] <umccullough> trinary :D
[09:21:31] <JonathanThompson> True, false, FileNotFound :P
[09:21:36] <umccullough> maybe
[09:21:47] <cyan-Q6600-2> What would more die space be used for? Larger caches? More cores?
[09:21:58] <JonathanThompson> I think one of the most interesting architectures is the TRIPS processor architecture that uses dataflow.
[09:22:29] <JonathanThompson> The biggest issue is parallelism and extracting it, and writing software for it that people can actually understand and debug, cyan-Q6600-2.
[09:22:41] <cyan-Q6600-2> I don't think I've heard of that... though dataflow-based designs lend themselves extremely well to reconfigurable hardware; FPGAs etc.
[09:22:44] <JonathanThompson> You can put a million cores together, but if something is inherently serial, then what?
[09:23:18] <JonathanThompson> cyan-Q6600-2, I think you'd find the TRIPS processor a curious thing.
[09:23:24] <JonathanThompson> Look it up via google :)
[09:23:32] <JonathanThompson> University of Austin, Texas.
[09:23:35] <cyan-Q6600-2> Then you're stuck, but what can be done about it? The only possible solution is if they get processors running at 300GHz+ on the market, for optimal single threaded performance...
[09:24:37] <JonathanThompson> And unless we come up with room temperature superconductors and semiconductors, or perhaps quantum computer architectures, that speed doesn't seem very feasible for mere mortal's computers.
[09:24:51] <umccullough> utexas runs a distributed computing project...
[09:24:53] <umccullough> http://eon.cm.utexas.edu/
[09:25:38] <umccullough> wonder if the two divisions have ever talked ;)
[09:25:50] <JonathanThompson> :)
[09:26:03] *** emitrax has joined #haiku
[09:26:28] <cyan-Q6600-2> I have to wonder if the problem with making things more parallel is actually just a problem with programmers and the languages they create, rather than anything inherent. Maybe something like functional programming would be more flexible...
[09:26:52] <JonathanThompson> No, it's an inherent issue of cause-and-effect, cyan-Q6600-2, for a lot of problems.
[09:26:54] <umccullough> haskell?
[09:27:39] <JonathanThompson> Or, "You canna change the laws of physics, cap'n!"
[09:27:41] <cyan-Q6600-2> umccullough: Along those lines, yeah. Try to make the compiler extract every last inch of parallelism from the code by clearing specifying relationships...
[09:27:57] <JonathanThompson> Without relationships, you only have noise.
[09:28:05] <JonathanThompson> And that's wherein the problem lies.
[09:28:27] <umccullough> cyan-Q6600-2, doesn't that basically mean, do a whole bunch of work and put the pieces together later?
[09:28:38] <JonathanThompson> Now, the TRIPS processor is inherently easily programmed to unroll loops very nicely.
[09:28:54] *** emitrax has quit IRC
[09:29:01] <cyan-Q6600-2> JonathanThompson: It still seems that there's a lot of algorithms where much more parallelism can be used, if it weren't for the hideous complexity trying to do it manually...
[09:29:12] <JonathanThompson> And the segment of the loop that's unrolled can easily be executed in parallel as a result.
[09:29:39] <umccullough> basically, calculate more than you need to since it's likely that you'll need it anyway
[09:29:50] <JonathanThompson> I strongly suggest you find the PDF about it and read it, cyan-Q6600-2, it's very interesting.
[09:30:03] <cyan-Q6600-2> umccullough: Pretty much. For instance, if you're calculating a complex equation, each bracketed part (as a simplified example) can be computed in its own thread, and then reassembled afterwards...
[09:30:16] <JonathanThompson> Yes, umccullough, that's what modern Out of Order x86 processors already do, to some extent :)
[09:30:17] <cyan-Q6600-2> JonathanThompson: I'm looking around for it at the moment...
[09:30:42] <umccullough> cyan-Q6600-2, as long as it's relatively certain you're going to need it anyway... but if you don't it's wasted effort... much like how the complex branching logic works in x86 processors these days anyway
[09:30:58] <umccullough> JonathanThompson, right, sorry - didn't see you specify that ;)
[09:31:00] <JonathanThompson> In many cases, it may take as long to parse such a complex equation for parallelism as it'd take to just run it on a single processor :P
[09:31:24] <umccullough> it's always better if a programmer can design the application as parallel as possible FIRST
[09:31:29] <JonathanThompson> (And I'd predict most likely more)
[09:31:47] <cyan-Q6600-2> umccullough: I think with functional programming, a lot of that is automatic -- if a given evaluation branch isn't needed, it won't be traversed.
[09:32:09] * JonathanThompson suspects cyan-Q6600-2 only sees the theory of compilers and knows little of the practical implementation details
[09:32:25] <umccullough> yeah, i've heard some of the theory also...
[09:32:32] <umccullough> just not sure i've seen it in practice
[09:32:55] <umccullough> if it was so superior, i'd expect to see a lot more of it in distributed computing...which I don't
[09:33:37] <cyan-Q6600-2> I can't say I know much about the internals of compilers, but I've written code in both C and assembler, and I've encountered a little functional programming. The thought of trying to make a compiler detect extensive parallelism in a C or assembler program seems absolutely hideous. If there were some more cues built into the language, things may be easier...
[09:33:43] <umccullough> most of distributed computing is about building tight, fast, algorithms to chunk through the small bits
[09:34:44] * JonathanThompson remembers when compilers didn't have nearly as hard of a time making things as fast as the hardware could possibly execute, because there was no cache and no speculative execution or out of order execution possible
[09:35:14] *** Ingenu has joined #Haiku
[09:35:32] <JonathanThompson> For the x86 series, the 486 was the last processor that worked fairly well.
[09:35:49] <JonathanThompson> Pentium on up got quite a bit more complex to hand-compute timings of sets of instructions.
[09:36:00] <cyan-Q6600-2> I don't think there's ever been a time where the performance of C and assembler have been so close though (discounting things like SSE). Hand-optimizing your own assembler programs is already nearly impossible..
[09:36:57] <cyan-Q6600-2> Yeah. As soon as you add a cache into the picture, timing kind of goes out the window anyway.
[09:37:31] <JonathanThompson> Caches aren't that hard to deal with by themselve,s and neither is out of order execution, but when you combine both, that's where it gets fun.
[09:38:49] * JonathanThompson feels like his bike: too tired, and goes to bed
[09:39:00] *** JonathanThompson is now known as JT-Sleep
[09:40:41] <umccullough> i should sleep also
[09:41:06] <cyan-Q6600-2> Ah, seeya
[09:41:23] <umccullough> 'night
[09:46:44] *** cyan-Q6600-2 has left #haiku
[09:48:22] *** emitrax has joined #haiku
[09:58:33] *** stargater has joined #haiku
[09:58:40] <stargater> moin
[10:07:08] *** MrSunshine has joined #haiku
[10:09:35] *** emitrax has quit IRC
[10:09:49] *** Kernel86 has quit IRC
[10:12:04] *** slaad has quit IRC
[10:15:09] *** Kernel86 has joined #Haiku
[10:19:22] *** slaad has joined #haiku
[10:41:43] *** JBurton has joined #haiku
[10:41:44] *** ChanServ sets mode: +o JBurton
[10:41:47] <JBurton> hi all
[10:42:37] <Begasus> hi JBurton
[11:12:36] *** judgen has quit IRC
[11:15:20] *** magnetron has joined #haiku
[11:15:53] *** stargater has quit IRC
[11:26:23] *** frodobeg25 has quit IRC
[11:35:01] *** MangoFusion has joined #haiku
[11:36:32] *** MauriceK has left #haiku
[11:36:52] *** JBurton has quit IRC
[11:37:51] <CIA-5> jackburton * r22406 /haiku/trunk/src/preferences/time/TZDisplay.cpp:
[11:37:51] <CIA-5> Patch by Rene Gollent which fixes displaying of current time. I've used
[11:37:51] <CIA-5> snprintf instead of sprintf and reduced the size of the char array,
[11:37:51] <CIA-5> though. Hope you don't mind, Rene.
[11:39:50] *** ken has joined #haiku
[11:42:14] *** ken has quit IRC
[11:42:37] *** kennyjb402 has joined #haiku
[11:47:27] *** JBurton has joined #haiku
[11:47:28] *** ChanServ sets mode: +o JBurton
[11:49:32] *** fyysik has joined #haiku
[11:50:36] *** meisje has joined #haiku
[12:07:37] *** Darknesss has joined #haiku
[12:07:47] *** kennyjb402 has quit IRC
[12:09:50] *** vi20 has joined #haiku
[12:12:35] *** judgen has joined #haiku
[12:12:52] *** vi20 has quit IRC
[12:14:37] <judgen> anyone looked into singularity?
[12:18:39] *** fyysik has quit IRC
[12:36:47] *** meisje has quit IRC
[12:39:11] *** fyysik has joined #haiku
[12:54:41] <CIA-5> axeld * r22407 /haiku/trunk/src/add-ons/kernel/drivers/network/stack/kernel_stack.cpp: Fixed initialization threading issues I introduced yesterday.
[13:02:33] *** TheNerd_WK has quit IRC
[13:12:29] *** jevin has quit IRC
[13:14:33] *** WindowsUninstall has joined #haiku
[13:15:10] *** waveshaper has joined #haiku
[13:15:45] <waveshaper> whats the status on audio on haiku? is there any at all?
[13:17:07] *** rcjsuen has joined #haiku
[13:21:49] *** rcjsuen has quit IRC
[13:22:54] *** frodobeg25 has joined #haiku
[13:23:17] *** dr_evil has joined #haiku
[13:24:54] <Thom_Holwerda> hey nice mail from axel
[13:26:26] *** Darknessss has joined #haiku
[13:26:55] *** Darknesss has quit IRC
[13:27:19] *** judgen has quit IRC
[13:28:00] *** Atomozero has joined #haiku
[13:34:30] <JBurton> waveshaper yes, there is audio
[13:34:54] <Atomozero> yo JBurton :)
[13:35:34] *** TuneTracker has joined #Haiku
[13:35:52] <TuneTracker> Wow, 70 users today...we're up a little!
[13:36:50] <JBurton> ciao Atomozero
[13:37:57] <Atomozero> ...pazienza....
[13:42:10] 
[13:42:15] <Atomozero>  [13:43:23] [/boot/home/Desktop/haiku]
[13:42:15] <Atomozero>  [5/505] > jam
[13:42:16] <Atomozero>  warning: Invalid jamfile cache: Failed to read file info.
[13:44:58] *** jevin has joined #haiku
[13:46:58] <JBurton> nn e' grave
[13:47:20] <JBurton> succede quando la cache e' corrotta per qualche motivo, tipo hai interrotto una compilazione a meta' o roba cosi'
[13:47:37] <Atomozero> uhm
[13:47:40] <Atomozero> no
[13:49:38] <JBurton> vabbe' nn e' nulla comunque
[13:49:40] <JBurton> brb
[13:49:41] <JBurton> :)
[13:49:53] <JBurton> hai visto la mail sulla roadmamdapapaaaapappaaaaaaaaaaaprot
[13:49:55] <JBurton> roadmap
[13:49:56] <JBurton> ?
[13:52:12] <Atomozero> no
[13:56:11] <Atomozero> urca! che bella mail! :D
[13:56:37] <CIA-5> axeld * r22408 /haiku/trunk/src/add-ons/kernel/bus_managers/acpi/acpi_busman.c:
[13:56:37] <CIA-5> * Fixed module leak in case there was an error during init when used on BeOS.
[13:56:37] <CIA-5> * Check safemode settings only when it's not already disabled (doesn't make
[13:56:37] <CIA-5>  sense to check those then).
[13:56:37] <CIA-5> * Minor cleanup
[14:01:13] *** mmu_man has joined #haiku
[14:01:13] *** ChanServ sets mode: +o mmu_man
[14:02:08] *** Atomozero has quit IRC
[14:04:30] *** rcjsuen has joined #haiku
[14:07:22] *** santos has joined #haiku
[14:09:39] <dr_evil> raid systems: http://fun.drno.de/pics/raid.jpg
[14:10:25] <mmu_man> lol
[14:10:26] <Ketsuban> lmao
[14:11:08] <alpha-lion> *hihi*
[14:11:22] <JT-Sleep> Someone had way too much time and water bottles on hand :)
[14:11:29] * JT-Sleep should be sleeping
[14:20:16] *** fyysik has quit IRC
[14:22:13] *** jevin has quit IRC
[14:22:58] *** Hummin has joined #haiku
[14:24:17] <Hummin> SATA driver.. YAY!
[14:24:24] <Ingenu> :)
[14:25:24] <Hummin> now I just gotto figure out how to get it installed
[14:25:29] <Hummin> through vmware, I suppose
[14:27:57] *** eric_j has joined #haiku
[14:28:43] <JBurton> dd
[14:29:24] <Hummin> can I copy a virtual partition's data onto a real one with that?
[14:29:29] <Hummin> I thought I'
[14:29:40] <Hummin> d just get the tree and install onto a real partition
[14:29:56] <Hummin> but I still need bootman on hd1 partition 1, right ?
[14:31:09] *** DeadYak has joined #haiku
[14:33:59] <JBurton> hmmm
[14:34:06] <JBurton> you need a bootmanager
[14:34:11] <JBurton> not necessarily bootman
[14:35:36] *** Begasus is now known as Begasus_bbl
[14:36:03] * DeadYak waves
[14:36:17] <Hummin> JBurton: Is there any other bootmanager that will load haiku ?
[14:36:57] * Hummin is still a little confused on how to install Haiku and run on real HW with the SATA driver
[14:37:15] <JBurton> grub
[14:37:18] <JBurton> any other sane bootloader
[14:37:22] <JBurton> which does chain loading
[14:37:34] <Hummin> but even if it chain-loads bootman
[14:37:37] <JBurton> yes ?
[14:37:54] <Hummin> will bootman load the rest off of my sata disk ?
[14:38:09] <JBurton> I'm confused as why you need bootman
[14:38:15] <Hummin> I don't ?
[14:38:29] <JBurton> which oses do you have on that drive ?
[14:38:36] *** dr_evil has quit IRC
[14:38:39] <Hummin> perhaps I don't. I just thought that bootman was needed to load the kernel or whatnot
[14:38:49] <JBurton> we have our own bootloader
[14:38:54] <Hummin> I have NO oses on the drive.. it's the second drive
[14:38:57] <JBurton> ah ok
[14:39:07] <JBurton> but our bootloader is only a... er.. loader, not a boot manager
[14:39:16] <Hummin> I can disable the first drive in the bios and make it the first drive by doing so
[14:39:24] <JBurton> ah ok
[14:39:27] <JBurton> then you don't need anything
[14:39:34] <JBurton> haiku has its own bootloader
[14:39:43] <Hummin> I don't have any bootload yet.. I only have XP on my first disc.. I've ran all the other oses in vmware
[14:39:46] <JBurton> I see
[14:40:10] <JBurton> basically, you need to copy haiku on the drive in some way (dd, for example, if you know what you are doing)
[14:40:13] <JBurton> then run makebootable
[14:40:14] <Hummin> JBurton: but I still need to install that bootloader somehow?.. or will formatting the partition and copying the haiku files suffice ?
[14:40:19] <JBurton> with makebootable
[14:40:28] <Hummin> I can use vmware to copy it
[14:40:30] <JBurton> makebootable installs the loader on the partition
[14:40:35] <Hummin> aah.. nice
[14:40:48] <JBurton> Hummin I'm not sure a copy (or copyattr) would copy all the files correctly
[14:40:51] <JBurton> in theory it should
[14:40:53] <Hummin> perhaps that's included in the jam install ?
[14:41:07] *** SprMa has joined #haiku
[14:41:09] <Hummin> well.. I can compile with the real partitions as output ?
[14:41:27] <JBurton> yeah
[14:41:38] <JBurton> if you can compile haiku you're done
[14:44:17] <Hummin> yeupp
[14:44:33] <Hummin> the sata driver is in the tree already?
[14:46:47] <Hummin> well.. here goes
[14:46:58] <Hummin> hope it won't take all day
[14:47:38] <Hummin> btw.. I only have a USB mouse
[14:47:48] <Hummin> should work, right?
[14:47:55] <Hummin> vmware emulates a ps2 one
[14:55:10] * JT-Sleep tickles DeadYak
[14:57:42] *** cyrann has quit IRC
[15:04:46] * DeadYak pets JT-Sleep
[15:04:54] * JT-Sleep lobs a pillow at DeadYak
[15:05:06] <DeadYak> you're up early :P
[15:05:11] <JT-Sleep> It's a very nice pillow :)
[15:05:16] <JT-Sleep> I've not slept well this morning.
[15:05:19] <JT-Sleep> (Or much)
[15:05:39] <DeadYak> qh
[15:05:40] <DeadYak> err ah
[15:06:20] <JT-Sleep> Thinking about it, I had my mind keep on working on the thought of a very complicate query being executed in many different ways, without getting detailed.
[15:11:40] <DeadYak> JT-Sleep: know the feeling, albeit not while trying to sleep :P
[15:12:04] <JT-Sleep> Ah, the weird things that help keep me conscious :P
[15:12:13] *** TuneTracker has quit IRC
[15:12:16] * JT-Sleep wonders if insomniac sheep count humans
[15:12:30] <mmu_man> possibly
[15:12:46] * DeadYak wonders what mmu_man counts
[15:13:03] <JT-Sleep> LOC?
[15:13:32] <mmu_man> 1 transistor
[15:13:34] <mmu_man> 2 transistors
[15:13:37] <mmu_man> 3 transistors
[15:13:44] <mmu_man> 4 transistzz
[15:13:49] <mmu_man> 5 transzzzZZzzZZ
[15:14:04] * JT-Sleep hopes mmu_man is never so badly unable to sleep he can count a modern CPU's transistors
[15:14:58] <DeadYak> I was thinking maybe he played KDL hangman in his head :)
[15:16:29] * JT-Sleep wonders when there'll be a KDL Tetris clone
[15:16:48] <DeadYak> ouch.
[15:17:03] <DeadYak> I don't think you can do curses from KDL, I might be mistaken :)
[15:17:22] <CIA-5> axeld * r22409 /haiku/trunk/src/system/runtime_loader/elf.cpp:
[15:17:22] <CIA-5> * load_program() (and probably others) could call delete_image() with a NULL
[15:17:22] <CIA-5>  pointer - which it now handles gracefully.
[15:17:22] <CIA-5> * This also fixes starting the runtime loader directly: it no longer crashes
[15:17:22] <CIA-5>  but will just return an error.
[15:18:21] <mmu_man> I hink Haiku's kdl handles colors
[15:18:40] <JT-Sleep> And then there's always Space Invaders :)
[15:19:51] <DeadYak> mmu_man: colors, yes, but drawing in arbitrary places on the screen?
[15:19:51] * JT-Sleep goes afk
[15:27:26] <MrSunshine> 1. The performance argument of BeOS nowadays doesn't count anymore since computers are so fast that they make up for any possible shortcomings of computer systems in that area. <-- haha wtf kind of argument is that? :P
[15:27:34] <MrSunshine> "so my windows is slow, my cpu can overcome that"
[15:28:26] *** emitrax has joined #haiku
[15:28:46] *** PieterPan has joined #haiku
[15:29:18] <MrSunshine>  On the surface Haiku/BeOS looks like the old Windows 95, its just painfully ugly. <-- wtf? ... i think beos looks nice :)
[15:29:23] <MrSunshine> its clean ... efficient
[15:30:50] <PieterPan> Well, after lots of backups and space making measures, I finally installed Haiku on my brand new laptop, with AHCI. Guess what, it works! (as long as I disable hyperthreading)
[15:30:57] <PieterPan> Even USB works
[15:31:14] *** MangoFusion has quit IRC
[15:31:32] <PieterPan> It is quite fast indeed :)
[15:32:06] <DeadYak> PieterPan: nice! :)
[15:33:24] <PieterPan> Hmm, shame, no networking though
[15:33:32] <MrSunshine> humm, i want to install haiku but i dont know how :( ... stupid windows
[15:33:46] <PieterPan> I did it through ubuntu...
[15:33:49] <MrSunshine> and my wlan doesnt work good under linux
[15:34:00] <MrSunshine> PieterPan, i wouldnt poke that damn distro with a stick
[15:34:01] <JBurton> MrSunshine tried ndiswrapper ?
[15:34:11] <JBurton> why not MrSunshine ?
[15:34:16] <MrSunshine> JBurton, yes it works ... but its borked out :)
[15:34:26] <MrSunshine> JBurton, last time i used it, installed nvidia drivers and everything fucked up
[15:34:31] <PieterPan> MrSunshine well it works, and it builds haiku.
[15:34:32] <MrSunshine> lags of like 5 secs every 10 secs
[15:34:36] <JBurton> O_o
[15:34:37] <MrSunshine> could not uninstall the driver
[15:34:39] <MrSunshine> etc etc
[15:34:41] <JBurton> well don't install them :)
[15:34:45] <PieterPan> MrSunshine right, I am having problems with the nvidia driver hehe
[15:34:46] <JBurton> s/them/it
[15:34:54] <MrSunshine> gentoo!
[15:34:58] <MrSunshine> but takes a day to install :)
[15:35:09] <PieterPan> I don't have that patience
[15:35:30] <MrSunshine> best distro ever, never had hany problems with it :)
[15:37:18] <PieterPan> Right, now I need to figure out my ethernet driver...
[15:37:48] <PieterPan> Or wireless, heh, but I doubt my brand new intel wifi card works :)
[15:38:03] <MrSunshine> JBurton, ndiswrapper works but a hell to find the actual card ... ID said one thing, the card is actualy another etc :P
[15:38:18] <MrSunshine> madwifi does not have support for it yet :&
[15:38:30] <JBurton> really ?
[15:38:36] <JBurton> I had no problem finding it
[15:38:44] <JBurton> checked the id
[15:38:47] <JBurton> followed the link
[15:38:48] <JBurton> done
[15:38:49] <JBurton> :)
[15:41:10] <PieterPan> Do usb sticks work yet from within haiku?
[15:41:15] <JBurton> not yet
[15:41:18] <PieterPan> ie: mass storage?
[15:41:39] <PieterPan> hmm ok, so I can't access the CD (ahci sata), I can't use ethernet, I can't use usb...
[15:41:56] <PieterPan> maybe a fat32 partition to communicate, but I'm out of partition space again
[15:41:57] * DeadYak didn't know there were SATA CD drives
[15:42:00] *** SprMa_ has joined #haiku
[15:42:04] <PieterPan> Yes there are
[15:42:05] <MrSunshine> JBurton, reported as a 5006 i think and its a 5007 card
[15:42:14] <PieterPan> got one in my pc, and also in my laptop
[15:42:22] *** SprMa_ has quit IRC
[15:42:31] <DeadYak> PieterPan: ah, every sys I've seen had an hdd on SATA and the CD drive on PATA, good to know
[15:44:21] <JBurton> yeah never seen a SATA CD
[15:46:33] <PieterPan> So my laptop has a Broadcom 5786... quite new gigabit ethernet, anyone know if there is a driver for haiku? :)
[15:46:58] <DeadYak> there's some form of bcm driver but I forget what series
[15:47:02] <DeadYak> could be as simple as a missing PCI ID
[15:47:09] <PieterPan> true...
[15:47:18] <DeadYak> looking
[15:47:24] <PieterPan> well I could try it, since I built it just now..
[15:48:18] <PieterPan> How can I get a list of the hardware in my laptop from within haiku? Does it has some tools to probe internally? :)
[15:48:44] <DeadYak> poke pci on R5 used to do that, I'm not sure if Haiku has that tool or not
[15:49:28] *** emitrax has quit IRC
[15:49:31] *** wildur has joined #Haiku
[15:52:41] <PieterPan> Nope, no poke tool on Haiku
[15:53:36] <DeadYak> could check syslog, iirc it dumps all the PCI discovery info from boot there
[15:53:53] <DeadYak> and Haiku has a bcm570x series driver
[15:53:59] <DeadYak> not sure how similar 5786 is to those
[15:54:20] <MrSunshine> need to port ath5k driver to haiku also :P
[15:54:48] *** jevin has joined #haiku
[15:56:14] <PieterPan> DeadYak right, I'll check out that driver... who knows it works with it...
[15:56:31] *** slaad has quit IRC
[16:01:14] <PieterPan> DeadYak http://svn.berlios.de/viewcvs/haiku/haiku/trunk/src/add-ons/kernel/drivers/network/bcm570x/README?view=markup It lists a 5788 and 5789. I'll try to add my pci id for my card and see if it magically works :)
[16:01:46] <DeadYak> PieterPan: good luck :) probably will work then
[16:01:50] <DeadYak> PieterPan: if it does, submit a patch!
[16:02:02] <PieterPan> Will try :)
[16:04:41] <PieterPan> http://www.panman.eu/haiku/onC2Dlaptop.JPG !! nice!
[16:05:34] <DeadYak> woohoo
[16:05:43] <DeadYak> can I have your laptop? :)
[16:06:12] <JBurton> does sound work too, PieterPan ?
[16:06:51] <DeadYak> though I shouldn't complain, my hardware's (almost) completely supported now
[16:07:08] *** rcjsuen_ has joined #haiku
[16:07:08] <JBurton> on my laptop, haiku works, although usb is OHCI, so not supported, and it runs in vesa mode since there is no video driver
[16:07:16] <JBurton> but it works well anywya
[16:07:18] <JBurton> anyway
[16:08:27] <PieterPan> JBurton I did see sound detected as HD sound. No files to test it with :)
[16:08:32] <PieterPan> That's what I need network for :)
[16:08:51] <PieterPan> DeadYak No, you can't have my laptop :) so sorry hehe
[16:08:58] <JBurton> PieterPan yeah I think we should include some audio and some video files in the image
[16:09:09] <JBurton> too bad there is no mass storage
[16:09:15] <CIA-5> stippi * r22410 /haiku/trunk/src/servers/app/ (7 files): (log message trimmed)
[16:09:15] <CIA-5> * added a way for the ServerWindow message loop to determine the required type
[16:09:15] <CIA-5>  of locking before processing the message (single/all window lock)
[16:09:15] <CIA-5>  -> in most message cases, I could comment out the unlocking/locking which
[16:09:15] <CIA-5>  switched to the different lock, because the required lock is now already held,
[16:09:16] <JBurton> otherwise I'd start using haiku for real
[16:09:16] <CIA-5>  this removes some race conditions which were commented in the code already
[16:09:19] <CIA-5> * EventDispatcher::SetDragMessage() didn't lock the object, this would have
[16:12:18] *** wildur has quit IRC
[16:16:21] *** emitrax_ has joined #haiku
[16:16:53] <PieterPan> JBurton true about the mass storage...  Well, my new network driver is compiling... we'll see if it works. I'll be very satisfie :)
[16:17:25] <PieterPan> +d
[16:19:39] <DeadYak> PieterPan: interesting, I thought C2D didn't have hyperthreading
[16:21:40] *** rcjsuen has quit IRC
[16:24:32] *** MangoFusion has joined #haiku
[16:27:42] <PieterPan> DeadYak well, strange thing is, now it boots without disabling hyperthreading
[16:27:56] <PieterPan> Last 3 times it wouldn't boot unless I did
[16:28:26] <PieterPan> DeadYak well anyway, so I added my pci id to the broadcom driver. Apparently it is not added to the image by default...
[16:28:37] <PieterPan> so I'll have to figure out how to do that
[16:30:16] *** rcjsuen_ is now known as rcjsuen
[16:30:47] <PieterPan> hmm so it does a subincludeGPL in the JAM file...
[16:31:10] <PieterPan> I'm new to Jam and the haiku build system
[16:32:08] <JBurton> configure --enableGplAddons or something like this
[16:32:23] <JBurton> or export some GPL_KIND_OF_VARIABLE
[16:32:26] <JBurton> and jam
[16:32:52] <JBurton> I'm really useful, right ?
[16:32:57] *** fyysik has joined #haiku
[16:32:58] <PieterPan> haha very :)
[16:33:21] <PieterPan> I'll try out some stuff :)
[16:33:55] <JBurton> the configure option is
[16:34:12] <PieterPan> ok thanks
[16:34:23] <PieterPan> I just renamed subincludeGPL to subinclude
[16:34:34] <PieterPan> If that doesn't work I'll use your configure option ;)
[16:34:45] <JBurton> PieterPan that won't work
[16:34:48] <PieterPan> Which, undoubtedly is the better way to go
[16:34:51] <PieterPan> Ah
[16:34:58] <PieterPan> Ok I'll reconfigure it
[16:34:59] <JBurton> check build/jam
[16:35:02] <JBurton> HaikuImage
[16:35:15] <JBurton> there, the drivers are added conditionally to the image
[16:35:23] <JBurton> only if some variable is defined
[16:35:31] <PieterPan> Ok thanks
[16:35:42] <JBurton> ok you could edit manually that file too
[16:35:49] <JBurton> but since there is the "simple" way...
[16:36:23] <JBurton> BEOS_ADD_ONS_DRIVERS_NET = etherpci ipro1000 rtl8139 rtl8169 sis900
[16:36:24] <JBurton> 	via-rhine wb840 net_stack #vlance
[16:36:24] <JBurton> 	$(GPL_ONLY)bcm440x $(GPL_ONLY)bcm570x
[16:36:28] <JBurton> see ?
[16:36:47] <JBurton> for a quick test you could remove the $(GPL_ONLY) part
[16:39:47] <PieterPan> It is reconfiguring now, I'll let you know
[16:40:01] <PieterPan> Otherwise I'll do it the hack way you just described ;)
[16:41:01] *** SprMa has quit IRC
[16:48:09] *** Stargater has joined #haiku
[16:48:12] <Stargater> hi
[16:54:23] <CIA-5> stippi * r22411 /haiku/trunk/src/apps/clock/ (6 files):
[16:54:23] <CIA-5> patch by Julun:
[16:54:23] <CIA-5>  * fixed ticket #1500
[16:54:23] <CIA-5>  * big cleanup and removal of unused code
[16:59:21] <PieterPan> Right JBurton I now have the driver, and it recognises the chip, but it does not obtain an ip address
[17:00:17] <JBurton> should it work in DHCP mode ?
[17:00:28] <PieterPan> Well it did in linux :)
[17:00:32] <JBurton> tried the networksetting preflet ?
[17:00:39] <PieterPan> Yes, I'm playing with that now
[17:00:47] *** JT-Sleep has quit IRC
[17:01:02] <PieterPan> strange, it picked very weird ip values, I'll try better values
[17:01:07] <PieterPan> manually
[17:06:59] *** stippi has joined #haiku
[17:07:00] *** ChanServ sets mode: +o stippi
[17:12:08] <PieterPan> Well, no luck yet, have to go shop some food
[17:12:22] *** HeToN800 has joined #haiku
[17:12:23] <PieterPan> It does correctly init the driver, it says.
[17:12:56] *** PieterPan has quit IRC
[17:13:02] *** rcjsuen has quit IRC
[17:13:58] *** meisje has joined #haiku
[17:14:16] <JBurton> I'm off
[17:14:17] <JBurton> bye all
[17:15:34] <stippi> bye
[17:17:16] *** JBurton has quit IRC
[17:21:45] *** jevin has quit IRC
[17:22:16] <CIA-5> axeld * r22412 /haiku/trunk/ (7 files in 3 dirs): (log message trimmed)
[17:22:16] <CIA-5> * Changed Ld rule to allow adding resource files.
[17:22:16] <CIA-5> * Changed ResAttr rule to allow not deleting the file before writing the
[17:22:16] <CIA-5>  attributes.
[17:22:16] <CIA-5> * Added application signatures for the runtime_loader and zbeos, just so that
[17:22:18] <CIA-5>  they may have an icon, too (hint, hint) :-)
[17:22:21] <CIA-5> * As a side effect, this also let's FileTypes handle these two as apps (even
[17:25:29] <mmu_man> go stippi, go!
[17:26:29] <stippi> mmu_man?
[17:26:42] <mmu_man> icon...
[17:26:49] <stippi> ah
[17:28:47] *** rcjsuen has joined #haiku
[17:40:08] *** JDarkness has joined #haiku
[17:42:52] *** tombhad_ has quit IRC
[17:43:21] *** tombhad_ has joined #haiku
[17:44:17] *** Darknesss has joined #haiku
[17:47:53] *** fyysik has quit IRC
[17:51:03] *** Darknessss has quit IRC
[17:56:10] *** SDragon has joined #haiku
[17:56:17] *** SDr has quit IRC
[18:00:56] *** stippi has quit IRC
[18:03:24] *** MrSunshine_ has joined #haiku
[18:03:24] *** MrSunshine has quit IRC
[18:04:49] *** kokito has joined #haiku
[18:05:00] <kokito> good morning folks
[18:05:07] <DeadYak> kokito!
[18:05:46] <etteyafed> morning indeen
[18:05:48] *** Darknessss has joined #haiku
[18:05:51] <etteyafed> indeed*
[18:06:25] <CIA-5> axeld * r22413 /haiku/trunk/src/system/kernel/vm/vm_page.cpp:
[18:06:25] <CIA-5> Added a TODO what we need to do with stolen active pages - for now, we don't
[18:06:25] <CIA-5> do anything with them, though.
[18:11:08] <etteyafed> Stupid debian might not qualify the alpha port next release.
[18:11:21] <etteyafed> HP still sells them
[18:11:39] *** meisje has quit IRC
[18:15:09] *** kokito has quit IRC
[18:15:22] <geist> bummer
[18:17:05] *** JDarkness has quit IRC
[18:19:21] *** Ingenu has quit IRC
[18:20:10] *** fyysik has joined #haiku
[18:20:55] *** Darknesss has quit IRC
[18:23:12] *** Lelldorin1 has joined #haiku
[18:23:27] *** SDr has joined #haiku
[18:23:37] *** Lelldorin1 has quit IRC
[18:24:46] *** SDragon has quit IRC
[18:25:38] *** kokito has joined #haiku
[18:26:20] *** waveshaper has quit IRC
[18:33:19] *** nielx has joined #haiku
[18:35:05] <fyysik> any Dutch here?:)
[18:35:24] <nielx> ja, hier!
[18:35:30] <nielx> ;-)
[18:36:19] <fyysik> wondering about "van" in names - is it close to german vOn or really "a" is more close to "A" there:)
[18:36:44] <nielx> you mean the sound?
[18:36:48] <fyysik> yup
[18:36:59] <nielx> it's like the a: in car
[18:37:07] <fyysik> thanks
[18:37:13] <nielx> though a bit shorter
[18:37:35] *** etteyafed has quit IRC
[18:37:51] *** Darknesss has joined #haiku
[18:38:10] *** lorglas has joined #haiku
[18:38:53] *** jevin has joined #haiku
[18:42:49] *** jevin has quit IRC
[18:43:57] *** Darknessss has quit IRC
[18:49:19] *** HeToN800 has quit IRC
[18:49:47] *** rcjsuen has quit IRC
[18:50:06] *** Player1 has joined #haiku
[18:50:11] <fyysik> nielx -  and "v" like "f" or more "tough"?
[18:50:44] <nielx> v is a voiced fricative
[18:50:45] *** pulkomandy has joined #haiku
[18:51:00] <nielx> like the 'v' in van
[18:51:07] <nielx> (the vehicle)
[18:54:38] <CIA-5> stippi * r22414 /haiku/trunk/src/ (kits/storage/AppFileInfo.cpp libs/icon/IconUtils.cpp): (log message trimmed)
[18:54:38] <CIA-5> * when a vector icon was present, BAppFileInfo::GetIcon() would return an
[18:54:39] <CIA-5>  error if the provided bitmap was B_CMAP8, now BIconUtils will convert the
[18:54:39] <CIA-5>  icon to B_CMAP8
[18:54:40] <CIA-5>  reading icons from attributes, there, the CMAP8 icon is prefered in case
[18:54:44] <CIA-5>  such a bitmap is passed, even if a vector icon exists. I am not really
[18:55:44] <fyysik> heh, tried to guess today from which country our city obtained bus - at place where sweden write "nod utgang" was "nood uitgang" - guessed it's Dutch, as they like double vocals too much:)
[18:56:24] <DeadYak> fyysik: emergency exit?
[18:56:41] <fyysik> yup, my flemish(?) firend:)
[18:56:55] <DeadYak> I'm not flemish but ok :)
[18:57:18] <DeadYak> I did live in Belgium for a while, but I'm not from there by any means :)
[18:57:38] <fyysik> how it is written in Belgium, DeadYak, for curiosity?
[18:57:46] <fyysik> ahh, i c
[18:57:53] <DeadYak> I'm not sure to be honest :)
[18:57:54] <fyysik> Begasus_bbl  is
[18:57:58] <DeadYak> could ask Begasus_bbl :P
[18:58:16] <DeadYak> dead is dod I think but no idea about Yak
[18:58:30] <Begasus_bbl> who where what when?
[18:58:39] *** mmu_man has quit IRC
[18:58:40] <DeadYak> Begasus_bbl: translate "DeadYak" to Dutch :P
[18:58:56] <Begasus_bbl> dode 'yak'
[18:58:57] <Begasus_bbl> ;)
[18:59:06] <DeadYak> Begasus_bbl: no native word for those?
[18:59:11] <Begasus_bbl> dead = dood
[18:59:21] <Begasus_bbl> dead person = dode persoon
[18:59:30] <Begasus_bbl> don't know 'bout yak
[18:59:32] <DeadYak> similarish conjugation rule to german then
[18:59:43] <Begasus_bbl> yep ;)
[18:59:43] <Thom_Holwerda> yak is an animal
[18:59:47] <Begasus_bbl> I know ;)
[18:59:48] <Thom_Holwerda> a... yak in dutch
[18:59:51] <DeadYak> Thom_Holwerda: yeah but is there a dutch word for it?
[18:59:58] <Thom_Holwerda> yeah, yak.
[19:00:00] <DeadYak> oh.
[19:00:02] <Thom_Holwerda> the same
[19:00:05] <Begasus_bbl> hehe
[19:00:08] <DeadYak> same word, that makes it easy :P
[19:00:17] <Begasus_bbl> k .. back to the drawing board ;)
[19:00:24] <DeadYak> Begasus_bbl: thanks :)
[19:00:39] <Thom_Holwerda> damn without realising it, i just wrote down the entire design rationale behind my blog's design
[19:00:43] * Thom_Holwerda blinks
[19:00:59] <Thom_Holwerda> http://cogscanthink.blogsome.com/2007/10/02/simplicity-elegance-cleanliness/
[19:02:05] *** Euver has joined #haiku
[19:02:32] <fyysik> Begasus_bbl -how is "emergency exit" in your country?In flemish or what is there besides german and french
[19:02:49] <Thom_Holwerda> fyysik: he speaks dutch :)
[19:02:56] <Thom_Holwerda> signs just read "uit"
[19:03:01] <DeadYak> fyysik: flemish is a dialect of dutch afaik
[19:03:03] <Thom_Holwerda> which literally means "out"
[19:03:33] <Begasus_bbl> "Nooduitgang"
[19:03:34] <DeadYak> I was under the impression the difference was mostly pronunciation though
[19:03:46] <Thom_Holwerda> DeadYak: yup
[19:03:51] <Player1> thom, whats the verdict on those new apple keyboards?
[19:04:01] <Thom_Holwerda> Player1: me likey?
[19:04:02] <Player1> they look...frustrating
[19:04:04] <Begasus_bbl> fyysik, "emergency exit" = "nooduitgang"
[19:04:11] <DeadYak> Thom_Holwerda: Flemish always sounded much gentler to my ears than actual dutch :)
[19:04:19] <fyysik> I'm interested in differences, Thom_Holwerda, Begasus_bbl - as swedish and Dutch versions are very similar but different:)
[19:04:39] <Thom_Holwerda> they're all ermanic
[19:04:43] *** kokito has quit IRC
[19:04:44] <Thom_Holwerda> germanic*
[19:04:46] <Begasus_bbl> yeah fyysik  ... ;)
[19:04:49] <fyysik> so next question about Danish and both norvegians:)
[19:04:58] <DeadYak> I thought swedish / norwegian / danish came from a different root?
[19:05:01] <Begasus_bbl> with some mix of german probly in them too ...
[19:05:13] <Thom_Holwerda> DeadYak: nope
[19:05:18] <kr1stof> swedish / norwegian is very semilar
[19:05:20] <Thom_Holwerda> danish is a lot like dutch, ctually
[19:05:31] <DeadYak> interesting
[19:05:38] <fyysik> DeadYak - some hunderds year ago it was one language with regional differences, AFAIK:)
[19:05:51] <DeadYak> fyysik: I meant a different root from the germanic languages
[19:05:59] <fyysik> ahh
[19:06:26] <DeadYak> though Finnish seems quite different at least :)
[19:06:32] <fyysik> absolutely
[19:06:34] <Thom_Holwerda> but yeah, you can classify "true" germanic languages like english/dutch/german seperated from nordic languages like danish/swedish/norwegian/icelandic
[19:06:44] <DeadYak> Thom_Holwerda: that's what I thought
[19:06:53] <fyysik> Finnish even don't belong to european group of languages
[19:07:01] <Thom_Holwerda> fyysik: correct.
[19:07:15] <DeadYak> what is that one then?
[19:07:16] <Thom_Holwerda> in dutch, we call finnish part of the "finoegrische" talen
[19:07:23] <Thom_Holwerda> related to... hungarian :/
[19:07:28] <fyysik> so called "Ural" group DeadYak
[19:07:30] <Thom_Holwerda> iic, or anoter one of those there
[19:07:31] <DeadYak> am I correct in thinking Altaic?
[19:07:48] <DeadYak> er wait, yeah Magyar was what I was thinking of
[19:07:50] <fyysik> yup, another name
[19:08:12] <DeadYak> weird trivia btw: Japanese is in the same language family as Turkish :P
[19:08:22] <fyysik> ghm
[19:08:27] <Thom_Holwerda> huh?
[19:08:30] <Thom_Holwerda> really?
[19:08:32] <DeadYak> Thom_Holwerda: I'm not joking.
[19:08:38] <Thom_Holwerda> i was about to say
[19:08:39] <Thom_Holwerda> heh
[19:08:44] <Thom_Holwerda> im that easy, yeah.
[19:08:44] <DeadYak> Thom_Holwerda: in terms of grammatical structure and such
[19:08:53] <DeadYak> Thom_Holwerda: pronunciation wise, not even close but..
[19:09:24] <DeadYak> it's not at all similar to Chinese or any of the other east asian language
[19:09:27] <DeadYak> +s
[19:09:28] <Thom_Holwerda> well, that's coincidental then, as turkish (like other arabic languages) is indoeuropean
[19:09:40] <fyysik> branches of altai group probably
[19:09:42] <Thom_Holwerda> and jap. surely aint.
[19:09:45] <DeadYak> fyysik: exactly.
[19:09:56] <fyysik> one migrated toeast another to west
[19:10:04] <DeadYak> Thom_Holwerda: that's debatable
[19:10:18] *** etteyafed has joined #haiku
[19:10:23] <Thom_Holwerda> DeadYak: well, the branches all stem from the same tree
[19:10:29] <Thom_Holwerda> if you go back long enough
[19:10:45] <DeadYak> Thom_Holwerda: I realize this, just saying it's debatable that japanese didn't stem from that
[19:10:49] <Thom_Holwerda> the stem is called protolanguage, by the way
[19:11:00] <DeadYak> Thom_Holwerda: depending on if there was a land bridge of some form in the past that no trace remains of or whatnot
[19:11:07] <DeadYak> lots of things we don't know
[19:11:17] <DeadYak> but in terms of language structure it's most definitely part of that family
[19:11:28] *** kr1stof has left #haiku
[19:11:55] <Thom_Holwerda> there are language elements that are shared among all languages, put those together and you get a faint glimpse into this rather elusive concept of a protolanguage
[19:11:56] *** dr_evil has joined #haiku
[19:12:15] <DeadYak> afternoon dr_evil  :)
[19:12:22] <dr_evil> hi
[19:12:24] <etteyafed> anyone know why an lvm volume might not show up in the mapper when using a recent live cd?
[19:12:34] <etteyafed> that has lvm installed
[19:12:57] *** frodobeg25 has quit IRC
[19:14:00] <etteyafed> wrong channel
[19:15:32] *** kokito has joined #haiku
[19:16:37] <etteyafed> i sitting in a channel like gentoo, or windows even, is like standing in the middle of the freeway.
[19:16:41] <etteyafed> feels like*
[19:18:08] <etteyafed> haiku won't run in qemu on my laptop anymore
[19:18:29] <etteyafed> says it can't find boot disks
[19:18:42] <etteyafed> or something after sitting there for a very long time
[19:20:04] <fyysik> kokito - did you know that Japanes is far relative of Turkish?:))
[19:20:18] <fyysik> Japanese language i mean
[19:25:35] *** joejaxx has quit IRC
[19:26:40] <etteyafed> WTF haiku svn is not letting me up.
[19:26:51] <etteyafed> must be really busy
[19:27:30] <etteyafed> anyone else have this trouble?
[19:28:17] *** rcjsuen has joined #haiku
[19:31:05] *** joejaxx has joined #haiku
[19:31:14] <kokito> fyysik, no I did not, but I doubt the Japanese would agree with that statement :)
[19:32:23] *** BePower has joined #haiku
[19:32:36] <etteyafed> svn: Can't connect to host 'svn.berlios.de': Connection refused
[19:34:15] *** PieterPan has joined #haiku
[19:34:55] <PieterPan> hey dr_evil I tried your AHCI driver, it works on my laptop
[19:35:37] <Ketsuban> fyysik: any attempts to link Japanese with any language other than those of the Ryukyu islands are tenuous at best.
[19:36:16] *** TuneTracker has joined #Haiku
[19:36:17] <dr_evil> PieterPan thats great, what chipset does it have?
[19:36:48] <PieterPan> Intel Crestline PM965 + ICH8-M
[19:37:03] <PieterPan> Do you need any debug information to check out?
[19:37:19] <PieterPan> hmm, berlios is down
[19:37:53] <PieterPan> Now I'm trying to get my broadcom ethernet chip to work, so I can actually do something...
[19:37:59] <dr_evil> do you have a setting in the bios for AHCI or IDE emulation mode?
[19:38:03] <PieterPan> AHCI
[19:38:07] <PieterPan> Yes, both
[19:38:12] <PieterPan> but it is in AHCI now
[19:38:22] <PieterPan> It is a Santa Rosa platform
[19:38:29] <PieterPan> C2D brand new
[19:38:50] <dr_evil> and when you set non AHCI mode, what does haiku do?
[19:39:00] <PieterPan> Well... we'll see won't we?
[19:39:13] <PieterPan> give me a few minutes
[19:40:07] <PieterPan> The option is AHCI Configuration - Enabled/Disabled. I'll disable it now
[19:40:08] <CIA-5> axeld * r22415 /haiku/trunk/src/add-ons/accelerants/intel_extreme/mode.cpp: Fixed PLL clock for i8xx chips again.
[19:40:55] *** Ingenu has joined #Haiku
[19:41:04] <kokito> fyysik, yes, understood that you were referring to the Japanese language. I was just trying to point to the fact that the Japanese like to think that they are unique, and will reject any idea that may even suggest that anything Japanese comes from outside of Japan.
[19:41:26] <PieterPan> err ide: ide_timout() bus 0x....
[19:41:40] <PieterPan> I'll try again
[19:42:20] <PieterPan> I
[19:42:47] <PieterPan> I'll try to disable hyperthreading (that helps sometimes)
[19:42:58] <PieterPan> Nope...
[19:43:27] <PieterPan> I don't have a serial debugging output, cause it has no serial output... :)
[19:43:51] <dr_evil> ok, you can stop
[19:44:20] <dr_evil> the same happens when I try ide emulation on my board, doesn't work either
[19:44:27] <PieterPan> Ok too bad
[19:45:25] <dr_evil> I'll probably add the chipset devide ids to the driver, instead evealuating only the class reported by the bios
[19:45:41] <PieterPan> http://www.panman.eu/haiku/ahci-ide_emulation.JPG
[19:45:44] <PieterPan> Ok
[19:45:50] <dr_evil> that would allow the ahci driver to ignore the bios setting
[19:46:17] <etteyafed> dr_evil: I have been trying to get haiku installed on a partition on my HP Pavilion dv6000 to test that driver on an intel 945 chipset but i am having trouble.
[19:46:49] <etteyafed> If only i could format a bfs partition and write to it from linux
[19:47:41] <PieterPan> http://haiku-os.org/documents/dev/installing_haiku_to_a_partition_from_linux
[19:47:49] *** Atomozero has joined #haiku
[19:47:52] <PieterPan> easy enough, did it this morning :)
[19:48:00] *** Player1 has quit IRC
[19:48:14] <DeadYak> etteyafed: the build system can do that for you
[19:48:15] <etteyafed> PieterPan: Yes. I tried that but the os won't load from grub
[19:48:19] <DeadYak> ah
[19:48:33] <PieterPan> did you subtract 1 from the hdd number?
[19:48:35] <etteyafed> i do rootnoverify (hd0,1)
[19:48:43] <etteyafed> chainloader +1
[19:48:44] <etteyafed> boot
[19:48:46] <PieterPan> sda4 became hd3 for me
[19:48:50] <etteyafed> it is sda2
[19:49:06] <PieterPan> hm, don't know then...
[19:49:14] <etteyafed> yeah. me either
[19:50:28] <Atomozero> berilios is downs?
[19:50:31] <Atomozero> down?
[19:50:33] <dr_evil> sda4 is hd0,3
[19:50:36] <etteyafed> etteyafed@Lola:~/Src/haiku$ HAIKU_INSTALL_DIR=/dev/sda2 sudo jam -j2
[19:50:43] <PieterPan> I think so yes
[19:50:48] *** jevin has joined #haiku
[19:50:48] <etteyafed> that is my cmd
[19:50:48] *** oco has joined #haiku
[19:51:05] <DeadYak> that won't quite work.....
[19:51:30] <etteyafed> DeadYak: Ok, but why?
[19:51:31] <DeadYak> that will try to install to /dev/sda2/haiku.image afaik
[19:51:38] <DeadYak> because the dir and image name are separate params
[19:51:46] <DeadYak> you'd want dir = /dev, image_name = sda2
[19:51:46] <dr_evil> please read the info
[19:51:52] <dr_evil> [19:47] <PieterPan> http://haiku-os.org/documents/dev/installing_haiku_to_a_partition_from_linux
[19:51:53] <DeadYak> which was stated in the post detailing how to do this
[19:51:56] <PieterPan> HAIKU_IMAGE_NAME	= sda6 ;
[19:51:57] <PieterPan> HAIKU_IMAGE_DIR		= /dev ;
[19:52:16] <PieterPan> Both parameters
[19:52:26] <PieterPan> Probably best to just put it in userbuildconfig
[19:52:28] <etteyafed> DeadYak: Ok. thanks i read that info but must have missed that poast
[19:52:34] <etteyafed> post*
[19:52:35] <dr_evil> sda6 is hd0,5 in grub
[19:53:18] <etteyafed> no sorry guys i had read a different doc
[19:53:42] <PieterPan> Okay. etteyafed Just make very sure you get the path right, otherwise you wipe out a partition
[19:53:46] <etteyafed> thanks for helping point a blind fool in the right direction
[19:54:11] <etteyafed> yeah. i am pretty good at that kind of stuff once i get the right info
[19:55:32] <PieterPan> DHCP works fine in Haiku, doesn't it? Cause my laptop has a Broadcom 5787M chip in it, which might just be supported by the bcm570x driver...
[19:55:44] <PieterPan>  I added my pci id, and it detects the card. But I don't get the correct ip address assigned.
[19:56:20] <PieterPan> NetworkStatus says no link, but it does have an address: 192.168.0.38
[19:56:33] <PieterPan> While it should get something like 192.168.123.xxx
[19:57:22] <etteyafed> lets see if it works! :)
[19:57:27] *** etteyafed has quit IRC
[19:57:31] <PieterPan> ... drum roll
[19:57:53] <DeadYak> PieterPan: DHCP works fine on my nforce chip
[19:58:08] <DeadYak> though I've occasionally seen weirdness that required deleting the network profile to get DHCP working correctly
[19:58:25] <PieterPan> Ok... I assume it is the driver that doesn't work, maybe minor changes to the chip...
[19:59:02] <dr_evil> PieterPan try to configure it manually / static
[19:59:37] *** BePower has quit IRC
[20:00:33] <PieterPan> Huh, interesting, shift tab doesnt go back to the previous field, while tab does go to the next field...
[20:01:31] *** SDragon has joined #haiku
[20:01:32] *** SDr has quit IRC
[20:02:21] *** BePower has joined #haiku
[20:02:29] *** etteyafed has joined #haiku
[20:03:29] <PieterPan> dr_evil nope, no luck. I think the No Link status in the NetworkStatus app kind of gives it away...
[20:05:12] *** Stargater has quit IRC
[20:05:16] *** SDr has joined #haiku
[20:06:32] *** petterhj has joined #haiku
[20:07:51] <etteyafed> I think everything got installed correctly, it just won't boot for some reason.
[20:08:11] <PieterPan> Did you enable debugging output on the screen?
[20:09:04] <etteyafed> PieterPan: Me?
[20:09:12] <dr_evil> PieterPan btw, cd/dvd rom drives are not supported with ahci yet. I first have to buy such a beast before I start working on it
[20:09:25] <etteyafed> Grub just says "Failed to load OS"
[20:09:47] *** lorglas has quit IRC
[20:09:59] <PieterPan> etteyafed oh then you don't even get there... Did you follow all the steps on the tutorial?
[20:10:01] <etteyafed> I don't get as far as kernel debug. I mounted sda2 in linux and everything looks ok
[20:10:21] <etteyafed> let me make double sure
[20:10:22] <PieterPan> dr_evil Yeah, I'm not sure actually what it is, sata or ide now..
[20:10:47] <dr_evil> etteyafed whats the partition?
[20:13:35] <etteyafed> PieterPan: Yes i have everything in place except the grub config, but i just do it from the grub cmdline until it works
[20:13:44] <etteyafed> dr_evil: dev/sda2
[20:13:53] <etteyafed> it is 6gb
[20:14:14] *** bga has joined #haiku
[20:14:15] *** ChanServ sets mode: +o bga
[20:14:42] <PieterPan> Can you try to add the entry to the menu.lst? I did that and it works fine
[20:14:42] <PieterPan> # Haiku on /dev/sda6
[20:14:43] <PieterPan> title		Haiku
[20:14:43] <PieterPan> rootnoverify	(hd0,5)
[20:14:43] <PieterPan> chainloader	+1
[20:14:59] <PieterPan> But then of course you correct the numbers..
[20:15:37] <etteyafed> i do exactly that in the grub command line. it is no different from doing it in the config file
[20:15:56] <DeadYak> including the chainloader part?
[20:16:01] <etteyafed> eg. i press c at the grub prompt, and then i type the commands in
[20:16:02] <PieterPan> Ah, at how many gigabytes does the partition start?
[20:16:27] <etteyafed> it starts near the end of the drive
[20:16:39] <etteyafed> maybe 110 or something
[20:17:00] <etteyafed> DeadYak: yes including chainloader and boot
[20:17:26] <PieterPan> Well, just try it with the modified menu.lst, can't hurt... Otherwise I don't know...
[20:18:37] <etteyafed> PieterPan: Starts at 73.3 goes to 80. i forgot this was the smaller drive
[20:20:09] <etteyafed> yeah, maybe it will work
[20:20:39] <fyysik> Ketsuban - I know two ideas - one links it to altai languages, so to turkish amongst other, another idea - link to languages like in use in  malaysia, fillipine, indonesia
[20:20:42] <etteyafed> if the partitions are not in logical order will that mess up grub?
[20:21:16] <PieterPan> Don't know
[20:21:49] <etteyafed> i dont think it does, because grub reeads the partition table and uses that
[20:21:56] *** alpha-li1n has joined #haiku
[20:22:21] <etteyafed> but i am not sure
[20:22:23] *** SDragon has quit IRC
[20:22:32] <fyysik> kokito  - so, Japanese think that  they originate from those islands, and didn't come from somewhere outside?:)))
[20:23:06] *** etteyafed has quit IRC
[20:23:36] <fyysik> and even 3 millions years ago, to say, Japan was populated with Japanese:)
[20:23:57] *** fyysik has quit IRC
[20:24:05] *** stargater has joined #haiku
[20:24:10] <stargater> re
[20:32:43] <bga> kokito: Around?
[20:32:56] *** HieiJ has joined #haiku
[20:32:58] <bga> umccullough: ?
[20:33:14] <kokito> bga, I'm here
[20:33:45] <bga> kokito: i will be in MTV for the next 2 weeks.
[20:33:54] <bga> Starting next sunday. :P
[20:34:00] <kokito> yay!
[20:34:01] <bga> When is the Mentor Summit?
[20:34:07] <kokito> on Sunday :)
[20:34:12] <kokito> what time do you arrive?
[20:34:25] <bga> Dunno yet, but probably near lunch time.
[20:34:30] <kokito> perfect!
[20:34:37] <bga> Would you think you could give me a ride from the San jose airport?
[20:34:46] <kokito> yes, no problem
[20:35:04] <bga> Cool! i will let you know about the details as soon as I do.
[20:35:23] <kokito> just email me your flight info bga
[20:35:43] <bga> B_WILL_DO
[20:35:51] <stargater> bga: you cab sayed here :-) the details
[20:36:12] <stargater> cab = can
[20:37:14] <Stamrogh> ?
[20:39:27] *** HieiJ has quit IRC
[20:40:24] *** alpha-lion has quit IRC
[20:41:55] <bga> kokito: I want to preorder something that will be released only in december 10...
[20:42:02] <bga> And they do not ship outside the US.
[20:42:27] <bga> Can I ship it to your home and then get it with you (or you can mail it to me, I would pay the shipping costs, off course).
[20:43:27] <kokito> bga, you can use my home address if you want
[20:44:00] <kokito> bbl
[20:44:29] <bga> kokito: Cool, thanks! Can you mail the address to me?
[20:44:34] <bga> I am buying this: http://www.pleoworld.com/
[20:44:35] <bga> :)
[20:49:26] <stargater> bga: thats cool
[20:49:33] <bga> stargater: Yes, it is. :)
[20:49:48] <stargater> :-)
[20:50:12] <PieterPan> How hard would it be to port a linux ethernet driver to Haiku? http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=blob_plain;f=drivers/net/tg3.c;hb=007a880d627aee0e854e793099bb33d0c1130678
[20:50:28] <PieterPan> Considering the size of that file...
[20:51:59] <PieterPan> this is a driver that Broadcom helps develop
[20:54:03] <PieterPan> Oh, I see that NathanW has an old driver of that.
[20:54:14] <PieterPan> Maybe that can be adopted
[20:54:26] *** dr_evil has quit IRC
[20:55:00] *** xenonsoft has joined #haiku
[20:59:40] *** wildur has joined #Haiku
[20:59:53] *** aldeck has joined #haiku
[21:00:58] <DeadYak> isn't the one in Haiku a port?
[21:01:30] <DeadYak> yeah, Haiku's is a port of the linux driver already
[21:02:27] *** rgb has joined #haiku
[21:02:47] <PieterPan> DeadYak hmm, yes, perhaps it is just out of date...
[21:03:13] <PieterPan> I don't know what it would take to upgrade it to the latest...
[21:03:28] <DeadYak> yeah, I'm not sure how much it was restructured
[21:04:03] <PieterPan> Well, the linux driver is 1 file, and I see a bunch of files for the haiku driver
[21:06:56] <PieterPan> Oh well... does anyone know if I can mount BFS in Linux to copy some files to it?
[21:10:57] *** Deffy_Lappy has quit IRC
[21:18:08] <PieterPan> never mind, I found it, through the UserBuildConfig
[21:21:23] *** emitrax_ has quit IRC
[21:27:25] *** Ingenu_ has joined #Haiku
[21:33:08] *** TuneTracker has quit IRC
[21:33:24] *** JT-Sleep has joined #Haiku
[21:37:51] <kokito> bga, sent
[21:39:42] *** JT-Sleep has quit IRC
[21:42:02] *** JonathanThompson has joined #Haiku
[21:45:24] *** Ingenu has quit IRC
[21:47:44] <CIA-5> bonefish * r22416 /haiku/trunk/ (38 files in 13 dirs): (log message trimmed)
[21:47:44] <CIA-5> * Renamed fs/vfs_select.cpp to wait_for_objects.cpp and got rid of
[21:47:44] <CIA-5>  vfs_select.h, respectively moved most of it into the new kernel
[21:47:44] <CIA-5>  private header wait_for_objects.h.
[21:47:44] <CIA-5> * Added new experimental API functions wait_for_objects[_etc](). They
[21:47:45] <CIA-5>  work pretty much like poll(), but also for semaphores, ports, and
[21:47:48] <CIA-5>  threads.
[21:48:42] <CIA-5> bonefish * r22417 /haiku/trunk/src/tests/system/kernel/ (Jamfile wait_for_objects_test.cpp): Little test program for wait_for_objects_etc().
[21:50:55] <bga> kokito: Thanks!
[21:52:52] <CIA-5> bonefish * r22418 /haiku/trunk/src/system/kernel/lib/Jamfile: Add wait_for_objects.cpp to the kernel, too.
[21:55:52] *** flyinghippo has joined #haiku
[21:57:37] *** PieterPan has quit IRC
[21:58:53] *** pyCube has quit IRC
[22:02:08] *** aldeck has quit IRC
[22:02:51] *** Begasus_bbl is now known as Begasus
[22:03:05] <Begasus> re
[22:05:17] *** twisted has joined #haiku
[22:05:26] <twisted> DeadYak: hi
[22:05:49] *** twisted has left #haiku
[22:08:11] *** DaaT has joined #haiku
[22:10:02] *** Euver has quit IRC
[22:12:49] *** rgb has quit IRC
[22:12:59] *** tombhad_ has quit IRC
[22:17:45] *** TuneTracker has joined #Haiku
[22:17:58] *** SprMa_webchat has joined #haiku
[22:19:59] *** guma has joined #haiku
[22:26:42] *** umccullough_work has joined #haiku
[22:27:31] *** cps1966 has joined #haiku
[22:31:10] *** aldeck has joined #haiku
[22:41:35] *** DeadYak has quit IRC
[22:48:23] *** BePower has quit IRC
[22:54:58] *** SprMa_webchat has quit IRC
[22:58:06] *** xenonsoft is now known as xns_away
[23:02:49] *** MikeW has joined #haiku
[23:03:00] *** Thomas___ has joined #haiku
[23:03:09] <MikeW> Cyan is crazy!
[23:03:33] <nielx> which one?
[23:05:08] *** BuildFactory has quit IRC
[23:05:15] *** wasosa has quit IRC
[23:05:44] *** wasosa has joined #haiku
[23:06:08] <umccullough_work> probably cyan-Q6600
[23:09:05] <aldeck> if it's the same cyan, then yeah he's crazy :-D http://bebits.com/app/4510
[23:11:54] <umccullough_work> yes
[23:13:53] <TuneTracker> My goodness, is that just a spoof?
[23:14:30] <Ketsuban> I don't think it is, because he runs his system without any cooling whatsoever because he complains about the noise.
[23:14:38] *** pulkomandy has quit IRC
[23:14:53] <Ketsuban> I don't recall him ever mentioning he uses IRC, and he certainly doesn't own a Core 2 Quadro.
[23:15:46] *** fyysik has joined #haiku
[23:16:30] *** santos has quit IRC
[23:18:02] *** xns_away is now known as xenonsoft
[23:20:00] *** DeadYak has joined #haiku
[23:20:04] *** TuneTracker has quit IRC
[23:23:34] *** Ingenu_ has quit IRC
[23:24:52] *** nielx has quit IRC
[23:25:33] *** kennyjb402 has joined #haiku
[23:25:38] *** pyCube has joined #haiku
[23:27:20] <pyCube> yep
[23:28:54] *** SDragon has joined #haiku
[23:33:33] <umccullough_work> Ketsuban, he already confirmed here in the channel that he's the same person.
[23:33:47] <Ketsuban> Oh, okay.
[23:33:49] <Ketsuban> I stand corrected.
[23:33:58] <umccullough_work> unless he's a poser
[23:34:13] <pyCube> rad
[23:45:15] *** guma has quit IRC
[23:45:46] *** SDr has quit IRC
[23:46:37] *** DeadYak has quit IRC
[23:48:46] *** magnetron has quit IRC
[23:49:33] *** DeadYak has joined #haiku
[23:50:06] *** WindowsUninstall has quit IRC
[23:50:07] <pyCube> is it just me, or is the fact the the US military contracts out to private companies for security services
[23:50:18] <pyCube> really weird
[23:52:52] <cps1966> army yes marines no
[23:54:02] <pyCube> but.. since when does the govt need to contract out to private firms in order to provide security for govt officials, embassies, etc?
[23:54:15] <pyCube> isnt that kinda what the military is already for?
[23:54:26] <cps1966> since they cut us forces
[23:54:56] <pyCube> it'd be like driving up to an army base and being greeted by rent-a-cops
[23:55:07] <pyCube> just seems odd
[23:55:08] <cps1966> hell we had to cook and everything now they have outsiders do it
[23:56:20] <cps1966> army pay 25000 a year private contrctor 100000
[23:56:33] *** aldeck has quit IRC
[23:56:34] <pyCube> yeah
[23:57:56] <pyCube> which is weird
[23:58:12] <pyCube> seeing as the contractors get paid by us govt
[23:58:23] <cps1966> yup all ex service members apply
[23:58:24] *** frodobeg25 has joined #haiku
[23:59:45] <pyCube> yet again, privatization seems to only be better for the one who gets the contract

   October 2, 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 | 31 | >