Show HN: Anycoin Trending – Algorithmic Cryptocurrency Newsfeed - <AUTHOR> https://anycoin.ai/trending <comment><USER2> Nice work, easy to quickly catch up on the news. Are you also running an ICO?

<comment><USER3> Thanks! Really appreciate the positive feedback.

We are indeed doing a private token sale. You can find more info on the AnyCoin project at this page and if interested can get in touch through the contact form: [https://anycoin.ai/](https://anycoin.ai/)

</comment></comment><comment><USER4> Very interesting! It would be very educational to see a Github repository of the code for this. Could you? Would you?

<comment><AUTHOR> Thanks!!

Ooh - good call on the repo. -Let me clean it up first :)

</comment></comment><comment><USER5> Waiting for github repo to be shared, thanks.</comment>


Suspended animation is becoming a life-saving medical procedure - <AUTHOR> http://nautil.us/issue/22/slow/how-to-turn-your-dog-off

<comment><USER2> I've read this guy's papers in the past and the premise, which is interesting, is basically cells can't die if they don't have the necessary chemicals to metabolize. The mouse experiment was pretty unique (suspended animation at room temperature).</comment>


Statistical Data Mining Tutorials - <AUTHOR> http://www.autonlab.org/tutorials/

<comment><AUTHOR> I was in Andrew's AI course at CMU! Best lectures ever!</comment>


'Snooper's charter' will cost British lives, MPs to be warned - <AUTHOR> http://www.theguardian.com/world/2016/jan/06/snoopers-charter-will-cost-british-lives-mps-warned <comment><USER2> Summary: A bill will expand the surveillance capabilities of Britain's equivalent to. A former NSA director believes it will collect so much irrelevant data that their analysts will be unable to efficiently find useful information on terrorist attacks or similar. The lost lives are a reference to people who may die in attacks that could have been prevented had they collected data in a different manner.

<comment><USER3> This argument doesn't seem to have made much difference to the national DNA database[1]. Innocent people have had to go to court to get the rules changed and to have their DNA taken off the database.

"They" want everyone's dna on the database. And police have said that there's no reason to take a person's DNA off the database.

Your DNA is taken and added to the database if you're arrested. You don't have to accept a caution; nor be tried, nor convicted, of a crime for them to keep it. Some people can apply to have it taken off, but it stays on their for two years for everyone.

With the current climate I can easily see "all immigrants need to go on the database" being populist bit of legislation.

[1] typing that name, about my country, feels weird and wrong.

<comment><USER4> Yes but with a complete DNA database you can match an external sample exactly to the database with (near) complete accuracy. The DNA database doesn't tell you anything itself.

With a database of all communications you have to mine it for probabilistic leads. The signal to noise problem grows as does the database.

Someone else (I cant recall who) said - the last thing you need when looking for a needle in a haystack is more hay.

<comment><USER5> How many years till they start analyzing the DNA for behavioural risk factors?

</comment></comment></comment></comment><comment><USER6> Did anyone think of the new Apple building when they saw that picture? Wonder if that's a coincidence ;-)

<comment><USER7> Prior art. The Doughnut was built in 2003. :)</comment></comment>


The world's longest and deepest sub-sea road tunnel [pdf] - <AUTHOR> https://www.vegvesen.no/_attachment/1875547/binary/1184044?fast_title=Rogfast+in+English%2C+May+2017.pdf <comment><USER2> A more detailed map: [https://www.vegvesen.no/_attachment/1865792/binary/1182925?f...](https://www.vegvesen.no/_attachment/1865792/binary/1182925?fast_title=Oversiktstegning+Rogfast%2C+mai+2017.pdf)

A good video of the whole project: [https://www.youtube.com/watch?v=4vp19pRTJ9s](https://www.youtube.com/watch?v=4vp19pRTJ9s)</comment>


Amazing '80s Ads From Omni, the Mag That Defined Geekdom - <AUTHOR> http://www.wired.com/underwire/2014/02/omni-advertisements/#slide-id-464251

<comment><USER2> Wire'd selection missed the best ad of all: in the very first issue was an ad for Rockwell aerospace. It was an iron-on transfer with a picture of the Space Shuttle and the words, "A Spaceship Has Landeded On Earth. It Came From Rockwell."

I cut that ad out and ironed it onto a white T shirt. Dunno how much an undamaged copy of the first issue might fetch, but that T shirt was worth it.

(posted on the Wired site too before I remembered that I got there via an HN link, so sorry for the dup).

</comment><comment><USER3> hmm I thought that was mondo 2000 - I recall having to goto forbidden planet (the uk biggest sf book shop) to buy my copies of mondo 2000 which where racked together with skin 2 :-)

</comment><comment><USER4> Omni is so much more interesting, open minded, and intellectual than most of today's geekdom... it's sad.</comment>


What Makes Remarkable People... Remarkable? - <AUTHOR> http://blog.sokanu.com/what-makes-remarkable-people-remarkable

<comment><USER2> This is one of the best articles I've read in a long time. Long, yes, but very, very, valuable.</comment>


Why Exceptions Suck - <AUTHOR> http://www.ckwop.me.uk/Why-Exceptions-Suck.html <comment><USER2> _Exceptions are a super GOTO. Rather than allowing you to jump anywhere in the position of the procedure, they allow you to teleport up the call stack to any number of handlers._

Wrong. Exceptions, unlike GOTOs, can't jump straight into a loop or any construct that has a local state. In fact, exceptions never break local states, and that's their beauty.

The best proof that exceptions don't break anything is that you can always represent a throw/catch cycle with IF's, RETURN's, possibly also subroutines, but there will be no GOTOs. You will have equivalent functionality, except the code will be a bit bloated and less readable.

<comment><USER3> What about the case of "finally" blocks executing after return?

<comment><USER2> You mean, how can that be replaced with ordinary operators? If you have multiple return's, move your 'finally' block to a separate function and call it before every 'return'.

<comment><USER4> I have never been able to use the finally block. I have yet to see an example where you would want to use it.

<comment><USER2> In languages with implicit construction/destruction facility, like C++, you'd probably live happily without the finally block. There are however situations in C++ when you want to create a class with ctor/dtor only to make sure some block is executed when going out of scope, no matter how. That dtor would be your finally block.

<comment><USER5> Indeed - once I discovered __del__ in Python, I immediately started to do it that way instead.

</comment></comment></comment></comment></comment></comment><comment><USER6> He argues that developers are generally too stupid and lazy to use exceptions correctly (which may be true), but if they instead are forced to use manual error code checking (which achieves the same, but requires typing lots of tedious and fragile boilerplate code) - they would do it diligently and correctly.

I'm not sure I buy that.

<comment><USER7> I didn't really think that that was his core argument. From my reading, he was saying this:

1) Exceptions that arise from a bug should just assert 2) Exceptions that arise from an expected 'exceptional' are actually part of the true logic of the program, and shouldn't be shunted off into a catch/rescue block, because that increases the temptation to consider these as being some how subordinate to the 'happy case'. 3) The fact that exceptions are easy to propagate up the stack means that they can break encapsulation, and it becomes easy for lazy programmers to not treat special cases correctly.

Of course, I may be completely wrong about that, but I just thought I'd share what I had understood, as it's apparently different to your interpretation.

<comment><USER6> I agree with you interpretation, I just don't agree with the logic that if developers are too lazy to handle exceptions, they will do the alternative (checking and handling return values) correctly, since it is just as easy to ignore an error code return value than it is to ignore an exceptions.

And if we agree that lazy developers might not handle every error, the "default case" with ignoring exception (the exception propagates to the top and kills the program) is much preferable than the default case without: the program state becomes corrupted, but the program keeps running.

Another point: Exceptions are not for cases which can be handled as part of the normal flow. Rather they are for exceptional cases which requires you to break out of the current context and handle the error on a higher level. So if you use exceptions correctly they don't break encapsulation, rather they help encapsulation since you can handle errors at the appropriate level.

</comment></comment></comment><comment><USER8> _For a start, unless you're Google, attracting talent is hard._

Why do people keep parroting this?

 _It's much harder to use a return code badly_

Return codes are almost always ignored. In straight C, errors are a real pain. They just are. In working code, the evils of exceptions don't come up, because you don't get exceptions for the most part. As a practical matter, they're just debugging tools, and not control handlers.

<comment><USER9> _In straight C, errors are a real pain. They just are. In working code, the evils of exceptions don't come up, because you don't get exceptions for the most part. As a practical matter, they're just debugging tools, and not control handlers._

This is 100% true. I was once trying to do something with POSIX semaphores on OSX and while the code compiled without so much as a peep and ran, the semaphore didn't seem to be working. Only after meticulously examining my semaphore calls and printing out the error codes was I able to discover that sem_init doesn't work on OSX. (At least this was my experience). This would have saved me hours of debugging time if the compiler spat out a warning instead.

<comment><USER10> Well, sorta. Honestly, the problem here was that your platform sucked. If sem_init() "doesn't work" on OS X (is that really true?), there's no guarantee that the putative exception-enabled version would be properly throwing an exception either. Exceptions can be really useful, but they won't fix broken libraries for you.

And it's also true that the POSIX synchronization primitives are a good example of how _not_ to implement error handling in a C API. Too many things that are fundamentally usage errors (and should be caught at compile time) are flagged at runtime, leading to the silent failure issue you saw.

<comment><USER9> You're right, my post had less to do with exceptions and more to do with venting my frustration at the less-than-helpful C error handling system. It's not good when the API makes you think you're losing your mind.

</comment></comment></comment></comment><comment><USER11> When reading C code either all return codes are checked or not. Either way you know whether errors are dealt with. If you don't check a pointer before dereferencing it - the code is wrong. It's that simple. Correct code looks correct, crappy or unfinished code looks crappy or unfinished. This is a good thing.

When you read Ruby code you have no idea if the programmer thought about exceptions at all. In order to figure out what exceptions should be possibly handled you have to take the union of all the exceptions that can be thrown by all the functions you call, and _then_ check if they are all handled correctly. Unfortunately, it's impossible to determine which exceptions can be thrown by a function, because any function can throw any number of exceptions. If your buddy decides to throw a new exception in some helper function then the exception signature of a hundred functions changes.

So basically, there's no way of telling whether the code is correct. Good luck with that. So people give up and just rescue every possible error and return a default value, excactly like described in the article.

For your enjoyment:

[http://www.google.com/codesearch?q=lang%3Aruby+rescue&hl...](http://www.google.com/codesearch?q=lang%3Aruby+rescue&hl=en&btnG=Search+Code)

And this is _production_ code you're looking at.

<comment><USER12> _If you don't check a pointer before dereferencing it - the code is wrong._

Really? This might be true after a malloc or another system call, but in general, your modules should have specifications. If you have written a function which states that the incoming value must be a pointer to some value, that pointer shoud _never_ be checked before dereferencing it. It's the caller's job to ensure that a valid pointer is sent.

Blindly checking for errors that will never come up is not much better than not checking at all.

</comment></comment><comment><USER13> Exceptions in mainstream languages have a fatal flaw: they unconditionally unwind the stack when thrown. This sacrifices flexibility and makes it unnecessarily difficult to save state or take action at the point of the throw. Of all languages I've ever seen, only Common Lisp really does this right by separating out the concept of signaling a condition and of handling it.

I don't want to get into the details here, but Kent Pitman wrote a great paper on the subject: [http://www.nhplace.com/kent/Papers/Condition- Handling-2001.h...](http://www.nhplace.com/kent/Papers/Condition- Handling-2001.html)

</comment><comment><USER14> I think his article should be called "unexpected errors suck". Sure, it would be nice if there were never any errors, but there are, and you have to handle them somehow. Compare:

       try {
          connect_to_database;
          prepare_query("SELECT * FROM ...");
          run_query;
          return results;
       }
       catch database error {
          warn "Whoa, your database is broken!";
       }

To a language without exceptions:

       dbh = connect_to_database;
       if(!dbh){
          errno = 0x23843;
          return NULL;
       }
       statement = prepare_query;
       if(!statement){
          errno = 0x28783;
          return NULL;
       }

At this point, I'm tired of typing the code. Checking for errors after every function call is way too much work, especially if future instructions need to past ones to have been successful. Exceptions let me break right out of the related block, and do something to fix it. If I don't do something to fix it, someone up the call stack can fix it.

I don't think exceptions suck. Errors are what suck.

<comment><USER15> The problem with the above code is without exceptions you know where the program failed 23843 or 28783 but with exceptions all you know is something is wrong.

<comment><USER16> bzzt. depending on the language and the author of the exception-throwing code, the exception will contain information about where the error occurred and what might have caused it.

<comment><USER15> True, but in the above code such information is not propagated outside of the function. If you want to add that you need to throw another exception inside of the catch block or skip the catch.

<comment><USER17> Which is exactly the right thing to do. I don't see the problem.

<comment><USER15> _At this point, I'm tired of typing the code. Checking for errors after every function call is way too much work_

Think of what the exception code ends up as in ASM. Basically _try_ transparently wraps system calls with the same type of error handling code as his example. However, if you want to write stable code you need to account for each of these errors anyway. So when your DB connection fails you need to know if it's a TCP/IP error or a Bad Password etc which means either wrapping each line with its own try catch or decoding the exception within a catch block. Granted, exception handling let's your write code for the ideal case and avoid crashing when something messes up but as soon as you want to recover from an error without starting over you end up writing the same code anyway. And because the happy path works it's not obvious just how far you are from high quality code.

<comment><USER16> See my later comment about expected errors versus unexpected ones. Exceptions were never meant to replace good error-handling code.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Exceptions suck, but I really think this is going the wrong way.

Exceptions usually suck because people are trying to graft some kind of complicated event handling system on it, to which it's not suited. Frankly, this sort of thing is better handled by co-routines. Exceptions suck because they're the often the only way to do something without more explicit control flow.

On top of this, we're supposed to be able to check everything and write error checked code, but suppressing errors can be surprisingly beneficial: observe, say, DRYing out deep checks <http://code.causes.com/blog/drying-out-deep- checks>.

One of the reasons GOTO sucked so much was because at the time it was all we had. Now it isn't. Explicit control flow is useful and important for certain tasks (like network programming).

</comment><comment><USER16> This kind of argument also seems to miss something important: that exceptions (at least in C++, but this argument probably applies to other languages as well) aren't intended as a general-purpose error-handling mechanism, which return codes are perfectly adequate for.

Exceptions are intended for unexpected conditions (i.e., exceptional) that must be handled somehow. In C++, this is pretty fundamental to the RAII idea.

</comment><comment><USER19> I agree with his premise that exceptions get misused by "average" developers. Where I work I see _a lot_ of swallowed exception, which has lead to some evil bugs. I have also encountered some code that's literally impossible to write meaningful test code for because every exception is swallowed and there's no return code.

However, I don't think that going back to checking return codes solves anything. Most of the problems I see at work are related more to checked exceptions than using exceptions in general. Thankfully, most of java frameworks I use have moved towards making everything an unchecked exception.

<comment><USER14> I only write Java on very rare occasions (usually for clients that don't care if the code is throw-away quality), and so I usually end up with a "throws Exception" after every method. Horrible, but hey... it's not _my_ fault Java sucks so hard.

<comment><USER10> No offense, but yeah: that's pretty horrible. Checked exceptions are one of Java's few true innovations. Used properly, they force you to handle errors in the spots where they occur. What you're doing is a 1:1 equivalent of ignoring the error codes returned from your C functions. That's just never the right way to do thing.

<comment><USER20> Exceptions are not meant to be handled where they occur, that's why they unroll the stack. For the most part, you can't recover from an exception -- you just abort whatever you're doing, print an error message, and let the user try something else. Checked exceptions cause developers to re-interpret the exceptions or just swallow them -- neither is a benefit.

<comment><USER14> Exactly. If the database server blew up, there's nothing my program can do. I could try reconnecting, and some libraries do, but that doesn't usually help anything. Once the server is back up, the Fibonacci (or exponential) back-off is so high that's it's faster to just restart the program manually. So usually, dying is easier for everyone.

</comment></comment></comment></comment></comment><comment><USER21> The problem with exceptions is that most developers using them don't use them well, which does kind of mean that they should be avoided if you're not sure you need it. But I don't think that they have no place in running code. (Since I write mostly Javascript, try/catch is so expensive that it's usually not worth it, especially if you build your site so that it works when the JS doesn't, which is just good practice.)

I recently came across something like this, which struck me as a horrendous abuse of "exception" handling:

      // drastically simplified so as to not make anyone nauseous/crazy:

      try {
        $x = doSomething();
        doSomethingElse($x);
        if (!$x->foo) {
          $x->foo = "bar";
          throw new NoFooException($x);
        }
        doSomeMoreThings($x);
      } catch NoFooException {
        handleNoFooCase($x);
      }

Not 10 lines later, in the same function:

      do {
        ...bunch of code.
        if (!$x) {
          break;
        }
        bunch more code.
        if (!$y) {
          break;
        }
        bunch more code.
      } while(false);

followed by new fewer than 3 other "clever" control constructs.

Frankly, GOTOs would have been easier to follow.

</comment><comment><USER22> I have lived this kind of crap before. New job. The boss has some fringe idea that makes life more difficult for everybody. But until now I haven't seen this. Exceptions suck. Yeah, sure.

</comment><comment><USER23> Exceptions suck. Prefer monads.

</comment><comment><USER24> """Can't this be fixed by hiring better developers?"""

The answer is _yes_.

</comment><comment><USER12> I personally thought the article was garbage. The author rehashed a lot of old ideas and lumped together a bunch of anecdotes without giving much new insight.

The thing that really bothered me is that I got the distinct feeling that the author is only parroting old advice, without actually trying anything himself.

In particular, he said that exceptions are expensive in any language. In Python in particular, exceptions are no more expensive than any other control structure, as that was an explicit design decision.

Exceptions _work_ , that's all there is to it, but they _have_ to be documented. The Python documentation is a very good example of this. For the built-ins in particular, every single operation states what type of exception is thrown in what case.

Exceptions can be very effective if:

1\. Each function/method documents what exceptions it throws under what circumstances.

2\. Exception causes are thoughtfully separated into different types. One example of a violation of this principle that has frustrated me recently is Python's os.makedirs function, which recursively creates a hierarchy of directories. This can cause an exception if one of the directories cannot be created for some reason (permissions, desired directory is an existing file, etc.) or if the leaf directory already exists. In some cases, the latter case really is not an error (you just want "mkdir -p" functionality), but it's hard to distinguish between the two cases.

3\. The proper exceptions are caught. Too often programmers attempt to catch every exception and re-propagate it (or worse, ignore it). In many cases, exceptions are only meaningful during debugging, and once minor issues are worked out, the exceptional case is guaranteed to never occur. These types _should be allowed to propagate to the top-level and crash the program_ , that is the whole point of the exception. In other cases, the programmer needs to be aware of what exceptions may occur (see 1), to reason about how such cases should be handled (if at all, perhaps allowing it to pass up the stack makes sense), and to handle it appropriately. Only in a top-level logger for a long- running program should a catch-all exception ever be used.

...and that turned out much longer than I initially planned. I am just tired of hearing the same old "exceptions are bad because people will use them to mask real errors" argument repeated over-and-over, when no programmer worth anything would ever do that. Also, this popular comparison of exceptions to GOTOs is ridiculous. The article on GOTOs was written at a time when spaghetti code which jumped all over the place to save repetition was not at all uncommon. Thanks to more recent constructs like do...while, break, continue, for loops, function objects, and more, crazy "old school" code patterns are much less common. To march that argument out today any time someone dislikes a given control flow structure is a disservice to the original paper (which was actually addressing _real_ problems in code structure), because the comparison invariably is between apples and oranges.

</comment><comment><USER25> Except for the point about exceptions being like GOTO, I fail to see how any of this differs from the complexities of procedurally handling return code errors. Exceptions give you a better way to distinguish error handling from control flow.

I'm not even sure I understand how GOTO is unmitigated evil. Occasionally it can be the clearest way to break out of a nested loop. Doesn't the Evil GOTO song and dance come from an ancient era when it played a completely different role in languages?

<comment><AUTHOR> _Doesn't the Evil GOTO song and dance come from an ancient era_

The languages may be ancient, but the era is not.

I'd be willing to bet more than half the production code running now has ancient GOTO capability and half of that is misusing it.

(Apologies to Churchill) Never was so much earned by so many maintenance programmers from the misuse of so few letters.

</comment></comment><comment><USER26> Flagged. What a shit post.

This is mostly a complaint about shitty developers than about exceptions.</comment>


A Sneak Preview Of Dropbox's (YC S07) Upcoming Android App - <AUTHOR> http://techcrunch.com/2010/03/22/dropbox-android-app/

<comment><USER2> Between this and selective syncing, I don't know which one I've been wanting the most. This news is fantastic, and it looks like it will be everything I'd hoped for. Now push it to the Market already :)</comment>


AI-generated fake content could unleash a virtual arms race - <AUTHOR> https://venturebeat.com/2019/11/11/ai-generated-fake-content-could-unleash-a-virtual-arms-race/ <comment><USER2> These deep fake articles are becoming a meme. They mostly seem alarmist, and yet they're not authored by people actually in the industry.

Deep fakes automate what deep pockets and state actors could already do with Photoshop and other professional tools. The world isn't going to become a scary place because the barrier to entry got lower and the technology has been democratized. People are smart. Fakes will be detectable through entropy measures, corroboration, common sense, etc.

FWIW, I've been working on real time voice to voice style transfer.

[https://drive.google.com/open?id=1zRvJEGJjTpKvvzel-J0agh3fKB...](https://drive.google.com/open?id=1zRvJEGJjTpKvvzel-J0agh3fKBn9aqGy)

There are already a few other (non-real time) players in this field.

I'm hoping to spin this up as a small social app or filter and sell it so I can fund my capital-intensive film making startup.

I think this tech _should_ be widely available. Not only will it make people think and question more, but it'll be fun too.

It's also amusing (and terrifying) to see all the anti-1st Amendment legislation aimed at combating deep fakes. The truth is that there is nothing to fear except our freedoms being taken away.

<comment><USER3> I don't think you should dismiss these concerns so quickly. It sounds like you have experience in this field. Perhaps that would make it easier for you to spot potential fakes? What about your grandma? How would she fare?

And besides, the end game isn't to fool everyone into believing a fake. No, the more insidious goal is to flood the zone with enough dis- and misinformation to overload our ability to filter it. It's like gaslighting at scale- at some point you just stop being able to process information because it's so voluminous and of dubious quality that you stop believing any of it.

<comment><USER4> > What about your grandma? How would she fare?

Grandma's still falling for the phone and mail scams. No amount of legislation is going to fix the reality of technological illiteracy among the oldest adults.

Deepfakes might fool some of today's adults who don't quite understand, but we are raising a generation that has turned into a meme: "Everything you read on the internet is true" -Abraham Lincoln

I think the real silver lining here is that the internet is an alternate reality. Many of us refuse to believe that, but social media has created manufactured people. The only solution is to bring people back to the real world. The people are real here. Their opinion, no matter how controversial, comes from a real mouth, and the face you see is the one they were born with.

If anyone forms their worldview based entirely on things they read on the internet, they probably would be just as susceptible to our real world forms of propaganda/gaslighting/ whatever you want to call it.

<comment><USER5> This essentially means the web is too difficult for some users and they need something else, like maybe an app store. Maybe some company will win big by providing a safer (or apparently safer) alternative?

Previous examples: Gmail had a better spam filter. Apple and Google did a better (though not perfect) job of protecting users from arbitrary code execution, as did the web itself, way back when.

This doesn't happen all that often, but if it succeeds, power users will scoff at how nerfed the new thing is.

I'm reminded of an old story [1] about an early game for children:

> I found myself unable to reconcile the idea of a virtual world, where kids > would run around, play with objects, and chat with each other without > someone saying or doing something that might upset another. Even in 1996, we > knew that text-filters are no good at solving this kind of problem, so I > asked for a clarification: "I'm confused. What standard should we use to > decide if a message would be a problem for Disney?"

> The response was one I will never forget: "Disney's standard is quite clear: > No kid will be harassed, even if they don't know they are being harassed."

But maybe text filters will be better if you throw enough machine learning at the problem?

[1] [http://habitatchronicles.com/2007/03/the-untold-history- of-t...](http://habitatchronicles.com/2007/03/the-untold-history-of-toontowns- speedchat-or-blockchattm-from-disney-finally-arrives/)

<comment><USER6> > _This essentially means the web is too difficult for some users and they > need something else_

I think you are on the right track, but not going all the way. The bigger issue here is that media literacy is _incredibly_ hard. You need a wide body of knowledge, essentially an educated[ß] mind, and an almost unhealthy skepticism against absolutely everything you read, see or hear.

As a short cut, a good first approximation is to be a cynic. Assume everyone is pushing their own agenda, and that even at best you can only see half of it.

(If you are asking yourself what agenda _I_ am pushing with this post, well done. You're off to a good start.)

ß: The ability to question information, conduct research, cross-check the results of research, and have the mental agility to identify your own biases - these are not natural tendencies, but learned traits. We can lump them all under the "educated" label, even if that's not the optimal term.

<comment><USER5> Yes, it is hard. But I think it's not just education, but epistemic humility. We have no direct knowledge of what's going on in other parts of the world. The past is often not recorded accurately, the future often unpredictable. So our default assumption should often be that we don't know what's going on.

Highly educated people in the grip of an ideology can dream up conclusions far beyond the limited and unreliable evidence we get from media consumption. They are often rewarded for this.

And one of these ideologies is the myth of rugged individualism (or competent adulthood), the idea that each person can and should figure out what's going on by themselves. It's obviously not true of children and the elderly, but most of us outsource a lot of our thinking. Living in modern civilization inherently means having a lot of trust and dependency on others.

The ideals of media literacy are simply unrealistic for most people. It's not clear what the alternative is, though.

</comment></comment></comment></comment></comment></comment><comment><USER7> This pretty much describes the end of the internet as we know it. Even before AI generated "content", the internet has become lower signal-to-noise as time has moved forward.

It is already the case that for many everyday searches I do, I am forced to be very creative in my search phrase in hopes of filtering out the garbage sites that manage to dominate the first results page.

Watching less tech-saavy people use computers (such as elder family) is enlightening and frightening. They either cannot tell real content from fake content, or worse they are satisfied with what they get from obviously suspicious sites.

Maybe my concerns of polluted websites are less relevant considering the general population is getting more of their "information" from within Facebook rather than even going to search engines (of which they use the default for their browser!).

<comment><USER8> New companies and technologies will be invented to solve this problem. Every problem has a solution. You are falling into the same trap that has caught humans since the dawn of man. The printing press, the car, the internet, and now "deep fakes" will cause hand wringing but will not destroy us. Just give it time.

<comment><USER9> >The printing press, the car, the internet

These all came with real tradeoffs and we've just accepted them. The printing press and the internet, in their own ways, sped up the world and shortened attention spans. Cars changed cities. The benefits have been there, but we've engaged with or ignored the harms posed by changes in different ways, and the same unconscious trade is going to happen again.

</comment></comment></comment><comment><USER10> Considering video, audio are accepted as evidence in most courts without any independent verification; I'm seriously worried about the implications of deep fake on justice.

There is an urgent need gap[1] on detection of deep fakes.

[1]:[https://needgap.com/problems/21-deep-fake-video-detection- fa...](https://needgap.com/problems/21-deep-fake-video-detection-fakenews- machinelearning)

<comment><USER6> Risky Business did a really good interview on the subject early last year[0]. Law profession is already aware of the potential problems.

Me? I welcome the future where audio and video evidence are just another piece of evidence.

0: [https://risky.biz/RB489/](https://risky.biz/RB489/)

</comment></comment><comment><USER11> We've had fake photographs for decades and it hasn't seemed to make a big difference in politics. But I think that's because in the past you had gatekeepers, like the editors and factcheckers of "respectable" publications, who would ascertain the legitimacy of a picture before using it. They'd make mistakes sometimes, but got it right 99% of the time.

Now news spreads horizontally through social media and group chats. It's common to see, say, a clip purportedly of police brutality right now in country X, which is actually 7 years old and from country Y. Someone will correct it, someone will dispute the correction, whatever - the damage is done. So I don't think deepfakes will move the needle much. The real damage is the end of gatekeeping, and that's already happened.

<comment><USER12> We haven't had high-velocity media for decades, and information is easier to make extremely false and get believers than photographs. You can't create a complete narrative through photos alone. You need associated information.

</comment></comment><comment><USER13> Well, this probably means end of unsigned content ; every line of text, every article, etc should be / will be signed by living person's key, or it will be heavily penalized in search engine output; governments will run keystores with citizens' keys, and content signatures will be checked against such keystores to ensure content authenticity (or lack thereof) . Time to reopen GPG , I guess.

</comment><comment><USER14> I was experimenting with this stuff and you can too here [1]. It's kind of impressive but not convincing. The main impression it gives is it doesn't know what subjects affect which objects, what one kind of relation implies about another relation and so-forth. Still, it gives a sequence of words with a consistent "feel" which is impressive.

However, I would still only find it's text convincing for producing ... a marketing blog since such things just seem like a contentless stream of buzzwords to begin with. If anything, it gives a certain idea of how marketing speech require something, a stream of words with certain feeling, but not real logic.

[1] [https://talktotransformer.com/](https://talktotransformer.com/)

<comment><USER15> I built [https://writeup.ai](https://writeup.ai) to help with that, but while it helps, it still feels like it's missing "something" at times.

<comment><USER14> The thing is that I think language over a longer term is about actually communicating a structure to world - in a way that requires knowledge of the world. It is just that over a shorter period, a good portion of language isn't about this communication but about just certain coloring of communication. Which is to say that I think this lacks more than it seems at first blush.

</comment></comment></comment><comment><USER16> OTOH: I'm pretty excited that these technologies are maturing so that they can be harnessed for empowering common people, or workers in enterprises to make their content beautiful, simple & into effective stories.

One example: Pentagon's slide decks. [https://archive.org/details/MilitaryIndustrialPowerpointComp...](https://archive.org/details/MilitaryIndustrialPowerpointComplex)

</comment><comment><USER12> The effects of an ever-higher velocity of fake news isn't clear, but there is no "solution".

Real news not believed, fake news believed has been an unsolved problem for a long time. For example, the history of medical advances show doctors not believing exceptionally solid science in many cases.

There are a number of quotes about progress along the lines of "First they say it's impossible, they they fight it, then they say they believed it all along".

This is a people problem and a media velocity problem going back to the famous quote "A lie travels around the globe while the truth is putting on its shoes."

You can't stop people from believing a lie after it has been released. Removing the lie doesn't help. "Reputable" sources not repeating the lie doesn't help.

</comment><comment><USER17> We shouldn't talk too much about our skepticism on this becoming problematic. Otherwise believable skeptic text can be generated by malicious actors through AI once it does become problematic so that they can drown out real concerns with virtual trolls.

</comment><comment><USER18> This has been true long before ai. Writing and journalism have always been weaponized. The opposite could be true in that it's easier to recognize automated fake news than well crafted hand done human deception.

</comment><comment><USER19> People very concerned about this should spend some time reading ${opposing political group} social media. As you'll discover, people will believe what suits them. Veracity is of remarkably little interest to a remarkably high percentage of the population. Most people, and this is not an exaggeration, would sooner kill/die than change their mind. And if that's true, then consider the mental acrobatics individuals are willing to go through before they even reach that point.

</comment><comment><USER20> I have personally yet to be convinced of AI generated media content (read articles, videos, photos) maybe the bias that I know that they are AI- generated, but to me it's equivalent buying a cheap knockoff iPhone from China: it'll work if you don't really think about it, or do not know the difference.

We have to top-up education and teach media-awareness in school, while giving badly researched and generally toxic content the cold shoulder.

</comment><comment><USER21> I try to take a different direction. Let's suppose some ai generated content is better than human created content (IMHO we are quite there). Let's go further: maybe in the future we will trust again only some "trusted sources" (newspapers? HN?) while everything else will be not taken into account because the quality will be low (like some comments saying the source is not in the industry...).

<comment><USER22> >> maybe in the future we will trust again only some "trusted sources" (newspapers? HN?) while everything else will be not taken into account because the quality will be low (like some comments saying the source is not in the industry...)

Do you realize that current conversational NNs are better at making comments than you?

<comment><USER21> Yes. That's the point :)

</comment></comment></comment><comment><USER23> I often wonder if Ranker, Thrillist, Collider, Vulture are all AI based. The seem to show up in every search

</comment><comment><USER24> All tech demos without strong use cases yet. Machine-generated content, spinning content, etc. are black hat tactics employed for decades in order to game Google. Works (just look at what crap ranks high) but the foundation for new huge industries? No.

</comment><comment><USER25> I am going to take the contrary opinion here. AI-generated fake content will inflate away the informational value transmitted by whatever it is trying to fake. It's like 'deep fakes', they'll just destroy trust to video.

</comment><comment><USER26> I might be wrong, but on some social networks as Reddit, many comments or shared links seem too weird, like if they were not real, and some posts that get resposted always end up with the same comments or similar words.

</comment><comment><USER27> Looks like this would be the new form of spam we will have to fight.

</comment><comment><USER28> How do we know this article was not generated by a bot?

</comment><comment><USER29> Doubtful. It's easier to photoshop fake content and we haven't seen that get out of control.

</comment><comment><USER30> Wow that AI-generated blog text actually made sense! The best I have ever seen. How did they do it?

</comment><comment><USER31> muching virtual popcorn</comment>


Heading Back from WWX (Thoughts on Haxe) - <AUTHOR> https://medium.com/@back2dos/heading-back-from-the-wwx-716bb5f3905d#.m6n69bjvs <comment><AUTHOR> This was a great personal stream-of-consciousness article on WWX and Haxe. I personally had a few jaw dropping moments, in particular when the Kha editor was able to debug shader languages with breakpoints.

It's been interesting to watch a language like Haxe grow organically without a corporate patron. Go, dart, swift, etc. are all great, but there's a bit of risk hitching your horse to a platform backed by a company _cough actionscript cough_. I realize that most languages now are open source, but I doubt many of them would survive without strong company support. In fact, I think only Ruby can claim to have made it "on their own", mainly thanks to Rails.

The governance issue will get solved I think. I don't think it's a problem with one (or a few) people. There's an implicit mistrust of bureaucracy that I think is merited.

Finding the right balance here will be tricky, and I don't think that Haxe can blindly follow governance models from other languages and communities. But, it's clear that Haxe leadership needs to grow along with the rest of its ecosystem.</comment>


THAT TIME a CONFEDERATE FLAG PARADE ENDED IN a PICKUP TRUCK CRASH - <AUTHOR> http://www.fastcompany.com/3047987/the-recommender/god-dont-like-ugly-that-time-a-confederate-flag-parade-ended-in-a-pickup-tr

<comment><USER2> "Although some people view the flag as a proud symbol of Southern heritage, that history is undeniably stained with the flag's only true meaning: slavery."

A flag's symbolism or meaning is only what a group of people decide to make it. Since the article even states that it's about southern heritage, this is a meaning to many.

Using this exact same logic, we should remove any flags that have the symbols of Islam on them because for a percentage of the Islamic population, it is symbolic of murder, rape, and the destruction of the US.

I also find it a little concerning that we are removing all confederate flags, not just in government buildings (which is fine, if the people decide). Why? It's erasing history. We need to know about history so we don't repeat it.

Otherwise, in the future, I can just deny it ever happened. After all, at some point you won't be able to show me proof any longer.</comment>


Death to LDAP and SAML – Round 2 - <AUTHOR> https://www.inversoft.com/blog/2015/12/17/death-ldap-saml-passport-lives/ <comment><USER2> Ad. Written by marketing.

</comment><comment><USER3> Agreed, this really isn't something interesting. It's an advertisement.</comment>


Migrating Slack's Desktop App to BrowserView - <AUTHOR> https://slack.engineering/growing-pains-migrating-slacks-desktop-app-to-browserview-2759690d9c7b <comment><USER2> What the hell is taking up all that RAM? Slack is using over 800MB of RAM on my computer right now, and it's completely idle. I've got a C# process on my computer right now handling thousands of messages _per second_ and consuming 1/20th the RAM. If you rebuild Slack in Xamarin you'd probably drop your RAM consumption to under 50MB, just a guess. JS fiends are gonna tell me C# ain't JS, and I agree. TypeScript ain't JS either, and it's a hell of a lot closer to C# than it is JS.

I'm a big JS guy, believe me, but I wouldn't call a chat app using "only" 800MB of RAM a "win." Sorry to the guys who worked hard on this.

<comment><USER3> Even if it was done in Xamarin, you'd still need some kind of web client / browser to fetch and render the actual slack workspaces

<comment><USER4> Why use web at all? IRC clients have been made with native UIs since the 90s.

<comment><USER5> Harder to work with than CSS. Harder to align look of web and desktop.

<comment><USER6> > Harder to align look of web and desktop

This is what I don't want, I want it to look like every other desktop app, I want to be able to set the theme of my OS and have every app adopt it, I don't want every piece of software thinking it's special and looking different.

> Harder to work with than CSS.

What native technologies have you used? Many are easier than css+html and look native by default.

<comment><USER7> It will happen when companies stop being rewarded for branding, which is to say never.

</comment></comment></comment></comment></comment></comment><comment><USER8> As a Linux laptop user, I fully endorse Electron. There's so much more available for Linux because of it that would have no client at all otherwise.

Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I'd rather have heavy software than no software.

<comment><USER9> Same here, it's really nice to have VSCode, atom, slack, etc.

RAM is pretty cheap, I'd rather put money towards a better Linux machine than give that money to Microsoft for the OS.

<comment><USER10> Oh what a lovely cycle. Every dev knows 16gb is the new 8gb so sure, why not have every desktop app consist of 20 independent webview/node processes. Can't wait until 32gb is the new 16gb.

Eventually, when every single desktop app is like this, and we can no longer keep shoving more RAM into computers, we'll realise that the only way to manage such hogs is to pickle background apps to disk Android-style and to just have one foreground app in memory. And that's when we'll all realise we might as well switch to Chrome OS. Well played, web devs, Google says thanks.

Or maybe Electron is a conspiracy by someone heavily invested in RAM production?

<comment><USER11> 32 is already the new 16.

<comment><USER12> That's horrifying.

<comment><USER11> That's progress.

<comment><USER6> That's regression. Despite having vastly more memory than 20 years ago I'm not getting anything more done with it.

<comment><USER13> What OS were you using in 1997? I believe I was using Windows 95 then and was definitely getting a lot less done with it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The screenshot shown in the article shows Slack using well over 600 MB of RAM. I'm not sure I find this acceptable for a chat app with four "tabs" open.

<comment><USER15> When these kinds of things come up there's often complaint that desktop apps running in the browser are inefficient. As it happens, I agree. An old favourite of mine, Adium, probably never used 600 MB because I'm pretty sure my PowerBook G4 had less RAM than that.

But I think it's a mistake to jump to the conclusion that these apps should be written in a native framework rather than a web view. Slack is doing much more than Adium: web previews, document previews, pulling in pre-rendered fragments from the server and modular stylesheets. I wonder how much RAM Adium would have used to do the same things, and I wonder how much time the developers of an equivalent cross-platform app would have spent if they had been split trying to optimise lots of different platforms. They would essentially be re- inventing a modular layout and rendering engine (aka a web browser).

I don't know what the answer is. Maybe the detractors would prefer that the app did less. I know I'd prefer not to have previews and emojis, but I'm sure my colleagues find them useful.

(EDIT: Per reply below, turns out Adium did use a web view for presentation!)

<comment><USER16> That's why I'm developing eul, a lightweight native desktop client for Slack, Skype, Facebook etc:

[https://eul.im](https://eul.im)

It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.

1.0 release is going to be out in early November.

<comment><USER17> One thing that concerns me about any 3rd party chat application is that it's difficult to know if my data is secure. Any thoughts on open sourcing your application?

<comment><USER16> Yes! I want to make it open source, from my experience that's the best option for all parties. Unfortunately it won't be possible to open source some parts of the app.

I'm setting up a company right now to increase trustworthiness. Like the home page says, no data will ever be shared with anyone and soon it will be possible to verify this.

<comment><USER18> > Unfortunately it won't be possible to open source some parts of the app.

Why is that? Are you licensing code from somebody else?

</comment></comment></comment></comment></comment></comment><comment><USER19> Christ, so many buzzwords and frameworks and rewrites but all users ask for is a damn chat application with few tabs.

Either I'm getting old and grumpy, or it used to be possible in the year 2000 without your computer fans taking off and 1gb of ram.

<comment><USER20> In year 2000 you might only have to care about Win98. And that's it.

In 2017 there's no tech stack that lets you write consistent UIs across multiple platforms. Except, unsurprisingly, Electron

<comment><USER21> [https://news.ycombinator.com/item?id=14066784](https://news.ycombinator.com/item?id=14066784). Here's a discussion on alternatives. It's really not the only choice.

<comment><USER22> It has become the default in enterprise settings, which can't swap solutions out quite so easily

</comment></comment></comment></comment><comment><USER23> I'm a proponent of Electron for startups just getting off the ground with cross-platform desktop apps.

Slack has raised some serious capital, however. The desktop app is the cornerstone of their product and performance is a known pain point (cpu/memory). Why haven't they left electron in the dust and taken performance seriously?

<comment><USER24> Slack can take performance seriously _and_ stick with Electron. That's certainly what this very article is about: big steps towards better performance.

<comment><USER25> Yes.

Slack switching to something like Qt would (maybe) fix Slack, but then we would still have many slow Electron apps.

</comment></comment></comment><comment><USER26> Spending time on problems you wouldn't have to solve if you would choose your tools more carefully instead of following fads, and still coming up with something very far from optimal.

That would be awesome post if it was made as an experiment, to test the limits of Electron, to learn and let others learn, to just play with BrowserView. But seeing this as a technical write-up about one of the very popular chat apps used out there, it's just sad and wasteful.

</comment><comment><USER27> How about improving boot time? Nobody talks about it, but since Slack uses so much RAM, I like to close it from time to time and open it when I feel like getting distracted.

But then, it takes 30 seconds (!) from opening the application to being able to type the first message. There is no other app on my MBP that needs so long, and we're talking pretty new hardware with SSD and an i7.

Sorry, but I don't care about your portability across different platforms, I just can't. I want the best experience on mine.

<comment><USER28> This is one of the highest priority items for the next quarter or two.

</comment></comment><comment><USER29> On a related note, for an app I have open all day long but interact with on an event-driven basis - Slack's UI is just too darn big. I miss the days when the only chat UI was a small column (eg. ICQ).

<comment><USER30> I think Slack tries to mimic IRC more than ICQ, and all IRC clients I know had big windows, because they assumed you want to see what's happening on the channel at all times.

<comment> forgot-my-pw I wish Slack has multi-window view, like many IRC clients.

</comment></comment></comment><comment><USER31> On macOS, web app wrappers created with Fluid ([http://fluidapp.com](http://fluidapp.com)) consistently use less resources than the official Electron-based versions, in my experience.

It's a wrapper for the system-supplied Webkit, so it inherits those benefits from that. I've been experiencing a similar performance to Chrome in Safari 11, but lower RAM/CPU/GPU usage overall.

<comment><USER32> I used Fluid, now use MacPin. Apps are much smaller, essentially just the size of their JS bundles. But then you're back to cross-browser woes and no native layer.

</comment></comment><comment><USER33> Really neat to see how Redux's design and extensibility make this kind of action serialization and store synchronization possible. There was another similar example recently where someone was synchronizing multiplayer game states via Redux actions [0]. There's actually quite a few addons available related to store synchronization [1].

[0] [http://jimpurbrick.com/2017/01/04/vr- redux/](http://jimpurbrick.com/2017/01/04/vr-redux/) , [http://jimpurbrick.com/2017/07/04/react-vr-redux- revisited/](http://jimpurbrick.com/2017/07/04/react-vr-redux-revisited/)

[1] [https://github.com/markerikson/redux-ecosystem- links/blob/ma...](https://github.com/markerikson/redux-ecosystem- links/blob/master/store.md#synchronization)

</comment><comment><USER34> I think this article is really helpful when deciding to use a nascent technology (Electron) in production- pretty cool you can create a desktop app with javascript, but at the same time, expect to do a lot of custom bug fixing and hope that there aren't issues in the core code (note: there always are) =D

<comment><USER35> This isn't Electron's fault. This is slacks fault. Look at the memory footprint of VS Code opening hundreds of files. A much much more substantial application than slack that uses a small fraction of the memory. On my machine, VS code with hundreds of open files is using just over 200MB.

<comment><USER36> Electron could still be faulty: its multi process architecture makes application developer easier to write memory leaking code.

</comment></comment></comment><comment><USER37> Following a link in the article led me to this nice quote[0] "The trade-off is that positioning and layering BrowserViews is trickier because you can no longer use the normal HTML and CSS positioning and layering primitives like you can with a webview. You have to manually layout BrowserViews and make sure that it is layered properly."

So to make electron less of a hog, you ditch the web part?

[0] [https://blog.figma.com/introducing-browserview-for- electron-...](https://blog.figma.com/introducing-browserview-for- electron-7b40b4b493d5)

<comment><USER38> Obviously not, clearly the point mentioned just has to do with the macro layout of one or more browser frames. It sounds like they moved from a model like <iframe> to <frameset>

<comment><USER24> More like moving from <iframe> to open in new browser tab and then working to position the new tab is if it were an <iframe>.

</comment></comment></comment><comment><USER39> Unicorn level startup. Still makes html based app.

</comment><comment><USER40> Dead Slack:

Stop being lazy. You're not a scrappy startup anymore. Build real native apps for each platform.

Using electron solves your problem. As a user it sure as hell doesn't solve any problem I have.

</comment><comment><USER41> I'm sure this will not fix my 25% cpu core burn on open gifs. Slack is no. 1 reason for my laptop to spin up fans because I left it open with a gif from giphy.

</comment><comment><USER42> Tried the new beta: it lost all my configured networks, and I had to re-add them all. Otherwise, it seems _way_ faster than the old one, and definitely an upgrade.

<comment><USER28> Hey, author here. :wave: If you don't mind doing Help > Report Issue it'll submit your logs and we can see what went down.

</comment></comment><comment><USER43> Holy heck is there really no more simple architecture for this app?

Even the TLDR at the bottom didn't succinctly explain the advantage of browserview over the old way.

</comment><comment><USER44> I am wishing that the devs on the HipChat desktop apps are paying close attention to this. The Slack desktop app has been a resource hog, but nothing compared to the HipChat desktop app. (All anecdotal evidence)

<comment><USER45> HipChat's being deprecated in the not to distant future in favor of Atlassian's Slack clone called "Stride".

<comment><USER44> Not according the the Atlassian folks. HipChat will live on, Stride is just replacing HipChat as their SaaS offering.

<comment><USER45> >Do you plan to sunset HipChat Cloud?

>For now, HipChat Cloud will continue to be supported, but eventually we will encourage all HipChat Cloud customers to upgrade to Stride.

This seems like business speak for "get converted to Stride sooner rather than later because HipChat won't be around for much longer".

[https://confluence.atlassian.com/stride-documentation/faq- st...](https://confluence.atlassian.com/stride-documentation/faq-stride-and- hipchat-cloud-937165565.html)

<comment><USER46> HipChat Cloud ---> Stride.

HipChat will live on as the behind the firewall solution for companies that do not want a pure SaaS app.

</comment></comment></comment></comment></comment><comment><USER47> Interesting to read Slack proselytize the use of Observables (which I'm a huge fan of). I really wish TC39 would move it to stage two. I found the following discussion/ reasoning pretty lacking for the amount of use Observables are getting.

[http://tc39.github.io/tc39-notes/2017-05_may-25.html#17iiia-...](http://tc39.github.io/tc39-notes/2017-05_may-25.html#17iiia- observable-proposal-to-stage-2)

</comment><comment><USER48> From github electron

        The BrowserView API is currently experimental and may change or be removed in future Electron releases.

Is it stable now?

</comment><comment><USER49> Does Slack use WebRTC for it's call and screen sharing features? If yes, that might be one of the main reasons why it is written with Electron. It's very very hard to find people who can actually handle WebRTC C++ stack. On the contrary, Chrome has one of the best WebRTC support and screen sharing works out of the box.

</comment><comment><USER50> Is anyone else getting chat service fatigue?

Looking at my dock I have Discord, Slack, Textual (IRC), WhatsApp Web open.

I wish there was a service that just amalgamated all these together into one thing, with a rough set of common features (e.g. ability to post images/gifs/videos, text etc)

<comment><USER51> If it doesn't exist yet, I'm sure someone will be along shortly to re-invent Trillian or Pidgin as an Electron app.

</comment></comment><comment><USER52> Don't these guys have the resources to write native apps at this point?

</comment><comment><USER53> Quick question -- in screenshots for macos version there's no "titlebar" (kinda like a HUD window) but both beta and stable on my system show the titlebar. Is there anything different there?

<comment><USER54> It depends on whether you're signed into multiple workspaces.

</comment></comment><comment><USER55> Can anyone summarise the difference between BrowserView and a Webview for Electron? I'm not getting the significance between them.

</comment><comment><USER56> And here I got excited for a second and thought they were migrating to true native apps...

</comment><comment><USER57> Wire just released Teams. I believe also all of their apps are really really native.

</comment><comment><USER58> I wonder if something like Flutter could end up replacing Electron eventually.</comment>


Bestiality in a Time of Smallpox - <AUTHOR> http://notchesblog.com/2015/01/20/bestiality-in-a-time-of-smallpox/

<comment><USER2> So not the Minecraft Notch, then?</comment>


Why Kenya's Cashless Payments for Public Transport Failed - tefo-mohapi http://www.iafrikan.com/2016/09/21/kenyas-cashless-payment-system-was-doomed-by-a-series-of-experience-design-failures/ <comment><AUTHOR> Better check data, KES 500 million ≠ US$50,000.</comment>


MHTML – Why you should always store user file uploads on another domain - <AUTHOR> https://insert-script.blogspot.com/2020/01/internet-explorer-mhtml-why-you-should.html <comment><AUTHOR> Personally I love mhtml. It allows you to easily store a webpage as a single file without having to resort to PDFs - which have lots of accessibility and rendering issues.</comment>


Six Techniques for Algorithmic Music Composition (1988) [pdf] - <AUTHOR> http://peterlangston.com/Papers/amc.pdf <comment><AUTHOR> I consider this a great paper to start from if you're interested in experimenting with computer composition. Bringing it up to date with a deep learning network would probably make for another nice paper.</comment>


Show HN: Daily photo diary of you staring at your computer; a chrome extension - <AUTHOR> https://glanceback.info/ <comment><USER2> I did something similar for over 3 years, with a cron job and imagemagik. It takes a webcam shot as well as a screenshot and combines them once per hour.

I have 13000 images at the moment from late 2015 to early 2018 (I forgot to enable in after I switched laptop).

One thing that was unexpected was that initially the script would put all images into one folder, which lagged a lot to open due to the massive amount of images. So I had to change it to put them into year-month-day folders.

I personally found that taking only a webcam shot lost all context, especially if you - like me - spend 90% of your time either at home or at work.

You can see the script here as well as some examples. [http://jontelang.com/blog/2015/08/15/automating- screenshots....](http://jontelang.com/blog/2015/08/15/automating- screenshots.html)</comment>


iPhone X is a sham - <AUTHOR> https://www.fastcodesign.com/90149136/we-dont-need-the-iphone-x?utm_content=bufferdf04d&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> iPhone X and 7 Plus cameras compared

[https://blogs.harvard.edu/philg/2017/11/03/iphone-x- and-7-pl...](https://blogs.harvard.edu/philg/2017/11/03/iphone-x-and-7-plus- cameras-compared/)

</comment><comment><USER3> Flagged for clickbait title.

</comment><comment><USER4> The actual article title is "We don't need the iPhone X".

<comment><AUTHOR> That was the first sentence of the article and the title Fastco used on Twitter but I can't change the title now, HN won't let me.

<comment><USER4> I encourage you to contact the mods in via the link in the footer to update it for you.

<comment><AUTHOR> Submit it again and see if it does better. It would be an interesting test.

</comment></comment></comment></comment><comment><AUTHOR> How can a thread titled "iPhone X is a sham" not take off?

<comment><USER4> Please update the submission title to match the article. The guidelines request the title not be editorialized.</comment></comment>


Rails 2.0 Released - <AUTHOR> http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

<comment><USER2> Does anyone have anything to add about the security of this:

Action Pack: Cookie store sessions

The default session store in Rails 2.0 is now a cookie-based one. That means sessions are no longer stored on the file system or in the database, but kept by the client in a hashed form that can't be forged. This makes it not only a lot faster than traditional session stores, but also makes it zero maintenance. There's no cron job needed to clear out the sessions and your server won't crash because you forgot and suddenly had 500K files in tmp/session.

This setup works great if you follow best practices and keep session usage to a minimum, such as the common case of just storing a user_id and a the flash. If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can't be forged (so is_admin = true is fine), their content can be seen. If that's a problem for your application, you can always just switch back to one of the traditional session stores (but first investigate that requirement as a code smell).

<comment><USER3> Yeah. There was a discussion about it in an earlier thread.

Unfortunately, I can't seem to find it anymore.

If you look at the code, the session store is stored in plaintext with the hash. Rails rehashes the plaintext in the cookie and checks it against the hash to make sure it has not been tampered with. The last time I checked, the hashing uses OpenSSL's HMAC hashing rather than the SHA1 in earlier versions of Rails.

You, as the developer, are responsible for entering in the site's secret code. It should be possible to write a Rails 2.0 initializer in config/intializer to check the presence of config/secret.yml and if not, generate it in runtime. This keeps you from having to save the secret in the version control, but unfortunately, doesn't work well when you deploy it across several machines.

Note that the cookie store was available in 1.2. Seems as if the core developers like it enough to enable it by default. As for me, I think I'll stick with ActiveStore for a while until my sites needs more drastic means, such as memcached or even cookie store.

<comment><AUTHOR> Heres the thread:

<http://news.ycombinator.com/item?id=81932>

</comment></comment></comment><comment><USER4> Nice summary for you: <http://blog.viget.com/whats-coming-in-rails-20/>

A big part about Rails2 is also to take the cruft out of the framework. In other words, moving things out into plugins and cleaning up the core.

</comment><comment><USER5> A 2.0 release seems like a big deal; is there a rails practitioner around who could describe the magnitude of these changes to those of us who don't use rails?

<comment><AUTHOR> I've been developing off of the preview releases for a few weeks, and there's nothing earth shattering. Generally, it just makes things nicer.

I don't do a lot of AJAXy stuff, and I don't talk very frequently to clients that aren't standard browswers. If I did, I think I would have a lot more to gain from this release.

<comment><USER6> That is probably a good thing. Rails is a great fit for what it does, a 2.0 danger was to do beyond its strengths. It seems to have evolved nicely. I look forward to using it.

As for the questions about the lack of "scalability" improvements, I don't really care. Its not needed for what I use it for anyway (and probably the same for most people).

</comment></comment></comment><comment><USER7> I'm seeing "Agile Web Development with Rails 3rd Edition" coming out soon!

</comment><comment><USER8> I know we're pretty excited. Performance is going to be a major issue for us once we get into providing live stats for people. We'll see how this helps.

</comment><comment><USER9> Its already 2.01 !!!</comment>


ATTN: Data Science and Business Analysts - <AUTHOR> http://www.twintechlabs.io <comment><AUTHOR> Streamline the data science process as well as give advanced business analysts the capability of driving real insights. Take your CSV and seamlessly train your model in minutes.</comment>


Google responds: Facts about our network neutrality policy proposal - <AUTHOR> http://googlepublicpolicy.blogspot.com/2010/08/facts-about-our-network-neutrality.html

<comment><USER2> It's the "in the spirit of compromise" line that I don't get. I'm pretty sure Google would prefer net neutrality to apply to wireless too, but they threw users under the bus to buddy up with Verizon. But no one asked Google to put this proposal together. No one said they had to work together with Verizon on it. Why didn't they just both submit their own proposals and let the FCC make up their own mind on the various issues? It's not like this proposal is going to get passed directly into law anyway.

Compromise? That doesn't sound like the Google I know and love.

Google has always been known for their lofty ideals and their principled founders. They are the company you can trust to walk away from billions of dollars before compromising what they believe. We saw that in their interactions with China. We saw that when they owned up to the data they accidentally collected driving down the street. We saw that when they changed their rules to make it harder for spammers to put adsense on temporary landing pages.

I've been a Google fan boy for a long time but this week they lost my respect.

<comment><USER3> _Why didn't they just both submit their own proposals and let the FCC make up their own mind on the various issues?_

I suspect that the FCC would see no common ground between the proposals and do nothing. In fact, that was pretty much the state of play until last week.

<comment><USER4> I think it would be better for the FCC to keep doing nothing at this point.

Right now the ISPs are afraid that if they create a tiered network that there would be outrage and the government would move in and regulate their industry.

However, now Google has given them coverage by making it appear to the FCC and congress that there is a compromise that can be made into law. I'd actually prefer that there be only light regulation, but a healthy paranoia from the telcos that they would be strong armed by the government (and corporations like Google) if they start to violate net neutrality.

It reminds me of a debate in US history about the Bill of Rights. Some argued that by listing your rights, you are inherently implying that there are no rights other than those listed. The idea is that by not enumerating rights you expand them.

<comment><USER3> I think the current state of regulatory uncertainty cannot last. Eventually Washington will get bored of the issue and — absent regulation — ISPs will go back to their old tricks.

<comment><USER4> Perhaps. But sometimes telling an industry not to fuck consumers or face regulation keeps them better behaved than telling them exactly how they are allowed to fuck consumers.

<comment><USER5> Which seems to exactly match up with the approach google proposed the government take with regard to wireless...

</comment></comment></comment></comment></comment></comment><comment><USER6> Principles which succumb to "political realities" or the "spirit of compromise" are no principles at all.

I'm still hugely disappointed but maybe it was naive to think a corporate entity could ever have true principles.

<comment><USER7> The "spirit of compromise" is the core principle of democracy. If you're against compromise, you're against democracy.

<comment><USER6> That is frightening logic and factually incorrect. History is full of examples of minority abuse at the hands of the majority.

Here is a good starting point: [http://en.wikipedia.org/wiki/Criticism_of_democracy#Oppressi...](http://en.wikipedia.org/wiki/Criticism_of_democracy#Oppression_by_the_majority)

<comment><USER7> I think most would agree that those are failed democracies. Just because democracy does certain things in practice does not mean that those things are in line with the core principles of democracy, of which compromise is one.

<comment><USER8> <http://en.wikipedia.org/wiki/No_true_Scotsman>

</comment></comment></comment></comment></comment><comment><USER9> The Myth/Fact format was probably the wrong choice when many of the "Fact" sections contain information supportive of the "Myth", along with a few weasel words like "But given political realities", "However, in the spirit of compromise", etc.

<comment><USER10> If you think political realities don't have an effect on what can be accomplished with net neutrality, you're just being naive. I think this marks the point in time where (publicly at least) Google has moved on from the unfettered idealist stage to the more pragmatic realist stage. It might be a sad shift, but it was an inevitable one.

<comment><USER6> If being pragmatic entails giving up the fight (as google has done in the wireless world), count me out.

<comment><USER11> Allowing a stall as part of a compromise is not the same as giving up.

<comment><USER6> They ceded the wireless world to the control of the carriers so it wouldn't be a stall so much as playing dead.

And a full reversal is certainly possible, it would imply a short-sightedness which is hard to reconcile with Google's policy history which tells us that it would take some major event (think the Chinese hacking incident) for them to reverse themselves entirely.

There is simply no way this agreement was undertaken lightly or without extensive analysis. Doubly so because it pisses off the technical elite (and they surely knew it would) both inside and outside Google.

</comment></comment></comment></comment></comment><comment><USER12> For context:

> Posted by Richard Whitt, Washington Telecom and Media Counsel

[http://www.circleid.com/posts/20090129_interview_richard_whi...](http://www.circleid.com/posts/20090129_interview_richard_whitt_google_telecom_media_counsel/)

From Linked-in profile:

      President at NetsEdge Consulting, LLC (Sole Proprietorship)
      VP of Federal Law and Policy at MCI
      Senior Director for Global Public Policy at MCI
      Director of Federal Law and Policy at MCI
      Regulatory Counsel at IDB WorldCom
      Associate Attorney at Sutherland, Asbill, and Brennan
      Associate Attorney at Bishop, Cook, Purcell & Reynolds

<http://en.wikipedia.org/wiki/MCI>

      > MCI, Inc. is an American telecommunications subsidiary of Verizon Communications.

</comment><comment><USER13> I've found that a pretty good rule of thumb for recognizing corporate BS is any time a campaign is called "Get The Facts" or something similar.

For example, look on the side of many boxes of junk cereal and you'll find a "Get The Facts" box touting the benefits of some miniscule quantity of vitamin contained in the cereal. Or when Microsoft launched a "Get The Facts" campaign in 2004 to try to steer users away from Linux.

I also find the phrase to be highly condescending.

<comment><USER14> So you've decided that your reading of this is going to stop at rules of thumb?

<comment><USER13> I've addressed this already above.

</comment></comment></comment><comment><USER15> "So, for example, broadband providers could offer a special gaming channel, or a more secure banking service, or a home health monitoring capability – so long as such offerings are separate and apart from the public Internet."

Can somebody explain? Does this mean verizon would be able to sell special secure service to say, bank of america for its public site? What is the meaning of "separate from public internet"? doesn't this eventually mean that by paying verizon, BOA would be able to offer secure service than a bank who did not buy the "special service" from verizon? Am I missing something here?

If this is the case, what is to stop verizon from going a step ahead from offering "secure" to "faster" service to those who care to pay. then where goes net-neutrality.?

<comment><USER16> If the special treatment that BoA pays for does not degrade my (or anyone else's) internet performance, and does not degrade the speed or accessibility of other bank websites, I don't mind. I think the "separate and apart" means this goes further - I can't just type <https://www.bankofamerica.com/> and get the special service.

<comment><USER15> I understand.. so yes - we as users won't mind. but what if I were another bank? The security upgrades that I would normally pay Infosys to do for me now no longer give me a competitive advantage over BoA. I'd have to pay verizon in addition to get the same "special service" to offer the same security (replace with speed/features etc.) right?

<comment><USER17> Yep, that's pretty much what it is. The words "upgrade" or "in addition" are purely PR: what is the difference between slowing down website A but not B, or increasing the bandwidth for website B but not A? I'd imagine that in the USA you'll get faster broadband in the future: either the "normal" usage gets redefined each time, or you could be stuck with "normal" being the situation in 2010 for the next decade or more.

<comment><USER18> When you increase bandwidth for A but not B because A is paying you more money, you are behaving in the exact same way that the internet does: paying for a faster connection leads to more bandwidth. When you slow down B but not A because A is paying you more money, you are actively messing with packets, holding back ones from B while pushing ones from A further up the queue. Speeding up A is not the same thing as slowing down B.

<comment><USER17> Eh??? Paying for a faster connection??? What are you trying to say? That if I own a website then it's ok to be charged money by an ISP to get an extra chunk of the last mile to the user???

<comment><USER18> No. You're charged for the connection your server has to the wider internet. The end-user is charged for their connection to the wider internet.

Note that I'm talking about the total bandwidth available, not the speed of the connection to an end-user. The distinction is important: having more bandwidth means that you can send data to more users without sacrificing individual speed.

Peering arrangements between providers are the closest it should be possible to get to paying for a larger chunk of the last mile: because the server they are trying to talk to is fewer hops away, they will have lower pings, and possibly more responsive page-loading. In a situation where the connection of a network to the backbone is saturated, this appears to be the same as giving the peered provider's packets priority, since that connection is not saturated. This situation is somewhat distinct, however, being an issue of incompetence or third-party malice (the connection is either too small for normal usage or being attacked) instead of hardware designed to prioritize packets by source (which would be malice or greed on the part of the provider). This assumes a simple network topography, with a single connection to non-peered network, but it may be expanded to explain situations involving larger networks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> MYTH: Google has "sold out" on network neutrality.

FACT: Sure, we were all ready to pay $4.6 billion to keep the 700MHz band open a couple years ago. Hey, had you _seen_ that iPhone thing? It was killing us. But that was yesterday. Just the other day, our BFF Verizon told us that Android was selling 300,000 units a day. _300,000 a day_. We were, like, "Net neutrality who?"

<comment><USER20> ACTUAL FACT: they got the neutrality concession on that spectrum and it will apply to verizon's 4G network.

<comment><USER17> How can you reconcile this view with the new Google where "wireless is already very competitive so no need for regulations"?

How is that not giving in?

<comment><USER21> As they clearly state, they can't see enough reason to force regulation _yet_. And with at least double the number of providers (far more if you count resellers) compared to landlines (USA-centric view), they're right.

Now, you can still argue that despite competition mobile internet needs regulation. But that's a much tougher argument to make.

<comment><USER17> What? So a few years ago Google believes that wireless needs to be kept open, makes a big bet and succeeds in ensuring as much.

Nowadays instead it does not require regulation because there's plenty of competition.

What has changed in the last few years to make Google change their mind? Have the number of wireless competitors gone up? From what I heard you (=Americans) are ending up with 2 large wireless companies (AT&T and Verizon), and a couple of little ones.

If anything competition has decreased. And yet Google feels regulation is not necessary anymore.

</comment></comment></comment></comment></comment><comment><USER22> What I got from the post was how arrogant Google has become. Anyone notice that they dress up their opinions with wasted "MYTHS" & "FACTS"? And while the myth statements & facts maybe be true, they don't actually dis-prove the point of many originating myths, which Is why they follow each Myth/Fact with an opinion.

I don't mind Google having an opinion worth fighting for, but Google is a private company trying to push their private deals on government acting like they are doing everyone a favor.

I personally don't appreciate what they're doing and I'm noticing a trend where I'm beginning to like Google as much as I like Microsoft, and I hate Microsoft.

</comment><comment><USER23> Is it me or does every "MYTH" seem to be proven true in the debunking?

</comment><comment><USER24> The most important point here is their defense of the wireless exemption.

Agree with it or not (I'm on the fence, and most people seem to disagree with it), it is deliberately temporary, and most importantly, subject to annual review and debate. So if you don't like it, please disagree, but do note that this is not meant to be a permanent provision.

<comment><USER25> But one could still argue that a deliberate, temporary solution still does no good. Why not just take care of everything right now, while we've already got legislators talking about it? If we have to bring up this whole discussion again a second time to get wireless done, I fear it will never be so.

<comment><USER26> Why not just take care of everything right now? For the same reason you don't get married on the first date. Wireless Internet is a very young and largely unknown market, we don't know what form it will eventually settle into and any laws we draft now are likely to be hopelessly naive in the much same way that software design patents are.

<comment><USER27> Wireless internet is already a total joke, where carriers charge you extra for tethering just to use the bandwidth you already paid for, and give you the runaround when you try to contest charges. The carriers will manipulate this market to squeeze every possible dime they can get from it.

And recall just how badly mobile phones stagnated before the iPhone and Android. That's carrier control at work.

The sooner these guys become reduced to dumb pipes, the better.

<comment><USER28> >Wireless internet is already a total joke, where carriers charge you extra for tethering just to use the bandwidth you already paid for

Bullshit. Don't dumb down the argument just because it serves your personal desires.

Tethering completely upsets the usage models. Their choice is then either to increase prices for _everyone_ , or, if it remains relatively rare, increase the prices for the few. They chose the latter.

<comment><USER29> Given that they claimed "Unlimited" bandwidth, I would say that you already paid for that slice of bandwidth you're using for your computer.

That said, it would be nice to have explicit limits at different price points, regardless of how you're using it. They don't seem to be doing this, though, even on AT&T where you're specifically paying for a given amount of bandwidth. You have to pay again.

So, parent was hyperbolic, but not bullshit.

<comment><USER28> >Given that they claimed "Unlimited" bandwidth

I haven't signed up for a plan that claimed unlimited since the 90s. Maybe organizations around here are just more rational?

However I do have a 5GB plan on my smartphone. In an average month I use around 500MB, because there's only so much you can do on a smartphone, and they know it, but they monitor the curve and provide enough excess that I know that if I really needed it for a period, I could use it. They also sell data sticks for PCs, and they charge much more for lower caps, because of course they know that you'll use it.

My gym membership costs something like $19 a month. Technically I could go every open minute of every day, hogging equipment and space. So could everyone else. Of course then the gym could host a membership count in the dozens instead of in the many hundreds, and my real cost would be significantly higher.

<comment><USER25> For what It's worth, both my FIOS and my data plan from T-Mobile claim to be unlimited. I have yet to read the fine print.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> Reminds of what pg said on Be good (<http://paulgraham.com/good.html>):

 _Anyone can adopt "Don't be evil." The catch is that people will hold you to it._

</comment><comment><USER31> Dear Google,

I'm new to this. Care to explain what is this "public Internet" you talk about? I always thought there was only the Internet.

Thank You

<comment><USER18> Sites only accessible to people on a network which is linked to the internet are not part of the public internet (for instance, my router's configuration page is most definitely not part of the public internet). A proprietary browser-based application running inside of a corporate network would not be part of the public internet, unless it is specifically designed to be accessible to anyone with a browser. The basic rule of thumb I would use is that something is on the public internet if anyone with a browser in a country with no filtering of the internet can reach it, given the proper passwords and so forth (and without using a VPN or similar tunneling to make it appear that they're elsewhere).

<comment><USER31> You are confusing between internet and the Internet.

Google said public Internet.

<comment><USER18> Would you mind explaining the difference between them, other than that one is capitalized while the other is not, then? Focus on how I would be inaccurate if I replaced every instance of "internet" with "Internet" in my previous post.

</comment></comment></comment></comment><comment><USER32> Personally, I am for total net neutrality (wireless, etc.).

But speaking pure strategy, you'd think after Microsoft antitrust, USL/BSDi, etc., that large tech companies would learn to avoid going anywhere near debates about the law.

Legal debates are really important. In fact they are so important that they have a habit of leaving some of the largest centers of innovation in their wake. And each legal fight is different, for sure. But I don't think people exactly appreciate the opportunity cost associated with anything but the most clear positions on social/legal issues.

Don't get me wrong: debate is important. Critical to our society and all that. But as a company, you can't ever afford to be kinda in a stance about something. Facebook, to their credit, come off as usually very decisive about their policy decision making (maybe it's that hacker, trial and error culture?), if wrong at first.

I think Google's approach in China was pretty good. They were almost decisive for about five minutes. But then it got mired in this or that proxy -- and meanwhile you create this doubt in people's minds. The doubters gain traction -- and it even infects your own focus, etc. -- all the way down the org chart.

And I don't know that I'm advocating disruptive, brash decision making. But you have to think of this whole technology and world environment as in a very fast-moving frame of reference. In which, anything that positions you in doubt and uncertainty grows with time until you clarify things. It's a fast moving set of integrals, running up area underneath at any given moment. Honesty is probably always the most important. But messed up frames of reference that _seem_ like the right thing but actually tie up entire reserves of focus, etc., will quickly waylay even the best by the side of the road.

</comment><comment><USER33> I'm having trouble blaming them for the out-of-band services exemption. That seems unavoidable to me as the alternative leads to absurdities.

How would you technically define "neutrality" between a digital TV service and its piggybacked internet connection? If the provider wants to allocate enough bandwidth for a specific quality video signal and use the rest for IP, is something wrong with that? Are they supposed to throttle the video signal to match the quality of Youtube?

Even if they use IP for the TV service, it's still going to blow away any competing service that has to traverse the public internet and I don't see any sensible way the ISP could avoid that. And it gets really weird when you look at internet over analog services, like DSL and cable modems.

The best you can do is force them to treat all IP traffic equally. Then they can't cripple Youtube or Skype without crippling the entire internet. The next least heavy-handed thing I can think of doing is simply forcing all digital services onto the public internet, which would be neat but a bit too ambitious.

</comment><comment><USER34> I know regular HNers are always saying how the community is becoming more like reddit and digg, and I knew there was an inevitable gradual change... but, threads like these really start to scare me.

There is very little factual, rational discourse in this 100+ point and 100+ comment thread. There are lots of passionate opinions and that's great but the naivety, over-confidence, strict idealism is, I think, really counter to the hacker culture/philosophy that makes this community appeal to me.

I'm not here crying the sky is falling; I just want those passionate arm-chair politicians to take a step back and reconsider the virtue of practicality and getting the best out of a bad/difficult situation.

</comment><comment><USER35>
      "MYTH: This proposal represents a step backwards
      for the open Internet.

      FACT: If adopted, this proposal would for the first time
      give the FCC the ability to preserve the open Internet
      through enforceable rules on broadband providers. At the
      same time, the FCC would be prohibited from imposing
      regulations on the Internet itself."

The last sentence seems to be exactly what net neutrality advocates have been endorsing; a regulated internet that prevents ISP's from favoring certain content providers. Why would Google tout this as a benefit? Maybe I'm misinterpreting, but this sounds like a reversal. Please clarify what they mean if I'm wrong.

<comment><USER36> What even net neutrality advocates want to avoid is the FCC becoming the "objectionable content police." The FCC should be able to enforce net neutrality, but _not_ create _new_ regulations regarding content.

The EFF discussed this in their recent post on the matter.

<comment><USER35> Thanks, hadn't read the EFF discussion, but I was not aware that content censorship was even at issue in the net neutrality debate.

Given that this is an official statement from a major stakeholder and given the technical/legal/societal implications, I would have hoped for more precise language.

I can still see this sentence being used to justify tying the hands of the FCC when new issues arise due to technological advancements; the whole Comcast judgment brought into question the scope of their regulatory authority & this proposal seems to significantly restrict what could potentially be required to ensure NN. IMO the issue is too important for this type of ambiguity and proposed restrictions on the FCC should be fully aired & vetted.

</comment></comment></comment><comment><USER37> Transparency in how providers muck about with wireless connections is nice and all, but honestly, what real use is transparency unless you can act on it. Between the wireless industry's pervasive contracts, and the low number of provider options, the average user has little recourse when they get poor treatment.

Google is pretty much telling us that it is too much to ask that we have choice, transparency and neutrality on our public airwaves, a common good. I do not agree.

</comment><comment><USER38> Read the article and when at the very beginning I saw it was written by a lawyer I had a bad feeling about what the rest of it would be like. And I was right.

</comment><comment><USER39> Google and other folks mention "political reality" as the reason for compromise. Folks, that just means we dont want to work hard at it, or make waves. If this country is truly democratic, then we, the people, have the power. We have the power to make not only Verizon and Google kneel to uus, but the FCC and the knuckleheads in DC.

</comment><comment><USER40> On a quick read this sounds more like they're throwing the word "facts" around pretty loosely. More like re-mything. "in the spirit of compromise" is the key phrase. The thing about de-regulation is that companies don't get stricter with themselves. The initial proposal is as tight as it usually gets.

<comment><USER14> This isn't de-regulation. There is no regulation right now.

<comment><USER19> There was also a strong political movement to create fair regulation, until Google threw it under the bus.

<comment><USER14> On the contrary, it seems that the movement is alive and well, and currently throwing Google under the bus.

</comment></comment></comment></comment><comment><USER41> Google response: It is kinda Neutral

</comment><comment><USER42> As soon as you start using "MYTH" in regards to opinions or analysis, you've lost me.

</comment><comment><USER43> This is such bull shit.

</comment><comment><USER44> I don't buy it.

<comment><USER45> Which part don't you buy? Do you think they're lying about their motivations, or do you not agree with their justifications?</comment></comment>


Ask HN: Domain name purchase: godaddy vs. route53? - <AUTHOR> Hi! I'm relatively new to these questions.
Since I'm going to host my app on AWS, I was thinking to purchase the domain name directly on Route53.
But the prices are quite different for a .com:
- Godaddy: $2.99 (y1) + $14.99 (y2)
- Route53: $12 (y1) + $12 (y2)
However, the AWS doc says the transfer is $12 but I'm not sure about the meaning of "transfer". If I purchase the domain on Godaddy, do I need to "transfer" it on AWS? In this case it would be less expensive to purchase on Route53.
Thanks for the help.
∞∞ EDIT ∞∞
Ok I think I've understood. A "transfer" means moving the management of a domain name from a registrar to another one. What I need in my case is just to change the DNS to use a domain name registered somewhere else. Please tell me if I'm wrong! :) <comment><USER2> Keep in mind you can pay one company to own the domain and then set the NS to point at AWS and use Route53 to manage it. That doesn't require a domain transfer.

Apart from the price, you could also look at the company history. I wouldn't touch godaddy even if they were the cheapest option to be honest. Quick google will give you an idea of various issues with them.

<comment><USER3> I use Namecheap as my domain name registrar and use Route53 as DNS Server. I'll never use godaddy.

</comment></comment><comment><USER4> If those are the two options you are considering, AWS hands down. Godaddy is not who I would ever rely on.

I use enom for ordering domains generally (I have a reseller account) and then point the NS to AWS. Keeps my costs low and allows me the flexibility of AWS Route53 which I really have come to love.

</comment><comment><USER5> I know you didn't supply it as an option, but I've found google domains to be really good. I moved off of GodAddy to them last year. Reasonably priced, easy to use and fast.

<comment><AUTHOR> Ok thanks, I will look at Google Domains.

Edit: the service is restricted to Canada, UK and US. :(</comment></comment>