Re: [PD] Legal restrictions for apps
On 02/05/2014 08:56 PM, Simon Wise wrote: On 06/02/14 00:36, Dan Wilcox wrote: Short answer: yes, it's sufficient to provide the object files and static libs As far as my understanding of GPL LGPL goes, you do not need to publish your app sources when using LGPL libraries as the Lesser part of the LGPL allows for distribution and is not viral. yes, though 'viral' is a misleading term ... the GPL does not, cannot, change any license for any other code, it is not infectious. The GPL is certainly more restrictive (regarding re-distribution, not use, of the code covered) than for example the BSD or LGPL. It restricts the right to distribute/propagate as part of a larger work to works where the whole of the source code of that work is made available for reuse, modification and re-distribution either under the GPL or in any less restrictive way. In the second case the GPLed code would no longer be licensed for distribution (and would have to be replaced or dropped or a different license negotiated with its copyright owners) if the work as a whole was modified and distributed with a more restrictive license. Whether this is useful or not has been very widely debated. There are two debates. One is between devs who license their code with the GPL and devs who license their code with 3-clause BSD. Both share what they make with the world. Both keep publicly auditable databases of the changes to the software. Both encourage smart, safe ways to design and maintain software and operating systems. BSD devs notice that when they share with GPL devs, the GPL devs say, Thanks. But when the BSD devs try to use what the GPL devs write they have to fuss with the license. This is because the GPL essentially puts the golden rule into the license, whereas the BSD devs have a minimal license (probably as minimal as a license can be) and just follow the golden rule as human beings. There are good reasons for both camps to do what they do, but it ends up requiring the BSD folks to care more about licenses than they'd like-- their license is only 3 clauses, after all! So the BSD camp complains that when the GPL devs (like Linux Kernel devs) improve on code that was originally BSD, it comes back to the BSD folks infected with the GPL license which requires them to then care about licenses. This is where the viral taunt comes from-- a genuine argument between two camps, both sharing what they make with everyone else to encourage a free and safe software ecosystem. Another debate is between any company that produces proprietary software and a straw man in a corn field. Here viral is irrelevant because the company isn't giving improvements back to the community. Unfortunately this is probably what first pops to mind when people hear this argument-- that, somehow, the GPL can infect the business of selling a product and make it impossible for a company to make money. But for better or for worse, we don't even need to consider minimal moral principles. It's demonstrably dangerous to rely on software that doesn't have a pubic codebase and revision history. (Unfortunately I think it's for the better since most devs seem allergic to stating minimal moral principles.) -Jonathan The motivation for the GPL is stated in the license and the LGPL was written to cover some cases where the authors considered a less restrictive license useful. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] cryptocurrency and pd
Has anything been done to try to marry these together yet? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
In what way? You should theoretically be able to visualize a proof-of-work block-chain as a dataflow diagram, for example. But generally speaking, Pd doesn't seem like it can offer much since it would be quite slow to do hashes or cryptographic functions. -Jonathan On Thursday, February 6, 2014 4:09 AM, i go bananas hard@gmail.com wrote: Has anything been done to try to marry these together yet? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
In what way? that's what i want to know! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
Hi, i go bananas wrote: In what way? that's what i want to know! If that's a general question, then the answer is yes, as you can get and send bytes over a network and do math with pd. It's also the answer for all general questions like can I do something a computer does with pd ? It does not mean it fits you needs, or the amount of work you want to put in :). Not giving contexts does not lead to useful answers. So, do you have something in mind ? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
On 02/06/2014 11:03 AM, i go bananas wrote: In what way? that's what i want to know! I don't know the specifics, but I think both cryptography and finance are areas where the feature of everything is a float actually gets in the way. In either case you cannot afford to lose precision. But you can prototype some of the features of a cryptocurrency in Pd. For example, Bitcoin uses the hashcash algorithm to verify each block of the transaction database. (If I understand it correctly it's like brute-forcing SHA256 keys, although they never completely succeed.) The miners basically start a counter, do a mathematical function on the value plus the previous value from the last entry in the transaction database, and finally check if the output has a certain number of leading zeros. If you ignore for the moment the counter and the mathematical function, you can see how the process works. Attached is a patch that just keeps spitting out pseudo-random numbers between 0 and 1 until all of the [random] objects happen to output zeros. It's essentially like a slot machine that keeps playing until you win. Now notice that when you hook up another [random] to the chain you double the average time it takes to find a winner. Add enough [random] objects to the chain and you will quickly hit a point where you can't compute a winner at all (even if you change the patch to compute answers as fast as possible). Bitcoin's block difficulty uses the same principle. The software has a hardcoded rule that it should take 10 minutes to find a winner. But instead of using a bunch of binary values, it uses a single number and requires the winner to be below a certain value (which is equivalent to counting the leading zeros in the representation of the number). Over a certain number of days it measures the average time it takes the network to compute a winner. If it's way less than 10 minutes on average then the software automatically does the equivalent of adding a [random] to the patch to make it twice as hard. If it takes too long then the software removes a [random]. The actual algo is probably more sophisticated but that's what it boils down to. Now, let's say you hook up 50 [random] objects in that patch and happen to find a winner. That'd be pretty spectacular, but how do you convince everyone that you are being truthful about your claim? This is where the hashing function and the counter come into play. Instead of the attached patch, imagine a [hash] abstraction that takes a counter value in the left inlet and the previous transaction hash in the right inlet. It will output a seemingly unrelated number in response to the input, but that number will be unique to the input you give it (or so close to unique that we can just call it unique). That's what a hashing function does. So you essentially do the same thing you did above, except you're looking for leading zeros in a single number rather than the collective output of a bunch of [random] objects. When you hit a winner you then broadcast your counter value and the new transactions to the rest of the network to add to the database. The rest of the network already has the previous entries in the transaction database, so they can take those with your counter value and verify that the resulting hash actually has the correct number of leading zeros. Then everyone starts working on the next winner. And why do they do that instead of trying to lie and say they were the one that actually found the winner? Because the first new transaction in the database is the real winner giving 50 bitcoins to themselves, and that transaction uses public key cryptography to ensure that it can't be forged or changed. One last thing-- the hashing function is designed so that it's extremely difficult (read: impossible) to start with a hash value that has the required number of leading zeros and work backwards to figure out the right counter value. Like a slot machine, you have to just keep trying until win. And just like a slot machine, if someone can figure out how get a winner without putting in the same work/money everybody else does, then the entire system breaks down. -Jonathan #N canvas -9 19 708 498 10; #X obj 176 44 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 176 65 metro 50; #X obj 176 172 random 2; #X obj 178 218 +; #X obj 246 172 random 2; #X obj 316 172 random 2; #X obj 178 255 +; #X obj 178 446 moses 1; #X obj 46 99 t a; #X obj 386 172 random 2; #X obj 178 286 +; #X obj 456 172 random 2; #X obj 526 172 random 2; #X obj 176 86 t b b b b b b b; #X obj 596 172 random 2; #X obj 178 327 +; #X obj 178 368 +; #X obj 178 413 +; #X text 356 114 connect more to increase the difficulty; #X text 358 271 ... and connect them here \, too; #X obj 46 137 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X connect 0 0 1 0; #X connect 1 0 13 0; #X connect 2 0 3 0; #X connect 3 0 6 0; #X
Re: [PD] cryptocurrency and pd
On 02/06/2014 02:08 PM, Charles Goyard wrote: Hi, i go bananas wrote: In what way? that's what i want to know! If that's a general question, then the answer is yes, as you can get and send bytes over a network and do math with pd. It's also the answer for all general questions like can I do something a computer does with pd ? It does not mean it fits you needs, or the amount of work you want to put in :). Not giving contexts does not lead to useful answers. That's a self-fulfilling prophecy. It also turns out to be wrong, because I made another self-fulfilling prophecy which turns out to be useful. -Jonathan So, do you have something in mind ? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] declare and abstraction (cont.)
hi miller, thanks for investigating this 'problem'. my patch is randomly reading wav's from a library(=folder). for that it needs first to find out what's in the folder. which is done with [moocow/readdir]. (i don't know another way) to give [readdir] the right directory i was using ../sounds. this doesn't work when Pd is started first. with [getdir] i hoped to have a workaround. however [getdir], following Pd, gives different answers, depending whether a [declare -path .] is used or not. strange enough (?) using ./sounds seems to work ok. it would mean to put the folder with wav's inside the patch folder. which of course isn't a very elegant solution. ciao, rolf Miller Puckette m...@ucsd.edu schreef: OK... but I don't see any problem there - 'empty' gets saved to the correct place, just with a different spaling of the file path, correct? I thought the original problem was in not being able to load a soundfile from a 'declared' folder somehow. cheers Miller On Wed, Feb 05, 2014 at 12:11:09PM +0100, ro...@dds.nl wrote: hi miller here's the zip i'm on Windows 7 ciao,rolf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
On 06.02.2014 10:09, i go bananas wrote: Has anything been done to try to marry these together yet? PuREST JSON includes a sonification for Bitcoin values going back to 2011, but I guess, that is not what you wanted to know. Thanks, Thomas -- We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.' (Dennis Ritchie) http://www.residuum.org/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
On 07/02/14 09:56, Thomas Mayer wrote: On 06.02.2014 10:09, i go bananas wrote: Has anything been done to try to marry these together yet? PuREST JSON includes a sonification for Bitcoin values going back to 2011, but I guess, that is not what you wanted to know. it sounds the more likely kind of dsp/bitcoin marriage, otherwise perhaps a pd concert with the ticket price in bitcoin??? simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
Pd or otherwise, I'd be very careful about sending any messages back and forth with the actual Bitcoin network. By doing so you are essentially telling the internet that fungible, irreversible tokens might exist on your machine, the value of which could far exceed anything that you have ever or will ever store on your computer. Also, blockchain.info likes to store the IP of the first node that told it about a transaction. It's pretty well connected, so if you make a transaction from your machine your IP is very likely associated forever with that transaction. (Just one of many ways in which Bitcoin is not anonymous.) But of course if you happen to be in Sochi then everything of value on your machine has already been stolen, so knock yourself out. :) -Jonathan On Thursday, February 6, 2014 5:59 PM, Thomas Mayer tho...@residuum.org wrote: On 06.02.2014 10:09, i go bananas wrote: Has anything been done to try to marry these together yet? PuREST JSON includes a sonification for Bitcoin values going back to 2011, but I guess, that is not what you wanted to know. Thanks, Thomas -- We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.' (Dennis Ritchie) http://www.residuum.org/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
