| 00:02.14 | *** join/#qi-hardware panda|x201 (~hzhang@123.116.117.86) |
| 00:06.32 | wpwrak | hellekin: perhaps it's more on-topic on this channel, though |
| 00:08.47 | wpwrak | hellekin: one thing would be safety for sw/hw developers using the chips: they can search for bugs themselves (or find someone to do it), and in case the manufacturer folds, they have at least a chance to get someone else to make the chips for them |
| 00:09.36 | hellekin | I repost here... |
| 00:09.46 | hellekin | wpwrak: I think the best compromise would be some router stuff. They do have radio engineers, but mostly to produce RFID, so it's probably not the same as proper RF or WiFi |
| 00:09.51 | hellekin | but in general, I'd like that they think about producing public infrastructure, so cheap mesh networking would be best |
| 00:09.57 | hellekin | as a fallback, PBX chips could be interesting. I don't see any of non-leaders building consumer nanoware anytime soon. A smartphone is very unlikely, although Brazil does have some local production (e.g., gradiente) |
| 00:10.31 | wpwrak | another benefit would be that they may get people to help. e.g., by reviewing. or making substantial suggestions. depends a bit on how popular the chips in question would be and what segment they address. |
| 00:11.02 | hellekin | I think that having free designs is a great argument. Softcore implementation is another one. |
| 00:11.41 | hellekin | but overall, there must be a large strategy. These people are manufacturing RFID for cattle, that's fucking boring |
| 00:11.45 | wpwrak | anything RF or smartphone in general is a patent minefield at the moment. if they can get suitable political protection, they could perhaps sell them nation-wide. but it's a big risk. |
| 00:11.49 | hellekin | but there's a huge market |
| 00:12.12 | wpwrak | (RFID for cattle) hah ;-) |
| 00:12.13 | hellekin | I would go for public network infrastructure |
| 00:12.50 | hellekin | but look at the perspective for the next few years: 2014 Soccer World Cup, 2016 Olympic Games |
| 00:13.18 | hellekin | all they can come up with is a U.S. imposed surveillance system with cameras all over rio de janeiro |
| 00:13.24 | hellekin | incredibly stupid |
| 00:14.08 | wpwrak | 2014 is soon. you don't want to start designing chips for that now. |
| 00:14.20 | hellekin | but we're dealing here with big geostrategical business: USA wants to keep control over latin america, and for that they need to pursue their non-conventional war program |
| 00:14.34 | hellekin | agreed wpwrak |
| 00:15.26 | hellekin | it's a long term project. And probably one that will involve more than Brazil. Venezuela, Ecuador, Mercosur in general would be interested in having locally-based chip fabs |
| 00:15.38 | wpwrak | does CEITEC have a strong political orientation ? or are they just trying to do their business as good as they can ? |
| 00:15.53 | hellekin | even the USA has an interest in having a chip fab in latin america rather than China or Taiwan |
| 00:15.59 | wpwrak | hmm. whose project exactly ? |
| 00:16.05 | hellekin | CEITEC is a national company |
| 00:16.19 | hellekin | a free project |
| 00:16.26 | wpwrak | i think there are some chip fabs in mexico |
| 00:16.53 | hellekin | I'm going there to see whether there's an interest in funding free hardware, or helping in mass-producing it |
| 00:17.21 | hellekin | probably some Intel ones, but AFAIK the CEITEC one is the first "Latin American" fab |
| 00:17.29 | hellekin | of importance |
| 00:18.39 | wpwrak | what do you mean with "free hardware" ? the sort of devices we make in qi-hw ? deeper down, like fpgas ? asics ? |
| 00:19.30 | hellekin | yes yes yes |
| 00:20.11 | hellekin | what's the relation between qi-hw and the freedombox foundation? |
| 00:20.51 | hellekin | I've met James Vasile and Jake Appelbaum, and Jake told me he wanted to have free hardware in the mix, but the first round would use ARM CPUs |
| 00:21.37 | hellekin | I think we cannot do free software without free hardware anymore. Within 5 years, it's a dead-end as every Internet company embraces hardware. |
| 00:21.56 | hellekin | with the vendor lockins that come with it |
| 00:22.39 | wpwrak | no relation to freedombox. jon and i briefly talked with jake about whether milkymist could be a basis for freedombox last year (at fisl), but it didn't look like a close match |
| 00:24.10 | wpwrak | (lock-in) dunno. at the moment it's bad thanks to the smartphone and tablet rush. but that may change. e.g., google should see quite clearly by now that they can save themselves a lot of trouble by using a bit of their leverage to keep things a bit more open. |
| 00:26.21 | hellekin | well I don't know about that. My take is that Microsoft pissed off a lot of people by releasing the Surface tablet and probably google can take advantage of it |
| 00:27.45 | hellekin | when I mentioned milkymist to jake he said that lekernel didn't want to hear about the freedombox because of the ARM processor. But I insisted to pursue that way both to Jake and Sebastien |
| 00:28.14 | hellekin | hopefully we can come up with something interesting. That's also why I want to talk to CEITEC. |
| 00:28.39 | wpwrak | ARM may have intellectual property issues |
| 00:29.02 | hellekin | I understand that a softcore is probably too slow for consumer apps, but for routing stuff it can be OK. And if we can turn it into an ASIC and have it mass-produced, bingo |
| 00:29.38 | wpwrak | for softcore, you'd have to find an application that explicitly benefits from having an FPGA |
| 00:29.42 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 00:29.44 | wpwrak | then work from there |
| 00:30.04 | hellekin | reconfigurable stuff I guess |
| 00:32.35 | wpwrak | could be reconfiguration as part of operation (e.g., on a scale of seconds or minutes), could be reconfiguration as part of configuration (hours, days), or reconfiguration as part of in the field upgrades (months). e.g., the latter is why many big routers have fpgas. |
| 00:35.00 | wpwrak | and one point you run into tool limitations. fpgas are quite anti-open at that level. |
| 00:36.01 | wpwrak | there are two ways out of this: 1) wait until wolfspraul figures out how to synthesize spartans, and overthrows the evil empire of secrecy. or 2) make your own fpga. |
| 00:36.01 | hellekin | remote reconfiguration of hardware can be problematic too. Depends on what and who updates |
| 00:36.25 | wpwrak | you mean in terms of security ? |
| 00:36.29 | hellekin | yes |
| 00:36.50 | wpwrak | probably the same issues as with software. i don't see a significant difference. |
| 00:36.57 | hellekin | I'm a bit short of arguments now, but I'd really like to be able to convince those guys to give it a try. |
| 00:37.18 | hellekin | Brazil has great ambitions, and one of them is technological independence |
| 00:38.04 | hellekin | for some reason rms makes a great difference between a circuit that's given and static, and one that can be flashed remotely |
| 00:38.11 | wpwrak | first you need to understand what they need :) if you just go there and tell them about your visions, they'll listen politely, maybe go "wow" from time to time, but unless they're really really terribly bored and unhappy with what they're doing right now, they'll ignore you |
| 00:38.38 | wpwrak | phew. i'd say rms is not the most useful guide in the realm of hardware :) |
| 00:40.17 | wpwrak | his focal point is software and the gpl. flashable firmware can be seen as a way to circumvent the GPL. that's why he's against it. |
| 00:40.42 | wpwrak | of course, from a technical point of view, it's almost always the only approach that makes sense |
| 00:41.17 | wpwrak | (or, if you want, run-time loading into some RAM. but i don't think he'll like that any better.) |
| 00:43.15 | wpwrak | what are you looking for from CEITEC ? that they join the revolution, in one way or another ? that they take a leading role ? to give you a job ? |
| 00:43.32 | hellekin | thanks for the tip about flashable hw and GPL |
| 00:45.23 | hellekin | I think CEITEC is in an unique position: it's a national company. Their mission is different from a private corporation. There's an opportunity for them to embrace free hardware. They could be convinced by the free designs already, that's an awful lot of work saved. |
| 00:45.24 | wpwrak | when do you plan to meet them ? |
| 00:45.33 | hellekin | in a few days |
| 00:45.49 | wpwrak | no specific date set ? |
| 00:46.29 | hellekin | I want to make a first contact, see how it goes. No, no specific plan. I invited them to my talk at FISL. It's about "Transitioning to a cooperative civilization" |
| 00:46.56 | wpwrak | (already convinced) well, that depends on a lot of factors ;-) in general, brazil is "Free-friendly", but that doesn't mean that everything brazil does is |
| 00:47.39 | wpwrak | ah, yes, i saw it. saturday. so you're planning to stay around for a few more days. |
| 00:48.20 | hellekin | yes |
| 00:48.36 | hellekin | I wouldn't miss the opportunity to go and meet them |
| 00:48.54 | hellekin | it's not like if I landed in Belem. It's just around the corner. |
| 00:49.18 | wpwrak | if your first contact will be on saturday, we'll probably have a few opportunities to talk about what to look for in a strategy. |
| 00:49.43 | wpwrak | belem ? |
| 00:51.22 | wpwrak | yeah, they're just down the road from PUCR |
| 00:51.32 | wpwrak | that road from hell ;-) |
| 00:56.48 | kristianpaul | wpwrak: yes in guadalajara |
| 00:57.19 | kristianpaul | mexico fabs^ |
| 00:59.23 | *** join/#qi-hardware rejon_ (~rejon@jp.fabricatorz.com) |
| 01:01.00 | hellekin | belem is a city at the end of the Amazon river. No fab there. |
| 01:01.06 | hellekin | but no Winter either |
| 01:02.16 | hellekin | well, thank you for your interest, wpwrak. I hope I can be useful there. In any case I'll try to grunt at the EHSM next December :) |
| 01:02.40 | *** part/#qi-hardware emeb (~ericb@ip72-223-89-137.ph.ph.cox.net) |
| 02:03.37 | *** join/#qi-hardware nikescar (~nikescar@120.50.66.5) |
| 02:04.15 | whitequark | wpwrak: (rms and firmware) I don't quite get how loading fw into RAM/flash circumvents the GPL |
| 02:04.22 | whitequark | if that does not involve tivoization |
| 02:07.17 | *** join/#qi-hardware mth_ (csprjrjz@dhcp-089-098-069-120.chello.nl) |
| 02:07.32 | *** join/#qi-hardware uwe_ (~uwe_@dslb-088-064-209-125.pools.arcor-ip.net) |
| 02:08.00 | *** join/#qi-hardware h_ll_k_n (~hellekin@lorea/faerie) |
| 02:39.47 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 03:00.51 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 03:18.24 | *** join/#qi-hardware rejon (~rejon@122.70.120.237) |
| 03:46.05 | *** join/#qi-hardware rejon (~rejon@122.70.120.237) |
| 04:20.16 | *** join/#qi-hardware rejon (~rejon@122.70.120.237) |
| 04:47.44 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 05:43.53 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 05:54.48 | *** join/#qi-hardware jluis|work (~jpddb@83.247.136.72) |
| 06:20.01 | *** join/#qi-hardware Openfree` (~Openfreer@64.191.99.80) |
| 07:03.07 | wpwrak | grmbl. and now tiny.cc is unresponsive. |
| 07:03.37 | wpwrak | wolfspraul: see, that's precisely why such things aren't just "ugly" |
| 07:04.44 | wpwrak | by introducing a link shortener in the mix, we not only obfuscate the real location of things, but also add a dependency on a completely unrelated 3rd party and add state that needs to be maintained in parallel to what we already have |
| 07:21.05 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 07:23.59 | DocScrutinizer05 | whitequark: wpwrak: I neither get RMS POV here. To me there's no obvious difference between configuring a chip by writing 32 register values to a known I2C addr and writing 250kBytes to some I2C addr for initializing that chip's RAM with "firmware" |
| 07:25.22 | wpwrak | from the RMS PoV, the (closed firmware) code has a close relationship with the (GPLed) driver. thus there's a conflict. |
| 07:25.28 | DocScrutinizer05 | either way on my AP there's no rogue stuff running, as long as the uploader is documented and FOSS |
| 07:26.37 | *** join/#qi-hardware panda|x201 (~hzhang@123.116.117.86) |
| 07:26.50 | DocScrutinizer05 | hell, RMS then should consider the lito masks for chip's CPU core as similarly relevant for FOSS |
| 07:27.02 | wpwrak | perhaps wolfgang can elaborate on this. he's been - with sean - on that trip our guru ;-) |
| 07:28.21 | DocScrutinizer05 | honestly RMS doesn't live in our universe anymore, and I'd dare to say he partially has NFC when it comes to hw |
| 07:29.19 | DocScrutinizer05 | he mustn't use any computer at all as everything from GPS to printers to HDD has firmware nowadays |
| 07:30.53 | wpwrak | you don't need to bark up my tree ;-) |
| 07:31.30 | DocScrutinizer05 | for me the definition is: there's an AP that's the master of the system (usually defined by this master controlling a lot of subsystems and HID, and nothing controlling the master). As long as that master AP doesn't have non-GPL code running on it, the system is OK for me |
| 07:32.24 | DocScrutinizer05 | given there's no tivoizations in boot process |
| 07:40.22 | wpwrak | the AP may only provide an interface and the real logic is in the device |
| 07:40.39 | DocScrutinizer05 | that's the usual way |
| 07:40.42 | wpwrak | the device could even be a bus master, manipulating kernel data structures |
| 07:40.50 | DocScrutinizer05 | no way |
| 07:40.59 | wpwrak | oh yes :) |
| 07:41.49 | DocScrutinizer05 | I know about shared mem and bridge concepts, from my current job. It's just not matching requirement of "nothing controls my AP" |
| 07:43.30 | DocScrutinizer05 | anyway there's no such thing like peripheral=busmaster, in I2c or SPI or HSI or CSI or CPI or ATA or.... you name it |
| 07:44.07 | DocScrutinizer05 | not in the sense of busmuster you used |
| 07:44.15 | DocScrutinizer05 | busmaster* |
| 07:44.54 | DocScrutinizer05 | for PCI(e) things are obviously a bit different |
| 07:45.40 | DocScrutinizer05 | but it's up to APE to use MMU and stuff wisely, to not allow PCI bus masters to access anything they aren't supposed to |
| 07:47.27 | DocScrutinizer05 | and btw *any* PCI card might do such rogue stuff. I.E. it's unrelated to whether there's any firmware to upload to the card, or the "virus" is mask programmed to the PCI card's controller chip |
| 07:49.39 | DocScrutinizer05 | depending on how nifty they hidden the rogue code and "API" in that PCI controller, you'll never find out no matter how hard you investigate the card. Until it actually triggers on "0xDEADBEEF" written to R:MS |
| 07:53.47 | DocScrutinizer05 | anyway in that respect embedded is rather sweet compared to a decent fullsize PC, as AP is controlling all the stuff like DMA, and usually there's not even any hw interface that *might* do this busmaster stuff (unless you have oneNAND shared mem for any coproc, like modem in bridge config) |
| 07:56.15 | DocScrutinizer05 | so as long as your system is designed according to age old best practice to always expect worst case input on any interface, there is no threat to openness ala FOSS detectable at my side |
| 07:56.56 | qi-bot | [commit] Werner Almesberger: fisl2012/: first outline of FISL13 talk; abstract and biography (master) http://qi-hw.com/p/wernermisc/cd80647 |
| 07:56.58 | qi-bot | [commit] Werner Almesberger: fisl2012/: editing (more to come) (master) http://qi-hw.com/p/wernermisc/83c0891 |
| 07:56.58 | qi-bot | [commit] Werner Almesberger: fisl2012/talk.tex: shorten URLs with tiny.cc (master) http://qi-hw.com/p/wernermisc/858ef9f |
| 07:57.01 | qi-bot | [commit] Werner Almesberger: fisl2012/: on-going editing (first drawings, more links, some small changes) (master) http://qi-hw.com/p/wernermisc/e342b7a |
| 07:57.02 | qi-bot | [commit] Werner Almesberger: Merge branch 'master' of projects.qi-hardware.com:wernermisc (master) http://qi-hw.com/p/wernermisc/85f5b56 |
| 07:57.03 | DocScrutinizer05 | of course ROM Bootloader of recent ARM systems is a PITA regarding that |
| 07:57.18 | DocScrutinizer05 | as it's usually closed blob |
| 07:58.01 | wpwrak | well, whatever :) i still have slides to prepare and to catch a plane in a few hours |
| 07:59.05 | DocScrutinizer05 | and you never know if TI/whoever_built_the_chip maybe integrated a hw timer that jumps into "ring0" romcode which in turn checks for a certain trigger condition to go big brother and hijack your whole system |
| 07:59.27 | DocScrutinizer05 | ooh, where you're traveling to? |
| 08:01.12 | DocScrutinizer05 | deducing from CIA you're about to join something called FISL |
| 08:01.39 | DocScrutinizer05 | waves |
| 08:02.31 | wpwrak | FISL13, in porto alegre. just a small hop :) |
| 08:03.39 | wpwrak | i notice that we have too many tools. already at ~30 slides for a 1 hour talk. and that doesn't even include major screenshots. |
| 08:09.07 | *** join/#qi-hardware jekhor (~jek@37.214.94.99) |
| 08:23.17 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 09:15.27 | qi-bot | [commit] Werner Almesberger: fisl2012/: on-going editing (more links, move libraries slide, add FISL12 items) (master) http://qi-hw.com/p/wernermisc/dc61289 |
| 11:32.19 | qi-bot | [commit] Werner Almesberger: fisl2012/Makefile: fix printing (master) http://qi-hw.com/p/wernermisc/b81ee8a |
| 11:32.20 | qi-bot | [commit] Werner Almesberger: fisl2012/talk.tex: some more small changes (master) http://qi-hw.com/p/wernermisc/72b587f |
| 11:35.30 | *** join/#qi-hardware kuribas (~user@94-227-93-194.access.telenet.be) |
| 11:44.31 | hellekin | wpwrak: I'm flying from Berlin |
| 11:48.41 | wpwrak | hellekin: you have the longer trip then :) for me it's just a hop from buenos aires |
| 11:57.44 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-204-197.w83-115.abo.wanadoo.fr) |
| 12:02.20 | hellekin | wpwrak: ah cool. I might go to Bs As after |
| 12:04.03 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-204-197.w83-115.abo.wanadoo.fr) |
| 12:10.25 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-204-197.w83-115.abo.wanadoo.fr) |
| 12:16.45 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-204-197.w83-115.abo.wanadoo.fr) |
| 12:18.39 | xiangfu | wpwrak, there are 5 VCCINT pins under slx9. do I need connect 1.2v to all those 5 pins for power on the device? |
| 12:19.13 | xiangfu | same question on other GND, VCC_O_X, VCCAUX? |
| 12:23.02 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-204-197.w83-115.abo.wanadoo.fr) |
| 12:44.38 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 13:40.03 | wolfspraul | in general you can probably assume the more pins you connect the more robust it is |
| 13:40.22 | wolfspraul | pins can help dissipate heat etc. |
| 13:40.38 | wolfspraul | the current may be distributed better |
| 13:40.55 | wolfspraul | you can start with one and see whether the chip runs at all, and if you already fried it with that test :-) |
| 13:41.03 | wolfspraul | maybe the datasheet has more info on this? |
| 13:51.21 | *** join/#qi-hardware antgreen (user@nat/redhat/x-vnxvgrcwzimubstc) |
| 13:55.31 | xiangfu | I have tried connect one 1.2v(VCCINT) and one 2.5v(VSSAUX) and the GND. and connect 4 jtag wires to slx9. |
| 13:55.50 | xiangfu | when I run 'detect' it give me "warning: TDO seems to be stuck at 0" |
| 13:56.06 | xiangfu | I have to look into datsheet. |
| 13:56.22 | wolfspraul | sounds like the real work starts now ;-) |
| 13:57.30 | wolfspraul | you can try to ask azonenberg in #milkymist too, though he may be offline right now |
| 13:57.51 | wolfspraul | connect a few more gnc and vcc is probably not a bad idea, though I'm not sure it's the source of your current problem... |
| 13:59.49 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:00.03 | *** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 14:21.53 | whitequark | DocScrutinizer06: well, there was a Motorola phone whose WiFi card had a backdoor forwarding all traffic to a node specified via a rogue ICMP packet |
| 14:22.13 | whitequark | with a slightly more complicated setup you could do DNS hijacking, at which point it actually becomes dangerous |
| 14:22.45 | whitequark | i.e. someone in a "trusted" network could intercept all your traffic without you noticing. |
| 14:22.59 | whitequark | well, arguably so |
| 14:29.40 | *** join/#qi-hardware GNUtoo (~gnutoo@50.118-226-89.dsl.completel.net) |
| 14:34.58 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 14:43.49 | kristianpaul | is getting ready a bom for digikey order in one click :) |
| 14:57.51 | *** join/#qi-hardware antgreen (user@nat/redhat/x-nuvgtrcqvtdedikd) |
| 15:06.28 | larsc | how to open a tcp connection from a c program? popen("nc.traditional ...") ... |
| 15:12.56 | kyak | seems more like a php program |
| 15:21.57 | *** join/#qi-hardware emeb (~ericb@ip72-223-89-137.ph.ph.cox.net) |
| 15:46.47 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 16:10.32 | *** join/#qi-hardware antgreen (user@nat/redhat/x-mdghecfgpgunjmho) |
| 16:49.14 | *** join/#qi-hardware jekhor (~jek@37.214.94.99) |
| 17:02.35 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-204-197.w83-115.abo.wanadoo.fr) |
| 17:28.48 | *** join/#qi-hardware scientes (~scientes@unaffiliated/scientes) |
| 17:37.54 | *** join/#qi-hardware mog (~mog@c-71-207-245-200.hsd1.al.comcast.net) |
| 17:37.54 | *** join/#qi-hardware mog (~mog@fsf/member/mog) |
| 17:46.42 | *** join/#qi-hardware FrankBlues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 18:26.22 | *** join/#qi-hardware mog (~mog@c-68-62-170-105.hsd1.al.comcast.net) |
| 18:26.23 | *** join/#qi-hardware mog (~mog@fsf/member/mog) |
| 19:05.26 | *** join/#qi-hardware antgreen (user@nat/redhat/x-uimfnnaomwkmaioy) |
| 19:23.49 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 19:28.24 | *** join/#qi-hardware GNUtoo (~gnutoo@50.118-226-89.dsl.completel.net) |
| 19:56.12 | *** join/#qi-hardware Jay7 (jay@128-73-75-228.broadband.corbina.ru) |
| 19:57.34 | *** join/#qi-hardware losinggeneration (~quassel@75-170-144-133.desm.qwest.net) |
| 20:06.19 | *** join/#qi-hardware antgreen` (user@nat/redhat/x-xeyvjjdwycwrlkap) |
| 20:49.38 | *** join/#qi-hardware wolfspra1l (~wolfsprau@221.220.176.181) |
| 21:10.52 | *** join/#qi-hardware gdm (~gdm@209.234.249.207) |
| 21:14.24 | *** join/#qi-hardware qwebirc19356 (95e182bf@gateway/web/freenode/ip.149.225.130.191) |
| 22:10.57 | *** join/#qi-hardware snipes (~soren@1Cust200.tnt12.fft4.deu.da.uu.net) |
| 22:50.56 | *** join/#qi-hardware rz2k (~rzk@93-80-220-109.broadband.corbina.ru) |
| 23:05.57 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 23:18.16 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1400:a::23) |
| 23:35.45 | *** join/#qi-hardware lg_quassel (~quassel@75-170-152-138.desm.qwest.net) |