[00:10] <nbd> {Nico}: ping
[00:16] <{Nico}> nbd: pong
[00:19] <nbd> just wanted to let you know, that i'm currently rewriting the kernel module handling
[00:19] <nbd> to make it look more like the stuff in package/
[00:21] <{Nico}> nbd: np, i was just hunting bug from ticket #598 and found that buildroot-ng was also affected
[00:22] <nbd> k
[00:23] <{Nico}> btw, i have some cosmetic changes in almost all package Makefiles to indent stuff and reorg variables
[00:25] <{Nico}> do you think it's ok to perform such a massive commit now?
[00:45] <nbd> {Nico}: sure
[03:55] <CIA-17> nbd * r4083 /branches/buildroot-ng/openwrt/ (5 files in 2 dirs): add support for new modules.mk format (no autogenerated Config.in yet)
[13:46] <florian> Kaloz: do you think a 300K binary can be easily reversed ;) ?
[13:46] <florian> it is not stripeed
[13:46] <florian> stripped sorry
[13:48] <florian> I forgot mentionning that I changed the au1000 kernel configuration in my commit
[13:49] <nbd> what kind of a binary do you mean?
[13:54] <florian> the built-in I had to commit to get firmware being built for brcm63xx
[13:54] <florian> it's in target/linux/brcm63xx-2.6/files/
[13:55] <nbd> a built-in.o? isn't there some source code for that available anywhere?
[14:01] <Kaloz> florian: erm, are you seriously commited a buil-in.o? :p
[14:01] <Kaloz> florian: does this thing boot?
[14:06] <florian> Kaloz: I am about to test it
[14:06] <florian> nbd: there was no source for that, or at least I could not find one
[14:06] <Kaloz> and?
[14:06] <Kaloz> :p
[14:06] <nbd> which gpl tarballs did you check?
[14:07] <florian> DG834GT.V1.02.04.tar.bz2
[14:07] <florian> I check if there is a newer one
[14:08] <florian> I know it's really bad to commit binaries
[14:08] <Kaloz> it's wrong
[14:08] <Kaloz> not bad
[14:08] <Kaloz> :p
[14:09] <nbd> there are lots of bcm63xx tarballs out there
[14:09] <nbd> i'm sure you'll find the built-in stuff somewhere
[14:09] <florian> I hope
[14:09] <nbd> maybe in the linksys wag54gs source
[14:09] <Kaloz> florian: the diff i gave you didn't need that crap
[14:10] <florian> Kaloz: your diff did not compiled and required external definitions if I well remember
[14:10] <Kaloz> sure, as it was just a cleaned up diff
[14:11] <Kaloz> but addign a built-in.o is simply a gpl violation
[14:11] <florian> the kernel needs board definitions
[14:11] <Kaloz> so remove it please
[14:13] <CIA-17> florian * r4085 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/files/built-in.o: Remove built-in.o
[14:16] <florian> Kaloz: should I remove everything else ?
[14:16] <Kaloz> nope
[14:17] <florian> ok
[14:17] <florian> Kaloz: so we still need board definitions that are provided outside the linux kernel :(
[14:18] <Kaloz> but those files were inside the pathc i gave you
[14:18] <florian> the 2megs or the smaller one ?
[14:19] <Kaloz> the smaller one
[14:19] <nbd> Kaloz: btw. have you done anything else about that linksys wrt54gr violation?
[14:19] <Kaloz> they should have published the sources already
[14:19] <florian> Kaloz: ok
[14:19] <nbd> Kaloz: i mean the redboot thing
[14:20] <Kaloz> maybe we should speak with Welte
[14:21] <nbd> do you want me to do it or will you?
[14:22] <florian> Kaloz: in which tarball did you find the USR patch ?
[14:22] <Kaloz> feel free to do it if he's around, i'm busy with other stuff right now
[14:22] <Kaloz> florian: the usr tarball? :) dunno, the alst one iirc
[14:24] <florian> Kaloz: last one provides a 2.4 kernel
[14:24] <Kaloz> i mean the last model number
[14:24] <Kaloz> 9108 or what
[14:25] <florian> ok
[14:35] <nbd> Kaloz: sent a mail to his request tracker
[14:36] <Kaloz> okie
[14:55] <florian> Kaloz: I found the USR tarball
[14:55] <florian> board spefici codes relies on external definitions
[14:56] <florian> damn I have difficulties in writing today
[20:06] <florian> Kaloz: it's ok, I have almost done a new patch that relys only on GPL part of what they release
[20:06] <florian> mixing with netgear and USR helped a lot ;)
[20:13] <CIA-17> nbd * r4086 /branches/buildroot-ng/openwrt/target/linux/control/kmod-ide.control: remove kmod-ide control file
[20:43] <florian> nbd: are there common broadcom definitions for nvram ?
[20:44] <nbd> i have no idea
[20:44] <nbd> but we probably don't need any nvram support on bcm63xx
[20:44] <florian> unfortunately there is a lot of references to it :(
[20:44] <nbd> then add limited nvram support
[20:45] <florian> like ?
[20:45] <nbd> only the early_nvram_* stuff
[20:45] <nbd> not the mtd based part
[20:45] <nbd> and not the /dev/nvram interface
[20:46] <florian> ok, I don't know how to do this
[20:46] <nbd> then just leave it in, i can help you with that later
[20:47] <florian> ok, I rather would like to understand how I could do it
[20:47] <florian> but we can see that later
[20:47] <nbd> ok
[20:47] <nbd> well, you need to figure out how the code works
[20:47] <nbd> and which parts are mtd based and which parts aren't
[20:47] <florian> ok
[20:47] <nbd> for bcm47xx, i renamed early_nvram_get to nvram_get and removed all the mtd-based stuff entirely
[20:55] <florian> damn bcm63xx is really crapy
[20:56] <nbd> is there a decent platform for dsl stuff at all?
[20:56] <florian> ar7 probably ?
[20:56] <nbd> nah
[20:57] <florian> it's a joke :)
[20:57] <nbd> i know
[20:57] <nbd> :)
[20:57] <florian> I can't even believe we could not just compile a custom kernel out of the box
[20:57] <nbd> i still haven't found a single hardware vendor's reference source that even comes close to the crappiness of ti's ar7 software stack
[20:58] <nbd> even broadcom's stuff looks somewhat beautiful compared to ti
[20:58] <florian> lol
[20:59] <florian> they have strange programming conventions
[20:59] <nbd> and ti's seems to be: 'fuck up every generic kernel subsystem you can find'
[21:02] <florian> yep
[21:13] <florian> sometimes I wonder if we should not specify our own hardware ?
[21:15] <db90h> ?
[21:18] <florian> I mean design our own access point/xDSL router
[21:28] <db90h> what's the trick behind getting the mtd utility to write the PMON/MTD0 partition?
[21:28] <nbd> removing a flag in the kernel
[21:28] <nbd> it's write protected in openwrt by default
[21:28] <nbd> so people don't do stupid stuff to it :)
[21:28] <db90h> ah, thanks
[21:29] <db90h> yes, a very good idea ;)
[21:32] <db90h> the vxworks reversion firmware will be done then, as soon as I rebuild with that flag gone.. since this is really just stock openwrt code, is it ok to just link to openwrt+sources? I'd hate to get everyone pissed cuz I've violated the license
[21:33] <nbd> the gpl would require you to put up your modified sources
[21:34] <db90h> ok, i'll do that
[21:39] <db90h> "+ { name: "pmon", offset: 0, size: 0, mask_flags: MTD_WRITEABLE, },"
[21:39] <db90h> ugh, what an ugly paste
[21:39] <db90h> that'd be it, I take it ;)
[21:40] <db90h> well i better look closer to be sure, i always open my mouth too soon ;p
[21:43] <nbd> that's it
[21:45] <db90h> yep, building now.. this outta be the first working reversion firmware image
[21:45] <db90h> i thought about adding a web UI to ask for the MAC address to embed in the VxWorks BSP.. but to hell with all that work.. I decided instead to let people replace the VxWorks BSP again/later with the bootrom.bin method if they desire to embed a MAC address
[21:46] <db90h> .. i'm writing a GUI to embed mac addresses in both VxWorks BSP and CFEs, then build an appropriate firmware image.. so that'll be good enough
[22:55] <florian> this brcm63xx port is driving me nuts
[22:59] <florian> what the hell is the problem with realeasing working GPL tarballs :
[23:00] <db90h> how come when I change a patch file the merge throws an error, 'assume reverted..'..'apply anyway..', etc
[23:00] <db90h> do I really need to create a new patch for any change, even if it's undoing previous patches in the chain?
[23:00] <florian> db90h: depends how your patch was diffed
[23:00] <florian> it's better to create a new patch for a new change ihmo
[23:01] <db90h> i'm merely removing the writable mask from the 001-bcm47xx.patch .. so it's a very minor tweak
[23:01] <db90h> it seems like the merge wouldn't fail..
[23:02] <db90h> but it seems to throw off that entire patch file
[23:03] <db90h> the last modified time on the patch file itself doesn't matter, surely?
[23:04] <db90h> i'm not even removing a line, just part of a line.. oh well, i'll create a new diff and add it to the chain i guess, it just seems stupid.. but I don't know what I'm doing wrong with the edit on that patch file
[23:05] <db90h> i don't suppose it's the way gedit is saving it that's screwing with it..
[23:05] <florian> db90h: you can probably do it inside the patch without recalculating the line differences
[23:06] <db90h> florian: exactly what I did.. no line number changes at all.. just clipped out part of a line that is patched in
[23:06] <florian> so ?
[23:06] <florian> did you make a rm -r build_mipsel/linux* ?
[23:06] <db90h> if aka make clean, yea
[23:06] <db90h> wait
[23:06] <db90h> i got the error again, after I undid my changes in gedit
[23:06] <db90h> maybe the way gedit is saving the patch file? is that possible?
[23:08] <db90h> "the error is "Reversed (or previously applied) patch detected! Assume -R [n]" .. then if I go ahead and apply the patch anyway, it fails.. and if I don't apply the patch, the build aborts.. the patches shouldn't already be applied, cuz the other ones get merged in fine
[23:10] <db90h> well now I know at least that it ought to be working, thx ;)
[23:10] <db90h> i've had this issue before tho.. i ended up creating a new patch, which is hwat i'll do here.. no time to figure out what the issue is
[23:11] <db90h> oh shit
[23:11] <db90h> duh
[23:11] <db90h> fuck me
[23:11] <db90h> my god
[23:11] <db90h> i am so stupid
[23:11] <db90h> gedit was creating a damn backup file
[23:11] <db90h> and that was being applied after the pathc
[23:11] Action: db90h kills himself
[23:12] <db90h> stupid '~' ;p
[23:12] <florian> lol
[23:12] <nbd> http://forum.openwrt.org/viewtopic.php?pid=29526#p29526 :)
[23:12] <db90h> i didn't expect anything other than *.patch to get applied (not *.patch*)..and that ~ is hard to see<g>
[23:19] <db90h> so is sveasoft still using openwrt code?
[23:19] <nbd> sure
[23:19] <nbd> he even keeps ripping off the newer stuff
[23:19] <nbd> like my wl.o integration work
[23:19] <db90h> he's an ass
[23:20] <nbd> or sometimes i write small shell scripts for specific purposes
[23:20] <nbd> like rate estimation
[23:20] <nbd> and later find them in his firmware
[23:20] <nbd> no matter how hackish they are :)
[23:20] <db90h> lol
[23:20] <db90h> that guy is totally whack
[23:20] <nbd> he's completely moved over to the openwrt kernel
[23:21] <nbd> sure
[23:22] <db90h> as I've previously mentioned, my dealings with him have been amusingly sickening.. but I didn't realize just how bad he was
[23:23] <db90h> ripping off code aside, i assume he is wrong about his argument about not having to distrubte source to those who he doesn't distribute binary?
[23:23] <nbd> i believe so
[23:23] <nbd> the gpl seems rather clear on this issue
[23:23] <nbd> either accompany binaries with the source
[23:24] <nbd> or make an offer valid for *any* third party
[23:26] <db90h> a disgusting shame..what can be done tho? in the end, I think he's obviously a quite miserable guy..but his misery doesn't put a stop to his ill-gotten income
[23:26] <db90h> you could take him to court, but who has that kinda money.. i guess he knows this
[23:27] <nbd> last time the public announcement has cost him several important customers
[23:27] <nbd> if the flamewar is kept alive, more people will stop using his crap
[23:27] <nbd> it just has to hit popular news sites
[23:27] <nbd> that's what has the most impact
[23:29] <db90h> he's probably in here right now, spying
[23:30] <nbd> he doesn't have to be in here
[23:30] <nbd> he can read the logs
[23:30] <nbd> they're public
[23:30] <db90h> oh yea, forgot about that
[23:30] <nbd> anyway, he already knows what i think about him
[23:30] <nbd> so i don't care
[23:33] <db90h> well, money isn't everything..he pays the price for his sins, i assure you
[23:33] <db90h> time to try the reversion firmware
[23:34] <db90h> brb
[00:00] --- Tue Jun 27 2006
[00:16] <{Nico}> nbd: pong
[00:19] <nbd> just wanted to let you know, that i'm currently rewriting the kernel module handling
[00:19] <nbd> to make it look more like the stuff in package/
[00:21] <{Nico}> nbd: np, i was just hunting bug from ticket #598 and found that buildroot-ng was also affected
[00:22] <nbd> k
[00:23] <{Nico}> btw, i have some cosmetic changes in almost all package Makefiles to indent stuff and reorg variables
[00:25] <{Nico}> do you think it's ok to perform such a massive commit now?
[00:45] <nbd> {Nico}: sure
[03:55] <CIA-17> nbd * r4083 /branches/buildroot-ng/openwrt/ (5 files in 2 dirs): add support for new modules.mk format (no autogenerated Config.in yet)
[13:46] <florian> Kaloz: do you think a 300K binary can be easily reversed ;) ?
[13:46] <florian> it is not stripeed
[13:46] <florian> stripped sorry
[13:48] <florian> I forgot mentionning that I changed the au1000 kernel configuration in my commit
[13:49] <nbd> what kind of a binary do you mean?
[13:54] <florian> the built-in I had to commit to get firmware being built for brcm63xx
[13:54] <florian> it's in target/linux/brcm63xx-2.6/files/
[13:55] <nbd> a built-in.o? isn't there some source code for that available anywhere?
[14:01] <Kaloz> florian: erm, are you seriously commited a buil-in.o? :p
[14:01] <Kaloz> florian: does this thing boot?
[14:06] <florian> Kaloz: I am about to test it
[14:06] <florian> nbd: there was no source for that, or at least I could not find one
[14:06] <Kaloz> and?
[14:06] <Kaloz> :p
[14:06] <nbd> which gpl tarballs did you check?
[14:07] <florian> DG834GT.V1.02.04.tar.bz2
[14:07] <florian> I check if there is a newer one
[14:08] <florian> I know it's really bad to commit binaries
[14:08] <Kaloz> it's wrong
[14:08] <Kaloz> not bad
[14:08] <Kaloz> :p
[14:09] <nbd> there are lots of bcm63xx tarballs out there
[14:09] <nbd> i'm sure you'll find the built-in stuff somewhere
[14:09] <florian> I hope
[14:09] <nbd> maybe in the linksys wag54gs source
[14:09] <Kaloz> florian: the diff i gave you didn't need that crap
[14:10] <florian> Kaloz: your diff did not compiled and required external definitions if I well remember
[14:10] <Kaloz> sure, as it was just a cleaned up diff
[14:11] <Kaloz> but addign a built-in.o is simply a gpl violation
[14:11] <florian> the kernel needs board definitions
[14:11] <Kaloz> so remove it please
[14:13] <CIA-17> florian * r4085 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/files/built-in.o: Remove built-in.o
[14:16] <florian> Kaloz: should I remove everything else ?
[14:16] <Kaloz> nope
[14:17] <florian> ok
[14:17] <florian> Kaloz: so we still need board definitions that are provided outside the linux kernel :(
[14:18] <Kaloz> but those files were inside the pathc i gave you
[14:18] <florian> the 2megs or the smaller one ?
[14:19] <Kaloz> the smaller one
[14:19] <nbd> Kaloz: btw. have you done anything else about that linksys wrt54gr violation?
[14:19] <Kaloz> they should have published the sources already
[14:19] <florian> Kaloz: ok
[14:19] <nbd> Kaloz: i mean the redboot thing
[14:20] <Kaloz> maybe we should speak with Welte
[14:21] <nbd> do you want me to do it or will you?
[14:22] <florian> Kaloz: in which tarball did you find the USR patch ?
[14:22] <Kaloz> feel free to do it if he's around, i'm busy with other stuff right now
[14:22] <Kaloz> florian: the usr tarball? :) dunno, the alst one iirc
[14:24] <florian> Kaloz: last one provides a 2.4 kernel
[14:24] <Kaloz> i mean the last model number
[14:24] <Kaloz> 9108 or what
[14:25] <florian> ok
[14:35] <nbd> Kaloz: sent a mail to his request tracker
[14:36] <Kaloz> okie
[14:55] <florian> Kaloz: I found the USR tarball
[14:55] <florian> board spefici codes relies on external definitions
[14:56] <florian> damn I have difficulties in writing today
[20:06] <florian> Kaloz: it's ok, I have almost done a new patch that relys only on GPL part of what they release
[20:06] <florian> mixing with netgear and USR helped a lot ;)
[20:13] <CIA-17> nbd * r4086 /branches/buildroot-ng/openwrt/target/linux/control/kmod-ide.control: remove kmod-ide control file
[20:43] <florian> nbd: are there common broadcom definitions for nvram ?
[20:44] <nbd> i have no idea
[20:44] <nbd> but we probably don't need any nvram support on bcm63xx
[20:44] <florian> unfortunately there is a lot of references to it :(
[20:44] <nbd> then add limited nvram support
[20:45] <florian> like ?
[20:45] <nbd> only the early_nvram_* stuff
[20:45] <nbd> not the mtd based part
[20:45] <nbd> and not the /dev/nvram interface
[20:46] <florian> ok, I don't know how to do this
[20:46] <nbd> then just leave it in, i can help you with that later
[20:47] <florian> ok, I rather would like to understand how I could do it
[20:47] <florian> but we can see that later
[20:47] <nbd> ok
[20:47] <nbd> well, you need to figure out how the code works
[20:47] <nbd> and which parts are mtd based and which parts aren't
[20:47] <florian> ok
[20:47] <nbd> for bcm47xx, i renamed early_nvram_get to nvram_get and removed all the mtd-based stuff entirely
[20:55] <florian> damn bcm63xx is really crapy
[20:56] <nbd> is there a decent platform for dsl stuff at all?
[20:56] <florian> ar7 probably ?
[20:56] <nbd> nah
[20:57] <florian> it's a joke :)
[20:57] <nbd> i know
[20:57] <nbd> :)
[20:57] <florian> I can't even believe we could not just compile a custom kernel out of the box
[20:57] <nbd> i still haven't found a single hardware vendor's reference source that even comes close to the crappiness of ti's ar7 software stack
[20:58] <nbd> even broadcom's stuff looks somewhat beautiful compared to ti
[20:58] <florian> lol
[20:59] <florian> they have strange programming conventions
[20:59] <nbd> and ti's seems to be: 'fuck up every generic kernel subsystem you can find'
[21:02] <florian> yep
[21:13] <florian> sometimes I wonder if we should not specify our own hardware ?
[21:15] <db90h> ?
[21:18] <florian> I mean design our own access point/xDSL router
[21:28] <db90h> what's the trick behind getting the mtd utility to write the PMON/MTD0 partition?
[21:28] <nbd> removing a flag in the kernel
[21:28] <nbd> it's write protected in openwrt by default
[21:28] <nbd> so people don't do stupid stuff to it :)
[21:28] <db90h> ah, thanks
[21:29] <db90h> yes, a very good idea ;)
[21:32] <db90h> the vxworks reversion firmware will be done then, as soon as I rebuild with that flag gone.. since this is really just stock openwrt code, is it ok to just link to openwrt+sources? I'd hate to get everyone pissed cuz I've violated the license
[21:33] <nbd> the gpl would require you to put up your modified sources
[21:34] <db90h> ok, i'll do that
[21:39] <db90h> "+ { name: "pmon", offset: 0, size: 0, mask_flags: MTD_WRITEABLE, },"
[21:39] <db90h> ugh, what an ugly paste
[21:39] <db90h> that'd be it, I take it ;)
[21:40] <db90h> well i better look closer to be sure, i always open my mouth too soon ;p
[21:43] <nbd> that's it
[21:45] <db90h> yep, building now.. this outta be the first working reversion firmware image
[21:45] <db90h> i thought about adding a web UI to ask for the MAC address to embed in the VxWorks BSP.. but to hell with all that work.. I decided instead to let people replace the VxWorks BSP again/later with the bootrom.bin method if they desire to embed a MAC address
[21:46] <db90h> .. i'm writing a GUI to embed mac addresses in both VxWorks BSP and CFEs, then build an appropriate firmware image.. so that'll be good enough
[22:55] <florian> this brcm63xx port is driving me nuts
[22:59] <florian> what the hell is the problem with realeasing working GPL tarballs :
[23:00] <db90h> how come when I change a patch file the merge throws an error, 'assume reverted..'..'apply anyway..', etc
[23:00] <db90h> do I really need to create a new patch for any change, even if it's undoing previous patches in the chain?
[23:00] <florian> db90h: depends how your patch was diffed
[23:00] <florian> it's better to create a new patch for a new change ihmo
[23:01] <db90h> i'm merely removing the writable mask from the 001-bcm47xx.patch .. so it's a very minor tweak
[23:01] <db90h> it seems like the merge wouldn't fail..
[23:02] <db90h> but it seems to throw off that entire patch file
[23:03] <db90h> the last modified time on the patch file itself doesn't matter, surely?
[23:04] <db90h> i'm not even removing a line, just part of a line.. oh well, i'll create a new diff and add it to the chain i guess, it just seems stupid.. but I don't know what I'm doing wrong with the edit on that patch file
[23:05] <db90h> i don't suppose it's the way gedit is saving it that's screwing with it..
[23:05] <florian> db90h: you can probably do it inside the patch without recalculating the line differences
[23:06] <db90h> florian: exactly what I did.. no line number changes at all.. just clipped out part of a line that is patched in
[23:06] <florian> so ?
[23:06] <florian> did you make a rm -r build_mipsel/linux* ?
[23:06] <db90h> if aka make clean, yea
[23:06] <db90h> wait
[23:06] <db90h> i got the error again, after I undid my changes in gedit
[23:06] <db90h> maybe the way gedit is saving the patch file? is that possible?
[23:08] <db90h> "the error is "Reversed (or previously applied) patch detected! Assume -R [n]" .. then if I go ahead and apply the patch anyway, it fails.. and if I don't apply the patch, the build aborts.. the patches shouldn't already be applied, cuz the other ones get merged in fine
[23:10] <db90h> well now I know at least that it ought to be working, thx ;)
[23:10] <db90h> i've had this issue before tho.. i ended up creating a new patch, which is hwat i'll do here.. no time to figure out what the issue is
[23:11] <db90h> oh shit
[23:11] <db90h> duh
[23:11] <db90h> fuck me
[23:11] <db90h> my god
[23:11] <db90h> i am so stupid
[23:11] <db90h> gedit was creating a damn backup file
[23:11] <db90h> and that was being applied after the pathc
[23:11] Action: db90h kills himself
[23:12] <db90h> stupid '~' ;p
[23:12] <florian> lol
[23:12] <nbd> http://forum.openwrt.org/viewtopic.php?pid=29526#p29526 :)
[23:12] <db90h> i didn't expect anything other than *.patch to get applied (not *.patch*)..and that ~ is hard to see<g>
[23:19] <db90h> so is sveasoft still using openwrt code?
[23:19] <nbd> sure
[23:19] <nbd> he even keeps ripping off the newer stuff
[23:19] <nbd> like my wl.o integration work
[23:19] <db90h> he's an ass
[23:20] <nbd> or sometimes i write small shell scripts for specific purposes
[23:20] <nbd> like rate estimation
[23:20] <nbd> and later find them in his firmware
[23:20] <nbd> no matter how hackish they are :)
[23:20] <db90h> lol
[23:20] <db90h> that guy is totally whack
[23:20] <nbd> he's completely moved over to the openwrt kernel
[23:21] <nbd> sure
[23:22] <db90h> as I've previously mentioned, my dealings with him have been amusingly sickening.. but I didn't realize just how bad he was
[23:23] <db90h> ripping off code aside, i assume he is wrong about his argument about not having to distrubte source to those who he doesn't distribute binary?
[23:23] <nbd> i believe so
[23:23] <nbd> the gpl seems rather clear on this issue
[23:23] <nbd> either accompany binaries with the source
[23:24] <nbd> or make an offer valid for *any* third party
[23:26] <db90h> a disgusting shame..what can be done tho? in the end, I think he's obviously a quite miserable guy..but his misery doesn't put a stop to his ill-gotten income
[23:26] <db90h> you could take him to court, but who has that kinda money.. i guess he knows this
[23:27] <nbd> last time the public announcement has cost him several important customers
[23:27] <nbd> if the flamewar is kept alive, more people will stop using his crap
[23:27] <nbd> it just has to hit popular news sites
[23:27] <nbd> that's what has the most impact
[23:29] <db90h> he's probably in here right now, spying
[23:30] <nbd> he doesn't have to be in here
[23:30] <nbd> he can read the logs
[23:30] <nbd> they're public
[23:30] <db90h> oh yea, forgot about that
[23:30] <nbd> anyway, he already knows what i think about him
[23:30] <nbd> so i don't care
[23:33] <db90h> well, money isn't everything..he pays the price for his sins, i assure you
[23:33] <db90h> time to try the reversion firmware
[23:34] <db90h> brb
[00:00] --- Tue Jun 27 2006