Re: [E-devel] using LZ4 compression tool in eet ?
On Sun, 13 May 2012 18:27:05 + (UTC) Thomas Kueling thomas.kuel...@gmail.com said: Torri vincent.torri at gmail.com said: actually forget lz4hc... lgpl3. Well, apparently no longer : LZ4 HC just went BSD. http://code.google.com/p/lz4/ eet now supports both lz4 and lz4hc :) in svn only tho. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Mon, 21 May 2012 20:47:46 +0200 thomas.kuel...@gmail.com said: Sounds Great ! If i do understand properly, LZ4 is supposed to improve eet user experience thanks to better responsiveness, due to faster ressource loading time and/or less memory usage ? If that's correct, will there be a way to measure such improvement ? edje_cc has 2 new options. -fastcomp and -fastdecomp. -fastcomp uses lz4. -fastdecomp uses lz4hc. fastcomp is fast to compress and decompress, but edje files bloat up by about 50% bigger (as expected). but compression time is faster than zlib and fastdecomp. fastdecomp is slower to compress than zlib, with the same compression ratios, but is faster to decompress at runtime. so it's a tradeoff as with many things. the only places you can really measure this is things like startup time of e or apps when they have to load and decompress edje data into memory, especially if the3 data is already cached in ram in the kernel buffer/cache. you may fine we save a few ms. feel free to find a way to test this. :) (e17 has some debug output of its own to give you timings of startup - this gets dumped to stdout. other apps - u'd have to add instrumentation somewhere to basically time how long between the beginning of main() and when the mainloop finally goes idle) Rgds -Message d'origine- From: Carsten Haitzler (The Rasterman) Sent: Monday, May 21, 2012 1:37 PM To: Enlightenment developer list Cc: Thomas Kueling Subject: Re: [E-devel] using LZ4 compression tool in eet ? On Sun, 13 May 2012 18:27:05 + (UTC) Thomas Kueling thomas.kuel...@gmail.com said: Torri vincent.torri at gmail.com said: actually forget lz4hc... lgpl3. Well, apparently no longer : LZ4 HC just went BSD. http://code.google.com/p/lz4/ eet now supports both lz4 and lz4hc :) in svn only tho. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
Torri vincent.torri at gmail.com said: actually forget lz4hc... lgpl3. Well, apparently no longer : LZ4 HC just went BSD. http://code.google.com/p/lz4/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
Hi, Someone from #tukaani on freenode has just made some benchmarks which can be relevant here: http://pokecraft.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO Speed will probably be impacted quite a lot by the data but I expect memory usage to not change. Anyway, not my benchmark, I can't say anything about how good it is (and anyway, you shouldn't believe me :-)). -- Adrien Nader -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Sun, 13 May 2012 18:27:05 + (UTC) Thomas Kueling thomas.kuel...@gmail.com said: Torri vincent.torri at gmail.com said: actually forget lz4hc... lgpl3. Well, apparently no longer : LZ4 HC just went BSD. http://code.google.com/p/lz4/ ok... so now it's on the possible list. :) so with lx4hc we get same compression ration as zlib -1, but slower speed (about 3x as long to compress). to date we have only been using zlib level 1 for images, level 9 for data (for various reasons). at least with lz4hc at decompress time we don't pay a greater IO cost than now for images (should be about the same size to load) but decompression speed when we DONT wait on IO is 6.4x faster... not bad. this still needs actual empirical testing to see what the actual costs and gains end up being in real life. it's too complex an issue since we deal with IO here to figure out with some thought exercises i think. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Wed, 25 Apr 2012 01:30:02 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 24 Apr 2012 12:10:46 +0200 thomasg tho...@gstaedtner.net said: On Tue, Apr 24, 2012 at 00:51, David Seikel onef...@gmail.com wrote: FSF may be good for their Four Freedoms, but they take away an important freedom with everything they touch. I have seen GPL stifling innovation in large projects. And this is precisely why, we may not use this new compression thing just coz we want EET to be BSD, and not be forced to make it GPL. Yes, GPL might be trouble if your goal is never to honor the license. Deal with it. no - its gpl v3's specific changes vs v2 that are the issue. Exactly, it's v3 I have problems with, not v2. That's what I have to deal with, and I choose to deal with it by not developing with anything tainted with that license. My goal is to honour licenses, which is why one that I can't agree to leads to not using stuff that is under that license for development. Note that I said I would not use ewebkit until that and a few other things where sorted out, not that I would go screw you and your license and not honour the license. I'm honouring the license by not using stuff that has it. That's an acceptable method of honouring a license. I don't agree to the license, I don't use the licensed material. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Tue, Apr 24, 2012 at 00:51, David Seikel onef...@gmail.com wrote: On Mon, 23 Apr 2012 22:42:22 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 23 Apr 2012 15:05:09 +0200 thomasg tho...@gstaedtner.net said: On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri vincent.to...@gmail.com said: actually forget lz4hc... lgpl3. hey just found that while reading the gnutls ML : http://code.google.com/p/lz4/ it seems that it allows the same ratio for compression than zlib but seems to be by far faster than zlib the memory consumption should be tested too. What do you think ? Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I don't see any problem using an LGPLv3 library. Are there really any changes necessary to make use of it in eet? Also, would it have to be distributed in a way where LGPL parts would actually be packed into an Eet binary or Eet source code? there i a problem because we'd have to compile it into eet - which would make eet lgpl3. gpl and lgpl3 are also highly propblematice in terms of acceptance. they are controversial at best. Although I of course can understand that it would not be possible to use Eet in an environment where no LGPL library could be accepted, wherever or whyever that would be. no, it's the gpl/lgpl3 (as opposed to 2). I'd be one of those not accepting of GPL 3, or it's variations. Google does not accept any GPL variants in Android officially, even though they rely on a few GPL parts for the base OS. Including the Linux kernel. Google does this in Android because Android is not an actual open source project - it's a google project which might or might not be released as open source at any point after a release. The GPL does not allow for software to be released as closed source, that's why google won't allow it in their distribution unless necessary. For what it's worth, I think I found a GPL3 bit buried deep in the ewebkit dependencies, but I kinda gave up for now after I had gotten several levels deep in dependency hell. I think the plan with ewebkit is to strip out some more dependencies to replace them with EFL bits? That would help, but right now it's a bitch to compile on Ubuntu 10.04. I'll try again later, when there is less dependencies, or after I upgrade to Ubuntu 12.04 later this year. Just because a GPL application is a dependency at some point does not mean it will make the project GPL. You have to explicitly link to it, unless the application itself would include GPL sourcecode unknowingly which would technically make your application GPL. Then again, that's a very rare case and it is specific to the GPL, not the LGPL. That's the danger with GPL 3 on huge projects. The main project might be BSD or something, but buried deep is a GPL 3 component of a sub component of a dependency that no one noticed. Likely coz it was GPL 2 when it went in. Then the entire thing is contaminated. FSF has been painting GPL 2 in a bad light, and swapping licenses on old versions of GNU stuff with out telling people. I think that's despicable. Yes, there is a danger with the GPLv3 on huge projects. On huge closed source projects that is. You cannot stuff GPLv3 software in it and not expect the user to get the sourcecode and change this parts. Thats what the GPLv3 is about, and there are valid reasons for it. If you want to use a GPLv3 software in your closed source project, you of course have to be careful, because the author of this software decided that he did not want you to use it there without making available your changes. The GPLv3 exists for a big number of very specific occasions where big companies made big money with heavy use of GPLv2 software and decided their users and developers
Re: [E-devel] using LZ4 compression tool in eet ?
On Tue, 24 Apr 2012 12:10:46 +0200 thomasg tho...@gstaedtner.net said: On Tue, Apr 24, 2012 at 00:51, David Seikel onef...@gmail.com wrote: On Mon, 23 Apr 2012 22:42:22 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 23 Apr 2012 15:05:09 +0200 thomasg tho...@gstaedtner.net said: On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri vincent.to...@gmail.com said: actually forget lz4hc... lgpl3. hey just found that while reading the gnutls ML : http://code.google.com/p/lz4/ it seems that it allows the same ratio for compression than zlib but seems to be by far faster than zlib the memory consumption should be tested too. What do you think ? Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I don't see any problem using an LGPLv3 library. Are there really any changes necessary to make use of it in eet? Also, would it have to be distributed in a way where LGPL parts would actually be packed into an Eet binary or Eet source code? there i a problem because we'd have to compile it into eet - which would make eet lgpl3. gpl and lgpl3 are also highly propblematice in terms of acceptance. they are controversial at best. Although I of course can understand that it would not be possible to use Eet in an environment where no LGPL library could be accepted, wherever or whyever that would be. no, it's the gpl/lgpl3 (as opposed to 2). I'd be one of those not accepting of GPL 3, or it's variations. Google does not accept any GPL variants in Android officially, even though they rely on a few GPL parts for the base OS. Including the Linux kernel. Google does this in Android because Android is not an actual open source project - it's a google project which might or might not be released as open source at any point after a release. The GPL does not allow for software to be released as closed source, that's why google won't allow it in their distribution unless necessary. depends - the copyright holder can do as they please, gpl or not, as only THEY can sue... who? themselves? as for gpl - gplv3 (vs v2) is an issue as it is viral beyond linking and derivative works. it affects the entire os and machine from bootloader or bios even and up. it is avoided like the plague by device manufacturers as a result. For what it's worth, I think I found a GPL3 bit buried deep in the ewebkit dependencies, but I kinda gave up for now after I had gotten several levels deep in dependency hell. I think the plan with ewebkit is to strip out some more dependencies to replace them with EFL bits? That would help, but right now it's a bitch to compile on Ubuntu 10.04. I'll try again later, when there is less dependencies, or after I upgrade to Ubuntu 12.04 later this year. Just because a GPL application is a dependency at some point does not mean it will make the project GPL. You have to explicitly link to it, unless the application itself would include GPL sourcecode unknowingly which would technically make your application GPL. Then again, that's a very rare case and it is specific to the GPL, not the LGPL. but we are talking lgplv3 code compiled directly into the eet lib itself. this makes eet lgplv3 - and v3 requires all sorts of exras beyond eet itself and what may link to eet on a system. That's the danger with GPL 3 on huge projects. The main project might be BSD or something, but buried deep is a GPL 3 component of a sub component of a dependency that no one noticed. Likely coz it was GPL 2 when it went in. Then the entire thing is contaminated. FSF has been painting GPL 2 in a bad light, and swapping licenses on old versions of GNU stuff with out telling
Re: [E-devel] using LZ4 compression tool in eet ?
On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri vincent.to...@gmail.com said: actually forget lz4hc... lgpl3. hey just found that while reading the gnutls ML : http://code.google.com/p/lz4/ it seems that it allows the same ratio for compression than zlib but seems to be by far faster than zlib the memory consumption should be tested too. What do you think ? Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I don't see any problem using an LGPLv3 library. Are there really any changes necessary to make use of it in eet? Also, would it have to be distributed in a way where LGPL parts would actually be packed into an Eet binary or Eet source code? Although I of course can understand that it would not be possible to use Eet in an environment where no LGPL library could be accepted, wherever or whyever that would be. Other than that, would it really be worth it? Even if in the best case the compression is only a little worse than zlib and compression time would be a lot faster - would it really be worth it? Eet usually is used WORM-style (Write Once / Read Many), so compression time is hardly an issue - but if decompression is not significantly faster (or even slower?), and file size is larger (thus I/O, which more often than not is a bottle-neck nowadays, being lower) you'd actually not gain anything but lose run-time performance instead. On the lz4hc page I only spotted compression benchmarks, nothing about decompression - if basic information is missing, there usually is a reason. If anything, what would make sense for Eet would be the XZ format, using LZMA. Compared to zlib, compression is a lot slower, but decompression is not much slower - and compression ratio and through that I/O throughput a lot higher. XZs liblzma is LGPLv2.1 though. Lastly: why would it be trouble supporting additional compression methods? Eet uses file format versions in the binary, right? Why not have features supported starting from a certain format version? Sure, that would make old files incompatible but would this really be an API-break? As I see it it would just mean newer files, or programs using newer files, would have to depend on a newer minor release of Eet without any actual API changes (in any case though it is an ABI change for the Eet files I guess). A way to do such a change might be having a new major release for it and default to the old zlib compression, so users who require for example XZ support can depend on it properly and not risk producing files nobody can use, for no reason. ~thomasg -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Mon, Apr 23, 2012 at 3:05 PM, thomasg tho...@gstaedtner.net wrote: On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri vincent.to...@gmail.com said: actually forget lz4hc... lgpl3. hey just found that while reading the gnutls ML : http://code.google.com/p/lz4/ it seems that it allows the same ratio for compression than zlib but seems to be by far faster than zlib the memory consumption should be tested too. What do you think ? Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I don't see any problem using an LGPLv3 library. Are there really any changes necessary to make use of it in eet? Also, would it have to be distributed in a way where LGPL parts would actually be packed into an Eet binary or Eet source code? Although I of course can understand that it would not be possible to use Eet in an environment where no LGPL library could be accepted, wherever or whyever that would be. Other than that, would it really be worth it? Even if in the best case the compression is only a little worse than zlib and compression time would be a lot faster - would it really be worth it? Eet usually is used WORM-style (Write Once / Read Many), so compression time is hardly an issue - but if decompression is not significantly faster (or even slower?), and file size is larger (thus I/O, which more often than not is a bottle-neck nowadays, being lower) you'd actually not gain anything but lose run-time performance instead. On the lz4hc page I only spotted compression benchmarks, nothing about decompression - if basic information is missing, there usually is a reason. If anything, what would make sense for Eet would be the XZ format, using LZMA. Compared to zlib, compression is a lot slower, but decompression is not much slower - and compression ratio and through that I/O throughput a lot higher. XZs liblzma is LGPLv2.1 though. Iirc, xz uses much more memory than zlib, even during decompression Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Mon, Apr 23, 2012 at 03:05:09PM +0200, thomasg wrote: XZs liblzma is LGPLv2.1 though. No, only the fallback support for limited platforms using gnulib is. The rest is PD. Joerg -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] using LZ4 compression tool in eet ?
On Mon, 23 Apr 2012 22:42:22 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 23 Apr 2012 15:05:09 +0200 thomasg tho...@gstaedtner.net said: On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler ras...@rasterman.com wrote: On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri vincent.to...@gmail.com said: actually forget lz4hc... lgpl3. hey just found that while reading the gnutls ML : http://code.google.com/p/lz4/ it seems that it allows the same ratio for compression than zlib but seems to be by far faster than zlib the memory consumption should be tested too. What do you think ? Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I don't see any problem using an LGPLv3 library. Are there really any changes necessary to make use of it in eet? Also, would it have to be distributed in a way where LGPL parts would actually be packed into an Eet binary or Eet source code? there i a problem because we'd have to compile it into eet - which would make eet lgpl3. gpl and lgpl3 are also highly propblematice in terms of acceptance. they are controversial at best. Although I of course can understand that it would not be possible to use Eet in an environment where no LGPL library could be accepted, wherever or whyever that would be. no, it's the gpl/lgpl3 (as opposed to 2). I'd be one of those not accepting of GPL 3, or it's variations. Google does not accept any GPL variants in Android officially, even though they rely on a few GPL parts for the base OS. Including the Linux kernel. For what it's worth, I think I found a GPL3 bit buried deep in the ewebkit dependencies, but I kinda gave up for now after I had gotten several levels deep in dependency hell. I think the plan with ewebkit is to strip out some more dependencies to replace them with EFL bits? That would help, but right now it's a bitch to compile on Ubuntu 10.04. I'll try again later, when there is less dependencies, or after I upgrade to Ubuntu 12.04 later this year. That's the danger with GPL 3 on huge projects. The main project might be BSD or something, but buried deep is a GPL 3 component of a sub component of a dependency that no one noticed. Likely coz it was GPL 2 when it went in. Then the entire thing is contaminated. FSF has been painting GPL 2 in a bad light, and swapping licenses on old versions of GNU stuff with out telling people. I think that's despicable. FSF may be good for their Four Freedoms, but they take away an important freedom with everything they touch. I have seen GPL stifling innovation in large projects. And this is precisely why, we may not use this new compression thing just coz we want EET to be BSD, and not be forced to make it GPL. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] using LZ4 compression tool in eet ?
hey just found that while reading the gnutls ML : http://code.google.com/p/lz4/ it seems that it allows the same ratio for compression than zlib but seems to be by far faster than zlib the memory consumption should be tested too. What do you think ? Vincent -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
