[FRIAM] BitCoin mining by visiting your site!
I'm too noob to really understand this http://tidbit.co.in/ .. but I believe it uses a way of using visitors to your web site to mine BC for you. Fascinating world BC is throwing us into! I used to think we should give away inexpensive computers to folks if they could care for them: power, internet, and a small partition for our use. Creates a sort of p2p Amazon Web Services. This clearly is a nice variation on the theme, which for them draws customers who want to remove adds from their site and instead borrow computrons from visitors. -- Owen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: NTY: Buy Apple gadgets, use Google services, buy media from Amazon
What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power. In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly. In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality. Ray Parks Consilient Heuristician/IDART Program Manager V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 NIPR: rcpa...@sandia.gov SIPR: rcpar...@sandia.doe.sgov.gov (send NIPR reminder) JWICS: dopa...@doe.ic.gov (send NIPR reminder) On Feb 13, 2014, at 2:40 PM, glen wrote: TL;DR -- but you asked... Well, I was being purposefully provocative, of course. When serious, I advocate agnosticism. Use everything as often as you can. For me, it's less about diversity and more about core skills. In my experience (which is admittedly peculiar), the primary skill is the ability to try something out, figure out the basic use cases, then move on to the next tool. If your purpose is to get something done, then use the first tool you try/learn that actually works. Do the job; move on. If, however, your purpose is to understand, then use as many tools as you can, taken to the extent of some predefined test. RE: platforms. It seems to me platforms are primarily a way to avoid learning, especially the more closed they are. Ease of use is the bogey man. It's the scapegoat upon which all platform closures hang their debt to society. This is why I cringe when I hear things like They [Apple's devices] are also the easiest to learn to use and the most durable. This is antithetic to what I would teach a child. If you always/only use the easiest tools to use, then you're only hurting yourself. And you're setting yourself up to be exploited by nefarious agents. Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've become at least adequate at using the other tools in the same domain. (In fact, anyone who claims something like OS X is the easiest or most intuitive OS is just ASKING to be grilled about, say, the difference between Gnome 3 and Unity. And if they show _any_ hint that they know those aren't operating systems, then we get to grill them on Plan 9 or the Hurd ... or maybe VMS if I'm feeling generous.) My point being that ubiquity = ignorance. If I were to try to write it down, it would read more like a book for kindergarten. Pay attention. Poke everything that looks like it'll do something when you poke it. Don't be afraid to break it. Actually, try to break it. You learn more about a thing by learning what breaks it than by doing what it's supposed to do. (Bending is the real cognitive target, of course. http://www.moogfest.com/circuit-bending) You learn even more if you try to fix it after you broke it. Anyway, my main point is that if you want to survive the next mass extinction event, learn the _domains_ and their use cases. The devices/tools that implement the use cases are interchangeable and largely irrelevant. On 02/13/2014 11:49 AM, Owen Densmore wrote: Good points. But diversity? Do you buy into that? I certainly use services outside of Google. Twitter mainly (have but don't use Facebook) but many forums which are not Google Groups. I try to use cross platform apps where possible. Sublime, for example, as a text editor. Chrome/Firefox. Terminal w/ standard CLI. Dropbox (mac/windows/linux) for files. iOS apps that are cross platform for the most part, although my cant-live-without-it Italian dictionary is iOS only and they tell me that it's the best choice for their market. Possibly iOS folks are more willing to pay? They seemed sincere. The article was about survival in a limited extent: how to deal with being jerked around by the demise of a popular service or platform. How do you deal with it? Could you teach a non-techie to follow your lead? Would write down a simpler set of rules that are easy to follow? -- ⇒⇐ glen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com smime.p7s Description: S/MIME cryptographic signature FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: NTY: Buy Apple gadgets, use Google services, buy media from Amazon
On 02/17/2014 09:39 AM, Parks, Raymond wrote: In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality. Precisely. An additional point, though, is that survival across infrastructure changes is similar to proof through isomorphism. The objective is to establish a kind of Platonic form (or category) for any given set of tools, then whatever tools you find lying about that are close enough to that form will do just fine. (Seriously. E.g. how is bandcamp.com different from amazon.com? Git vs. Mercurial? Pinterest vs. Instagram? Boinc vs. Tidbit? Cloud Foundry vs. Heroku? Etc.) Of course, to think this way is antithetic to what the hyperbole machines out there want you to think. I attribute the hype mostly to the venture capitalists and their desire for 10-fold RoI exits (or at least the consumerist product differentiation that drives our economy). But it could easily be caused by the same thing that causes our 2 party political system, something like an addiction to convenient pigeon-holing. -- ⇒⇐ glen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] BitCoin mining by visiting your site!
On 02/17/2014 10:31 AM, Owen Densmore wrote: I'm too noob to really understand this http://tidbit.co.in/ .. but I believe it uses a way of using visitors to your web site to mine BC for you. They say 20k hashes/client. For comparison, a small ASIC miner will do 500,000 times that a second. In a few months it will be almost another factor of 10 or so per unit cost. That's a lot of customers, and ultimately a big waste of energy. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: NTY: Buy Apple gadgets, use Google services, buy media from Amazon
On 2/17/14 10:39 AM, Parks, Raymond wrote: What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power. In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly. In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality. My mystical version of this is that while it *is* Turtles all the way Down, it is worth knowing the names of the Turtles. I don't honestly expect people to do their development using rod logic but it might behoove any self-respecting hacker to actually understand how such a thing *might* be done... just as Assembly/Machine language is a useful lower-level abstraction for understanding the basis for early HLL's like Fortran IV and ultimately Block Structured (F77 and C?) and then OO (C++/ObjC/Java/etc.)? One *needn't* be proficient in these lower levels of abstraction, just *appreciative?* of how to get from one to another? I'm just sayin' Ray Parks Consilient Heuristician/IDART Program Manager V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 NIPR: rcpa...@sandia.gov mailto:rcpa...@sandia.gov SIPR: rcpar...@sandia.doe.sgov.gov mailto:rcpar...@sandia.doe.sgov.gov (send NIPR reminder) JWICS: dopa...@doe.ic.gov mailto:dopa...@doe.ic.gov (send NIPR reminder) On Feb 13, 2014, at 2:40 PM, glen wrote: TL;DR -- but you asked... Well, I was being purposefully provocative, of course. When serious, I advocate agnosticism. Use everything as often as you can. For me, it's less about diversity and more about core skills. In my experience (which is admittedly peculiar), the primary skill is the ability to try something out, figure out the basic use cases, then move on to the next tool. If your purpose is to get something done, then use the first tool you try/learn that actually works. Do the job; move on. If, however, your purpose is to understand, then use as many tools as you can, taken to the extent of some predefined test. RE: platforms. It seems to me platforms are primarily a way to avoid learning, especially the more closed they are. Ease of use is the bogey man. It's the scapegoat upon which all platform closures hang their debt to society. This is why I cringe when I hear things like They [Apple's devices] are also the easiest to learn to use and the most durable. This is antithetic to what I would teach a child. If you always/only use the easiest tools to use, then you're only hurting yourself. And you're setting yourself up to be exploited by nefarious agents. Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've become at least adequate at using the other tools in the same domain. (In fact, anyone who claims something like OS X is the easiest or most intuitive OS is just ASKING to be grilled about, say, the difference between Gnome 3 and Unity. And if they show _any_ hint that they know those aren't operating systems, then we get to grill them on Plan 9 or the Hurd ... or maybe VMS if I'm feeling generous.) My point being that ubiquity = ignorance. If I were to try to write it down, it would read more like a book for kindergarten. Pay attention. Poke everything that looks like it'll do something when you poke it. Don't be afraid to break it. Actually, try to break it. You learn more about a thing by learning what breaks it than by doing what it's supposed to do. (Bending is the real cognitive target, of course. http://www.moogfest.com/circuit-bending) You learn even more if you try to fix it after you broke it. Anyway, my main point is that if you want to survive the next mass extinction event, learn the _domains_ and their use cases. The devices/tools that implement the use cases are interchangeable and largely irrelevant. On 02/13/2014 11:49 AM, Owen Densmore wrote: Good points. But diversity? Do you buy into that? I certainly use services outside of Google. Twitter mainly (have but don't use Facebook) but many forums which are not Google Groups. I try to use cross platform apps where possible. Sublime, for example, as a text editor. Chrome/Firefox. Terminal w/ standard CLI. Dropbox (mac/windows/linux) for files. iOS apps that are cross platform for the most part, although my cant-live-without-it Italian dictionary is iOS only and they tell me that it's the best choice for their market. Possibly iOS folks are more willing to pay? They seemed sincere. The article was about survival in a limited extent: how to deal with being jerked around by the demise of a popular service or platform. How do you deal with it? Could you teach a
Re: [FRIAM] [EXTERNAL] Re: NTY: Buy Apple gadgets, use Google services, buy media from Amazon
On Feb 17, 2014, at 9:39 PM, Steve Smith sasm...@swcp.com wrote: On 2/17/14 10:39 AM, Parks, Raymond wrote: What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power. In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly. In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality. My mystical version of this is that while it *is* Turtles all the way Down, it is worth knowing the names of the Turtles. I don't honestly expect people to do their development using rod logic but it might behoove any self-respecting hacker to actually understand how such a thing *might* be done... just as Assembly/Machine language is a useful lower-level abstraction for understanding the basis for early HLL's like Fortran IV and ultimately Block Structured (F77 and C?) and then OO (C++/ObjC/Java/etc.)? One *needn't* be proficient in these lower levels of abstraction, just *appreciative?* of how to get from one to another? I'm just sayin’ I’m in violent agreement. While someone can drive a car without being an auto mechanic, I can’t really understand why anyone who drives a car wouldn’t want to at least understand the basics of internal combustion engines, automatic/manual transmissions, hybrid powertrains, and so on. Same with microprocessors, compilers, assembly language, high level languages, lambda calculus. I think that being a hacker is a state of mind that naturally wants to tear things apart to see how they work, and (hopefully) put them back together again. Maybe even put something new together just for the heck of it. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: NTY: Buy Apple gadgets, use Google services, buy media from Amazon
On 2/17/14 7:54 PM, Gary Schiltz wrote: I think that being a hacker is a state of mind that naturally wants to tear things apart to see how they work, and (hopefully) put them back together again. Java is an example of a language that can be compiled to be fast. When Java isn't fast in the wild, various accusations get made like the garbage collector is to blame (i.e. some other factor supposedly out of that person's control that isn't just their own sloppy work and laziness -- like, say, _making_ lots of garbage). Of course, the individual who is really to blame is the sort of person that does not have the mindset you mention. Nonetheless, Java is often`for' the person that wants to be insulated from things, and is happy to work that way. It's not about paying dues, or learning the right things or the right way or bollocks like that. It's about whether a developer insists to be able to find answers when they ask questions about how things work, and whether they are the sort of person that asks those questions at all. Developer communities that _like_ their constraints may be productive by some measures, but IMO aren't, in the end, very interesting. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: NTY: Buy Apple gadgets, use Google services, buy media from Amazon
What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power. Well, I dunno. Several points along these lines. - What is foundational for one is not foundational for another. As an example, for drum music, I may worry a great deal about the welds on the tacks, the speed of sound in the wood, distribution of force laterally in a drum shell, various details about adhesives and even what they fed the cow that supplied the cowhide, but that doesn't necessarily make me a better drummer than somebody worried about kinesthesiology of the forarm and shoulder and how it relates to the mass and dimensions of their drumsticks. - Knowing too well what is apparently foundational may prevent you from innovating. For example in wood joinery instead of cutting biscuits, I may know enough about epoxy strength to design a situation in which a bead of epoxy is its own biscuit and thus make a stronger joint that I would be able to if I had kept to wood joinery fundamentals. - The ability to perform a task at all depends on the capabilities at hand. In the power tool example, losing electricity does not necessarily mean one can effectively fall back to hand tools. It such a case it may no longer be economical to perform the task at all, given alternatives. - Then there's time. One could of course say that flint knapping an obsidian hand axe from scratch will make you more proficient with a hand chisel.At some point one has a task to do, a time constraint, and a power planer at hand. That said, yes, its good to know some hand drafting before you get into CAD. But fundamentals and foundations can be slippery concepts. Carl On 2/17/14, 10:39 AM, Parks, Raymond wrote: What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power. In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly. In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality. Ray Parks Consilient Heuristician/IDART Program Manager V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 NIPR: rcpa...@sandia.gov mailto:rcpa...@sandia.gov SIPR: rcpar...@sandia.doe.sgov.gov mailto:rcpar...@sandia.doe.sgov.gov (send NIPR reminder) JWICS: dopa...@doe.ic.gov mailto:dopa...@doe.ic.gov (send NIPR reminder) On Feb 13, 2014, at 2:40 PM, glen wrote: TL;DR -- but you asked... Well, I was being purposefully provocative, of course. When serious, I advocate agnosticism. Use everything as often as you can. For me, it's less about diversity and more about core skills. In my experience (which is admittedly peculiar), the primary skill is the ability to try something out, figure out the basic use cases, then move on to the next tool. If your purpose is to get something done, then use the first tool you try/learn that actually works. Do the job; move on. If, however, your purpose is to understand, then use as many tools as you can, taken to the extent of some predefined test. RE: platforms. It seems to me platforms are primarily a way to avoid learning, especially the more closed they are. Ease of use is the bogey man. It's the scapegoat upon which all platform closures hang their debt to society. This is why I cringe when I hear things like They [Apple's devices] are also the easiest to learn to use and the most durable. This is antithetic to what I would teach a child. If you always/only use the easiest tools to use, then you're only hurting yourself. And you're setting yourself up to be exploited by nefarious agents. Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've become at least adequate at using the other tools in the same domain. (In fact, anyone who claims something like OS X is the easiest or most intuitive OS is just ASKING to be grilled about, say, the difference between Gnome 3 and Unity. And if they show _any_ hint that they know those aren't operating systems, then we get to grill them on Plan 9 or the Hurd ... or maybe VMS if I'm feeling generous.) My point being that ubiquity = ignorance. If I were to try to write it down, it would read more like a book for kindergarten. Pay attention. Poke everything that looks like it'll do something when you poke it. Don't be afraid to break it. Actually, try to break it. You learn more about a thing by learning what breaks it than by doing what it's supposed to do. (Bending is the real cognitive target,
