I guess the spamming problem might be solved if each web-server is crawled by it's own builtin search agent and a set of indepent search agents that also belong to the p2p network.
This way, even if the webserver advertises false information, this information isn't taken into account if it isn't verified by information coming from independent agents of the network.
Right, preserving the integrity of the search results in the case of malicious users injecting false information into the system sounds like a challenging problem. But a p2p search engine seems to be the only way to go for an open-source search engine implementation.
Something that would make a nice opensource project would be to include p2p search functionality in apache itself. This way all the modificed web servers would make a giant distributed search engine. Some nice algorithms like koorde or kademlia could be used. Anyone thought about starting something like this?
There is something I don't understand in his announcement: he says it's not feasable to set up a server that acts as a third party to set-up connections between NATed hosts because it would require too much bandwith. But wouldn't it be possible to build a server that is used just to setup the connection and send the subsequent data directly between the initial hosts, therbey nopt using the server's bandwidth?
The BSD license is very good for this. The government should be allowed to build closed source software using the other BSD-licensed software they have funded themselves.
I think that System.Windows.Forms is a pretty good GUI library. (I find it much better than wxWindows using Python for example). However, it will be a lot of work to reimplement it using free toolkits instead of gdi+.
Having used both java and.net, my preference goes to.net. I think the.NET CLR is much more advanced than the java JVM (language independence, etc.). I also like the operability with legacy code. I also think the.NET framework library is better designed than the java library. I also like the fact that a large part of the Framework has been submitted for standardisation. I disagree with people that don't like.NET just because it's made by Microsoft.
.NET is great! The.NET framework library is very complete and easy to use. The.NET CLR is also very cool. I will be nice when I can develop things using Visual Studio.NET and deploy the assemblies on Linux servers using MONO.
wavelet transform: There is also support for the lossless 5-3 wavelet. (I've tried to cover as much as possible of the standard, as you will notice if you are interested in the code)
stepsizes: The reason pnmtoj2k specifies all the stepsizes by itself is that it operates j2k_encode in the _explicit_ stepsizes mode. In this mode, the caller chooses the stepsize for each band explicitly. It is not a design flaw.
documentation: I plan to release some documentation on the libj2k API. (usage of j2k_encode and j2k_decode+specification of coding parameters) There is no documentation yet. (I didn't choose when this article on slashdot was published)
motivation: I've tried to produce the simplest implementation as possible. (In terms of choice of datastructure, memory usage, etc.) This is because I am using this code as a basis for a hardware implementation (on SoC). -- datrus
Well I haven't finished the docs yet. Come back later (or don't). In the meantime: The libj2k library has only 2 API calls: j2k_encode and j2k_decode. It shouldn't be to difficult to figure out how it works. (because there are 2 example applications) -- datrus
I'm pretty sure there are no patent problems. All algorithms used in the JPEG-2000 standard can be used freely. (like IBM's MQ-coder)
About the video codec: I implemented an H.263 and MPEG-4 compliant codec. But I didn't get paid by the opencodex guy, so I aborted the project. Still, if anybody's interested, I have some pretty good MMX and altivec optimised code lying around.
B SD-licensed JPEG-2000 implementation
on
JPEG2000 Coming Soon
·
· Score: 5, Informative
Hey, I've implemented a JPEG-2000 codec using a BSD-style license. It's been tested at the MIT biodmedical department already for compression of medical images. It's available at http://j2000.org/. It would be nice to see this work in my favourite browsers.
I made some h.263(+) libraries for the opencodex contest. The code is really SUPER clean and the encoder and the decoder compile in less than 20k (vlc tables included).
Unfortunately I have to finish the really nasty part of the contest: the quicktime component. Quicktime is really a nightmare to program. The benefit is that after this component is done, all quicktime movies (sorenson,...) can be converted to the opencodex format.
Anyone interested in the libh263 source code (LPGL) can contact me (david.janssens@pandora.be). Full source should be publicly available when contest is over (ie: qt component is ready).
I took part in the opencodex contest and won it.
The codec libraries (based on h.263+) where finished late september.
The quicktime component was assigned to somebody else, and was the reason the whole thing took so long. I am now working on the component myself. The quicktime API is a real mess.
Anyone interested in helping me out with this is welcome...
The codec shared libraries are fully LPGL and are available in the usual automake/autoconf form.
As for 3ivx, i believe the player is open-source but not the codec. One cool feature is postfiltering, but it increases the decoder complexity a lot.
A second version of the opencodex codec is scheduled for mid-2001, it uses localised wavelets and therefore eliminates the need for postfiltering.
Slashdot Mirror
I guess the spamming problem might be solved if each web-server is crawled by it's own builtin search agent and a set of indepent search agents that also belong to the p2p network.
This way, even if the webserver advertises false information, this information isn't taken into account if it isn't verified by information coming from independent agents of the network.
David
Right, preserving the integrity of the search results in the case of malicious users injecting false information into the system sounds like a challenging problem.
But a p2p search engine seems to be the only way to go for an open-source search engine implementation.
David
Something that would make a nice opensource project would be to include p2p search functionality in apache itself.
This way all the modificed web servers would make a giant distributed search engine.
Some nice algorithms like koorde or kademlia could be used.
Anyone thought about starting something like this?
David
HAHA!
There is something I don't understand in his announcement: he says it's not feasable to set up a server that acts as a third party to set-up connections between NATed hosts because it would require too much bandwith.
But wouldn't it be possible to build a server that is used just to setup the connection and send the subsequent data directly between the initial hosts, therbey nopt using the server's bandwidth?
David
So why isn't building pianos freedom of speech also then?
Check out MMPlayer for a DivX/MPEG-1,2,4 player that works on regular Palms.
David
Checkout mmplayer.com.
I'm trying to develop a mobile media player that supports most codecs, formats and protocols.
I think this will be most useful when finished.
I think a solution against spam would be to have
an authentication mechanism that identifies the sender.
Users would have to pay only once a small amount of money to get a pub/priv key pair from a certification authority.
Then users would use this pair to authenticate the messages they sent.
E-mail recipients could then simply choose to enable or disable reception of unauthenticated messages.
David
plenty of benchmarks on http://dotnetguru.org/
The BSD license is very good for this.
The government should be allowed to build closed source software using the other BSD-licensed software they have funded themselves.
I think that System.Windows.Forms is a pretty
good GUI library. (I find it much better than wxWindows using Python for example).
However, it will be a lot of work to reimplement it using free toolkits instead of gdi+.
Having used both java and .net, my preference goes to .net. .NET CLR is much more advanced than the java JVM (language independence, etc.). .NET framework library is better designed than the java library. .NET just because it's made by Microsoft.
I think the
I also like the operability with legacy code.
I also think the
I also like the fact that a large part of the Framework has been submitted for standardisation.
I disagree with people that don't like
hurray!!! .NET is super! .NET!
long live
I will love it when I will be able to deploy my assemblies on FREE linux servers!
.NET is great! .NET framework library is very complete and easy to use. .NET CLR is also very cool. .NET and deploy the assemblies on Linux servers using MONO.
The
The
I will be nice when I can develop things using Visual Studio
The .NET framework is excellent stuff!
Go mono!
datrus
.NET technology is excellent! It is in many ways superior to java. Go mono!
datrus
j2000.org A BSD-licensed JPEG-2000 library developped under the European Union PRIAM project. Documentation is underway.
wavelet transform:
There is also support for the lossless 5-3 wavelet. (I've tried to cover as much as possible of the standard, as you will notice if you are interested in the code)
stepsizes:
The reason pnmtoj2k specifies all the stepsizes by itself is that it operates j2k_encode in the _explicit_ stepsizes mode. In this mode, the caller chooses the stepsize for each band explicitly. It is not a design flaw.
documentation:
I plan to release some documentation on the libj2k API. (usage of j2k_encode and j2k_decode+specification of coding parameters)
There is no documentation yet. (I didn't choose when this article on slashdot was published)
motivation:
I've tried to produce the simplest implementation as possible. (In terms of choice of datastructure, memory usage, etc.) This is because I am using this code as a basis for a hardware implementation (on SoC).
--
datrus
Well I haven't finished the docs yet.
Come back later (or don't).
In the meantime:
The libj2k library has only 2 API calls:
j2k_encode and j2k_decode. It shouldn't be to difficult to figure out how it works. (because there are 2 example applications)
--
datrus
I'm pretty sure there are no patent problems.
All algorithms used in the JPEG-2000 standard can be used freely. (like IBM's MQ-coder)
About the video codec: I implemented an H.263 and MPEG-4 compliant codec. But I didn't get paid by the opencodex guy, so I aborted the project. Still, if anybody's interested, I have some pretty good MMX and altivec optimised code lying around.
Hey, I've implemented a JPEG-2000 codec using
a BSD-style license.
It's been tested at the MIT biodmedical department already for compression of medical images.
It's available at http://j2000.org/.
It would be nice to see this work in my favourite browsers.
that's 275$ not 175$
I made some h.263(+) libraries for the opencodex contest. The code is really SUPER clean and the encoder and the decoder compile in less than 20k (vlc tables included).
Unfortunately I have to finish the really nasty part of the contest: the quicktime component. Quicktime is really a nightmare to program. The benefit is that after this component is done, all quicktime movies (sorenson,...) can be converted to the opencodex format.
Anyone interested in the libh263 source code (LPGL) can contact me (david.janssens@pandora.be). Full source should be publicly available when contest is over (ie: qt component is ready).
I took part in the opencodex contest and won it. The codec libraries (based on h.263+) where finished late september. The quicktime component was assigned to somebody else, and was the reason the whole thing took so long. I am now working on the component myself. The quicktime API is a real mess. Anyone interested in helping me out with this is welcome... The codec shared libraries are fully LPGL and are available in the usual automake/autoconf form. As for 3ivx, i believe the player is open-source but not the codec. One cool feature is postfiltering, but it increases the decoder complexity a lot. A second version of the opencodex codec is scheduled for mid-2001, it uses localised wavelets and therefore eliminates the need for postfiltering.