Notes on debugging Clojure code - <AUTHOR> http://eli.thegreenplace.net/2017/notes-on-debugging-clojure-code/ <comment><USER2> A few more tricks:

\- CIDER, the de-facto Clojure environment for Emacs, has a debugger[1]. This is also true for some of the larger IDEs, like Cursive.

\- Timbre[2] has a number of cool debugging macros, especially spy, which you can tack onto any expression and it'll log it for you. Very useful, similar to the macro in the post, except you don't have to write it :)

I really can't overestimate how valuable a real REPL-driven development environment is.

[1]: [https://github.com/clojure- emacs/cider/blob/master/doc/debug...](https://github.com/clojure- emacs/cider/blob/master/doc/debugging.md) [2]: [https://github.com/ptaoussanis/timbre](https://github.com/ptaoussanis/timbre)

<comment><USER3> I find debugging + error messages to be the worst part of Clojure.

In CIDER I have to mark my functions as debuggable before I can step into them - this is an odd requirement and a PITA when the functions are spread out through the codebase. It's so easy to accidentally commit a non-debuggable version as well.

Cursive is a lot better and more modern, with one painful problem: no proper support for 'break on exception'. So on exception the program just closes and I'm just left with a stacktrace in the console. You can turn on 'Java Exceptions', but this has multiple problems:

1\. On load of Clojure files there is a ton of Java exceptions thrown, literally making it unusable

2\. and if you disable those exceptions in the Condition field the boot up process takes _forever_ to actually run (likely because it's interpreting the Condition field code over and over and over again..).

Any good solutions to these?

<comment><USER4> >In CIDER I have to mark my functions as debuggable before I can step into them - this is an odd requirement and a PITA when the functions are spread out through the codebase. It's so easy to accidentally commit a non-debuggable version as well.

When I'm connected to my repl, I often want to debug things I didn't mark as debuggable (hint: nothing is ever debuggable by default). I can jump to definition, toggle debugging, and then run some code (usually from a comment block or my scratch/user.clj (gets excluded by gitignore)). When I'm done, I can toggle it off or simply re-eval the function. In spacemacs, the normal mode binding for this is

        , d b

</comment></comment></comment><comment><USER5> After being Clojure-only for a long time, I decided to write the front end to my last project in Elm, just to see what the fuzz was about.

While I miss code-is-data very much, there is no turning back from the type system and how there are no unpure functions. It is just so mind-blowingly easy to catch almost every bug I would usually write.

I'm afraid this is the point where I should try Haskell, and be unsatisfied for the rest of my professional life.

<comment><USER6> You should definitely try, even if you end up being somewhat unsatisfied every time you have to use something else.

When I write code in Haskell, it feels right, just like when I discovered Lisp. Only better. And oh, the purity! Not only in the mathematical sense, even the code is completely deprived of clutter.

<comment><USER7> But at what cost!? Every time I write Haskell code it reads like a mathematical proof that's beyond my ability to comprehend! Whereas my Ruby, Python, and Clojure programs read like a poem I might have written in third grade.

<comment><USER6> I don't think Haskell code looks like this. You don't have to use all the guru syntactic sugar; the library functions usually have pretty explicit names, and yours should have to.

</comment></comment></comment></comment><comment><USER8> Another trick is to define temporary inline vars. If I have some Ring handler, it can be quite annoying to construct a request by hand. Instead, I can do something like:

        (defn foo-handler [{{:strs [authorization]} :headers :as req}]
          (def *req req)
          (def *auth authorization)
          ...)

Then fire off a request in my browser and simply proceed to play around with `req` and `auth` in my editor/REPL, which is where I am running my local server from.

<comment><USER9> This is a terrible advice, and is not even necessary. Even println debugging is better than this. Not only defs are abused contrary to their intended use, they are difficult to distinguish from legitimate defs, and thus some may (and will!) slip away into the wild.

<comment><USER8> > Even println debugging is better than this.

Print debugging is great. A carefully placed print statement is something many great programmers swear by [1], despite the existence of "sophisticated" debuggers (see footnote in OP). This is a complement to this when you want to play around with the data directly.

> Not only def's are abused contrary to their intended use, they are difficult > to distinguish from legitimate defs, and thus some may (and will!) slip away > into the wild.

Never been an issue for me. It's just an extension and morphing of playing around with data in a standalone REPL. The temporary defs are never used in actual code logic, the prefix character makes it clear it is purely for exploration. Is it a dirty hack? Yes, but one might argue that's partly what Lisp is too: _The most intelligent way to misuse a computer_ \- Dijkstra (paraphrasing) Lisp

Some unsolicited feedback: you might want to consider that there is more than one way to skin a cat. If you want to understand the trade-offs of solutions people find, you might find it useful to not dismiss solutions outright. Especially something as universally useful like print debugging, considering how many people use it. Instead, a more useful question to ask yourself is: why do experienced programmers use print debugging when they are aware of the existence of debuggers? That might expand your worldview, as opposed to categorizing these people as "doing it wrong". See _Worse is Better_ etc.

1: From this lovely quote by Brian Kernighan: _The most effective debugging tool is still careful thought, coupled with judiciously placed print statements._

<comment><USER10> Why not define debug-req and debug-auth as atoms before this function, and set them with (reset! debug-req req) etc.?

</comment></comment></comment></comment><comment><USER11> Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar.

Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but...

I just want to learn the language, not the language _and_ an editor that seems entirely alien at the same time. If I _had_ to learn vim as a prerequisite to learning and writing Python (specifically using the debugger and a REPL), I probably would have never learned Python.

<comment><USER12> It makes sense to use Lisp-specific tools with Lisp, otherwise the whole experience is underwhelming. The best Lisp tools are usually written in itself or some variant of it.

On the Mac you can download Clozure Common Lisp from Apple's Macintosh application store:

[https://itunes.apple.com/us/app/clozure- cl/id489900618?mt=12](https://itunes.apple.com/us/app/clozure- cl/id489900618?mt=12)

It comes with a small IDE written in itself.

A lot of people who use CL as a serious hobby or for work use one of the commercial development environments: Allegro CL or LispWorks.

There are several other (some are obscure) options, but many use GNU Emacs / Slime or its fork Sly.

<comment><USER13> I would love a proper "hobbyist" priced license for a full 64-bit LispWorks at around $200.

Stephen Wolfram did it for Mathematica (Home license)...

<comment><USER12> The LispWorks 64bit hobbyist license costs 600 Euro. It is not tied to a single machine and can run more then one process.

</comment></comment></comment></comment><comment><USER14>
      When it comes to debugging, I'm firmly in the printf camp; I rarely prefer debuggers over printf-based debugging

I'm struggling to understand this. Why would you ever prefer printf debugging in your local dev environment over using a debugger?

<comment><USER15> Language and environment independent. It just works. It's like IDEs -- so many people spend so much time writing and learning IDEs specific to a language rather than just picking a standard text editor that can be used for any language on any platform.

<comment><USER16> Yeah this. Does this thing colour parenthesis and stdlib builtins? We're good to go.

</comment></comment></comment><comment><USER17> I have years working experience with Clojure. The tooling in Clojure is much better than this. If you want a debugger, Cursive has it out of the box, if you are used to Intellij, you can use it right away. If you are an Emacs user, then you know your way around CIDER and its tooling. It's not that I don't agree with the author's post. But I mean for simple functions, good enough tooling and unit tests are your friends.

</comment><comment><USER12> I fear Lisp had already a better debugging experience in the mid to late 60s...

<comment><USER9> Clojure also has better debugging experience. This is a bare-bones workflow of a guy who doesn't use the best tools available in Clojure.

<comment><USER18> Could you provide links to this better debugger

<comment><USER18> Found them in other comments, I don't see anything that's native to clojure though, not like pdb is for python at least

<comment><USER4> Debugging, like most things in clojure, is a library. You can view the implementation (as an nREPL middleware) here[1]. It's possible to use this debug middleware from any random nrepl client, but I'm not aware of any that actually implement a command-line debugger such as you get with python's pdb. I suspect, but don't have any time or inclination to verify, that implementing a basic command-line debugger using this library would be a weekend hack. I suspect this debugger is far more useful integrated into your editor than stand-alone since clojure isn't really a file/line-oriented language (which would make selecting forms hard).

[1] [https://github.com/clojure-emacs/cider- nrepl/blob/master/src...](https://github.com/clojure-emacs/cider- nrepl/blob/master/src/cider/nrepl/middleware/debug.clj)

</comment></comment></comment></comment></comment><comment><USER19> Also worth noting that Cider (the most-commonly-used Clojure plugin for Emacs) has had a decent debugger for a couple years: [https://github.com/clojure- emacs/cider/blob/master/doc/debug...](https://github.com/clojure- emacs/cider/blob/master/doc/debugging.md)

Cursive (Clojure for IntelliJ) does too.

</comment><comment><USER20> interesting to see Eli as a famous Python lover started to try Clojure.</comment>


Germany and Tesla's PowerWall - <AUTHOR> http://www.catalyticengineering.com/the-berlin-powerwall/

<comment><USER2> Just an observation that this analysis doesn't include the powerwall's benefit of also providing backup power when the grid is down. It's hard to know how much this would be worth and certainly would vary from home to home.

On the other hand, since Tesla is also selling a battery specifically for grid backup I would assume that they've done some market research into it and this value might be higher than one would think.

<comment> semi-extrinsic > When the grid is down

Historically in Germany (and most of western and northern Europe AFAIK) a blackout is something that happens every ten years and lasts for two hours. It's rare and inconsequential enough that no-one bothers hedging against them.

Wind and solar are increasing the probability of large blackouts, but the proper solution to that is building more nuclear power, eventually transitioning to fusion.

<comment><USER3> > Wind and solar are increasing the probability of large blackouts, but the > proper solution to that is building more nuclear power, eventually > transitioning to fusion.

Can we stop betting on pipe dreams? Fusion isn't proven, and while I'll advocate for continuing research into it, solar, wind, and geothermal is here _today_.

We should be advocating for the installation of solar on every roof, on every brownfield that can't be used for housing or agriculture, wind where ever possible, and geothermal where it makes sense.

It is _silly_ that we continue this nonsense that nuclear (fission today and fusion tomorrow) are our saviors. We have proven, as a species, incapable of properly managing the small risks that nuclear presents.

It takes 10-20 years and over $1 billion US to bring a new nuclear plant online, and this does not take into account the government limiting their liability in the event of an accident. Wind turbine parks and solar fields can be developed in under a year, with fewer (if any!) cost overruns.

<comment><USER4> No reason we can't do both.

Fusion is the ultimate energy generation technology. It _will_ be real soon enough.

Your comment reminded me of Interstellar :-)

</comment></comment></comment></comment><comment><USER5> A few points:

1 - Assuming that the power-wall acquisition costs are already "sunk," I wonder if it could ever make financial sense anywhere to do "power arbitrage." IE buy electricity at cheap off-peak rates and sell it back at peak times.

2 - The existence of those kludgy sell-to-the-grid solar setups is a gift for Tesla. There are so many of them installed and they're pretty much just waiting for a powerwall to come along.

3 - I hope those setups don't crowd out other applications. The obvious one is necessarily off grid installations. There are a lot of off grid setups in the world. They mostly run on generators that smell, make noise and get turned off at night (melting all your ice-cream). Remote homes, hotels, mobile homes, boats... lots. Yachts alone...

This really is a bottleneck product.

<comment><USER3> I'm looking at a powerwall specifically for powering a sailboat, with solar providing the bulk of my power needs with the remainder provided by a diesel generator while underway.

EDIT: After a quick shower, I wanted to come back to expound on this a bit.

I've also wanted to lead a bit more of an independent life on a sailboat, traveling within my home. As an engineer at heart, I've always thought about how to best manage energy to have the top quality of life on a boat with minimal sacrifice. Solar is almost always the way to go, as the sun is usually shining where ever you're at (some folks do go with a wind turbine, but they're unreliable at sailboat scales).

Tesla's PowerWall product enables this. No longer do I have to consider running a generator full time, or having a dangerous amount of lead acid batteries onboard to store enough power to meet my first world standard of living. The more energy I can safely store, the longer I can be aware from a port, not run a generator, or in short, spend money. The less money I spend, the less I have to work a job I don't enjoy or want to (disclaimer: I love technology, I'll always work in it, I just want to be able to always be picky about the jobs I take)

Dense, cheap energy storage enables everyone to better manage their energy use, and energy is what (mostly) drives the world now. Thanks Tesla!

<comment> semi-extrinsic I have good news and bad news.

Bad news: the battery chemistry used in the Tesla PowerWall (Li-ion NCA or NMC) is not safe for marine applications. Only Lithium-iron-phosphate batteries, with lower energy density, are safe for this purpose. Putting a PowerWall on your boat would not only void your insurance, it would carry a real risk of setting your boat on fire.

Good news: there are already several manufacturers that sell lithium battery packs that have been safety tested and approved for marine use. GIYF.

<comment><USER3> I had spoken to my prospective insurance company, and they had assured me a lithium ion chemistry was acceptable for onboard use, even if I choose to use it as part of the power train in a series hybrid setup (this is going in a multi-hull catamaran). I'll have to call them back and get something in writing. Thanks!

<comment> semi-extrinsic No problem. Remember when the entire Boeing 787 fleet was grounded due to li- ion fires - you really really don't want that in your boat. If possible, buy something that's been certified for marine use by an independent safety auditor like Bureau Veritas or similar.</comment></comment></comment></comment></comment>


A suggested improved customer interaction with the Apple Store - <AUTHOR> http://www.hanselman.com/blog/ASuggestedImprovedCustomerInteractionWithTheAppleStoreAndCloudServicesInGeneral.aspx

<comment><USER2> Apple's email was straight forward and to the point (high signal to noise). The "solution" needlessly tacks on boilerplate, and divulges additional information about the user in the email. If someone's iTunes account has been compromised, it is possible that their email account may have been as well. Best not to show too much.

The actionable item in Apple's email is very clear: change my password, and then learn how to be more secure. In the "solution," it is not. You need to "associate [my] new device with [my] Apple ID"? Huh? Do I need to re-register my current device, or what?

I'm all for using Bayesian inference behind the scenes, but don't needlessly flood the user with excess information. Tell them what's up, and what they need to do.

Withholding information could be helpful later, should the user need to verify their identity over the phone (for example).

Sending an email when an account is used for the first time on a new device is not a bad idea, but it could become another hoop for the user to jump through, and again, their email may also be compromised.

</comment><comment><USER3> Apple obviously knew there was something off. Their systems detected an issue. Detecting an intrusion is obviously not a problem, though I do think your suggestions for detection would be nice.

The way it reacted to an intrusion, however is absolutely unacceptable. Simply informing you that you got hacked after it's already happened is not the way it should have dealt with this. Ideally, it would block the purchase, blacklist the IP, then force you to confirm through an email.

Sure, if your email got compromised too, that won't do any good, but at least it would have _tried_ to stop the unauthorized access.

Another nice thing I'd like to see would be something like Google's two-step authentication, where you would have to authorize the new registration via a previously registered device.

<comment><USER4> Sure, my hope is that if they emailed me (NOT at mobile me email, but a non- Apple address) at my Gmail which is setup for 2-factor, for confirmation that'd be ideal.

The irony is that they are all setup for 2-factor auth...the phones I have already _are_ the second factor. The idea that someone, anyone, with a phone and my password could make effectively unlimited purchases against my saved payment instrument without being challenged makes me, as a former banking engineer, cringe.

All I'm asking is that new phones authenticate and be challenged, expecially if they don't match clearly recorded existing behavior patterns.

<comment><USER3> I agree, apple really dropped the ball in this case.

In fact, how did this app manage to slip through the review process? It seems to me that the only purpose is to funnel stolen money to somebody.

Sadly, the state of many online security systems is entirely sub-par. It's a sad sign when your email has more security features than your bank account (as I know is the case for me)</comment></comment></comment>


TechPowerUp:Leaked AI-Powered Game Revenue Model Foretells a Dystopian Nightmare - <AUTHOR> https://www.techpowerup.com/240655/leaked-ai-powered-game-revenue-model-paper-foretells-a-dystopian-nightmare <comment> King-Aaron From the comments:

> The ones of most concern are the fact that the AI can discern whether a > subject is female or not, and then subsequently learn their menstrual cycle > based on the language they used throughout the month and then tailors that > users experience in order to sell them more crap during that cycle.

Now doesn't that just sound lovely.

<comment><AUTHOR> Well add to this the environment mapping using sound and wireless. So we give them our personal data, share our environment, share our bio-metric data. In few words one can completely reconstitute your life without asking you nothing and use these data for purpose you will never know.

The real issue as it was for BTFII, it target also children in young age. So we persecute rapist but not persecute these behaviors that totally rape the point of view and behavior of small infant. Especially if linked to any related games our children play with. If these new AI algorithm work on grown human being, their impact would go even further on infant!

At this point i would prefer my child playing with DUKE NUKEM than the actual modern smartphone/PC games!

<comment> King-Aaron > At this point i would prefer my child playing with DUKE NUKEM than the > actual modern smartphone/PC games!

To be fair, the Duke was superior to pretty much any smartphone game I've come across yet :P

<comment><AUTHOR> I agree, the paradox make me smile. Hence i was said these kind of games were bad for children's. And now look were the gaming industry drive us. This blow completely my mind as gamer fan! ^^

</comment></comment></comment></comment><comment><USER3> This is pretty clearly a hoax. The slides are text-heavy and expository to an unrealistic extent (for a powerpoint anyway) and the language is closer to amateur dystopian sci-fi than a technical presentation.

That said, it is a nice encapsulation of how "A.I." may come to be viewed as a surveillance, advertising and monetization tool.

<comment> King-Aaron I feel there's other things that identify it as a possible hoax - <USER2> screenshots at the start, for instance, seem unfinished - but I've dealt with many powerpoint presentations over the years like this - way too many words for an overhead screen, but these sorts of presentations get shared around quite a bit with the intention of being just read on the computer screen..

<comment><AUTHOR> Still the things explained into this presentation could be potentially true and really used. They are not too much difficult to implement in a real daily basis case. There is a lot of gaming publishers that are focusing on patenting AI algorithm to be used in modern games.

<comment> King-Aaron Correct. I read the slides as more of a draft technology proposal rather than a launch presentation for the product.

</comment></comment></comment></comment><comment><AUTHOR> Telemetry, telemetry and user data mining everywhere!</comment>


Show HN: SponsorBlock – Skip YouTube Sponsorships, Intros, Outros and More - <AUTHOR> I recently released an update adding skip categories, a long wanted feature. My blog post about these changes: https://blog.ajay.app/categories-sponsorblock
Homepage: https://sponsor.ajay.app/ Source Code: https://github.com/ajayyy/SponsorBlock
Previous discussion: https://news.ycombinator.com/item?id=20778926 <comment><USER2> No! Stop!

I've been using SponsorBlock since the last time you posted about it! It's amazing! It works for damn near any YouTube video I wanna watch, it works without any intervention, and it lets me skip past the annoying RAID: SHADOW LEGENDS advertisements.

If you keep posting about this it'll very quickly become popular, and eventually YouTube will obfuscate their code to prevent this extension from working.

<comment><USER3> I'm surprised SponsorBlock didn't blow up on here again. In all seriousness, it's a terrific add-on.</comment></comment>


Faker is a Python package that generates fake data for you - <AUTHOR> http://www.joke2k.net/faker/ <comment><USER2> I made a tool like this for my company in Ruby (it wasn't nearly as mature as this). The largest challenge I struggled with (and never really solved) is that ultimately, there's no way to generate data as useful as real data. The value of real data comes from the fact that it's messy. Real data is different sizes than you expect[1], collides with your sentinel values[2], and comes in with unexpected encodings[3]. And sometimes people will enter data that is intended to break your system[4][5].

The value of testing with real data is that it doesn't conform to your assumptions.

As far as I can tell, this benefit is impossible to fake with a system that generates fake data algorithmically. Generated data conforms to the assumptions of the system that generated it and therefore can only be used to test that a system conforms to those assumptions.

Fake data is still useful. Volume is often important (does your database slow down or crash when there are 10 billion records?). And if your fake data has very few assumptions, you can use that to reduce the assumptions made by the system you're testing.

Nevertheless, I'd really like to see a system like this which integrates data from some sort of general-purpose real dataset. Ideally it would be configurable so that people can document and choose a 99% use case they want to support (for example, a US company might want to support long names, but might not get a ton of value from supporting names with Chinese characters).

[1] [http://jalopnik.com/this-hawaiian-womans-name-is-too-long- fo...](http://jalopnik.com/this-hawaiian-womans-name-is-too-long-for-a- drivers-l-1313683178)

[2] [http://www.snopes.com/autos/law/noplate.asp](http://www.snopes.com/autos/law/noplate.asp)

[3] [http://www.joelonsoftware.com/articles/Unicode.html](http://www.joelonsoftware.com/articles/Unicode.html)

[4] [http://en.wikipedia.org/wiki/Buffer_overflow](http://en.wikipedia.org/wiki/Buffer_overflow)

[5] [http://xkcd.com/327/](http://xkcd.com/327/)

<comment><USER3> I'd suggest looking into fuzzers. Short version - tools designed to input messy, non-conforming data to ensure the inputs don't cause problems, that things are sanitized correctly, etc. At this point they are a mature technology, with improvements constantly being researched. They are generally thought of as security tools[1], but are very useful for basic development too.

[1] The common use of fuzzers in a security context is to send malformed packets to protocol parsers to see if they fall over or cause buffer overruns, or otherwise do fun things in the context of exploiting a system. Another common one being automatic sql-injection discovery tools.

<comment><USER4> A quick search gave me this list: [http://www.infosecinstitute.com/blog/2005/12/fuzzers- ultimat...](http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate- list.html) is there a notable fuzzer missing? It's a pretty long list, does anyone know which of these tools are really worth checking out?

<comment><USER5> That's a pretty old list. Just to name one, I would recommend taking a look of Radamsa

[https://www.ee.oulu.fi/research/ouspg/Radamsa](https://www.ee.oulu.fi/research/ouspg/Radamsa)

...from the Oulu University. It's more like a framework for generating intelligent fuzzers than a shrink-wrapped product, though.

The OUSPG guys are really good at fuzzing. There is also a commercial spin- off, Codenomicon, whose tools are quite widely used.

</comment></comment></comment></comment><comment><USER6> I love faker! It pisses me off a bit that the library is named faker but the package is fake-factory. It trips me up all the time.

I use it with factory_boy ([http://factoryboy.readthedocs.org/en/latest/](http://factoryboy.readthedocs.org/en/latest/)) to generate test fixtures that seem to make logical sense. Usernames are real names, birthdays are real dates, etc.

I think it helps with experimentation when you're using the REPL and also makes bugs stand out a bit more easily. Very neat for demoing purposes too.

Perhaps my favourite is faker.bs() which always gets a giggle when doing live demos.

<comment><USER7> It's probably fake-factory to prevent confusion with the Ruby gem that's been around for more than 6 years [http://www.rubyinside.com/faker-quick-fake-data- generation-i...](http://www.rubyinside.com/faker-quick-fake-data-generation- in-ruby-665.html)

It's a standard gem in the community and it's used for generating various types of seed database data. Don't know if does the exact same things that the Python faker does.

<comment><USER8> I used fake-factory because faker was already busy on pipy. Initially I asked the author to leave the name, but the response was negative.

</comment></comment></comment><comment><USER9> I'm not a huge fan of the 'factory' singleton pattern used here.

I can see how explicit execution of the startup code is a good thing, but can't help thinking how much better the experience would be if it just lazy- loaded the same code.

Am I missing something obvious that would prevent this? Bad magic?

</comment><comment><USER10> Has anyone ever done a project like this that builds test databases from larger production databases? I mean something that can look at a prod db and model the data in the columns and the relationships between tables and produce a much smaller test db that has the same statistical properties? For numeric columns you could just fit a statistical distribution and sample from that. For names I'm thinking you could look at the frequency charts for first, second, third ... letters and sample according to that. I believe it is also called Markov Chains.

In Andrew Ng's Machine Learning class he talked about taking labeled images and expanding the set by inverting, shearing, flipping, distorting them etc. He called the technique 'data synthesis'.

The test data problem has been hampering my team's ability to create maintainable automated tests.

<comment><USER11> I've been working on such a project for a couple years as a solo/on-the-side thing. It's not available as a turnkey product yet, but the technology is working and can build arbitrary amounts of realistic test data (based either on your private data sets, or public sources like census data). I'd love to begin working with others on how exactly to integrate this into their test and development workflows. Email me at email@example.com if you'd like discuss further.

</comment></comment><comment><USER12> After quick look it seems that this is only poor randomizer. Good generator generates data which isn't too random and internal correlations and ranges are right.

I used to maintain one over 15 years ago.

At least City Street address post number and telephone had to be internally linked. Those are things that can be easily and automatically checked. So those constraints need to be checked also when generating data. It's also silly to give flat address on area where there aren't any flats etc. 30th floor on country side? Oh yeah. Distance based address downtown. As silly.

</comment><comment><USER13> The name looked familiar and it's indeed inspired by the Faker library for PHP: [https://github.com/fzaninotto/Faker](https://github.com/fzaninotto/Faker)

Another interesting library that is build on top of Faker is Alice. It allows you to define complex fixtures in .yml: [https://github.com/nelmio/alice](https://github.com/nelmio/alice)

<comment><USER14> Aren't they all kind of inspired by the original Perl implementation? I use the Ruby one for testing.

Something kind of similar and worth thinking about is this:

[http://en.wikipedia.org/wiki/QuickCheck](http://en.wikipedia.org/wiki/QuickCheck)

<comment><USER15> I was just about to comment the same thing about QuickCheck. Arbitrary data galore.

I've only done serious work with QuickCheck in Haskell but here's the python implementation I've played with: [https://pypi.python.org/pypi/pytest- quickcheck/](https://pypi.python.org/pypi/pytest-quickcheck/)

</comment></comment></comment><comment><USER16> I've got a semi-similar python library that I've been adding to for a few years called testdata: [https://github.com/Jaymon/testdata](https://github.com/Jaymon/testdata)

testdata has a lot of unicode and file system stuff I've found really useful, it looks like between this and testdata I'll be in generated data heaven :)

</comment><comment><USER17> I've used the Ruby version of Faker to do fuzz/property/quickcheck-style testing in Ruby. I believe this to be an incredibly important, under- recognized form of testing. Faker is not the best tool for this as you really need more sources of randomness than it provides, but it's not a bad start.

The best places to learn are from the canonical libraries, quickcheck in Haskell, Quviq in Erlang, simple-check in Clojure, and there are others.

The challenge with all of these methods is that you want some notion of referential transparency in order to make useful properties. You can at least do that in certain contexts for certain expressions in Ruby and doing so will improve code readability.

I'd love to hear from others with experience using these techniques in Ruby or Python.

</comment><comment><USER18> Testing data serves multiple purposes. Boundary conditions (long fields, unicode etc) is important for invalidation testing. (i.e. Testing to break your code and functionality)

Testing at scale is important for performance and predicting bottlenecks as you grow. (i.e. Testing to break your systems capacity)

It can be difficult to generate good quality test data at scale, and data based on your specific schema.

This is how [http://goodtestdata.com/](http://goodtestdata.com/) came about. It has the building blocks of core data and new sources can be built on request.

</comment><comment><USER19> Awesome! I needed something just like this a couple of years ago. A couple of comments:

\- I wanted fake CC numbers and SSNs/other national IDs at the time (don't remember why). I see that Faker is missing those, so they might be useful additions to the library.

\- Method names should be snake_case rather than camelCase ([http://www.python.org/dev/peps/pep-0008/#method-names-and- in...](http://www.python.org/dev/peps/pep-0008/#method-names-and-instance- variables)).

<comment><USER19> Actually, it looks like this doc is out of date. The README on Github shows that method naming has been corrected, and CC numbers have been added: [https://github.com/joke2k/faker](https://github.com/joke2k/faker)

</comment></comment><comment><USER20> I wrote a much simpler Python version a few years ago:

[https://pypi.python.org/pypi/Phony/0.5.0](https://pypi.python.org/pypi/Phony/0.5.0)

I don't recommend my version: it isn't maintained and isn't complete. However, writing a faker-type library is a great way to learn a language: you learn about how to organize code, how it handles different types, and how to package it up for use.

</comment><comment><USER21> I created a .NET port[1] of the Ruby port of the original Perl Faker library. It's also available on NuGet[2]

[1] [https://github.com/slashdotdash/faker- cs](https://github.com/slashdotdash/faker-cs)

[2] [http://www.nuget.org/packages/Faker.Net/](http://www.nuget.org/packages/Faker.Net/)

</comment><comment><USER22> I wrote a similar package in JavaScript for the browser or for node I called Chance:

[http://chancejs.com/](http://chancejs.com/)

[https://github.com/victorquinn/chancejs](https://github.com/victorquinn/chancejs)

</comment><comment><USER23> Yet another entry from "I made something similar to this" category, although the tool I wrote isn't as feature rich as this.

[https://github.com/mindcrime/dummydatagenerator](https://github.com/mindcrime/dummydatagenerator)

</comment><comment><USER24> We use something very similar in node called Charlatan: [https://github.com/nodeca/charlatan](https://github.com/nodeca/charlatan)

Very very useful in any build.

</comment><comment><USER25> Thanks for posting this, I was unaware of the various Faker implementations. I had often considered implementing a similar lib, but never invested the time. Now I don't have too!

</comment><comment><USER26> Inspired by faker, I created [https://github.com/alexmic/mongoose- fakery](https://github.com/alexmic/mongoose-fakery) for Mongoose.

</comment><comment><USER27> The amount of batteries included with this library is impressive.

</comment><comment><USER28> I wish it had support for more locales. Esp. more Asian locales (ja_JP would be really useful).

</comment><comment><USER29> This sort of looks like Faker.js and I remember we used it to populate a table with fake data so we could fill it up and demonstrate the app. It was very useful.</comment>


Ask HN: Is Firefox causing me to be IP-banned from HN? - <AUTHOR>

Hi Everyone. I have just been IP banned for the 2nd time in quick succession by HN. No complaint at all about that, in fact I want to thank those that have taken the time to show me logs of what is going on - appreciate your help!
I am bombarding HN with HEAD requests and yet from my point of view I am doing absolutely nothing differently in how I have been using HN for years. I use Firefox on Windows 7 64 and generally keep HN open in a tab. Every few minutes, or hours, I manually click on the title to see the latest updates to the front page and comments. Pretty normal useage I would say, and up to now never been a problem.
Clearly something is different and my browser, or something else is turning me into a rude user.
- Is it possible that keeping HN open in a tab is causing Firefox to send HEAD requests rapidly enough to get me banned?
- How can I test this?
- Aside from using another browser, how can I avoid this in future?
- Is anyone else noticing this sort of behaviour? <comment><USER2> Type "about:config" in your location bar and then set "network.prefetch-next" to false. Might help.

</comment><comment><USER3> Install the plugin "Live HTTP Headers" to see what is being sent and received.

<comment><USER4> Recent versions of Firefox have a much improved Browser Console (formerly known as the Error Console, and before that known as the JavaScript Console). It's like a browser-wide version of the per-page Web Console that showed up about a year ago. It shows HTTP requests (among many other things), and may be quite sufficient for diagnosing this problem.

Press Ctrl+Shift+J to open it, or click Firefox -> Web Developer -> Browser Console.</comment></comment>


Aptana is dead - <AUTHOR>

Aptana is a really good Eclipse-based tool for web developers. We use IBM Rational Application Developer  but I was thinking of trying out Aptana Studio. After checking out their website http://www.aptana.org/news, I am a bit skeptical - their last news are from August 2012 and their last Tweets are from a year ago. Is Aptana dead? Did their entire development and management team just vanish? <comment><USER2> I use Aptana and enjoy it.

I get automatic updates periodically, last one was within the last couple months I think.

Tried sublime 2, I couldn't find any good highlight themes, no printing support (then again Apatan's printing is not great on linux, i usually copy/paste to gedit or something that prints decent)

I like Aptana's editor, easier highlight theme modification, catches some syntax errors, and flag files in the project tree that have issues, pop up references to functions in your project (ala PHP documentor?) and used veriable in your code, highlights open and close pairs when cursor is next to them.

I'd say try it out, only takes up space in your home folder, and if you don't like it you can just delete it.

<comment><USER3> I use Aptana too. Yes, I've seen updates from them. It's the best Javascript IDE I've found, but that's not saying much. I guess JS is just too hard for IDEs to autocomplete all the time. Aside from that, Aptana does a nice job on things like syntax coloring and formatting. I used to be nutty about finding a good JS IDE but then I realized that Java IDEs became so good simply because Java was so hard to write (without stupid syntax errors and climbing through enormous and complicated frameworks like Spring).

</comment></comment><comment><USER4> Their development team didn't vanish, their latest commit was just 21 hours ago and commits seem to be done daily.

<https://github.com/aptana/studio3/commits/development>

</comment><comment><USER5> I use to use it but have since switched to Sublime Text 2. Aptana was purchased by <http://www.appcelerator.com/> a while back and at that point I figured it was moving towards its end. However it looks like there have been bug fixes as recent as January <https://jira.appcelerator.org/browse/APSTUD-7638> but thats almost 6 months ago. There may be newer tasks in their jira but I just saw this on the main page.

</comment><comment><USER6> Why would you make a topic making a statement as the title and then use the same statement as a question in the actual post??</comment>


Internet Society told to halt .org sale by its own advisory council - <AUTHOR> https://www.theregister.co.uk/2020/02/19/internet_society_org_sale/ <comment><USER2> If this sale is successfully prevented, the next step needs to be to identify and purge ISOC and ICANN of anyone who negotiated or advocated for this deal. Not just because of the corruption issue, but the pure lack of good judgment.

I keep thinking about the fact that first, ICANN was freed of it's tie to the US government, and since then, it's been business deal after business deal to corrupt the domain system.

<comment><USER3> We shouldn't be surprised. The whole TLD debacle has been a bit cash grab, which hasn't been beneficial to anyone but a few. Take the subsequent acquired domain of ".dev" by Google for instance, which then reserved it for internal usage only.

<comment><USER4> .dev is available for public registration... I have one.

<comment><USER5> "vanity" domains are $200/yr or more

Including "{firstname}.dev"

Nonsense.

If Google's worried about domain squatters, it controls the TLD rules and can come up with a less moneygrab strategy. Perhaps require a Github account and limit to one domain per customer?

FCFS is fairer than extortion.

<comment><USER6> _require a GitHub account_

You do know that there are devs that prefer other code hosting platforms, right? GitHub is a proprietary service that's generally terrible for developers.

<comment><USER5> > GitHub is a proprietary service that's generally terrible for developers.

In what way? I find it incredibly awesome.

</comment></comment></comment></comment></comment></comment><comment><USER7> So if I'm understanding this correctly...even if the Chapters Advisory Council formally recommends NOGO on the sale (which they haven't officially voted on yet), ISOC would not be legally bound in any way to bend the knee, and a hypothetical board decision to move forward with the sale anyways--assuming ICANN blessings--would risk organizational implosion stemming from the rage of its chapters followed by unfolding of a fragile justification for its tax exempt charity status?

<comment><USER8> Yes.

</comment></comment><comment><USER9> This whole situation is ridiculous. We need an alternative to all this centralized control, and we need it now.

<comment><USER10> > We need an alternative to all this centralized control, and we need it now.

The Handshake Naming System [1] provides a decentralized option, works directly with the existing legacy system so there will be 0 difficulty in the transition, and it's usable right now [2]!

Just install hsd [3] and point your resolution to localhost to join the movement to an internet owned by the people.

[1] [https://handshake.org](https://handshake.org)

[2] [https://hnscan.com/names](https://hnscan.com/names)

[3] [https://github.com/handshake-org/hsd](https://github.com/handshake- org/hsd)

<comment> jude- What happens when Ethos starts running their own mining software (or bribes existing miners) in order to jack up prices for .org?

<comment><USER10> In Handshake, rather than renting your domain from .org or .com, you own your tld.

This means that nobody will be able to charge you for using your own name. No more rent seeking or getting taxed by a pseudo government of the internet.

<comment><USER11> > In Handshake, rather than renting your domain from .org or .com, you own > your tld.

Given the conversation we had on [https://news.ycombinator.com/item?id=22312014](https://news.ycombinator.com/item?id=22312014), I think this claim is leaving out a lot of information. Handshake is not optimized for ordinary people to buy TLDs the same way they buy .com domains.

\- There's no market information I can find about what a TLD will cost on average.

\- Purchasing a TLD will take at least 5 days at a minimum, with no guarantee that you're going to get the TLD at the end.

\- Auctions are blind, so you have almost no guarantees at all -- you'll just have to guess what the market value is.

\- The intention is still for TLD owners to be able to sell access to subdomains, which will enable the exact same rent seeking and exploitation. The only difference is that there'll be no regulation on the rent seekers.

\- Given that subdomains allow us to repeat names (myname.com vs myname.org vs myname.io), having one TLD system is going to be a _decrease_ in the number of available domains, not an increase. The increase comes from the fact that we'll have a ton of TLDs and people will rent subdomains on them (see above).

That's not to say Handshake might not still be a good idea in the sense that it increases competition overall, but I think it's borderline deceptive to say that everyone is just going to own a TLD. Registering a TLD in Handshake may end up being significantly more complicated and significantly more costly than buying a .org domain today -- especially once the good names get used up and new users are effectively forced to rent from existing owners or compete in blind auctions over much more limited resources.

I'm a little bit irritated at this comment, because I've followed Handshake for a while and it's been really hard to get concise, clear information about how it works, even from the main project website. People don't understand the product being offered, and Handshake advocates keep posting very vague statements about how problems are just 'solved'. And whenever I dig into those claims and try to find out how they're solved, I find out that the implementation details aren't as clear cut.

I _want_ a project like Handshake to succeed, but y'all need to be a lot more up-front about the tradeoffs.

<comment><USER10> > Registering a TLD in Handshake may end up being significantly more > complicated and significantly more costly than buying a .org domain today

It's significantly easier than the process is today. It's very hard to get a TLD from ICANN as the process consists of a non refundable application fee of 185k with no guarantees you'll be approved.

> There's no market information I can find about what a TLD will cost on > average.

Rather than artificial set costs, the market will dictate this.

> The intention is still for TLD owners to be able to sell access to > subdomains, which will enable the exact same rent seeking and exploitation.

People can either register their own TLDs or choose one owned by someone who doesn't want to gouge people.

> Auctions are blind, so you have almost no guarantees at all -- you'll just > have to guess what the market value is.

Yes, and every bidder will have to be serious about wanting to win a domain instead of squatting every last domain.

I appreciate your comments, and understand your concerns. I would be irritated too if I couldn't find information about how this worked. Unfortunately, all the details (like Bitcoin was at the beginning) are buried in technical papers and developer docs. Luckily, Handshake is a community owned, community run project, and comments like yours help to propel the project forward and bring the explanation that people deserve.

Thank you for your help and questions, and please keep them coming!

<comment><USER11> > Rather than artificial set costs, the market will dictate this.

But you're coming into this conversation claiming that Handshake is going to democratize TLDs, that anyone will be able to buy one. We don't really know that the average cost of a TLD won't spike up to a thousand dollars, right? We don't know that every fortune 500 company in the world and every government in the world won't step in and snatch up every auction that gets posted. By design, there's no way for us to stop them from doing that.

There are very plausible scenarios here where ordinary people will not be able to buy TLDs under Handshake. Meanwhile, the worst case pricing scenario for the .com domain market, even with all of the centralization problems, is that it ends up costing $10-20 more per year over the 5-10 years.

I'm not saying that there aren't advantages to letting the market decide, and I'm not saying that the worst-case scenario will necessarily happen. It might be great. But I am saying that people learning about Handshake for the first time are looking at it as a drop-in replacement for .com, and it's decidedly not. I'm skeptical anyone has any idea what price or availability is going to be.

> or choose one owned by someone who doesn't want to gouge people.

Without protocol-level migration tools between TLDs this is still centralization. I'm still stuck relying on a rented product owned by a private individual that I can move away from.

Remember, when .com and .org came out, they were also owned by an organization that didn't want to gouge people.

The decentralization benefits of Handshake are entirely encapsulated in ordinary people owning their own TLDs. We really shouldn't be talking about rented subdomains at all, rented subdomains are the problem that Handshake was advertised as solving.

> Unfortunately, all the details (like Bitcoin was at the beginning) are > buried in technical papers and developer docs.

For what it's worth, Handshake isn't the only project of its type that struggles with this. It was similarly difficult to find out how projects like IPFS really worked.

<comment><USER10> > We don't know that every fortune 500 company in the world and every > government in the world won't step in and snatch up every auction that gets > posted. By design, there's no way for us to stop them from doing that.

There is a scarcity of coins which will help to prevent this. Whenever you bid on a name, your coins are further locked up until the end of the auction.

> Remember, when .com and .org came out, they were also owned by an > organization that didn't want to gouge people.

No I don't remember this - it never happened. Quick history lesson: It was 50 dollars to get a .com or any name, and later 35 dollars. Network solutions had a monopoly on it.

> The decentralization benefits of Handshake are entirely encapsulated in > ordinary people owning their own TLDs.

Absolutely! In addition, it serves to solve issues with the CA system. It democratizes ownership of the internet and makes it safer.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> This whole thing is ridiculous. It makes me both laugh and cry. Selling org to an "unavailable name" private equity firm is just ironic to the extreme.

<comment><USER13> It's worse than ironic. It's crony capitalism. An inside deal with no benefit to external people, where the transaction will make money for the insiders. It's all hidden because it's corrupt.

</comment></comment><comment><USER14> Well, I have to say I'm quite proud of everyone who stood up and made a fuss over this. It is blatant corruption. Keep the good fight going, folks!

<comment><USER15> > Was...

Is it over yet? From how i read it, no:

'[The internet society] will vote this month on whether to approve a formal recommendation that the society "not proceed [with the sale] unless a number of conditions are met."'

<comment><USER16> Those conditions require the release of new information and, I would assume, re-scrutinizing the decision based on that new information.

This information should reveal that indeed this is a fraudulent sale. If the information does not reveal that, there is less of a reason for blocking the sale. Really, what should be reversed is the decision to remove price-hike caps on the .org TLD.

</comment></comment></comment><comment><USER17> I wonder if this is a deliberate strategy ... I .e. first advisory council halts, does their DD, and then says its all good... which they can then point to and create a defense. Prob not the case but can't rule anything out.

</comment><comment><USER18> Once the deal goes through someone from the ISOC will be getting a high-paying job at Ethos. Wait for it . . .

<comment><USER19> Already happened:

[https://en.wikipedia.org/wiki/Ethos_Capital](https://en.wikipedia.org/wiki/Ethos_Capital)

<comment><USER20> Isn't this level of quid pro quo corruption punishable? Or does nobody even care anymore?

<comment><USER21> Everyone is in bed with each other. They all inside trade, they all bribe each other for different leverages. And a lot of plebeians support it ironically.

</comment></comment></comment></comment><comment><USER22> Snake biting it's own tail:

[https://en.wikipedia.org/wiki/Ouroboros](https://en.wikipedia.org/wiki/Ouroboros)</comment>


For those who like real torture: developing .Net apps on Raspberry Pi - <AUTHOR> http://www.jeremymorgan.com/tutorials/raspberry-pi/how-to-c-sharp-raspberry-pi/

<comment><USER2> what's this title, this sound like trolling at best.

"Next up on HN, walking eclipse on your Raspberry Pi"

<comment><USER3> I agree, stupid headline, stupid tutorial

<comment><USER4> Even if you are right, it would be a lot more helpful if you reasoned as to why you think that. That would help the original author improve the article and anyone else reading this to write better headlines and tutorials.

Your comment at the moment adds no value. The author spent hours writing something and you dismissed it with less than a reason.

<comment><USER5> I am the author of the article, though I didn't submit the headline. I'm fairly used to this sort of criticism, especially when I create something targeted at beginners.

You're correct and not only does it not add value but the person you are criticizing gives no weight to your opinion, because you just look like a "hater". Seems like the trend these days.</comment></comment></comment></comment>


The New Kindergarten - <AUTHOR> http://www.wilsoncenter.org/index.cfm?fuseaction=wq.essay&essay_id=480269 <comment><USER2> "Unfortunately, no scientifically rigorous evidence supports the claims of pre-K's impact on middle-class children. James Heckman, a University of Chicago Nobel laureate in economics, is one of the strongest voices in favor of early education for low-income children, but here is what he says about applying the model to the middle class: 'Advocates and supporters of universal preschool often use existing research for purely political purposes. But the solid evidence for the effectiveness of early interventions is limited to those conducted on disadvantaged populations.' As Bruce Fuller, an education professor at the University of California, Berkeley, and author of Standardized Childhood (2007), explains, 'For middle-class kids the quality of preschool centers would have to approach a nirvana-like condition to present radically richer environments than the majority of middle-class homes, or home-based caregivers.'"

</comment><comment><USER3> Pre-K just sounds like adding another inadequate piece to the already crumbling K-12 system.

Just focus on K-12, heck, just focus on high school, and make it really good. One thing at a time.</comment>


A blockchain is a specific set of choices suitable for a narrow set of use-cases - <AUTHOR> https://threadreaderapp.com/thread/987266940887535616.html <comment><USER2> I was recently at an "Emerging Technology" conference for emerging technologies that was targeted at non-technical entrepreneurs and innovators. 90% of the conference was focused on blockchain, while the remaining was focused on AI. During the entire conference, blockchain was being touted as a silver bullet for many problems, and many of the people at the conference ate it up.

The best anecdote to summarize the conference was a speech by IBM where they covered a project which they did with major retailer to track a supply chain. The speaker mentioned some impressive results which caused a noticeable people around me to literally say "wow". However, they did not once mention specifically how blockchain was the cause of these results or give reasons why blockchain was superior. From what I could tell as an engineer, the entire application could have been built without blockchain.

I was surprised at how blockchain was being touted as the next technological revolution (and very light on the details) and was concerned at how quickly the other attendees accepted blockchain as it was being sold. I left the conference thinking that it would only be a matter of time before blockchain would be touted as a silver bullet in the larger community due to conferences like these (although I am sure they've been happening for a while, and this was my first exposure). It will not be long before a large number of software projects will be based on blockchain needlessly, and/or the engineers will be arguing with management why using blockchain is a mistake.

<comment><USER3> We now live in the information age. Blockchains and AI will transform everyday life as well as specific sectors such as health care and trade.

Imagine walking in to a Starbucks café, order a cup of coffee, digitally signing a payment transaction on your mobile or laptop and then wait for it to be confirmed by the Blockchain while enjoying the hot cup of coffee you have ordered.

What is more, think about AI, you will not need to talk to the staff to place an order for your coffee. The staff can relax and watch you make gestures to a camera. They will be able to read on a screen if you'd like it white or black.

I think the article is too negative and does not see the big picture of transformation that is going on (as exemplified above).

<comment><USER4> > Imagine walking in to a Starbucks café, order a cup of coffee, digitally > signing a payment transaction on your mobile or laptop and then wait for it > to be confirmed by the Blockchain while enjoying the hot cup of coffee you > have ordered.

You could do the the exact same thing now with credit cards, except the waiting. And then you could get your money back if the coffee sucked, and you wouldn't lose all your money if someone happened to steal your private key .

<comment><USER5> Pretty sure it was sarcasm.

<comment><USER6> It's important to keep Poe's law in mind when you're posting plain-text parody; you don't have tone of voice and body language to help convey your real intent.

</comment></comment></comment></comment></comment><comment><USER7> What exactly is the specific use case where Proof of Work blockchain are appropriate?

Consensus in that design is:

1\. Perhaps the single most expensive consensus algorithm ever designed.

2\. Deliberately one of the slowest.

3\. Does not actually provide trustless consensus once 1/3 of the miner nodes decide to collude.

Other than "our data is a merkle tree but you have to trust us to submit transactions to it", and "a currency system with a failed promise to deliver either scale or trustless consensus" what, is the proper application?

<comment><USER8> If you can invent a reliable alternative to proof-of-work distributed consensus there is a multi-billion dollar opportunity there. It's inefficient, but before bitcoin came along there was no way to even do it. An inefficient way is better than no way at all.

Some other cryptocurrencies are trying alternatives. But none have been as "battle hardened" as bitcoin.

Follow the core developers and you'll see their focus is on creating an open distributed platform. It's up to us to figure out what to use it for.

<comment><USER9> > An inefficient way is better than no way at all

Really, why?

IMHO, there's a pretty compelling argument to be made that Bitcoin and the other cryptocurrencies have had a significantly net-negative impact on the world, from facilitating scams and other illegal activity to now having to worry that sites we visit will monetize by stealing CPU cycles to the significant impact on climate change, these technologies have caused a lot more harm than benefit. And all the while, they haven't even figured out how to build a ledger that can scale to day-to-day transactions. My bet is that the whole thing ends up being a tax on people who've forgotten their 17th century Dutch history.

<comment><USER10> > from facilitating scams and other illegal activity

The same was said over and over on the nascent days of the internet, about how it facilitated anonymity so easily and how it would be used by criminals.

> by stealing CPU cycles

Difficulty in bitcoin mining is raising all the time (because of the competition among miners). This is why nobody mines nowadays with CPUs or GPUs but with ASICs. The fact that some sites are trying to achieve some decent mining hashrate by pulling the amount of visitors of a website is a naive move that will soon be off-set by even more raising levels of difficulty. Soon this will not be profitable at all, even if your website was the 1st in Google's page rank.

> to the significant impact on climate change

I like that skeptics raise this point, because:

1) The cryptocurrency mining industry is the fastest one to chase energy- efficient solutions. As soon as a device consumes less electricity, it's adopted widely because of the huge incentives to do so (e.g. CPU->GPU->ASIC).

2) Compare the electricity spent by the entire banking industry with the electricity spent by the entire crypto-mining industry. Now guess what's more efficient.

<comment><USER7> > The same was said over and over on the nascent days of the internet, about > how it facilitated anonymity so easily and how it would be used by > criminals.

There's 2 things I want to say about this comment:

1\. Those accusations _were not wrong._ In the same sense that we have pretty clear evidence that a lot of the value injected into bitcoin and stored there is via money laundering.

2\. _Unlike_ proof of work currency blockchains, the internet clearly delivered and had no direct theoretical challenges to its very existence that people subsequently and fervently denied.

Proof of work is a bad idea. It's been discredited. It doesn't do what people thought it did. And it's MUCH too expensive to keep doing.

<comment><USER11> Proof of Work is the only way for people to transact in which they don't have counterpary-risk problems before transacting.

Before PoW was invented, there was no way of doing this.

Now, thanks to layer2 technologies, PoW will start becoming much more (orders of magnitude more) energy efficient.

How is that a bad idea? Make something possible, and later make it sustainable. So long as there's demand for that something, then it's a good idea.

<comment><USER12> There are two sides to a trade, and typically Bitcoin only handles one of them. Buy some food with Bitcoin and it still might taste bad or make you ill.

Even for purely financial transactions, any kind of loan or investment still has counter-party risk.

So even if a crypocurrency worked perfectly, it doesn't solve very much.

<comment><USER11> > There are two sides to a trade, and typically Bitcoin only handles one of > them. Buy some food with Bitcoin and it still might taste bad or make you > ill.

You have this same problem with any form of money. The problem I raised is counterparty-risk when holding your assets (before transacting).

> Even for purely financial transactions, any kind of loan or investment still > has counter-party risk.

Yeah, that's why maybe loans should have higher interest (right now, the low interest is artificial, because the bank is really making more money from the fact that it's working as a fractional reserve, not from the interest it gathers from loaning you money).

> So even if a crypocurrency worked perfectly, it doesn't solve very much.

It solves just one thing. Granted, it's not a silver bullet. But there are never silver bullets. Every single invention that humanity achieves, just improves the world a little tiny bit. Cryptocurrency does this as well.

<comment><USER13> It does not solve anything. It's true that cash and bitcoin both avoid a narrow slice of counterparty risk. But that's not a whole problem, just part of one. As a currency, Bitcoin is an abject failure. Even big proponents admit that: [http://avc.com/2017/08/store-of-value-vs-payment- system/](http://avc.com/2017/08/store-of-value-vs-payment-system/)

Bitcoin made no practical dent in existing legal financial transactions because it's not better for the great majority of use cases.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> While the definition is exact, it's a pretty narrow one. I understand that people are tired with all the hype and naturally want to counter it somehow.

But don't let it blind you, blockchain technologies will deeply change our societies. It's a trust machine: it creates trust where there is none. Trust being one of the pillar of our civilization, the scope of its applications is wider than you would expect.

Edit: thanks for the downvotes... if your confirmation bias can't handle a contrarian, respectful point of view, i'd seriously question your rationality as a member of this scientific-related community.

<comment><USER15> In most situations trust between two parties can be obtained by means of a third party they both trust.

That's how the banking system has worked for centuries.

The use case for a blockchain is narrower: it can be used to establish trust between two parties in absence of a trustable third party.

<comment><USER14> Exact, and we have seen how well this third-party trust system worked during the last financial crisis just a decade ago.

<comment><USER16> Which system failure from that crisis does blockchain technology fix?

<comment><USER14> Sudden cascading lack of trust?

<comment><USER16> Blockchains can reduce counterparty risk in a transaction, but there's no technical solution to the fact that trust is required between, for example, a lender and a borrower. The idea that you can just sprinkle some blockchain dust and avoid financial crises is naive.

<comment><USER17> >but there's no technical solution to the fact that trust is required between, for example, a lender and a borrower.

No, it does not. However, if someone lends bitcoin to a borrower, it does not involve third parties, and therefore cannot "run" like a fractional reserve bank.

<comment><USER4> Of course it can.

Someone (A) can loan Bitcoin to another person (Bank), with the terms that if he asks he can have it back at any time, and he'll also receive a small percentage of interest each year.

Bank can then lend 90% of the money to a third person (C), betting that A will not ask to get all his money back at the same time. To decrease this risk, he does this with lots of people so he is covered in case only a few ask all of it back (but still is in trouble if too many of them do at the same time).

A still has money (his assets are very liquid as he can ask for them back at any time, very liquid assets are what we call money), C has money, the sum is more than the initial amount, so money was created through fractional reserver banking.

That's all fractional reserve banking is, and nothing about Blockchain prevents it.

<comment><USER17> >That's all fractional reserve banking is, and nothing about Blockchain prevents it.

Implicit in my comment was the idea that it would be a bad idea to start a fractional reserve bank which used a currency of account that wasn't available in infinite supply from a nearby government.

Also, I merely stated a way in which Bitcoin could be used as a sound bank, not that all possible banks which use Bitcoin are sound.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> It's interesting how blockchain became so incredibly hyped though isn't it? Something to do with money (bitcoin) and some new technology perhaps?

I wanted to find out what was going on, so I literally applied for a bunch of blockchain jobs just so I can talk to these people on the phone to see what they're all about. I end up asking really basic questions like: "So why are you using a blockchain instead of a normal database?" or "What problem are you actually trying to solve?" It is actually embarrassing; I feel like I'm being abrasive on the phone by asking such truly basic questions, yet they always seem so startled by these kinds of questions and assume I'm somehow incredibly intelligent and perceptive to ask these basic questions.

Generally what happens is as follows. Some business MBA type people watch a TED talk or read in the FT that blockchain is the next big thing, so they go out and look to hire "blockchain evangelists". Evangelists is the word they often use, and that sounds about right because it is just like a religion sometimes. Then I only end up talking to the business people about these projects, because that's all the people they have. I won't name them, but I've had conversations with huge firms or startups that both equally talk utter nonsense. One large firm told me that they're working on "permissionless and permissioned blockchains for everything from auditing to wine". While for a small startup I once asked: "why are you using a blockchain for this instead of just having a database?". The answer I got was "well... our customers aren't really technical people...". I told them perhaps they should look at something like Google's certificate transparency rather than blockchains, and they echoed back to me "Oh we are definitely looking at certificate transfer!" (Transfer, not transparency.) It's astonishing.

To summarize, huge firms tend to have people who just want to get paid so they always say yes to whatever the clueless MBA person asks, while startups tend to mostly know it's bullshit but go along anyway because there is a lot of $$$ involved, particularly with ICOs.

<comment><USER19> I really like the idea of phoning up the recruiters to find out more about a technology!

We have a Blockchain meetup group in my city, however its mainly about cryptocurrency investments than any actual blockchain technological innovation.

<comment><USER18> To be honest I'm more onboard with cryptocurrency, even though obviously there are way, way too many of them (Kanyre-West coin anyone?) becuase at least blockchain actually solves a very specific problem for bitcoin: decentralized peer-to-peer currency. It's when you get blockchains for sexual consent and tracking your bananas in Laos that really annoys me (both real proejcts btw)

</comment></comment></comment><comment><USER20> As part of my job, I often have to convince business folks that they don't need to buy a fucking private blockchain (from IBM of course, because they're old enough to think that no one ever got fired for buying IBM). This is very close to the arguments I make, and adds some excellent, articulate points!

<comment><USER21> This is happening at both of my companies now. I'm almost to the point of telling them to buy it just so they can tell their golf buddies they're using blockchain too.

<comment><USER20> Pro-tip: do an "experiment" with blockchain (built in house to keep it cheap) so they can tell their golf buddies they're looking into it. Make sure it's compared to a sane solution, because then they can feel superior for having "insider knowledge" that it's pointless.

</comment></comment></comment><comment><USER22> These are all very excellent points. I would go even further: "The only viable application of blockchain is cryptocurrencies" (and cryprocurrencies have a whole different set of problems).

By arguing that there is only a "narrow set of use cases" you open the door for the counter argument "yes, but MY blockchain startup is not bullshit".

I isually use the argument "show me the increase of profit margin specifically by using blockchain technology".

I so far have not gotten a satisfying answer.

<comment><USER23> I think there are also use cases that revolve around using a blockchain as a public database and API for the transfer and security of data.

Obviously, you could do this without using blockchain _IF_ you could get the top 20 players in vertical X to agree on what that looks like. However, using "blockchain" as an excuse to get the project funded and get buy-in from those same top 20 players so they can talk about blockchain at the next board meeting is an enabler of practical problem solving. Sometimes you have to take the path of least resistance.

</comment></comment><comment><USER24> This guy makes a lot of good points, but at heart, this is a false appeal from authority. Every distributed system makes a set of tradeoffs. If you were to design a distributed system with the same tradeoffs as a blockchain (single global state, and very low trust of node operators), you would end up with something that has similar performance characteristics as a blockchain.

Arguing that these tradeoffs are not good is perfectly valid. For instance, this guy feels that you should be willing to trust your bank with your money, and Microsoft with your code execution, in return for better performance. Valid opinion.

The problem is when he comes in with this hand wavy stuff about how him and his very smart friends think this and that and they are distributed systems engineers so you should listen to them. It's not a technical question, it's a basic question of where you want to place your trust, and a distributed systems engineers opinion is just as valid as that of UI designer, a teacher, or a janitor.

<comment><USER25> I don't think that was the point of the article at all.

The point is that distributed systems engineers know already about these sets of tradeoffs, and many of the alternatives to them, and with that wider perspective see few, if any, reasons to recommend blockchain.

Meanwhile many the people going around hyping up blockchain know very little about the tradeoffs and alternatives, and are definitely _not_ recommending blockchain because it's the right set of choices in each of the tradeoffs.

Like - picking randomly - KodakCoin[1], he would argue (and I would agree), definitely did not choose to use blockchain because was the database that made the most sense for their needs. Indeed, it's probably a terrible choice compared to the alternatives.

(Except, perhaps, for optimizing for"hype factor" as seems to have worked considering their stock price, in which case the best thing to do might actually be to lie and _say_ you're using blockchain, and then... not.)

[1] [https://en.wikipedia.org/wiki/KodakCoin](https://en.wikipedia.org/wiki/KodakCoin)

<comment><USER24> > _The point is that distributed systems engineers know already about these > sets of tradeoffs, and many of the alternatives to them, and with that wider > perspective see few, if any, reasons to recommend blockchain._

It's not really a technical question. People who like blockchains like them _because_ of that set of tradeoffs. Beyond obvious scams and stupid corporate hype (by most of the same people who misused "cloud", btw), people understand the tradeoffs.

I don't think that distributed systems experience qualifies you to do any more than understand the tradeoffs, and these specific tradeoffs are understood well by a very large number of people already.

</comment></comment></comment><comment><USER26> _Thank you._ This is what I've been telling people forever. Blockchain technology is revolutionary for a very specific and narrow set of use cases, and outside of that it ranges from a crappy solution to completely irrelevant.

</comment><comment><USER27> I think people are severely underestimating the value of a single source of digital signing and chronology, as well as the network effects of interoperability. Time will tell ;)

also to the point of specific design decisions, there are plenty of models that will evolve including arbitrary protocols on the Filecoin Merkle forest, so I'm not worried about that

also find that distributed systems experts tend to fail to see things through the lens of cryptoeconomics, which was nakamoto's fundamental innovation. it's about provable behavioural security

<comment><USER28> I agree. Imagine a frontend developer connecting to the internet and with a couple tools like truffle and his crypto wallet, that dev will immediately have access to so much information and logic through smart contracts via one interface, that it blows my mind. It's still young but it's going to be ubiquitous and pervasive. At least I'm 90% sure it will be ;)

<comment><USER29> I'm a frontend developer. So let's assume I've connected to the internet with "a couple of tools". Which information and logic (???) are now available to me that were previously inaccessible?

</comment></comment></comment><comment><USER30> There's room for more choices than that. E.g. you can do transactions off- chain and keep some relevant state yourself, with an exit plan to the public chain in case of cheating. Examples include state channels and Ethereum's Plasma.

</comment><comment><USER31> I've found my life is a lot happier and I'm a lot less frustrated if I replace "blockchain" with "distributed database" in my mind any time these types of discussions come up. Technically they're different, but what is actually potentially revolutionary about everything happening right now isn't the hash chain, it's the idea of moving apps to distributed databases, self contained databases and away from the database tech of old. This could apply to consumer apps, enterprise apps, pretty much anything. When I think about it that way, I'm much more ok with the broad overuse of the term blockchain.

</comment><comment><USER32> On the bright side, we can stop calling it a scam and start calling it a religion soon

</comment><comment><USER33> There's only one use case for blockchains: creating ecosystems. Solving a customer's problem is typically not something you do on your own, you need to collaborate in ecosystems. Having one company dictating what rules and technologies are in effect in the ecosystem is risky (e.g. ecosystems created by Amazon or Facebook). A blockchain democratises the collaboration, at the cost of efficiency. So at its core it's a governance technology, and a trade- off between efficiency and security of your ecosystem.

Blockchains are just a technology. The point is to look at use cases that are now viable because of the ecosystems we create.

</comment><comment><USER4> I was recently asked to give a short presentation on "what is blockchain" at a session with government agencies who wanted to formulate a position on whether they should do anything with blockchains.

And my conclusion was almost exactly the same as this post: blockchain is part of a set of specific technologies you need to solve the very specific problem that Bitcoin solves. Another thing without which Bitcoin wouldn't work is the PoW stuff. If your requirements are different, then many of those other technologies are still relevant but blockchain is not. And if you are not a digital coin, your requirements _are_ different.

</comment><comment><USER34> This happens with most of the technologies. Remember the days when AJAX was introduced? every other site was being ajaxified. Tech companies were promoting it as if something very unique arrived in this world. Later it was found that Microsoft was using it in outlook for long time, it's just they failed to coin the term for it. Same seems with blockchain and as usual IBM is at it's best to cash this hype for enterprises who are already customer of their products one way or other, specially Middle east countries.

</comment><comment><USER35> The blockchain enables a set of use-cases around trust, value exchange and cryptoeconomics. With these building blocks, there are a number of companies working on amazing projects that are truly revolutionary.

[https://vitalik.ca/general/2018/04/20/radical_markets.html](https://vitalik.ca/general/2018/04/20/radical_markets.html)

</comment><comment><USER36> Here's my case. I have problems trusting any centralised cloud service out there that is significant for my privacy. I have problems with Pocket, because it knows what I read.

If data would be stored on the decentralized nodes and accessible over the smart contracts, my zen would be way closer.

<comment><USER37> But wouldn't that change your data being readable by Pocket to your data being readable by everyone?

I fail to see how that's better. And if encryption is the solution, there could be encrypted centralized or decentralized apps.

<comment><USER38> Readable by everyone != decentralised / blockchain

Blockchain code literally runs in an open source, open memory environment. Which means you can guarantee the execution of code without interference.

<comment><USER39> But that non-interference comes from exposing all the information it operates on to the public. Otherwise, you wouldn't be able to maintain a consensus.

(if you encrypt your data, then nobody else can see it, but you can't do anything with it on the chain and you might as well store it in S3 or wherever)

<comment><USER40> Technically, fully homomorphic encryption exists (and may someday be practical)

<comment><USER37> But still, you could have a centralized service that involves client-side (potentially homomorphic) encryption and stores (and in the case of homomorphic encryption, does operations with) the data on their servers. So that shouldn't give a privacy benefit from blockchain over centralized servers.

<comment><USER40> You would get a privacy benefit in the sense that the computation provider would not learn anything about the data you gave them. However you are right that centralized computation providers are equally constrained (ie don't learn anything) as blockchains in this regard.

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> I am a distributed system engineer. I worked for aws... I agree with that bitcoin blockchain is only specific for electronic payment system. But its design concept is quite interesting, could make quite huge impact.

</comment><comment><USER42> The shortest I have been able to explain it as:

If you want an append only log with arbitrary (including malicious) actors then use a blockchain. Otherwise you may want to avoid the huge costs associated.

</comment><comment><USER43> Only some projects have utility in the blockchain Actually, some of the are Augur or Cryptocup.io

</comment><comment> johnx123-up _As original link is not available, posting the content from Google Cache for future reference_

Thread by @clemensv: "I've talked to a lot of distributed systems engineers (who build cloud-scale stuff) from across the industry about blockchain. While most pl […]"

I've talked to a lot of distributed systems engineers (who build cloud-scale stuff) from across the industry about blockchain. While most platform folks I talked to are perfectly happy to help with frameworks that help selling product or services, ...

... and some even rode the crypto wave to make some hay, I have a hard time finding people in the distributed systems platform community who believe that blockchain is even remotely as significant as the hype wants to make us believe.

Engineers at the center of the industry understand the qualities of append- only logs, understand signatures and non-repudiation, and understand consensus protocols. They understand that those are a few building blocks from a large toolbox and that there are choices for each.

A "blockchain" is a specific composition of specific choices for these building blocks that's suitable for a fairly narrow set of use-cases. The blockchain-specific consensus models are tailored to (a) all-around lack of trust and (b) convergence to a singular global log.

Convergence to a singular global log with many candidate writers and many replicas makes it hard to reach consensus and for that consensus to be propagated; PoW or PoW+PoS (cleverly) solve that by being intentionally slow.

The PoW lottery is probabilistically set up so that a singular mining winner can emerge and its winning block can be propagated throughout the network before another miner finds a competing solution (there can be many valid ones). The enabler for that is a time window.

The tradeoff the "nobody is trusted" blockchain model makes, is that it literally trades trust for time. It's slow by design. Giving consensus forming ample time is foundational. (I'll be happy to hear arguments that prove the contrary).

Once parties trust eachother to faithfully collaborate, the existing consensus models that we all use to build hyper-scale cloud systems become applicable and those can resolve even complex and contested consensus problems in a few milliseconds, largely gated by network latency.

Even if there's no all-around trust, there's often a neutral party that can supervise a transaction of two parties that don't trust eachother, but who each trust that party. "Sidechains" and "Private permissioned blockchains" are playing that trick.

However, once there's a trusted neutral party, that trusted neutral party can already establish non-repudiation by forcing authentication/authorization along with a content signature and only ever allowing appends. With any regular old database that the neutral party maintains.

The world's economy today is built on the very principle that accounting records are both safe from deletion and immutable in digital accounting systems. There's a clear sense of order. They are written to audit logs for non-repudiation proof.

The cryptographic chaining of records is a good idea to strengthen the immutability of the ledger as a whole, but it's not really superior to holding a ongoing full copy of the ledger in safe escrow. A signature chain can be done on any existing database.

The single global log requirement and therefore the global consensus problem completely falls apart in all cases where the problem is partitionable (FWIW "sidechains" are partitions). Turns out, that's true for most problems, otherwise nothing would ever scale.

Once you can use partitions, the consensus scope shrinks to the scope of the partition. When you transfer money from your bank account, the intial scope is just your bank, with the initial transaction to a clearing account. (FWIW, a "sidechain" is a clearing account). Easy.

For those familiar with (shall I say "classic"?) distributed systems architecture, it's amusing to see things like "sidechains" with local trust relationships emerge, because they are nothing but a reaffirmation of the partitioning principles foundational for a functional economy

Yes. The combination of decentralized operation, variable trust, and non- repudiation is very attractive. The world already works like that. There are easily 15,000+ banks globally and countless more businesses that maintain various ledgers. That's hardly "centralized".

"Centralization" is not when 15000 organizations are federated such that you can transfer funds between them. Yes, you need a banking license and audit in the local jurisdiction to be a bank. Because, as we see, some people are happy to separate other people from their funds.

The specific combination of well-understood architectural building blocks that make up "blockchain" is very well applicable, but nearly exclusively applicable to all-around trustless global ledger accounting problem (e.g. "coins").

Any other set of requirements is likely better addressed using a different combination of elements from the broad toolset that exists across the distributed systems platform landscape today. /fin

PS: I'm not an ideolog on this matter. If you're convinced that you need a blockchain, I'll surely help with the communication path if asked. I have the finest shovels.

Clemens Vasters 🇪🇺 (@clemensv)

</comment><comment><USER44> First, I can't stand these people who qualify their logic based on "My crypto friends say ...", "All my start friends are saying ... ", "All my friends who are building distributed systems say ...", instead of 100% being responsible for their own words. I see them as lazy cowards who takes other people's words and transforms them into attention (a.k.a. retweets, viral posts, media mentions, ad revenue, etc.)

Second, some thoughts on this specific argument. This whole thread is based on an assumption that "skilled distributed systems engineer" is an authority when it comes to Bitcoin or blockchain.

Except they aren't.

I would even go further to say that the very developers who are working on Bitcoin protocol itself cannot be trusted as an "authority". They may be very good at cryptography and coding, but it is very difficult for one individual who has made a career out of a single expertise suddenly become an "expert" in all things combined (economics, coding, cryptography, game theory). Especially the economics part, if you're coming from a programmer background. A lot of programmers seem to THINK they understand how Bitcoin works after reading an economics 101 book, but the thing is, even the economists are never 100% certain about their theories. There's a good reason why there are multiple parties of thoughts in economics.

I once read a blog post from a guy who's very well respected in the Bitcoin community who wrote a post about "crypto keynesians" and "crypto austrians", and it was so obvious that he had no idea what he's talking about because he got it completely opposite. The post only made sense if you interpret what an "austrian economist" and "keynesian economist" is on an extremely superficial and shallow level, perhaps reading a couple of blog posts or investopedia articles on that topic.

I think people really need to be humble when they talk about this topic because I'm pretty sure it's really hard for one person with narrow expertise --unless she/he is very motivated to learn everything--to understand Bitcoin/blockchain as a whole. This is especially true for those who just have one expertise and never really delved into the rest because they think it's a bullshit technology even before learning about what actually powers it.

And I have yet to see a single person who's dived really far into learning everything Bitcoin is made up of and come away thinking this whole trustless ledger thing is a fad and a bullshit. Some may get disillusioned that the current existing solutions don't satisfy what they were promised, but even these people still they understand that this doesn't mean the whole idea of a trustless ledger is a sham. They would only think there's got to be a better solution.

<comment><USER45> Note that blockchain and economy (or more precisely _finance_ ) are two very different things. Do not mix up blockchains and cryptocurrencies. The first is a distributed system creating a centralized log, the second is a class of (very classic, mostly unregulated) financial assets (which could be constructed on top of very different architectures). I'm pretty sure this guy doesn't even care about the financial asset thing, he is criticizing the blockchain from a computer-science pow.

<comment><USER4> > Do not mix up blockchains and cryptocurrencies. The first is a distributed > system creating a centralized log

It's a _very specific_ distributed system creating a centralized log, namely one that absolutely rules out using any mechanism of trust. Only cryptocurrencies need that. It does so at huge cost in terms of security and efficiency.

</comment></comment></comment><comment><USER46> > I have a hard time finding people in the distributed systems platform > community who believe that blockchain is even remotely as significant as the > hype wants to make us believe.

Right here! Take eBay or Amazon for example, the entirety of their business can be run as decentralized smart contract software. The blockchain is a distributed ledger whereby storing information is incentivized. It's unbelievably significant. The scale problems will be figured out and reliable and auditable databases will be the defacto choice.

<comment><USER7> We already have reliable databases. Blockchains purport to offer _trustless_ consensus. If that were true, it'd be a big deal. It's not clear that they do.

But why would eBay want a trustless consensus? Their entire business model is around being that trusted arbiter and broker.

Even off in darkweb land, companies exist to service and broker transactions that then fall back to the blockchain to reconcile payment. So presumably if you were correct we'd see that model emerging.

I've looked, but the inside of Tor is a big place. Maybe you've seen an example I haven't?

<comment><USER46> > We already have reliable databases.

not in the way that a blockchain maintains the final state and a clean audit log of every transaction.

<comment><USER7> Git does this, doesn't it?

(Not that people here appreciate my contention that GitHub is a "white label blockchain company")

<comment><USER46> Yeah that's true, and Github is really popular, I use it every day.

<comment><USER7> Well then: Git is a blockchain with proof of ownership for commits and it doesn't need multiple miners or anything and you use it every day with what I guess is acceptable risk.

<comment><USER4> Because it uses trust. I trust that only I can access my local Git repositories, and that Github's authorization does its job.

Which is absolutely great, but nothing new and not what people mean when they hype about "blockchain".

<comment><USER7> I find most folks don't mean anything they think they mean when they hype about blockchain, so I like to try and inject reality.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER47> The Blockchain is TCP/IP with History.

That's how you think about it and once you do that a huge amount of things open up. Some of those might not make sense to the current cohort of developers, proponents, and critics but the next coming generations will grow up with this normalized and will find plenty of ways to use it.

The most underappreciated part of the blockchain is its ability to create a secondhand market (not secondary) for digital assets. This means that digital assets will be able to increase in value if ex-owned by the right person (think an ebook who was owned by Obama. If you think this is far out I urge you to look at the art industry to understand how things with no inherent value gets traded for often insane amounts.

Collectors Cards (Crypto Kiddies) this is only the beginning and when I look at the kind of things my son care about it's fairly obvious that digital memorabilia is going to be a huge industry.

Digital Identity this is going to be the defacto standard in a few decades, decentralized is the future.

So hate it or love it. The blockchain is here to stay and there is nothing wrong with us not having found any real traction for it yet outside the speculation space, it will come because the fundamental properties are sound and useful.

It's worth spending many more billions on this to get it to to become the 2nd layer on top of TCP ip on the internet. That's my take on it.

Edit: I'm genuinely curious. Why the downvotes? Did I say something wrong?

<comment><USER48> > I'm genuinely curious. Why the downvotes? Did I say something wrong?

"The Blockchain is TCP/IP with History" \- this is just sound bytes, noise without any substance, technically wrong, and could have triggered most of your readers to stop reading right there and press the downvote button.

<comment><USER47> The title of the Post starter isn't technically right either so that's hardly a reason to downvote as that's not really the purpose of the articles.

Understanding bitcoin isn't about understanding the technology any more than understanding economics is about how you technically print money.

Analogies are very important and the analogy I use isn't that wrong and not without substance, in fact, I provide that.

I am not the only one who think of it like that [https://www.wired.com/2015/01/how-bitcoins-blockchain- could-...](https://www.wired.com/2015/01/how-bitcoins-blockchain-could-power- an-alternate-internet/)

It wasn't the creator of TCP/IP that created Google, Facebook or any of the other big companies out there and it most likely won't be that either with Bitcoin.

<comment><USER48> You asked a question, I provided an answer. There is no point for me to discuss this any further.</comment></comment></comment></comment>


We didn't evolve from apes? Well - <AUTHOR> https://fcsuper.blogspot.com/2017/07/we-didnt-evolve-from-apes.html <comment><USER2> This is one of those "while technically true..." sorts of articles. Clearly, the author has not argued very much with creationists. Creationists are wrong, usually know they're wrong, and aren't afraid to argue in bad faith. So, while it's technically true that humans evolved from apes, the question from a creationist is usually, "If humans evolved from apes, why are apes still around?" This article's argument lets creationists bog the argument down by deliberately not understanding nuances, and seemingly small truths that will undermine the creationist arguments.

If you're going to argue with creationists, don't do this one. Use the "well actually, humans and apes have a common ancestor" one. You'll do better against bad faith, willfully moronic argumentation.</comment>


Bynamite - Privacy Is Dead, Take Control (what advertisers know about you) - <AUTHOR> http://www.bynamite.com/ <comment><USER2> i'm curious about this - anyone use it? it looks like it's a "privacy spin" on a service that will be sold to advertisers as improving accuracy / response (because people are indicating what they _do_ want to receive advertising for). so i guess if you're in the win-win camp it might be quite cool.

if you're in the cantankerous bastard camp, I just installed the RequestPolicy plugin and it's pretty neat - <http://www.requestpolicy.com/></comment>