**** BEGIN LOGGING AT Mon Mar 10 09:59:57 2008 Mar 10 10:46:29 moinmoin stinks :p Mar 10 11:42:43 Kaloz ack. but MW isnt better ;) Mar 10 11:43:04 in your case youre lucky.. importing into something like trac is easy from moinmoin Mar 10 11:44:30 hi roh Mar 10 11:44:36 hi Mar 10 11:46:03 problem is that every wiki engine I saw went nuts when too many people started to use it Mar 10 11:46:08 btw.. there are also plugins for forum/discussion or a blog... ;) Mar 10 11:47:57 maybe I we should use GeekiGekki and simply ignore the missing features :P Mar 10 11:48:34 ? Mar 10 11:48:41 http://www.codewiz.org/wiki/GeekiGeeki Mar 10 11:48:54 eeeek Mar 10 11:49:13 :))) Mar 10 11:49:34 what? :D Mar 10 11:49:44 .oO(uhuh.. that even sucks in performance on the page of its creators) Mar 10 11:49:58 ah.. no.. it was a link to gitweb *sigh* Mar 10 11:50:17 ;) Mar 10 11:50:24 it's pretty small and fast Mar 10 11:50:33 only problem is the missing stuff Mar 10 11:50:35 nah.. fast is different Mar 10 11:50:42 http://www.codewiz.org/wiki/GeekiGeekiToDo Mar 10 11:50:42 :) Mar 10 11:50:58 history generation takes ages due to the git Mar 10 11:51:48 honestly history generation takes ages for moinmoin as well, and honestly 90% of the time I would disable it Mar 10 11:52:10 moinmoin also sucks Mar 10 11:52:51 most of the time history is just a PITA Mar 10 11:53:20 and most of the time only lame users and crawlers take away resources with it Mar 10 11:53:48 don't say that. i use it quite often to find out the source of a information Mar 10 11:55:14 well.. i can only suggest it, but if you havent decided and since you already have data in a moinmoin format i strongly suggest using a trac as wiki. you can disable the repo and all features you do not wanna use easily. played around a lot with it recently since i have own plans at work ;) Mar 10 11:55:49 least pain of all webservices i touched last year.. which was mediawiki, gforge, mailman, rt, and some others Mar 10 11:56:20 we use the trac wiki for development stuff.. honestly no idea how fast would it be with lots of users and data Mar 10 11:56:37 bah.. its not that your wiki is soo big Mar 10 11:56:42 ;) Mar 10 11:56:51 it's full of crap Mar 10 11:56:52 ;) Mar 10 11:57:07 btw.. trac has nice features for fighting spammers and such Mar 10 11:58:10 and i would find it fancy to build a macro which does show some 'state' as background color or image when given a name of a wikipage by looking at tags or such Mar 10 11:58:58 means ... e.g. routerxyz has a page with links to chips/soc_blafasel and chips_wifichipset_foo Mar 10 12:00:03 the goal would be to have only one place per 'thing' to edit when making updates... if someone writes a driver for chip foo he just adds the tag 'WIP' and removes 'unsupported Mar 10 12:00:40 and voila, all routers using it show a yellow instead a red box around that link, so getting a overview about whats supported and how far gets easier Mar 10 12:00:43 no offense, but I think OE poisoned you :P Mar 10 12:00:51 indeed ;) Mar 10 12:00:58 but they don't have that feature Mar 10 12:01:10 they have only a few feature Mar 10 12:01:12 .oO(or documentation anybody wants to read) Mar 10 12:01:21 but it needs gigabytes to build and it's hell slow and disgusting Mar 10 12:01:24 ;P Mar 10 12:01:46 back a few years OE was nice Mar 10 12:01:50 Kaloz well.. its not features there.. the problem is: everything is convention and not clearly visible design/abstraction Mar 10 12:02:33 Kaloz i do not wanna defend oe, on the contrary.. but OW needs quite some more abstractions to support such a wide range of configs Mar 10 12:02:40 OE is fishy since the day they went for monotone and ecided to OverEngineer everything :) Mar 10 12:02:44 .oO(and a few thousand packages) Mar 10 12:03:15 adding packages is pointless until someone uses them - in that case someone can port it to owrt Mar 10 12:03:37 yes. but for example using regular glibc would be nice as a choise Mar 10 12:03:45 how so? Mar 10 12:03:48 or dietlibc Mar 10 12:04:12 I couldn't really find any reason to use glibc at all other then being "compatible" with some binary only stuff Mar 10 12:04:14 in oe i can just switch for lots of platforms (atleast ulibc/glibc) Mar 10 12:04:26 Kaloz does glib/gtk run on ulibc? Mar 10 12:04:39 dietlibc on the other hand sacrifices too much about compatibility Mar 10 12:04:48 roh: as far as I know it does Mar 10 12:04:59 hm? thats new to me Mar 10 12:05:11 on OM we use glibc.. and no.. we do not care that its big. Mar 10 12:05:22 we also have c++ code and thus the libc seems small Mar 10 12:05:28 (webkit is c++ for example) Mar 10 12:05:36 we have uclibc++ ) Mar 10 12:05:38 ;) Mar 10 12:05:52 yes. you have only small stuff Mar 10 12:06:22 which is nice for some small usecases but really sucky when you want to work with stuff the regular way Mar 10 12:06:23 well.. you know, there is simply one thing we will never agree on (which isn't a problem really) Mar 10 12:06:46 e.g. i miss -p support on netstat and -f on ps Mar 10 12:07:07 @openmoko guys _think_ they do standard stuff, while for real _there is no standard_ when it comes to embedded Mar 10 12:07:14 ack Mar 10 12:07:19 there is no standard. Mar 10 12:07:32 and most of the technical decisions are simply wrong there Mar 10 12:07:43 and there should not be one. just too many usecases and restrictions (often simply by ram or flashspace) Mar 10 12:07:46 come on.. glibc? X? should I continue? Mar 10 12:07:55 it's more like a joke then a serious decision Mar 10 12:08:02 thats intentional and really the least of a problem Mar 10 12:08:14 much more work are the details nobody gets notice of. Mar 10 12:08:28 designing, debugging and massproduction of hw is no fun Mar 10 12:08:47 roh: okay, one small thing for example.. did you flahs openwrt on anything already? Mar 10 12:08:51 getting people and companys to supply documentation for free drivers is less fun Mar 10 12:09:12 and getting code nice enough for upstream while the release pressure increases is bad Mar 10 12:09:36 if you've ever flashed openwrt, you notice a small and great idea Mar 10 12:09:50 roh: being everyones darling is impossible Mar 10 12:09:52 Kaloz i flashed openwrt on different devices. used it in qemu, used it on a wrapboard, used it on fonera and installed it to a asus wl500gP in the last 48hours Mar 10 12:10:12 Kaloz the great thing is 'it works' Mar 10 12:10:22 roh: okay. so you've noticed we do combined filesystems, optionally jffs2-only is a solution Mar 10 12:10:33 the 'thing' is .. its simple and only limited flexible. which has good and bad sides Mar 10 12:10:57 Kaloz i do. i wondered about it and got some insight from nbd ;) Mar 10 12:11:00 roh: now explain me, why openmoko keeps useing a jffs2 only solution, and even if it does so, why can't people understand that they do it wrong? Mar 10 12:11:21 roh: for exmaple, let's say openmoko want to stick to jffs2 only for some abnormal reason Mar 10 12:11:52 roh: they could still use the code from us which wipes the flash partition after the jffs2 end marker Mar 10 12:11:58 Kaloz why? i really dunno. there was just no reason not to besides what came up recently (that jffs2 sucks on big partitions) Mar 10 12:12:49 roh: so people wouldn't have to delete the jffs2 partition from the bootloader.. but for real, using jffs2 is pointless, as squashfs-lzma would mount faster and would give sbetter compression -- not to mention that it would allow an easy restoration point to default Mar 10 12:13:01 if it was my call i would want to have jffs2 and squash and in different part. so the bootloader could do a real factory reset by wiping the jffs2 clean Mar 10 12:13:08 like we did on the triple dragon stb Mar 10 12:13:49 roh: pointless again :) with our patch, you should only have to "echo" the EOf marker to the end of the jffs2 partition, and it would be erased on reboot :) easy, fast, simple :) Mar 10 12:14:00 Kaloz to be true i don't think anybody would find out why we do it that way Mar 10 12:14:19 and it would happen in the background without stopping/slowing dow the boot process Mar 10 12:14:33 s/dow/down/ Mar 10 12:14:34 :) Mar 10 12:14:55 not even people like me working for OM ;) Mar 10 12:15:12 mickeyl's fault :P Mar 10 12:15:17 but anyhow.. i would love to see OM support in openwrt. Mar 10 12:15:33 nbd has a tree with it iirc Mar 10 12:16:10 but i do not see us changing buildsystems... every 'change' does too much penalty to a workflow and any schedule Mar 10 12:16:27 and openwrt lacks some features for us (like half of our userland) Mar 10 12:16:56 yeah, but "merging" some of these into your system would take minutes and it would save you more time on the first boot than what merging took Mar 10 12:17:00 roh: a complete build in 2 hours insteed of 36 hours is a goog argument Mar 10 12:17:16 ryd well.. it takes 6hours for a clean build here Mar 10 12:17:45 roh: I was only speaking about the FS issue currently, didn't even started exmplaining the other stuff :) Mar 10 12:17:47 which is ok, considered what it builds and that most of the time is wasted in mtn and autoconf/automake Mar 10 12:18:15 roh: we tries a year ago Mar 10 12:18:31 s/tries/tried/ Mar 10 12:18:47 .oO(and it took me only 6 weeks to learn enough oe for one build Mar 10 12:18:56 after 6 month you know where to kick it Mar 10 12:20:00 roh: but I understand - with mickey and maybe so other it is impossible to change :) Mar 10 12:20:53 thats one thing.. the other is that getting a few thousand people to use a different buildsys is 'not that easy' Mar 10 12:21:17 especially when you have bigger problems on other fronts which require your time Mar 10 12:21:28 propably it just still works too well... Mar 10 12:21:45 :) Mar 10 12:21:46 .oo(and these 2.4ghz quadcore cpus for the devels were too cheap) Mar 10 12:22:21 builds a kernel in < 90seconds Mar 10 12:22:53 depends more on io/ramsize for fs-cache then as for cpuspeed Mar 10 12:24:36 hehe, know I understand the 6 hours Mar 10 12:24:47 /know/now/ Mar 10 12:29:17 roh: do you reallu Mar 10 12:29:22 y Mar 10 12:29:25 argl Mar 10 12:29:51 roh: du you really belive, there will be a market for om? Mar 10 12:36:07 hi, i'm not sure is this the right place to ask, but is anybody running the kamikaze trunk on Atheros SoC based systems? can't get the trunk boot on Meraki Mini. kamikaze 7.09 boots, though. Mar 10 12:36:58 janne-: iirc it boots just there are issues with the phy Mar 10 12:37:03 bug nbd about it :) Mar 10 12:37:50 ryd well.. people are literally buying every device we build and sell atm ;) Mar 10 12:37:54 nbd is sitting in plane - answer can take a while Mar 10 12:38:22 ah right, you are correct, it seems to boot but not answer to telnet :) Mar 10 12:38:31 ryd: oh :) where's he flying? Mar 10 12:38:33 so yes. especially if you think about the people/companys building and selling products based on it.. see openwrt on linksys wrt54G ;) Mar 10 12:38:47 roh: sure - do you know the selling facts from iphone? Mar 10 12:39:04 Kaloz: india Mar 10 12:39:08 a few bits. but they have a differen targetgroup Mar 10 12:40:03 ryd ours is 'wanna do stuff with it what all phones cannot do' 'wanna mod it' 'wanna have a menu nobody else needs here' and 'i just want a unbranded phone which does what i want and not what the carrier suggests' Mar 10 12:40:11 roh: is it? apple target also business market Mar 10 12:41:07 apple is 'i life in $predefined usecase and will not step out of it' .. + their business-practices which carriers and customers seem not to find too cool Mar 10 12:41:16 roh: honestly (I know this will sound funny in one point of view) I see one proper target for the neo (even the current crappy one) when the power management is working Mar 10 12:42:03 yes. that it 'works' properly in regular usecases of 'phone' is a requirement for every potential usecase *g* Mar 10 12:42:26 roh: fifth estate ;) Mar 10 22:45:14 nbd * r10582 /trunk/target/linux/ixp4xx/image/apex/Makefile: fix apex compile on osx, suppress some build warnings Mar 10 22:45:35 nbd * r10583 /trunk/package/ixp4xx-microcode/Makefile: fix ixp4xx-microcode compile on osx Mar 11 00:44:52 nbd: doh! I had r10582 sitting in a branch and I forgot about it. Mar 11 00:45:25 matteo * r10584 /trunk/ (2 files in 2 dirs): Add AG241 code pattern (fixes #1089) Mar 11 00:59:13 matteo * r10585 /trunk/target/linux/ar7/patches-2.6.24/160-cpmac-rx-ring-use-eoq.diff: cpmac: patch to reimplement rx ring with EOQ markers to avoid reset storms (closes #2569) Mar 11 01:18:28 matteo * r10586 /packages/net/wshaper/Makefile: wshaper: fix install path Mar 11 01:23:34 matteo * r10587 /packages/net/wshaper/Makefile: wshaper: stupid me, forget to create dirs Mar 11 01:25:09 matteo * r10588 /trunk/package/ar7-atm/patches/100-compile_fix.patch: ar7-atm: fix sysctl (closes #3122) Mar 11 02:43:11 matteo: you forgot /net/wshaper/files/wshaper.init Mar 11 07:56:42 Hmm. ok - I've read the howto on submitting packages - but the email was rejected - who do I send the patch to? Mar 11 07:56:54 - or do I have to subscribe to the list or something? Mar 11 07:59:20 yes, you can't send email to the list until you are subscribed, I assume to prevent spam Mar 11 08:00:08 Bartman007: ok - so I should subscribe? or can I send it on to somebody? Mar 11 08:00:10 gg Mar 11 08:00:18 reply - I'll pick up the answer later.. Mar 11 08:07:37 yeah, feel free to subscribe, it's better if you post the patch since you created it. **** ENDING LOGGING AT Tue Mar 11 09:59:56 2008