"Please don't use knx-hdinstall any more! I won't support it any longer and its just there as uhm, its not my project, but those of Christian Perle. knoppix-installer should now work in both modes (see below) and give a fairly stable system. "
Yeah, good point... in a rational world, although, I suspect:-
a) my local constabulary in Surrey is going to be totally disinterested in the actions of a florida spammer.
b) so is my local MP. I have enough problems getting him to tackle very local issues.
c) the Florida DA (or whatever would be appropriate) is likely to be disintersted in the plight of some limey recieving spam from one of their tax paying, voting citizens.
Unfortunately I think in these situations the only people likely to get anywhere are the weasels , sorry, lawyers.
True but who's going to actively sue the spammers for their illegal activity? The only people with the money and resources to do that effectively are the ISP's, and so far most aren't tackling the problem.
Re. withdrawing the certificate, no-one is going to withdraw the certificate of a major ISP even if a spam flood is originating from their network. The customers computer that has been compromised is connected perfectly legitimately to the ISPs mail server and is 'legitimately' sending it emails. Sure the ISP could cut their account for sending x thousand emails, but then again they could cut existing spammers accounts at the moment for sending thousands of spam emails... but they don't.
Re. contact information in the spam, we're dealing with people here who really will simply ignore the law, they will use a myriad of techniques to claim that the spam advertising the service is in no way connected to them. Unless you can prove that the company/person identified in the body of the email was the person who sent it that doesnt get you very far.
A good idea to start with... However, after having spent the weekend tracking and blocking a flood of SoBig viruses from a couple of large canadian ISP's which has focused my thinking this morning, I think this type of system will again simply cause the spammers to look for alternate delivery systems, i.e. as more ISPs take a tougher line against spam, more and more spammers will start to take extreme measures to propagate their product.
So cable modem users with big bandwidth and vulnerable machines will be used to send the spam. The spammer uses a worm to find vulnerable machines and piggybacks the users connection and sends the spam, it still goes through the ISP's mail server and so will get validated and delivered.
Also, unless I missed something (possible) even though the recipient can specify what type of email he will accept, there's nothing to stop the sender simply specifying whatever they feel like.
An amusing aside, I sent a warning to one of the ISP's (sprint.ca) that was the source of the viruses on friday warning them of their problem, the flood (one every 30 seconds) was still going on during sunday, so I sent the same warning but copied in their 'corporate customer email' and 'noc@' email contact addresses, believe it or not I got a response within an hour telling me that they didn't appreciate me "SPAM"ing their email addresses and I should just email "abuse@"! Oh and the virus flood is still going on. Ho hum.
Re. not that distribution of the decompiled driver code is necesarily legal. I think it probably is not,
As I posted several times already, the VIA license (posted in this thread somewhere) with this library explicitly allows derivative works.
so I also have no idea what an Italian court would think
I'm in the UK actually, the.it was a nice to have to split my site up.... and it wouldn't hurt to got there every once in a while. The UK courts would take the same attitude to the Italian or US ones when it comes to copyright of code. What we luckily don't have yet is anything as stupid as the DMCA or software patents... but with enough lobbying from hollywood and the US software industry it probably will happen.
This is different. This was not a commercial product that was disassembled.
The VIA driver was released with the notice: "Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files... to deal in the software without restriction including without limitation the rights to use, copy, modify, merge, publish, distribute, sub-license and/or sell..."
The driver was released for people to play with in an attempt to stimulate linux development. Unfortunately no source code was provided, and no spec/development manual, so actually creating a working application against the driver is difficult. Hence the reason for generating the source.
On your final point, there's nothing stopping MS using GPL code, as long as they released their derivative work under the GPL.
Being in the UK, and with the wording of VIA's Copyright notice (see other posts), court isn't going to be a problem. (Until there's a european DMCA equivalent of course).
The main problem with VIA was their attitude, they made a big deal and got lots of positive press for their announced Linux support but then failed to deliver. They announced these boards as providing hardware MPEG decompression (true) but then failed to supply either any software to achieve that or information on how it could be done. As far as I know, the hardware MPEG is only supported on windows with a single version of PowerDVD too.
Finally they announced that they would make the source code available but only to companies "producing commercial products". I tried to contact VIA but was ignored, so I decided to do it myself.
Hopefully now this should get the ball rolling and we'll start seeing software making use of the MPEG hardware appearing.
Perhaps VIA might even now decide there's no point not releasing their own source?
On point one, the problem is I have yet to see a decompiler output anything but complete shit.
Why not get yourself a decompiler like REC and run it against the library and see what you get (although REC will probably crash).
If it does run, you have a chunk of assembly you know works, and a chunk of pseudo C code from your decompiler that you can't be sure bears any relation to the original code and may not have been decompiled correctly and probably misses huge chunks of code that the decompiler wasn't sure about. That doesn't get you very far. For me the best process it to use a very good disassembler and go from there.
On point two, yup spot on. I can't see any reason for them not releasing the code. It doesn't do anything clever, I cant see any super special algorithms in there. Why not release the code.
Yup, the problem is that VeXP is just a modified and slightly broken version of xine rather than a patch to get the EPIA mpeg hardware going. Also, the VeXP code relies on using the VIA ddmpeg binary driver and VIA binary video drivers.
But from a 32bit hex number I now know which direction the iocall is being made and the correct type of the pointer. I reckon that's an improvement.:-)
Opps was fast asleep in bed when this was posted. I've now tweaked the bandwidth throttling on the site so it should be a bit quicker now anyway. Cheers for the source mirror, do you mind if I add a link to it on the download page for now?
The copyright statement in the driver from via states:-
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sub license,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial portions
* of the Software.
It's just that they didn't actually release the code for the driver. So the port doesn't need to be a proper clean room reverse engineer.
Actually, yes I did try contacting VIA and signing up to their developer program through the contact details they provided but they simply ignored my requests. I assumed therefore that they were actually only interested in dealing with companies as stated.
Hmm but.AVS files are already used for Intel's old video compression format. link. This isn't going to cause confusion oh noooo. Can't see intel being too happy about their use of the AVS name for their standard either.
It would be nice if they published some specs of the power gain for their commercial cantenna to back up the claims that it is more powerful though. It looks like similar dimensions to my "Campari" cantenna which I've tried to model the gain for. link. Comparing its performance to a commercial antenna which I have the spec sheet for suggests the calculations are pretty accurate too.
Well until we get the DMCA in europe I guess this level of reverse engineering is acceptable under the 1991 Software Copyright Protection directive.
The copyrighted firmware isn't shipped with the linux driver anyway and has to be extracted by the user from another driver file.
Indeed you discovered the link to the leaked binary drivers.
However when the sourceforge project was started there were no binary drivers at all.
Indeed it is a non-trivial task to decompile those drivers, and that was what was done to assist the development of the oss drivers.
As you will note Dlink aren't providing or supporting those binary drivers you discovered either they've simply got fed up of all their customers asking them how to get their hardware running on linux and so added the link onto their FAQ.
So no wash.
Yeah that FAQ has changed a few times. I think there's a history of its comments on seattle wireless somewhere, rummage, rummage, here.
Initially they said a linux driver would be released december 2002. In december that date was changed to Q1 2003. At the end of december they then said there were no plans for a linux driver and customers should not 'hold onto cards in the hope of drivers' being written.
Then they added a link to the leaked binary drivers
Basically most work was done by disassembling a linux binary module for the chipset that leaked from one of the manufacturers. Additionally the behaviour of the card and correct initialisation process was determined by analysing the ARM disassembly of the firmware and watching the traffic that goes between the access point board and its embedded PCcard.
This is particularly galling when you read about manufactureres who are actually reaping the benfits of open source development in their own products link but then refuse to support linux using customers.
Slashdot Mirror
To stop the country specific bounce, just add noredir=1 to the url i.e.
http://search.msn.com/?noredir=1
From that changelog:
"Please don't use knx-hdinstall any more!
I won't support it any longer and its just there as uhm, its not my project, but those of Christian Perle.
knoppix-installer should now work in both modes (see below) and give a fairly stable system. "
+5 Funny. :-)
Well... probably nothing yes.
I think there would be a perceived problem of where the crime was committed (the spam not the brick!).
Hmmm not sure about the knifepoint trick though, tempting though.
Yeah, good point... in a rational world, although, I suspect:-
a) my local constabulary in Surrey is going to be totally disinterested in the actions of a florida spammer.
b) so is my local MP. I have enough problems getting him to tackle very local issues.
c) the Florida DA (or whatever would be appropriate) is likely to be disintersted in the plight of some limey recieving spam from one of their tax paying, voting citizens.
Unfortunately I think in these situations the only people likely to get anywhere are the weasels , sorry, lawyers.
True but who's going to actively sue the spammers for their illegal activity? The only people with the money and resources to do that effectively are the ISP's, and so far most aren't tackling the problem.
Re. withdrawing the certificate, no-one is going to withdraw the certificate of a major ISP even if a spam flood is originating from their network. The customers computer that has been compromised is connected perfectly legitimately to the ISPs mail server and is 'legitimately' sending it emails.
Sure the ISP could cut their account for sending x thousand emails, but then again they could cut existing spammers accounts at the moment for sending thousands of spam emails... but they don't.
Re. contact information in the spam, we're dealing with people here who really will simply ignore the law, they will use a myriad of techniques to claim that the spam advertising the service is in no way connected to them. Unless you can prove that the company/person identified in the body of the email was the person who sent it that doesnt get you very far.
A good idea to start with...
However, after having spent the weekend tracking and blocking a flood of SoBig viruses from a couple of large canadian ISP's which has focused my thinking this morning, I think this type of system will again simply cause the spammers to look for alternate delivery systems, i.e. as more ISPs take a tougher line against spam, more and more spammers will start to take extreme measures to propagate their product.
So cable modem users with big bandwidth and vulnerable machines will be used to send the spam. The spammer uses a worm to find vulnerable machines and piggybacks the users connection and sends the spam, it still goes through the ISP's mail server and so will get validated and delivered.
Also, unless I missed something (possible) even though the recipient can specify what type of email he will accept, there's nothing to stop the sender simply specifying whatever they feel like.
An amusing aside, I sent a warning to one of the ISP's (sprint.ca) that was the source of the viruses on friday warning them of their problem, the flood (one every 30 seconds) was still going on during sunday, so I sent the same warning but copied in their 'corporate customer email' and 'noc@' email contact addresses, believe it or not I got a response within an hour telling me that they didn't appreciate me "SPAM"ing their email addresses and I should just email "abuse@"! Oh and the virus flood is still going on. Ho hum.
How may times to I have to make this post... ? :-)
.it was a nice to have to split my site up.... and it wouldn't hurt to got there every once in a while.
Re.
not that distribution of the decompiled driver code is necesarily legal. I think it probably is not,
As I posted several times already, the VIA license (posted in this thread somewhere) with this library explicitly allows derivative works.
so I also have no idea what an Italian court would think
I'm in the UK actually, the
The UK courts would take the same attitude to the Italian or US ones when it comes to copyright of code. What we luckily don't have yet is anything as stupid as the DMCA or software patents... but with enough lobbying from hollywood and the US software industry it probably will happen.
This is different. This was not a commercial product that was disassembled.
The VIA driver was released with the notice:
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files... to deal in the software without restriction including without limitation the rights to use, copy, modify, merge, publish, distribute, sub-license and/or sell..."
The driver was released for people to play with in an attempt to stimulate linux development. Unfortunately no source code was provided, and no spec/development manual, so actually creating a working application against the driver is difficult.
Hence the reason for generating the source.
On your final point, there's nothing stopping MS using GPL code, as long as they released their derivative work under the GPL.
Being in the UK, and with the wording of VIA's Copyright notice (see other posts), court isn't going to be a problem. (Until there's a european DMCA equivalent of course).
The main problem with VIA was their attitude, they made a big deal and got lots of positive press for their announced Linux support but then failed to deliver. They announced these boards as providing hardware MPEG decompression (true) but then failed to supply either any software to achieve that or information on how it could be done.
As far as I know, the hardware MPEG is only supported on windows with a single version of PowerDVD too.
Finally they announced that they would make the source code available but only to companies "producing commercial products". I tried to contact VIA but was ignored, so I decided to do it myself.
Hopefully now this should get the ball rolling and we'll start seeing software making use of the MPEG hardware appearing.
Perhaps VIA might even now decide there's no point not releasing their own source?
On point one, the problem is I have yet to see a decompiler output anything but complete shit.
Why not get yourself a decompiler like REC and run it against the library and see what you get (although REC will probably crash).
If it does run, you have a chunk of assembly you know works, and a chunk of pseudo C code from your decompiler that you can't be sure bears any relation to the original code and may not have been decompiled correctly and probably misses huge chunks of code that the decompiler wasn't sure about.
That doesn't get you very far. For me the best process it to use a very good disassembler and go from there.
On point two, yup spot on. I can't see any reason for them not releasing the code. It doesn't do anything clever, I cant see any super special algorithms in there. Why not release the code.
Yup, the problem is that VeXP is just a modified and slightly broken version of xine rather than a patch to get the EPIA mpeg hardware going.
Also, the VeXP code relies on using the VIA ddmpeg binary driver and VIA binary video drivers.
Hehe, well it does then get translated into:
:-)
ioctl(fVideo, VIA_VID_GET_2D_INFO, &gVIAGraphicInfo)
But from a 32bit hex number I now know which direction the iocall is being made and the correct type of the pointer. I reckon that's an improvement.
Opps was fast asleep in bed when this was posted. I've now tweaked the bandwidth throttling on the site so it should be a bit quicker now anyway. Cheers for the source mirror, do you mind if I add a link to it on the download page for now?
The copyright statement in the driver from via states:-
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sub license,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial portions
* of the Software.
It's just that they didn't actually release the code for the driver. So the port doesn't need to be a proper clean room reverse engineer.
Actually, yes I did try contacting VIA and signing up to their developer program through the contact details they provided but they simply ignored my requests. I assumed therefore that they were actually only interested in dealing with companies as stated.
flavor incorrect spelling - 2,780
flavour incorrect spelling - 1,470
Google is not god
Hmm but .AVS files are already used for Intel's old video compression format.
link.
This isn't going to cause confusion oh noooo. Can't see intel being too happy about their use of the AVS name for their standard either.
It would be nice if they published some specs of the power gain for their commercial cantenna to back up the claims that it is more powerful though.
It looks like similar dimensions to my "Campari" cantenna which I've tried to model the gain for. link.
Comparing its performance to a commercial antenna which I have the spec sheet for suggests the calculations are pretty accurate too.
Well until we get the DMCA in europe I guess this level of reverse engineering is acceptable under the 1991 Software Copyright Protection directive. The copyrighted firmware isn't shipped with the linux driver anyway and has to be extracted by the user from another driver file.
Indeed you discovered the link to the leaked binary drivers. However when the sourceforge project was started there were no binary drivers at all. Indeed it is a non-trivial task to decompile those drivers, and that was what was done to assist the development of the oss drivers. As you will note Dlink aren't providing or supporting those binary drivers you discovered either they've simply got fed up of all their customers asking them how to get their hardware running on linux and so added the link onto their FAQ.
So no wash.
Well if you want a project and you think people will be interested in it, set yourself one up and try and round up support for it.
Yeah, that's life (well /. anyway). :-)
:-)
What was the outcome of petitioning the BBB? Did you get any response/comments from TI at all?
---
Hmmm, just wondering how many devices you own have TI chipsets in them.
Yeah that FAQ has changed a few times. I think there's a history of its comments on seattle wireless somewhere, rummage, rummage, here.
Initially they said a linux driver would be released december 2002.
In december that date was changed to Q1 2003.
At the end of december they then said there were no plans for a linux driver and customers should not 'hold onto cards in the hope of drivers' being written.
Then they added a link to the leaked binary drivers
Then they added a link to the oss drivers
Wonder what they'll change it to next?
Basically most work was done by disassembling a linux binary module for the chipset that leaked from one of the manufacturers.
Additionally the behaviour of the card and correct initialisation process was determined by analysing the ARM disassembly of the firmware and watching the traffic that goes between the access point board and its embedded PCcard.
This is particularly galling when you read about manufactureres who are actually reaping the benfits of open source development in their own products link but then refuse to support linux using customers.