<kyak> jow_laptop: what do you think about the ffmpeg update? Will it be reverted or we must live with it and adapt/throw away other packages?
<bartbes> so did anyone ever get the image to run in qemu?
<jow_laptop> kyak: up until now I didn't think anything at all :) So the problem is the api change?
<viric> is anyone here good at hanging the linux in the nanote?
<viric> or it's something you find hard to do?
<alcy> hanging ?
<viric> :)
<viric> yes. hang the system
<alcy> heh.
<viric> I've a weird problem with a sheevaplug
<viric> I think that 'tmpfs' don't cope well with the OOM killer
<viric> if you manage to be writing small things often to a tmpfs, and at the same time you have a OOM killer situation, it will hang.
<viric> (I talk about the case of no swap)
<viric> I can reproduce the issue easily. The kernel stops working.
<C-Keen> viric: check if you have configured the correct amount of RAM?
<viric> yes. 512MiB
<viric> I think that if I disable tmpfs, I'll have no trouble
<viric> But now I think there is some race between tmpfs and the oom killer.
<viric> the oom killer all the time hits fine the process it should kill
<viric> and sometimes the system keeps on running fine... and suddenly, just at one oom kill, the kernel kill report is the last thing you can expect from that kenrel
<kyak> jow_laptop: yeah, the problem is the api change
<Jay7> viric: there was known OOM on Zauruses with udev
<Jay7> may be you hit this too
<viric> Jay7: how did it go?
<viric> Jay7: I know the process that takes lots of RAM. I want linux to kill it - that's what I expect. I don't want linux to hang. :)
<Jay7> viric: I don't know details
<Jay7> iirc, it was fixed in other version or something like
<viric> does the nanonote linux stand fine processes taking lots of ram?
<qi-bot> [commit] Werner Almesberger: cngt/cngt.c (do_key): merge common x/y positioning code (master) http://qi-hw.com/p/cae-tools/daa3554
<qi-bot> [commit] Werner Almesberger: cameo/templates/mkmk-simple: added optional BOARD_Z parameter for board thickness (master) http://qi-hw.com/p/cae-tools/6795057
<qi-bot> [commit] Werner Almesberger: cngt/cngt.c: added positioning-only mode (master) http://qi-hw.com/p/cae-tools/eb8964d
<qi-bot> [commit] Werner Almesberger: cngt/cngt.c: added small steps (default) and long steps (with shift) (master) http://qi-hw.com/p/cae-tools/639d9a2
<lekernel> wpwrak, for your optocoupler thing, what about 1) putting a forward diode in series 2) having a resistor connected in parallel to to optocoupler diode so the protection diode takes all the voltage when the polarity is reversed ?
<lekernel> (and if Murphy is there, a capacitor to absorb voltage spikes due to the parasitic capacitance of the protection diode... kidding ;-)
<wpwrak> lekernel: hmm, the series diode would add its own Vf, raising the minimum input voltage at which the whole thing can operate
<wpwrak> lekernel: i.e., i'd like to be able to handle 1.8 V systems. that's kinda the next step after 3.3 V. future-proofing ;-)
<lekernel> use those icouplers you mentioned, then
<wpwrak> yeah, with them it would be easy ;-) but they're rare birds. e.g., there doesn't even seem to be a second source for functionally similar parts. guess we just have to sit out these 20 years until the technology becomes safe to use.
<wpwrak> (you can second-source some that don't carry power, though. but then you need an independent supply on the secondary side)
<DocScrutinizer> wtf now you consider specialized optocouplers, but you don't like a solution with a rather standard MAXIM chip plus a (FET-)transistor
<DocScrutinizer> ?
<wpwrak> i think you missed the irony ;-)
<DocScrutinizer> maybe
<DocScrutinizer> +-50V isolation, 2 inputs
<DocScrutinizer> http://www.clare.com/home/pdfs.nsf/www/AN-107.pdf/$file/AN-107.pdf p.3
<DocScrutinizer> but yeah that needs an isolated Vcc
<DocScrutinizer> wpwrak: I missed if you need separate isolated GND for each input as well?
<wpwrak> yeah, no common ground
<DocScrutinizer> ouch
<wpwrak> if you want common ground, connect it outside :)
<wpwrak> why "ough" ? an optocoupler handles this just fine, no ?
<DocScrutinizer> so you want to connect the N inputs to N devices that all have different GND levels?
<wpwrak> i want to connect to up to 4 devices about whose ground levels i know nothing
<DocScrutinizer> :-S
<DocScrutinizer> and those 4 devices all are not prepared to drive a proper signal output for that purpose
<DocScrutinizer> I really don't get it
<wpwrak> it may not be an "output" to them. i may just connect somewhere into the circuit.
<wpwrak> and yes, i realize that my approach has its limitations. e.g., i couldn't probe a line with a very weak drive, e.g., a pull-up
<wpwrak> grmbl. my first try at milling the board went amazingly well, considering that i forgot to tighten the screws holding the board in place
<wpwrak> it only became airborne once the mill tried to cut the outline ...
<wpwrak> (which the machine detected even without decapitating the endmill, quite nice)