<qi-bot> [commit] Xiangfu Liu: gmu: update to 0.7.2, it's need lib speedx http://qi-hw.com/p/openwrt-packages/7fbb60a
<qi-bot> [commit] Xiangfu Liu: new package: flite, a small, fast run-time synthesis engine http://qi-hw.com/p/openwrt-packages/cd33c1c
<qi-bot> [commit] Xiangfu Liu: ikog.py: using UNPACK_CMD instead of download everytime compile http://qi-hw.com/p/openwrt-packages/f93258c
<wolfspraul> here you see some of the pain with those 2 connectors
<wolfspraul> really really bad idea to put 2 different connectors side by side
<wolfspraul> :-)
<wolfspraul> adamw_: I'm not sure about cutting J5 (fig.10)
<wolfspraul> first we already sold some boards with the full length
<adamw_> wolfspraul, now there's no chance to change P2 JTAG(on pod) and J6 JTAG(on M1)
<wolfspraul> and then we would move to a non-standard height and could never find this connector anymore
<wolfspraul> and people may have trouble connecting other cables to it
<wolfspraul> yeah it's a mess, just as I predicted :-)
<wolfspraul> well we have a chance to bath in a bad idea now, for a while
<wolfspraul> need to enjoy that at least...
<wolfspraul> :-)
<wolfspraul> so maybe we just leave it as in Fig. 10 right now?
<wolfspraul> we just say that is the 'official' way?
<wolfspraul> maybe that's the least pain, and we can wait a little, sell some boards, grow the community, and eventually find a better solution for this
<adamw_> I used standard FTDI TTL-232L-3V3 cable, its wafer is connected well on  my trimmed J5 headers.
<wolfspraul> who knows we might even integrate the jtag-serial on m1 one day. I've heard enough people tell me the whole concept of a daughterboard in this case is nothing but stupid.
<adamw_> actually I tested 100pcs by figure 10. Always...I know it's not good.
<wolfspraul> adamw_: we declare Fig. 10 to be the official way?
<adamw_> but I won't push pod too much un-horizontal
<wolfspraul> like I said sometimes you just have to admit something is crappy. is this crappy? yeah sure it is... that's the best we were able to do for now...
<adamw_> wolfspraul, if we declare to use Fig. 10, this means they may trim by themselve.
<wolfspraul> that's even worse.
<wolfspraul> then we risk that people damage their boards, we get returns
<wolfspraul> everybody will have a different height
<wolfspraul> some will cut too much, some too little
<wolfspraul> and so on
<wolfspraul> that's not a good idea at all
<wolfspraul> we need to do the best we can, and then sell our result
<wolfspraul> also we need to clearly say what is the official (!) way
<wolfspraul> if people do their own thing, that's another issue. but they should know what the 'recommended' way is...
<adamw_> but if people want to use JTAG/Serial pod, must trim to let P2 JTAG(on pod) with J6(on M1) to be well-contacted.
<qi-bot> [commit] Xiangfu Liu: new package: offlineimap, Read/sync your IMAP mailboxes [Python] http://qi-hw.com/p/openwrt-packages/3fb4302
<wolfspraul> adamw_: you mean fig. 10 is not good?
<wolfspraul> actually in fig. 10 the jtag does not connect well?
<adamw_> still connected well while I tested all 100pcs, but I do not suggest this fig. 10
<wolfspraul> ah great :-)
<adamw_> you can zoom in to to see fig. 10 to see JTAG contact.
<wolfspraul> so that answers my question - fig. 10 cannot be the 'official' way
<wolfspraul> can you find a shorter serial header for future m1 runs?
<wolfspraul> we can even rework the ones you still have now...
<adamw_> I won't gurantee how many times the J6 (on M1) its plastic outlet will be broken.
<wolfspraul> you mean with fig. 10?
<adamw_> yes, you should zoom in the fig.10
<wolfspraul> better not...
<wolfspraul> :-)
<adamw_> i am trying to find another shorter J5 for next M1 run
<wolfspraul> can you find a shorter serial header for m1?
<wolfspraul> serial for m1 == j5 ?
<adamw_> yes
<wolfspraul> maybe we can rework the boards you have now too
<wolfspraul> I want to have one good/official board, with the best result we can produce.
<adamw_> ha. :) do this later once have orders. :)
<wolfspraul> I rather hold off on selling the current boards until this is better...
<adamw_> sure
<adamw_> yes
<wolfspraul> no
<adamw_> agreed
<wolfspraul> no orders until this is better
<wolfspraul> the j5 on m1 is pretty long (standard height I think)
<adamw_> agreed
<wolfspraul> but maybe we can find a shorter there...
<adamw_> sure if I find then I directly rework.
<wolfspraul> and still easy to source in the future, hopefully
<adamw_> hope we are lucky
<adamw_> you really don't need to worry if J5 is too short that standard wafer(female) can insert.
<wolfspraul> ok
<adamw_> i used FTDI cable, they are ok
<wolfspraul> ok, so the plan now is to find a shorter j5 asap, and then rework all existing boards
<wolfspraul> people who have boards already need to cut their j5 themselves, carefully, or use the jtag-serial like in fig. 10
<wolfspraul> adamw_: agreed?
<adamw_> agreed this.
<wolfspraul> ok cool
<wolfspraul> we created the mess, we cleanup the mess :-)
<adamw_> when you received 12pcs, you could also insert to feel.
<wolfspraul> I don't have an m1 board right now...
<adamw_> yes
<adamw_> ok
<wolfspraul> I will only send them to people who bought m1 boards already.
<wolfspraul> so because we don't have a good official solution, this problem will be multiplied to many people...
<wolfspraul> oh well. at least we try to stop it now...
<wolfspraul> but your pictures are very clear, thanks!
<wolfspraul> adamw_: I'm a little worried telling people to clip off the j5 on m1 themselves
<wolfspraul> the metal is quite thick, and they need quite a bit of force. I can easily imagine they break off the entire connector from the board.
<adamw_> wolfspraul, hmm...to trim this four metal pins 4.3mm off, yes, it's quit hard to trim exactly..
<adamw_> but just slight trim 2mm first then another 2mm..
<adamw_> and contact with pod.
<wolfspraul> hmm
<wolfspraul> well. like I said.
<wolfspraul> we already agreed on a plan.
<wolfspraul> let's find shorter j5 ourselves first, asap.
<adamw_> i just trim four pins in this way and to hook up them together.
<wolfspraul> then rework the existing boards
<adamw_> ok
<wolfspraul> if we believe we can find them, we can also start trimming j5 on the m1 boards ourselves now, before we sell them
<wolfspraul> but the main thing is to find a standard connector
<wolfspraul> yeah, so maybe we do that too.
<wolfspraul> if someone orders m1 now, we send them a trimmed m1
<wolfspraul> but you don't need to trim them all now, let's look for a standard connector first, buy them, and then rework the boards you have with that standard connector
<adamw_> well...to find a exist header not just a standard one.
<adamw_> i would trim them once I sure I can order a shorter header.
<wolfspraul> you think trimming is better than changing to the new header?
<wpwrak> (pain) looks nasty. and that's after picking the "right" connectors ? :-( well, i'll read the backlog over breakfast ... nothing like a good tragedy to start your day :)
<wolfspraul> I tried to explain to you recently that this was already unavoidable...
<wolfspraul> the mistakes were made earlier, but we try to contain them now.
<wolfspraul> one could even argue whether the idea of a separate debug board has merits or not
<wolfspraul> and if it has to be, the next idea was to use 2 different connectors side by side to make an 'ultra flexible' solution
<wolfspraul> well, that backfires badly now, but no surprise...
<wolfspraul> like I said, sometimes you just have to enjoy the mess, what can you do...
<wolfspraul> we've already sunk a lot of hours into this, and many more will follow
<wolfspraul> with all the costs into this already today, I would have enough money to put ft2232 + connector on the first 1000 milkymist one, at least
<wolfspraul> and the bills keep coming...
<wolfspraul> anyway this will not kill the project, we'll fix it and recover
<wpwrak> (unavaoidable) yeah. just in the discussion a few days it looked as if you were trying to find a part that solves it for this run (after rework), too. anyway, the pictures don't look nice indeed.
<wpwrak> "M1 rc2 J5 header cut shorter pod C27 collide J6 headers outlet on m1.png" is the cap on the jtag board in front hitting the shroud of the jtag connector on mm1 ?
<wpwrak> "M1 rc2 J5 header cut shorter pod U1 collide J6 headers outlet on m1.png" just looks messy, can't say whether right or wrong :)
<wpwrak> three bens arrived at customs at 3 am. let's see how long they take. those fedex multi-piece shipments are funny - the last time, they delivered one the first day, without covering customs fees or taxes, but the second one only the next day, saying their delivery folks had been overloaded. optimization ... doing it very wrong ;-)
<lekernel> don't worry about that cap. it still works, and it's plastic so no short circuit possible
<lekernel> just move it for the next run, but it's not a big issue
<lekernel> and what's so hard about trimming connectors...? with cutting pliers it's easy
<wolfspraul> yes we look for shorter j5 on m1 too
<lekernel> u1 is a bit more of a problem, but not a show stopper either... working solutions are better than perfect solutions :)
<lekernel> yeah, just put a shorter connector. and trim it on the existing boards
<wpwrak> (cap) yeah, just mechanical stress could be an issue
<lekernel> people ignoring the project are more of an issue
<wpwrak> (trimming connectors) one problem can be mechanical stress if there's any sudden separation. can break solder joints and such. lead-free solder and anything mechanical don't go along well
<wolfspraul> yeah well [u1]
<wpwrak> yeah, where are the articles on heise news ? :)
<wolfspraul> if we want articles, we need good stories
<wolfspraul> that's a lot of work to talk to journalists etc. I for one will start that once I have my stuff under control, which is hopefully soon :-)
<wolfspraul> things like this jtag-serial...
<wolfspraul> there's no way heise will just write about it because...? because what?
<lekernel> wpwrak: why does trimming connectors aggravate this?
<wpwrak> wolfspraul: because its technologically unusual ?
<wpwrak> lekernel: the act of clipping may
<lekernel> using proper cutting pliers does not put strain on the solders, does it?
<wolfspraul> go to heise, read the headlines, think who cares about this stuff and what more they might be interested in
<wolfspraul> but be honest :-)
<lekernel> has never seen a solder break because he cut some component lead attached to it
<wpwrak> lekernel: yes, if you do it right and slowly one by one, stress should be minimal. the key is doing it right :)
<wpwrak> wolfspraul: hmm, "Mini-ITX-Mainboard mit AMD E-350 und USB 3.0" sounds a lot more boring even the least inspired headline about MM1 could say
<wolfspraul> ok, keep thinking
<wolfspraul> if that's the case, why is it there?
<wolfspraul> you know they track very precisely click rates and what not...
<wolfspraul> do you think they don't know what their readers want?
<wolfspraul> if this is what they want, why do they want that?
<wolfspraul> (the readers)
<wolfspraul> and what more could they possibly want?
<wpwrak> well, readers want to know what's going on in general
<wpwrak> so you get boring stuff, too
<wolfspraul> this is publishing business, very competitive. 'boring' to them is an article with low click rates.
<wpwrak> MM1 is a lot more on the fringe. people like that as well. "Lebewesen bauen wie mit Lego"
<wpwrak> boring doesn't mean unpopular. if i'm about to buy a new pc, this information may be relevant. but it's still boring.
<wolfspraul> ok! "about to buy a new pc" - now we're getting practical...
<wolfspraul> so when would someone want to read about Milkymist?
<wolfspraul> or m1
<wolfspraul> the IC design or the VJ product?
<wpwrak> VJ, FPGA fans, but mainly people who want to know about solutions off the beaten path
<wolfspraul> I would challenge whether 'fpga fans' exist, and how to find them.
<wolfspraul> you think someone will buy something only because it has an fpga?
<wolfspraul> I really doubt that, and even if such people exist, finding them will be very hard.
<wolfspraul> same for people who like solutions 'off the beaten path'?
<wolfspraul> that's not enough
<wolfspraul> I know some people who buy 'every new gadget', but they usually have a price limit, for example I've heard 150 EUR from such people.
<wpwrak> there are actually very few good headlines on heise lately - all just product evolution and a bit of finances and politics. well, reduces the time drain caused by idle browsing :)
<wolfspraul> aha :-)
<wpwrak> high cost may be an issue, yes
<wolfspraul> plus I'm not sure whether we should try to sell the m1 to those 'every new gadget' folks.
<wolfspraul> they would all disappear into nowhere
<wolfspraul> just makes a little cash
<wolfspraul> it helped me sell a few NanoNotes... turned on once, then into drawer.
<wpwrak> (fpga fans) i was thinking more of people who already use fpgas or are following the technology and are interested in novel uses. MM1 may be about the most ambitious use of mid-range fpgas so far and it's a bit quirky (VJ) as well.
<wpwrak> you don't need to sell to the gadgeteers. get them to talk, spread the news
<roh> wolfspraul: i think the mm1 is well suited for people doing fpga work in general. not neccessarily vj stuff, but as a fpga-develboard
<roh> dunno how expensive spartan6 develboards usually are. i guess 'more expensive'
<wpwrak> the more serious folks may not have the time to look everywhere for the juicy bits of information. but let the gadgeteers be the bees who bring the seeds and flowers together :)
<roh> selling to 'i only buy it because its a gadget' people only generates support requests which are annoying ;)
<wpwrak> roh: digi-key, enter spartan ... many in the same range, one (SP601, out of stock) cheaper (USD 268)
<wolfspraul> I'm thinking about highlighting the vj application.
<wpwrak> err, in stock but a non-stock item
<wolfspraul> the only problem is that 'vj' may make a lot of people think 'oh, that's not me'
<roh> wolfspraul: sure.
<wpwrak> i you could choose to travel both paths independently
<wolfspraul> 'party machine' or 'party station' sounds primitive though
<wolfspraul> video hub - argh
<wolfspraul> :-)
<wolfspraul> VJ station...
<lekernel> embedded multimedia computer?
<roh> wpwrak: eh.. the cheaper develboard seems to have no nearly no io stuff and a smaller spartan
<wolfspraul> we can say it's a VJ station that is so easy to use that anybody can use it, even just for a simple party at home
<wpwrak> not sure how close it is to being ready for VJs, though. it it stage-stable ? or does it have enough features for studio use ? maybe just a "toy" for creative inspiration ?
<lekernel> ah, yeah good idea
<roh> XC6SLX16-CS324
<lekernel> wpwrak: from my experience it is stage stable, except perhaps the video input
<roh> wpwrak: SP605 is XC6SLX45 which costs 450E
<roh> i wouldnt try selling to 'end consumers' which think its a computer. that only generates grief.
<roh> but one could use it as generic stage-equipment.. midi-dmx converter... controlling terminal...
<roh> a dmx lighting computer
<wpwrak> lekernel: sw and hw ?
<roh> such stuff.
<roh> would need a app for that of course
<wpwrak> lekernel: also, is the general handling VJ-friendly ? e.g., most VJs probably don't know what JTAG is and may not have learning openocd very high on their list of personal priorities :)
<wolfspraul> jtag? totally not needed
<wolfspraul> wpwrak: this product is really cool, and definitely usable already!
<wpwrak> wolfspraul: so jtag is just for debugging ? no tricky bootstrap every now and then ?
<wolfspraul> and lekernel has very good focus to continue exactly along those priorities, which I think is what can really launch it eventually.
<wolfspraul> oh no, definitely not.
<wolfspraul> in fact, if the software is a bit more improved, reflashing over the software (without jtag) will be so easy that the jtag itself is really only necessary for rare development or debugging problems.
<wolfspraul> not sure when we are there, and how high on the priority list this is.
<wpwrak> i think not having to touch jtag would be an important feature for being able to sell it to VJs
<wolfspraul> it's already there
<wolfspraul> the only thing is that right now, reflashing via software is still harder than reflashing via jtag
<wpwrak> is it "it's already there" or "if the software is a bit more improved" ? :)
<wpwrak> ah, i see
<wolfspraul> (assuming you have the jtag-serial board)
<wolfspraul> without the need for upgrades, it's already there
<wolfspraul> with upgrades, reflashing via software is still harder, but it's a moving target and I believe Sebastien is on this
<wpwrak> i supposed upgrades will be unavailable
<wolfspraul> as soon as upgrading via software will be easier than via jtag, jtag is relegated to rare problems
<wpwrak> good
<wolfspraul> and that should be within weeks, at most a month or two? don't know Sebastien has the plan...
<wolfspraul> we are not seriously planning to add an extra hole for the jtag-usb into the case, for example
<wolfspraul> not needed
<wolfspraul> by then jtag is only needed for rare problems
<wpwrak> so you want to sell to end-users first. not going the geeks-as-beta-testers route
<roh> i got a comment from people doing stuff on the 27c3 about flickrnoise
<roh> they said 'make the menu darker' .. or find a way to remove it.
<roh> e.g. controll via ethernet and web-ui
<roh> because it generates a lot of 'streulicht' on the beamers
<roh> alternatively there could be a second video/vga out for the 'ui'
<roh> and different resolutions. possibly also for the matrox thingie... thats used by vj's _a lot_
<roh> basically it simulates a monitor which has the H res of 'all outputs stiched together' and the V res of one of them.
<Jay7> +1 to web ui
<roh> but thats all stuff for the 'todo/wannahave/suggestion/ideas'-box, regardless of solving the last few electrical, mechanical and sw issues with mm1
<roh> for 'later' ;)
<larsc> roh, do you still maintain the new openmoko.org servers?
<roh> new?
<roh> i still got root.. but only touch it if i need to to be fair
<roh> i dont think anybody is actively 'maintaining' atm
<wolfspraul> roh: speaking about admin stuff, I recently switched from exim to postfix, and from uw-imapd to dovecot
<kristianpaul> ['vj' may make a lot of people think 'oh, that's not me'] yup
<larsc> roh: ok. git access via the git protocoll does not seem to work.
<wolfspraul> I do the backups with lvm snapshots now, mysql flush tables with read lock etc.
<roh> wolfspraul: heh.. i still use exim. and dovecot
<roh> larsc: i'll take a look
<larsc> roh: thanks
<lekernel> reflashing via software is easy with the current flickernoise/rtems... only the software you've flashed into the rc2 boards didn't support that yet
<lekernel> that's why upgrading those is a bit messy
<wolfspraul> lekernel: we can reflash what we have in stock with something new, if you have a release
<wolfspraul> lekernel: do you think reflashing with the latest software is already easier than with jtag?
<lekernel> yeah definitely
<lekernel> just ftp 3 files or put them on the memory card, then select them in the GUI and click "program flash"
<roh> larsc: can you try accessing it?
<roh> daemon is running.. watching logfiles right now
<wolfspraul> wpwrak: there you go...
<lekernel> it's just steps 5 and 6 with the current sw
<larsc> roh: "git.openmoko.org[0: 88.198.160.201]: errno=Connection refused"
<roh> hm.. last log entry from 2010-12-15 .. ill restart the vm
<roh> try again please
<kristianpaul> memory card ways looks clean for me :-)
<larsc> roh: seems to work, thanks :)
<bartbes> so ehm
<bartbes> what is that jtag?
<kristianpaul> [embedded multimedia computer] i like it too
<roh> larsc: :)
<lekernel> so yes : jtag = rare problems, developers-only, etc.
<lekernel> bottom line: order shorter connectors for the next mm1 run, snap those damn connectors on the already-made boards, move u1 and the capacitor on the jtag layout for the next run if you care (I don't think they're so much of a problem), and don't delay anything
<lekernel> having the daughter board isn't a bad idea
<lekernel> it enables regular jtag cables to be used (don't forget we needed the xilinx cable at the beginning) and standard serial adapters
<roh> lekernel: why not just a longer connector for the jtag instead a shorter one for the serial? wouldnt that also solve the cap problem?
<wolfspraul> :-)
<lekernel> whatever is faster
<wolfspraul> the reason it's a bad idea is economical, not technical
<wolfspraul> but it's OK now, we move forward
<wolfspraul> this will cost us more, guaranteed...
<wolfspraul> I can sense it already :-)
<wolfspraul> until today, I'm sure we already would have paid for 1000, if not more, ftdi chips on m1
<wolfspraul> not even counting all the free work by Yanjun Luo, test runs, what not
<wolfspraul> and we will keep changing and fiddling with this, I'm sure.
<wolfspraul> next we have to discard the 50 usb cables we already bought, and look for those rare ones that are pointing upwards.
<wolfspraul> and so on
<wolfspraul> economically, it's a disaster
<wolfspraul> and there will be more changes
<lekernel> you're too perfectionist...
<lekernel> the current usb cables can be used by removing one of the sides of the case
<wolfspraul> let's not make things worse, we carefully move forward now.
<wolfspraul> next step: find shorter serial headers for m1, clip the boards in stock, or rework to new header.
<wolfspraul> look for new 'point up' usb cable
<lekernel> the usb connector issue is a mere inconvenience
<wolfspraul> fix the C27 issue on the next jtag-serial run (no need to start this work now)
<lekernel> not a show stopper
<wolfspraul> of course not, but it's all work
<lekernel> so it's down the priority list
<wolfspraul> and i guarantee you, mark my words, that this daughterboard will cause us more pain/work
<wolfspraul> 100% guaranteed
<wolfspraul> hopefully one day something comes up where we will think 'yay, we can do this easily because we have the jtag-serial board'
<wolfspraul> just have to believe that day will come :-)
<wolfspraul> we already start the savings for that day today...
<wolfspraul> :-)
<wolfspraul> I'm all easy about it btw.
<wolfspraul> it's good, all moving
<lekernel> I still don't think so. so far the only significant issue i've seen is a connector that needs to be made shorter
<wolfspraul> now that we have this daughterboard, maybe we can reuse it on xue. or who knows, maybe not because there's another good reason not to use it there...
<lekernel> which is easily doable with a pair of pliers, if nothing else
<lekernel> how many consumer products can you count which have JTAG? many
<lekernel> integrated USB/JTAG, none
<wolfspraul> our volumes are totally different
<kristianpaul> [m1 jta-serial ]  Trim  to be ok, if is already did,  but i will not unplug that board once is there, also to be careful with usb cable when connecting that un-horizontal balance dont look good to me either
<wolfspraul> of course nobody adds a 4 USD IC to a consumer electronic
<wolfspraul> but the jtag-serial daughterboard has easily cost us 5000 USD in cash now, with all the time and opportunity costs it's far more
<wolfspraul> and how many m1 have we made so far? :-)
<wolfspraul> 40 :-)
<wolfspraul> unless our m1 volume goes into the thousands, economically separating the jtag-serial will never make sense
<lekernel> but we want it to go into the thousands, don't we?
<wolfspraul> and even if we go into the thousands, there would be enough time and resources to react then, for example to just leave the footprint unpopulated
<wolfspraul> yeah, we can think like that :-)
<roh> lekernel: do you have any scripting language running on the mm1 yet?
<lekernel> roh: ruby works
<wolfspraul> that will make us feel better about it...
<roh> lekernel: wow..  also rails?
<wolfspraul> so let's just move full power now
<lekernel> roh: don't know, I just tested the core
<roh> lekernel: still very nice.
<roh> lekernel: because i got somebody with rails experience who could eventually help out doing a web-ui for flickrnoise
<lekernel> uhm
<lekernel> ruby is slow
<roh> whatever... in the end 'some httpd' and 'cgi or so' would be needed
<lekernel> might still be enough for generating webpages, I don't know
<lekernel> for remote control with "advanced" devices there's already OSC by the way
<lekernel> the menus don't look nice on the beamer, but you're not supposed to see them there
<roh> lekernel: and how does one control a complete flickrnoise with that?
<lekernel> only because the 27C3 setup was a hasty mess
<roh> huh?
<roh> nope. thats a regular vj setup what youve seen there
<lekernel> I'm talking about my own setup
<roh> ah. where should the menu come out elsewise?
<lekernel> I didn't have time to prepare anything on the M1, so I just did it in front of everyone
<roh> its not about preparing. its about being able to access the full ui while its running
<lekernel> prepare first (and connect the interfaces), then go to performance mode
<lekernel> yeah, this feature is a bit hard technically, so I keep it for way later
<roh> sure. one thing at a time
<lekernel> we could also simply add a second vga port using the gpio header
<wpwrak> (daughterboard pain) have you considered connecting it to the MM1 with an FPC ? ;-)
<lekernel> but that's a significant work on software and fpga design
<roh> lekernel: how much work is doing xga and multihead?
<lekernel> especially if you consider that scanning the extra screen will suck memory bandwidth and slow everything down
<lekernel> quite a bit, memory bandwidth isn't an easy problem
<roh> i see. but isnt your memory quite fast already?
<lekernel> oh, it is, but xga/multihead can easily consume more than a dozen gpbs
<lekernel> Gbps
<lekernel> we can also do fake multihead and scale a lower resolution picture in the RAM on the fly
<lekernel> much easier
<roh> hm. the second head for the ui could be lower fps/ and or resolution i guess
<lekernel> fps isn't the problem, the screen refresh rate is
<roh> xga would be most important i think
<lekernel> no matter how slow the image moves, you need to scan the screen at 60Hz (and typically more)
<roh> right
<adamw_> wpwrak, FPC? more pains.
<roh> adamw_: s/fpc/crimped cable
<roh> fpc sucks (breaks easily, tears, wears out)
<wolfspraul> adamw_: he was joking
<lekernel> what's fpc?
<adamw_> wolfspraul, oah...you guys are funny.
<wpwrak> (reflashing) what happens if the board resets after the "erase", before transferring the new files ?
<lekernel> wpwrak: there's a rescue mode
<lekernel> just boot the rescue partitions in this case
<wpwrak> lekernel: (fpc) flexible plastic cable / flexible printed circuit. this was an inside joke - at openmoko, we had a "debug board" with jtag and serial, connected with an fpc. it caused us no end of trouble.
<lekernel> ok. well I think the MM1 daughterboard trouble is pretty much over
<roh> it ended with 'having a known good cable' which was 'made fitting' with a cutter and pressing the connector while flashing to make it work
<wpwrak> roh: i never did the "press the connector" part. even the ones that snapped could be jammed such that they would stay in place :)
<wpwrak> lekernel: (rescue mode) excellent
<roh> wpwrak: stay in place yes... but have proper contact.. nope... not with connectors rated for 20 insertions
<lekernel> thinks many of you ought to try flickernoise and the mm1
<wolfspraul> lekernel: one thing I don't like is that the video-in and audio-in connectors are so far apart
<wolfspraul> there are many cables that are bound together, and it's not easy to connect them. for example from digital cameras.
<lekernel> yeah, maybe, but again that's a rare problem
<lekernel> btw with typical loud music the internal microphone picks up the sound well enough
<wolfspraul> I think it's quite common. We may even be forced to put an extension cable into the box, but let's see...
<wolfspraul> what if someone wants to play something they recorded on the camera?
<lekernel> yeah, and then why not as many adapters as there are connectors on every equipment :)
<lekernel> big jack, rca, .. :o)
<lekernel> that's not a typical use case
<wolfspraul> I'm just thinking practical.
<wolfspraul> it's almost funny how far the video and audio connector are apart.
<roh> i wouldnt worry
<wolfspraul> as if it's on purpose :-)
<roh> i seldomly see video and audio used from the same source in vjing
<wolfspraul> yes it's a trs connector too
<lekernel> same here
<lekernel> btw I hear all sorts of stuff about this box
<lekernel> can it play video
<lekernel> can we put connectors on the top
<lekernel> can we have a second screen
<lekernel> can we have xga
<lekernel> does it support usb sticks
<wolfspraul> we need to describe the 'perfect' use cases it was designed for
<lekernel> etc etc etc
<wolfspraul> until we do that, people will wander around asking all sorts of things, just as you describe
<wolfspraul> can I use this as my wifi router? :-)
<lekernel> yeah, that's why I want to shoot a presentation/tutorial video asap
<wolfspraul> put a usb wifi dongle in - should work, right?
<wpwrak> drivers ?
<lekernel> answering "yes if you write the software" usually turns down those slackers pretty easily :)
<wolfspraul> from what I understand now, I think in general it's a box that helps you if you want to throw a party, or some other stage/art/lighting event
<wpwrak> that's why putting things on linux is so nice. almost instantly, all those driver and stack problems just vanish :)
<wolfspraul> if that's true, that's quite a statement and it will put the rest in context.
<lekernel> wpwrak: no because I don't really care about people wanting to make a wifi router
<lekernel> and maybe linux has many drivers, but it also comes with at least as many issues, as I already mentioned many times
<wolfspraul> we really need to describe precisely which types of events/use cases this is for, and which not
<lekernel> but since you love linux that much, why not give larsc a hand porting it?
<wpwrak> lekernel: but they may care about you and particularly your work, interferingly so :)
<wolfspraul> we cannot ask everybody to figure this out themselves, like "hey, it has a spartan-6 fpga and this and that connector. you should know what it's for"
<wolfspraul> I want to watch a video in my living room? no
<wpwrak> lekernel: (porting) i'd love to. alas, i don't think i'm in a position to commit to such a project
<lekernel> wolfspraul: I was kidding :)
<wolfspraul> kidding about what?
<roh> i think there would be much more intterrest in porting linux if there was a mmu
<wolfspraul> the use cases it is intended/designed for are still not crystal clear to me
<roh> cpus without arent worth shit for a real os.
<lekernel> we need to make a demo/tutorial video asap
<wpwrak> roh: helping with the mmu would have to be part of a port, yes
<wolfspraul> I'm slowly getting the hang of it, after the presentation in Bogota, talking to some people, seeing it live in Berlin, etc.
<roh> wpwrak: sure. i just dont feel competent enough to be not standing in the way ;) thats why i move my ass out of the way
<wolfspraul> but if you give me 50 different use cases, and want to hear a clear yes/no from me whether that's what m1 was made for, I would have a hard time giving a clear answer for a lot of them.
<wolfspraul> many times it would be 'maybe. Ask Sebastien.' :)
<wpwrak> wolfspraul: it's not only what it is designed for but what people could find it useful for. so it would be good to market it such that those who might have new uses don't think it's overly specialized
<roh> wolfspraul: sure. but if that 50 usecases would be weigthed... not 'yes/no' but 'yes | yes,but: |no, but:| no' and having some 'how much work it is and what needs to be researched' for the 'but'-s ... that would help
<roh> like having a faq to search
<wolfspraul> I agree. but the only way to stimulate this type of "hey, I can also use this for XYZ" thinking is to describe the current intended use cases as clearly as possible
<roh> i could even imagine using the mm as some kind of usrp.. with the 3 adc for video as input
<wpwrak> describing the current use case sounds good, yes
<wolfspraul> in fact that's part of the reason you need it, because of course we want people to take this in new directions.
<roh> for signals of only a few mhz bandwith it would do fine
<wolfspraul> but if even the current 'directions' are not described well, there will be just chaos and nothing else :-)
<wpwrak> (headline) how about simply Open Hardware VJ station ? people who don't care about the VJ bit but would like the underlying technology may find the "open hardware" interesting enough. and the VJs will probably look at anything that mentions their niche anyway.
<wpwrak> for marketing material (demo videos, use case, documentation), both tracks should probably be independent
<lekernel> wpwrak: sounds good indeed
<wpwrak> one challenge would be to explain why 80 MHz is not as shitty as it sounds. that may need explaining for technophiles and VJs. also the latter may know that their ultra-low-cost netbook has 20 times the clock rate.
<roh> leave it out
<wolfspraul> it may be thrown into the 'fpga computer - fail' category
<roh> move it to the tech-specs
<wolfspraul> yes, agree
<roh> the 80mhz thingie
<wolfspraul> I think it should be marketed over the end user features.
<roh> 'hw based rendering' +ducks*
<wolfspraul> but written in a good way so that tech people can take this and carry it into what they think they can turn this into...
<roh> we can surely find some buzzwords
<wpwrak> roh: but even from the tech specs, you need an explanation. people will find it - and make fun of it.
<wolfspraul> yes and no. the whole design is so unusual, like you said we could highlight the UNUSUAL part of it.
<roh> wpwrak: sure. but stupid people arent targetgroup anyhow
<wolfspraul> but then we need to be careful because people will ask "unusual, ok. but does it have a future?"
<wolfspraul> nobody is interested in one-off nonsense projects...
<Jay7> do benchmark against ultra-low-cost netbook :)
<Jay7> compare fps
<wolfspraul> I like the vj thing, just that the use cases have to be described very well.
<wolfspraul> in text, pictures, videos.
<wolfspraul> and that also includes describing a list of use cases it is not good for.
<wolfspraul> 'not intended for'
<wpwrak> roh: 80 MHz even sounds bad to non-stupid people.
<wolfspraul> that's not to stop people from doing exactly that, in fact a lot will read that list and say "that is EXACTLY what I am going to use it for..."
<wolfspraul> but it's to clarify the focus of the product
<wpwrak> Jay7: yup, benchmarks are important. particularly to answer the question "why not just some off the shelf netbook" ?
<wolfspraul> wpwrak: not necessarily. press coverage is always good, even negative. Let them laugh.
<wolfspraul> we just need to feel good about it :-)
<wolfspraul> when Bill Ray ran the "dedicated vi device" story for the NanoNote on theregister.co.uk, that brought worldwide attention
<wolfspraul> of course there was a slight touch of retard to the text, so what
<wpwrak> wolfspraul: (bad news are good news too) well, you're grabbing people's attention. what would you like them to focus on in those precious moments until the zap to the next channel - something good or something bad ?
<wolfspraul> well, that's what we need well written use cases for
<wolfspraul> of course there has to be more than a catchy headline
<wolfspraul> the whole story must make sense
<wolfspraul> I like the vj angle, definitely.
<wolfspraul> this can work.
<wolfspraul> we just need to describe use cases better, and lekernel is already planning to do something there...
<wolfspraul> btw, if someone has an idea, just email whatever journalist or blog you know/like
<wolfspraul> journalists need news, no need to waste time here talking to ourselves
<wolfspraul> they want to hear the story
<Jay7> 80MHz is good reason to ask yourself "why so slooow CPU may doing that amazing things but my 1GHz netbook can't?"
<wolfspraul> every blog, every paper has a info@ submitnews@ or similar forms on their site
<qi-bot> [commit] David Kühling: Port of SVGAlib; patched to only use the linux frame buffer http://qi-hw.com/p/openwrt-packages/ac7a991
<wolfspraul> just spam them a little, see what happens :-)
<wpwrak> (a) good VJ promo video(s) will definitely be useful. not only showing the final result but also the steps leading there. making it clear it's not just some cleverly crafted demo but actually a real tool.
<Jay7> btw, yes.. try to record some video with good known VJ/DJ on some fest :)
<wolfspraul> hah. the known ones will be careful to not be (ab)used for sales promotions...
<wolfspraul> understandably slow, too much crap on the market
<Jay7> or even donate some parts to known VJ's :)
<wolfspraul> understandably so,
<lekernel> wpwrak: I said a _tutorial_ video. this obviously includes that
<Jay7> s/parts/devices/
<wpwrak> lekernel: perfect
<wolfspraul> Jay7: I have never once seen this kind of seed-donation strategy work.
<lekernel> only it takes time to make, and I already have 2 conferences, several people to meet and a 3500+km road-trip to prepare atm
<lekernel> probably when I'm back
<wpwrak> Jay7: or better, work with them. let them send the video, bragging of their results ;-)
<wolfspraul> in fact, when you see this, you know that thing will not go very var.
<wolfspraul> far.
<Jay7> wolfspraul: I see it right now
<wolfspraul> which product?
<Jay7> genesi donated about 50 smartbooks to developers
<wolfspraul> alright :-)
<wolfspraul> mark my words...
<Jay7> so efikamx smartbook is most active platform for linaro developers
<Jay7> beagleboard was before
<wolfspraul> I'm very relaxed. It never works, ever.
<wolfspraul> sometimes this type of early donations cannot stop the success of a product, it's not that bad, but they never contribute to it either.
<wolfspraul> well that's my experience at least, ymmv
<Jay7> co-working with well-known VJ's/DJ's should be good anyway :)
<wolfspraul> yes if we find someone who truly believes in the product
<wolfspraul> then I totally agree with you
<wolfspraul> and in that case, that person is making a time commitment worth many times over the cash price of the product anyway
<wolfspraul> so the cash price becomes an irrelevant little blip, for both sides
<wolfspraul> lekernel: which conferences are you going? can we do anything to support m1 sales there?
<Jay7> btw, what is price of MM?
<lekernel> fosdem + an academic conference at uni
<Jay7> OpenEmbedded have stand on fosdem '11
<Jay7> jfyi :)
<lekernel> bearstech too, I hope they'll replenish their stock
<Jay7> MM is good to have on background
<Jay7> music/visual effects
<wolfspraul> Jay7: I can sell you one for 350 USD + shipping.
<wolfspraul> that's including jtag-serial, without case
<wolfspraul> and including power adapter of course
<Jay7> hm..
<wolfspraul> you can pay with visa/mastercard, or paypal
<wolfspraul> wanna buy? :-)
<Jay7> well, I'll think about this :)
<wolfspraul> great, thanks!
<wolfspraul> it's truly a good product, we really put our whole heart into this thing...
<Jay7> I see :)
<wolfspraul> (i'm not saying that means it will be successful, but it's the truth)
<wolfspraul> do you live in Europe or the US?
<kristianpaul> lekernel: You put a BUY link/pic at milkymist.org, but if you go to the distributors there is no milkymist or dates about it, is this intentional?
<Jay7> Russia
<lekernel> kristianpaul: no, it's just because they're late
<lekernel> but if you call them, you could get one
<kristianpaul> ah ok, just asking
<Jay7> now we are needed some good copyleft music :)
<Jay7> to bundle with :)
<wolfspraul> Russia, OK. that would be a shipping/customs challenge but why not.
<Jay7> wolfspraul: yeah..
<wolfspraul> I think fedex only takes parcels declared up to 75 USD to Russia now.
<wolfspraul> we can try to go just under that radar...
<lekernel> Jay7: http://www.plexrecords.com/ (pretty experimental ;)
<Jay7> I've looked at some tracker-music archives but almost all have no license to broadcast music in public place
<wolfspraul> jamendo.com ?
<Jay7> only for personal use
<Jay7> same thing.. you should contact every author and ask permission.. or just pay jamendo :)
<wejp> oh jamendo there are songs that are by or by-sa licensed. not all of them, but there are several
<kristianpaul> for now archive.org
<kristianpaul> and wiki commons
<wejp> and you don't have to pay jamendo
<wejp> just have a look at the license being used
<wpwrak> (seeding the community) particularly for relatively inexpensive items, this doesn't sound reasonable. that is, unless you're actually targeting people who couldn't afford to have dinner at a restaurant :)
<kristianpaul> lekernel: (plexrecords) sounds good, experimental indeed
<kristianpaul> "All Tracks are licensed under a Creative Commons License." wich one?..
<wolfspraul> kyak: you there?
<wolfspraul> remember the libiconv-full/dependency problem that was being discussed here? I chatted with mirko about it, and he said he has an idea for a fix, but would prefer it to be brought up and discuss on the mailing list.
<wolfspraul> can you email the issue to discussion@lists.en.qi-hardware.com ?
<wolfspraul> maybe the solution can help more OpenWrt users in general...
<kyak> wolfspraul: hi
<kyak> ok, i'll do it.. though i mentioned once how i dislike posting to mailing lists :)
<wolfspraul> oh
<wolfspraul> I would write it, no problem, but you know how this is with relays.
<wolfspraul> unless I go through and first recreate it myself, my description would be totally wrong and useless.
<wolfspraul> maybe xiangfu can write it up too, he seems to know what exactly the problem is.
<kyak> i'm already writing it, don't worry..
<kyak> it is sent.. might be muddled, but if mirko is inside of this problem, he would understand
<kyak> wolfspraul: how does it reach mailing lists? is it waiting for some approvement?
<wolfspraul> hmm
<wolfspraul> yeah I was just wondering
<wolfspraul> let me check...
<wolfspraul> it's not in the archives yet, I was just about to ask :-)
<kyak> can't see it just now in mailing lists
<kyak> mailing lists.. the reason for spam in your mailbox and so much less convenient than forums :)
<wolfspraul> ok I just manually approved it, and put you email address into the auto-accept list
<wolfspraul> no the mailing lists are definitely not to blame for spam
<kyak> ah ok, so not everyone can send there..
<wolfspraul> I remember 2 spam mails on any qi mailing list since we started 1.5 years ago.
<wolfspraul> and both bugged me and I'm thinking about how to avoid them :-)
<kyak> no, i mean that your e-mail address is visible to the whole Internet
<wolfspraul> we strictly to opt-in (you have to manually subscribe to the list), and there are many ways to unsubscribe
<kyak> and it will be used for spamming
<wolfspraul> I think it's parsed out in the archives, let me check...
<kyak> the e-mail is coded as "name at mail.tld"
<kyak> i think it's not a problems for those who collect email addresses..
<wolfspraul> yes we could probably change that setting somewhere
<wolfspraul> I'm using spamassassin, and it works quite well. Lately I'm also experimenting with grey-listing, which seems to put a bullet through the rest of the spam.
<wolfspraul> although it affects mail delivery times which is not so nice.
<qi-bot> [commit] Xiangfu Liu: gmu: fix DEPENDS http://qi-hw.com/p/openwrt-packages/437e156
<wolfspraul> pretty good.
<wolfspraul> one thing I could do is take some of the equipment they are talking about, see which online publications are covering it, and then email those publications about the m1
<wolfspraul> Korg, Edirol
<zrafa> kyak: you do not write to mls because you want to avoid spam? :)
<lekernel> wolfspraul: there are already some "video synthesizers" around, e.g. by Edirol, but they're very expensive and do not work so well (and have little advantages over PCs)
<lekernel> http://beta.vjcentral.com/hardware/edirol-cg8-0 I think we're already doing a better job than that...
<wolfspraul> ok so I'm on the right track :-)
<wolfspraul> like I said - homework #1 - find out which blogs or publications are covering stuff like Edirol
<wolfspraul> homework #2 - contact all of those publications and tell them a good story about Milkymist One
<wolfspraul> that will hopefully establish some connections to people who are interesting in bringing a story
<lekernel> yup
<wolfspraul> I'll work on this.
<roh> wolfspraul: hehe..  i was already thinking about 'doing an input interface'
<roh> like 'knobs and dials, some small display'
<lekernel> the hacker community is pretty small anyway (and often has other interests like networking and security) so this won't sell thousands - but the only reason I want to go this path first is there are a few hackers who are also artists and can handle sw problems (or even bring it or the hardware into new directions)
<roh> maybe i cook something up based on some arm develboard or so.. just as a prototype to get the mechanics right from a HIG standpoint.. talk to some VJ's and such
<roh> using the mm1 to do the 'gruntwork' on the data
<lekernel> input interface? there are already many
<lekernel> midi controllers, dmx stuff, ...
<lekernel> and cheap
<roh> they all suck.
<roh> and the cheap ones are garbage. atleast thats what i am told.
<roh> there seems to be nothing below 500-1500E depending on the problem which is worth the money
<lekernel> I have a 40 euro dmx table which doesn't do such a bad job for that money... but anyway
<roh> lekernel: it seems to be a mostly mechanical thing.. bad quality encoders and such. i was also even warned to use behringer equipment because of that (even when i have no hard feelings about that brand)
<roh> things like "dont have precise 'klicks'" and such
<roh> it seems that its the little things which get performers annoyed
<wolfspraul> roh: which means we need good Flickernoise documentation
<wolfspraul> are there other free software VJ apps?
<roh> wolfspraul: i think there are.. but i dont know them
<qi-bot> [commit] David Kühling: gnuplot-gfx: a graphical gnuplot that uses truecolor libvga graphics http://qi-hw.com/p/openwrt-packages/7336686
<wolfspraul> who created the 'Flickernoise' name?
<wolfspraul> was it Sebastien?
<wolfspraul> is that the name just for the app, or the whole system? The wiki seems ambiguous about that ("Flickernoise uses RTEMS")
<wolfspraul> I guess we have a whole bunch of news here :-)
<lekernel> yes
<lekernel> and just for the app
<wolfspraul> you created that name?
<lekernel> yes
<wolfspraul> ah OK
<wolfspraul> and it's based on some older software, right? Genode FX?
<wolfspraul> I read something about that...
<wpwrak> bartbes: (flite) i was wondering when i saw xiangfu's intricate command sequence :-)
<lekernel> genode fx is a GUI toolkit, used to create to windows, buttons and such, which I forked (MTK)
<lekernel> flickernoise uses mtk for window management, widgets, etc.
<lekernel> funny how you're discovering that just now :)
<lekernel> I started talking about it in March (or so) last year
<wolfspraul> it's not as bad as me 'discovering' it now, I just try to get some official 'party line' from you :-)
<lekernel> I wanted it to run on Linux originally, then I ran into the GNUtard and Theobroma related issues
<lekernel> yes, that's why I forked
<wolfspraul> so MTK is a fork of Genode FX?
<lekernel> yes
<wolfspraul> is that fair to say?
<lekernel> yes
<wolfspraul> ok. And flickernoise uses MTK.
<wolfspraul> alright, so Flickernoise is a totally new app, no fork of anything.
<lekernel> it's not a fork, but it draws ideas from Milkdrop with which it's partially compatible
<lekernel> regarding the rendering system
<bartbes> wpwrak: I can totally beat him ;)
<lekernel> the renderer code is original (but somehow based on the demo firmware which I also wrote)
<wolfspraul> ok but that's more of an input format compatibility for the MilkDrop patches, right?
<lekernel> yeah, and how the general process of rendering works
<wolfspraul> we just say Flickernoise is a new app, started from scratch
<wolfspraul> it uses the MTK toolkit which is a fork of Genode FX, and it has some patch compatibility with MilkDrop
<wolfspraul> that's a headline that might work for heise "free software VJ project started"
<wolfspraul> they seem to have a really vibrant group of people who likes to argue, passionately, for or against free software
<wolfspraul> feels like they are all stuck in the 90's somehow, but whatever. heise feeds them what they need...
<lekernel> if you want to feed the troll, you can also point out it's not ported on PCs...
<wolfspraul> no I don't care to feed the troll, but that's a headline I could imagine on heise (for example)
<wolfspraul> they like to announce the start or death of free software projects
<lekernel> ha
<lekernel> well ok then
<wolfspraul> maybe someone has a list they can check off. 'succeeded' yes/no. 'failed' yes/no. then they can yet again bring forward their arguments.
<wolfspraul> painful but I've seen it a lot there...
<wolfspraul> they should get a life :-)
<wpwrak> wolfspraul: "selling" the software apart from the hardware ?
<wolfspraul> not selling, but I think nobody knows anything about flickernoise
<wolfspraul> we just have to unwind the unknown stuff slowly
<wolfspraul> sebastien has started a number of efforts that are worth to be understood separately, and need to be understood separately
<wpwrak> alright. break it down into many little newsbits. why not.
<wolfspraul> Milkymist the IC design
<wolfspraul> Milkymist One the VJ station
<wolfspraul> Flickernoise the VJ app
<wolfspraul> MTK the Genode FX-fork fpga gui toolkit
<wolfspraul> can you develop flickernoise on a pc or emulator?
<lekernel> you can also add liboscparse, which is a fork of liblo without autoconf and other non-portable bits :)
<lekernel> but that was a one-day project :p
<lekernel> yeah, you can use QEMU
<wolfspraul> well that's the thing. to be a 'project' it needs to be announced, explained, nurtured, etc.
<lekernel> there are still a few problems with the rendering but overall it works
<wolfspraul> so you could run the whole thing in qemu on your notebook?
<lekernel> if you don't run into rendering bugs, yes
<wolfspraul> how about the midi, dmx, video-in stuff then?
<lekernel> they're not emulated
<lekernel> that's the point of the M1: have stuff you don't find on PCs
<wolfspraul> how about line-in/out
<lekernel> it works with the soundcard
<wolfspraul> what's emulated in qemu?
<wolfspraul> everything but those 3 I listed?
<wolfspraul> infrared probably not
<wolfspraul> buttons
<lekernel> cpu, base peripherals, vga, pfpu, tmu, mouse, keyboard
<lekernel> audio
<wolfspraul> buttons?
<lekernel> not emulated afaik but I might be wrong
<wolfspraul> ok
<wolfspraul> so mainly missing: dmx, midi, video-in, infrared
<wolfspraul> got it
<lekernel> flickernoise doesn't use them yet anyway... and I just plan to use them as accelerator keys for things you also can click with the mouse
<larsc> and leds!
<larsc> ;)
<wpwrak> heh, someone should produce the ben-blinkenlights board :)
<roh> wolfspraul: heh.. when there is the point for another mm board... we need more leds
<roh> s/point/situation
<kristianpaul> wpwrak: a 8:10 IO cable will be usefull too, ready to connect to breadboard !
<wolfspraul> kristianpaul: we have that already. I will put some into the shipment to you.
<wolfspraul> how many do you need?
<wolfspraul> I think I only have 3 left or so, so your option is 1 or 2? :-)
<kristianpaul> 1
<wolfspraul> ok great, I'll add it
<kristianpaul> wow i never tought see octave on the nanonote and here it is !
<kristianpaul> Cheers to David Kuehling !
<kristianpaul> oh wait thats was gnuplot thread
<wolfspraul> yes it's gnuplot
<wolfspraul> but he's amazing
<wolfspraul> I can hardly keep up in tracking all this, let alone doing a proper app catalog, or test plan for releases...
<lekernel> roh: what do you need leds for?
<lekernel> you can simply connect a mega shift register on the gpio port ;)
<roh> lekernel: lighting up the acryllic
<lekernel> ah...
<lekernel> well that makes perfect sense as a separate daughterboard :)
<roh> lekernel: naah. too expensive.
<roh> 12-20 leds cost nearly nothing.. another pcb costs dollars
<lekernel> you can use FR2 :)
<roh> still mechanically complicated
<roh> would be simple to do on the main pcb
<wpwrak> lekernel: "what do you need leds for?" what a question ! now i'm beginning to doubt you ...
<kristianpaul> roh: even just wiring the leds (and no pcb) just some conectors will be fine i think
<roh> lekernel: git is ok. but not as a central repo for stuff like kerneltrees.
<roh> larsc: hm.. i dunno the correct solution for now.. i think i need to fix my notrbooks fan unit first
<wolfspraul> roh: come on. that's what the whole world knows git for :-)
<wolfspraul> it's all about staying practical I think. everything grows. maybe the server just doesn't have enough ram?
<roh> wolfspraul: well.. i've seen it doing such bad error reporting quite some time now.
<wolfspraul> 2 GB is nothing nowadays, should be 4 or 8.
<wolfspraul> and in a few years 20 GB will be normal, and so on.
<roh> wolfspraul: the machine has ram. still the repo is big.
<roh> 8gb is really far.
<wolfspraul> sure I'm not doubting your experience.
<roh> eh fat.
<roh> it clutters.
<wolfspraul> it's just funny you say "not as a central repo for stuff like kerneltrees"
<roh> needs manual repack from time to time.
<wolfspraul> don't you think that's funny?
<roh> its not 'switch it on and it works' sw.
<roh> which is a bad omen in general.
<wolfspraul> it's like saying a car is not so good for driving people around, but as shelter when it rains, it's quite nice :-)
<roh> its a bit like djb sw from the documentation and usability part. can't use it purely. one needs 'stuff around it'
<roh> git without gitosis for example is clearly not usable for sane people.
<wolfspraul> sure git is 'decentralized', but man there's tons of stuff at kernel.org these days...
<wolfspraul> must be hundreds if not thousands of people committing there everyday, no?
<roh> not saying that djb sw is bad. i use it a lot. but its not a solution for any problem. its a toolbox full of parts.
<roh> wolfspraul: i bet kernel.org has a) paid admins and b) massive ressources to make problems dissapear
<wolfspraul> of course
<wolfspraul> but whatever solution you have, when you scale there will be issues
<wolfspraul> and then you need to zoom in on them in a practical way
<roh> bad sw often can be counteracted by throwing ressources at it.
<roh> the thing is: last time i repacked that repo, it broke.
<larsc> roh: my kernel repo i only 1.2GB and it contains more the the openmoko git repo
<roh> and the point that that can happen makes me think and not trust it entirely. its not a showstopper. somebody could just repush a working copy. but its still sucky.
<wolfspraul> I have seen lots of serious git bugs being found and fixed over the years.
<wolfspraul> to go from 1 corruption to 'I don't trust the tool' is really crazy.
<wolfspraul> that corruption can have so many root causes...
<roh> wolfspraul: google for it. repack seems to have that effect not only for me
<roh> what i wonder is: why do i need to do that AT ALL?
<wolfspraul> ok then stay away from repack until the consensus is that it is rock-safe
<roh> also i learned: lots of unix sw has _shitty_ error handling
<roh> git not being an exception.. the error output is worthless.
<roh> error handling meaning: stuff like ressource shortages etc.
<larsc> hm, i guess i can't run repack with git+ssh access?
<roh> buffer space... sockets... pages.. whatever. lots of stuff just deadlocks or even goes completly crazy
<roh> i'll now do something i dont like...  shoot into the blue
<roh> i bumped the lockedpages limit up quite a notch and restarted the vm please retry
<roh> also i started a vzdump on the vm... as soon as its done i'll try repacking
<larsc> roh: same problem
<roh> hm. if i knew... could it be a diskspace problem?
<roh> where does git-pack store its stuff when doing the pack?
<roh> hm. it wasnt lockedpages
<roh> atleast it didnt run against the limit
<roh> hm. to be fair... ive got no clue what to do besides waiting for the backup and repacking
<lekernel> error handling sucks in C
<lekernel> no wonder why programmers do it wrong (including me)
<lekernel> in a typical C program you have to type more stuff to handle errors than to actually do things
<lekernel> that is totally counter productive
<roh> sure. thats what libs are for.
<lekernel> libs?
<roh> libaries.
<lekernel> yeah got it
<lekernel> but I don't see how
<roh> question of api concept
<lekernel> imo a better solution would be exception, but without all the overhead of stupid systems like SjLj
<roh> exceptions arent doing anything different. just different coding style
<lekernel> sure, but the coding style is what matters here
<lekernel> not having to check the return value of every function call for errors is good
<roh> sure. but thats a question how the api looks like.
<lekernel> and the exceptions make a big difference in the generated code (i.e. they bloat it)
<lekernel> at least given how they're implemented with the GNU C++ compiler
<lekernel> I don't know how other compilers handle that (and I wouldn't be surprised if they did a better job)
<roh> i dont do c++.
<lekernel> neither (or little of it) but it would be nice to have exceptions in C
<roh> doesnt make it prettier.
<lekernel> but it would sure make writing C programs more productive and make them have better error handling
<lekernel> seriously, having to check the result of *every* memory allocation manually... this sucks
<roh> sure. thats why that should be abstracted.
<roh> if you want to write highlevel code, use a highlevel language. this does mean that neither C or C++ come to mind.
<lekernel> my_malloc(x) { r = malloc(x); if(r == NULL) { complain(); exit(1); } return r; }
<roh> C iss a macroassembler.
<roh> C++ is its bastard little brother with a second head on its knee.
<lekernel> current high level languages are slow
<lekernel> but don't get me wrong, I do use python, and I think it's good
<lekernel> but not when I need speed
<roh> ;)
<lekernel> atm I'm writing a fpga synthesis tool (when I have spare time), and I need both speed and high level constructs. so I write it in C and abuse assert(), perror() and exit()...
<roh> hrhr
<larsc> if you don't do any large allocations it doesn't make a lot of sense to check for allocation failures in userspace
<roh> larsc: depends. if your code crashes and burns otherwise... its a good idea.
<roh> especially since nearly all servers are virtualized and have hard ressource limits nowadays
<roh> but hey.. when you write apps and dont use any wrappers you are weird anyhow ;)
<roh> glib for example afaik does block-allocation anyhow
<larsc> if you can allocate your 30bytes struct anymore, it does not really help to catch that error, because you probably won't have enough memory to print error msg or whatever either
<larsc> s/can/can't
<roh> true
<roh> but your printing routing would take it from some block-allocation usually.
<roh> where you also should get your few byte snippets from.
<wpwrak> roh: so it's failing ?
<wpwrak> roh: or are you just bracing yourself for impact ... for now ? :)
<roh> well.. i am still waiting for git fsck --full --verbose to exit
<roh> root     32574 91.2  7.2 1014656 591900 /var/lib/vz/root/201/dev/pts/0 R+ 21:35  36:17                                  \_ git fsck --full --verbose
<roh> memload varies... mostly between 500m and 1g
<roh> will try to repack to chunks of a few hundred mbyte afterwards
<roh> the machine has 8g ram..
<wpwrak> try virtualbox some day for the really scary stuff. the occasional bruise with the windows world really helps to see the little nuisances we have to deal with in perspective :)
<wpwrak> (in my case, caused by the pc running the one bloody piece of non-free software i use dying)
<roh> wpwrak: nah... got kvm on my local notebook. no need for vb
<roh> we got native win32 machines around (e.g. the lasercutter)
<wpwrak> i'm trying to avoid them going native :)
<roh> wpwrak: not an option (no other usecase, dedicated hw)
<roh> and we need working usb
<wpwrak> vb-sun handled usb. maybe vb-oracle does, too
<roh> sure. still i dont use it. bad code. bad experiences.
<roh> hm. slow process runs slow
<roh> root     32574 93.0 11.3 1173756 926412 /var/lib/vz/root/201/dev/pts/0 R+ Jan06 189:52                  |               \_ git fsck --full --verbose
<kristianpaul> Is just me or for some reason the Ethernet Gadget in the Xbusrt may reset sudently sometimes..
<kristianpaul> argg i'll check the usb cable, this is getting disturbing
<qi-bot> [commit] Xiangfu Liu: config.full_system, add math stuff and some new pakcages http://qi-hw.com/p/openwrt-xburst/ca0b6e7
<kristianpaul> Wb :-)