Highway of riches, road to ruin: Inside the Amazon's deforestation crisis - <AUTHOR> https://www.theglobeandmail.com/news/world/amazon-rainforest-deforestation-crisis/article37722932/ <comment><USER2> Amazon Lumberyard is really an issue.</comment>


Factorial function as a limerick - <AUTHOR> http://www.limerickdb.com/?376

<comment><USER2> If you like that, you'll really like this: <http://www.limerickdb.com/?269>

<comment><USER3> You may also enjoy <http://www.limerickdb.com/?77> and <http://www.limerickdb.com/?103>

<comment><USER4> A+++ would limerick again.</comment></comment></comment>


NSA has total access via Microsoft Windows - <AUTHOR> http://www.wnd.com/2013/06/nsa-has-total-access-via-microsoft-windows/

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

See also:

[https://www.schneier.com/crypto- gram-9909.html#NSAKeyinMicro...](https://www.schneier.com/crypto- gram-9909.html#NSAKeyinMicrosoftCryptoAPI)

[http://www.wired.com/science/discoveries/news/1999/09/21577](http://www.wired.com/science/discoveries/news/1999/09/21577)

Basically, this has been known about for >14 years and it's probably nothing to worry about.

</comment><comment><USER3> [http://www.heise.de/tp/artikel/5/5263/1.html](http://www.heise.de/tp/artikel/5/5263/1.html)

</comment><comment><USER4> This is the most scary news I've read in the past week. Makes Stallman's 'The road to Tycho' a conservative, unimaginative piece on the power of governments.

<comment><USER5> It is wnd.com, a lot of it comes right from their imagination.

See other comments re: NSAKEY, Schneier's is probably the best summary as usual.

</comment></comment><comment><USER6> This is a terribly written, horribly sourced, mash up of information that has been known for some time.

>Access to Windows source code is supposed to be highly compartmentalized, actually making such actions easier because many of the people working on the software wouldn't see the access.

Uhm, okay.</comment>


Why Facebook Will Fail Miserably Building a Smartphone - <AUTHOR> http://stevecheney.posterous.com/why-facebook-will-fail-miserably-building-a-s

<comment><USER2> I was onboard until "The Facebook mobile app is absolutely awful – and hasn't improved in years. A lot of these reasons are subtle like lack of support for the Nitro JavaScript engine in native apps which wrap HTML content like Facebook's (Apple doesn't allow this)."

Horseshit. The Facebook mobile app is absolutely awful because Facebook allows it to be absolutely awful. Look at all of the rock-solid, supremely pleasant, sync-and-serve social experiences on iOS and tell me exactly why Facebook is a special case.

Dropped posts, stuttering scrolling, lost comments, photo upload glitches, punishing load times, punishing layout glitches, nonfunctional UI... none of this can be laid at Apple's feet. A magical ~JIT Javascript~ wand isn't going to solve any of this mess.

<comment><USER3> It's much better on Android, if you ignore the 20 second wait everytime you open the app or navigate around too much.

The mobile webpage is nearly identical. Minus push notifications, but it renders instantaneously, scrolls great on my GNex, etc. I just have a Facebook icon Bookmark to Chrome for Android instead of the Facebook app installed (and my battery life improves!)

<comment><USER4> I don't know anything about iOS (or their native Facebook app).

That said, I cannot believe that the Android app is better than anything else. It's .. sad. I wonder if this thing is build in some random two engineers 20% time and they usually work with iOS (or .. something else, but not Android) and really just do this task for the giggles.

I use the website on my device, because the native app fails to provide a bunch of things anyway - and it's sooooo sloooow..

I know this reads like a rant and it probably is. In fact, I use FB in a limited way and even there the native client is lacking. It's - ignoring all emotions for a second - really subpar on every level in my book.

<comment><USER3> Nah, I'm right there with you, but I'm given to understand, from my iOS- defensive-friends, that the iOS app is even worse. It has the slowness on the Android version with intermittent crashes.

</comment></comment></comment></comment><comment><USER5> > Google TV's failures and the storied missteps around Google-branded Android > smartphones prove this.

Sorry, but what missteps do you mean regarding the Nexus brand?

</comment><comment><USER6> I'm not sure if you remember the Motorola ROKR, but Apple flopped a couple times before reinventing the phone industry.

Facebook's taken two cracks at it. They've got a massive war chest and one of the most recognized brands on _earth_ plus 2 failures worth of experience under their belt.

Sure, mobile's a challenge - but it seems like you've thrown in the towel already on it. I don't think Facebook has quite yet.

<comment><USER7> Money and experience alone mean nothing. The ability to learn from that experience is what's important. Based on track records in other areas where they've been slow to learn (privacy) I'd expect they need to fail a minimum of 4-5 more times before they have any prayer of getting it right.

<comment><USER6> So, they're on attempt #3. Why get them at mad for trying? (it's not like they can get failures 4 and 5 out of the way without going through #3 first).

Their slow "learning curve" on privacy has been on purpose. They're trying to reshape how people view "sharing" and are succeeding in doing that w/ almost a billion people.

</comment></comment></comment><comment><USER8> "In the game of thrones, you either win, or you die!" Apple is king of the world (the bit of it that isn't Chinese and has lots of money), it collects taxes, makes laws, executes peasants (you app store developer, you). Facebook, Microsoft, Google, these are rich noble families... they want to be king, they want to live, standing still is not an option - talk to RIM, Yahoo! or MySpace. This is a bid to break the tax monopoly that Apple has which Facebook needs to access to monetize mobile.

One small problem - making phones is hard, making phone operating systems is very hard. However there are 4 options that Facebook has : WebOS, Maemo, Blackberry 10 and.. Windows Mobile 8.

Hardware - well it is bloody hard, unless you have a lot of cash (errr) in which case - go thee, go thee to China. There are some very, very, very clever engineers in China (gee dad?) who if you will give them the volumes, will give you the kit you want.

The trick isn't going to be making a good phone, the trick will be selling it.

In the Game of Thrones no one gets what they want, but everyone gets something.

</comment><comment><USER9> Well, if Facebook wants to be really serious about mobile, they can purchase RIM.

RIM has essentially everything facebook lacks - expertise in building consumer hardware, carrier relationships, retail channels, top-notch systems engineers, etc. They are also very cheap, with a current market cap of $5.5B.

<comment><USER10> RIM's been trying pretty hard to build a popular smartphone (in today's market) without much success. I'm not sure having their phone's "Facebookized" would make them that much more popular - and it would almost certainly not be popular with their remaining enterprise base.

Not to mention that my sense of the cultures of these two companies (admittedly, from the outside only) is that they're about as oil-and-water as you can get. Buying RIM would mean taking on maybe a billion or more in inventory risk, plus the risk that you'd see a lot of the talent walk out the door anyway (something that's been going on for a while now.)

</comment></comment><comment><USER11> I'm not really sure what FB hopes to gain from trying to elbow their way into the mobile phone market. The market is pretty well divided between Google and Apple with MS and RIM mixed in as well.

It seems like there are cheaper ways to improve their users' experience on existing mobile platforms.

The only non-nefarious reason I can think of is they feel a threat from both Google and Apple in their area of expertise - social graphs.

Of course, it's possible that it's all a feint on the part of FB to get some loving from Apple.

[http://www.telegraph.co.uk/finance/newsbysector/mediatechnol...](http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/electronics/9301172/Apple- boss-Tim-Cook-cosies-up-to-Facebook.html)

<comment><USER12> >The only non-nefarious reason I can think of is they feel a threat from both Google and Apple in their area of expertise - social graphs.

Google, perhaps.

But Apple hasn't made much of an inroad into the social sphere at all. I'm not sure if it's even going to be something that they're going to consider moving into, considering the razor thin margins that social network companies make.

<comment><USER13> I think they tried Apple tried their hand at social with Ping which has not really been successful.

However, doesn't iOS now have some kind of special integration with Twitter? That must be pretty bad for Facebook.

<comment><USER12> iOS does have the twitter integration. I'm not sure why Apple(or Google) and Facebook haven't worked out a similar agreement, because it's really a win/win for everyone involved.

</comment></comment></comment></comment><comment><USER14> I seriously think Facebook is going to collapse soon. It's so overhyped it's not even funny -- just look to their stocks to see a prime example. So many people are just itching to get away from it now that it can't last long. We'll see, of course. But it is soon to be a Myspace, et al.

<comment><USER15> They have cash (quite a bit, post-IPO) and revenue. Companies with cash and revenue don't collapse, even if their stock is overvalued. Myspace didn't "collapse" either, though ultimately it lost in the market to a better competitor.

It's possible Facebook will ultimately lose too, but it won't be because of their stock value or their being "overhyped". Hell, statistically it's much more likely that they'll be beaten by a _much, much smaller_ company (though I guess G+ might do it too).</comment></comment>


An Introduction to Angular for Backbone developers - <AUTHOR> https://koglerjs.com/verbiage/angular

<comment><USER2> I couldn't agree more with this article.

For all the Angular.JS beauty and promises, I can't get past their decision of 'extend' a document mark-up language (HTML) into a 'full' programming language with loops, flow control, etc.

We might as well start developing browsers of the future in which the script (be it JavaScript, Dart, etc) get served first and then the script loads the HTML if we feel web apps are now the first class citizen of the browser and static documents second. But merging the two... I just don't grokk it.</comment>


Announcing the First Netflix Recommended TVs - <AUTHOR> http://blog.netflix.com/2015/04/announcing-first-netflix-recommended-tvs.html <comment><USER2> This is an odd precedent we're setting here...

But I'm not a fan of Smart TVs anyway because they will become disposable much more quickly.

<comment><USER3> It's not so much a choice between Smart TV vs. not Smart TV anymore. If you buy a TV today, it is very likely to be "smart". You can just decide to use the features or not (or when to stop using the features).

<comment><USER4> > If you buy a TV today, it is very likely to be "smart".

Of course, if you aren't using the built in receiver for OTA broadcasts, you don't really need a _TV_ , you need a monitor. You can get commercial monitors that are just like "Smart TVs" without the smarts and the receiver that makes it a TV instead of a monitor, though you may have to look outside of the consumer-focused retailers that you think of when buying a TV.

<comment><USER5> I did this for years, but monitors are oddly more expensive than TVs.

All my TVs now are actual TVs, but they are more or less permanently set to HDMI1 input and all the other input source switching is handled externally. The exception being Netflix on the non-theater TVs, for that I usually use the on-TV Netflix client.

<comment><USER6> It's not odd that they are more expensive, monitors typically have higher refresh rates and faster response times. Both of which imply more powerful hardware for the monitor's driver.

<comment><USER5> Not these days (from what I've seen). I think it's mostly a supply/demand thing. Though some monitors do come with longer warranties, it's not worth the added cost.

</comment></comment></comment></comment></comment></comment><comment><USER7> Shouldn't they also take other factors into account, like image quality, sound quality, connectivity and the likes? Seems rather easy just to slap a "quality" label onto a TV just based on how well it runs the Netflix client.

<comment><USER8> I think because those are qualities that are evaluated on their own -- the 'Netflix' label applies to tvs whose specific Netflix app is good/exceptional. Sort of like how a restaurant cleanliness score doesn't evaluate the quality of the food, but is useful in determining if you want to dine there anyway.

<comment><USER9> Or EnergyStar. The label doesn't mean it's a good fridge. It means it's low power.

</comment></comment></comment><comment><USER10> "These TVs wake up quickly"

So a TV that turns on when you turn it on is a feature worth certifying for, now? Ahh the joys of smart equipment. My dumb TV turns on instantly.

<comment><USER11> My girlfriend bought a new TV recently that turns on immediately, but the "smart" TV software takes about 30 seconds to boot up and become available. I think the time to availability of the software is what they're talking about.

<comment><USER12> Wow, 30s? I have a dumb TV (Viara plasma) and an AppleTV 3rd generation.

The AppleTV is practically instant on, the Viara is PDQ, not instant, but way less than 30s.

30s is nothing in the grand scheme of things, but considering how quickly my current setup is ready, if I had to wait 30s with a new TV, I would take it back.

</comment></comment></comment><comment><USER13> Strangely no mention of 4K TVs supporting Netflix 4K/Ultra HD in this standard.

<comment><USER14> Not so, from the article "LG 4K UHD TVs w/ webOS 2.0"

Which are 4K TVs and likely support the Netflix 4K standard as well.

</comment></comment><comment><USER15> Do any of the Smart TVs have interesting network functionality (e.g. remote control APIs? SNMP? WOL? UPNP?) or are they just using their network capabilities to phone home and stream?

<comment><USER9> My 2013 Panasonic supports most of the HDMI interoperability features (e.g. streaming to my Chromecast automatically powers up the TV and switches to the right HDMI port) and UPnP both as a client and renderer.

That said UPnP is a fractured standard, so behavior is patchy. Some formats simply aren't supported, and Windows can't figure out how to control volume when rendering to the TV- but that's the fault of a weak standard more than of the TV.

There is a remote control API as evidenced by the Android remote control app, but it's probably a closed API.

</comment></comment><comment><USER16> Blah. I have a smart TV that can use netflix, but I hardly ever use it considering that I have a Chromecast and XBox One that can use netflix.

<comment><USER17> I think you're in the minority. Most TV owners don't have xbox or chromecast. Netflix bundled with a TV strictly reduces the friction to watch Netflix.

<comment><USER18> I think you're overestimating the pull Netflix has. Literally everyone I know either has a Chromcast, a Roku, or an Apple TV.

While I'm sure some sales will be driven by this, I don't believe its going to be enough to move the needle. If anything, it'll push Amazon and Google to provide better offerings with their respective devices.

<comment><USER17> Just because literally everyone you know uses those platforms doesn't mean they have meaningful pull either. That's unless you know every TV owner in the world. Your anecdotal experience is irrelevant compared to the average experience of the hundreds of millions of TV owners across the country and world.

Most Netflix subscribers (edit from people) just want to watch Netflix on their TV. If you're buying a new TV, the easiest way to do that is to get one that supports Netflix out of the box.

<comment><USER4> > Most people just want to watch Netflix on their TV

If all you want to watch on your screen is Netflix, why buy a _TV_ (defined by being a monitor with a TV tuner built in) at all?

<comment><USER19> Because it's cheaper to buy a television rather than a monitor.</comment></comment></comment></comment></comment></comment>


Why doesn't Nokia buy Palm? - <AUTHOR> http://www.theregister.co.uk/2010/04/15/nokia_buy_palm/

<comment><AUTHOR> Actually, the final link to this Sep. 2009 longer piece about the Nokia perspective is even more interesting: <http://www.fastcompany.com/node/1325729/print> (or the 'normal' version with pictures, but multi-page, at [http://www.fastcompany.com/magazine/138/iphone- envy-you-must...](http://www.fastcompany.com/magazine/138/iphone-envy-you- must-be-joumlking.html) )</comment>


Ask HN: Where do our comments go when we are dead? - <AUTHOR> what is the HN data retention policy? Are our comments gone after some fixed time period? <comment><USER2> I think that the plan is to store the comments forever [ _]. For an official answers from the mods send an email to firstname.lastname@example.com

[_] Or at least until a big server crash deletes all of them, or YC goes out of business. Anyway, assume that Google, Bing, and a few more people have a backup.</comment>


Ask HN: What are the essential components of your front-end workflow? - <AUTHOR> Whether it's for ongoing work, or starting a new project, what are tools that have become indispensable components of your workflow? <comment><USER5> I'm a big fan of npm and modular code.

      - npm to manage dependencies and versions
      - npm-scripts to handle basic build tasks
      - beefy during module development
        (when a bundle isn't necessary)
      - watchify & browserify/uglifyjs during app development
        (when a bundle is necessary)
      - gulp if the project is more involved (LESS, etc)
      - grunt if the project is with a team
      - tape / tap for testing, and testlingify for the git hook

I try to avoid bower since it's no good for re-usable modules. But sometimes you can't avoid it (e.g. threejs, pixi).

<comment><USER6> Why is grunt better than gulp for teams?

<comment><USER5> Because it's been around for longer; new devs are more likely to be familiar with it, easier to find tutorials/docs on the web, better stability, more tasks to choose from, etc.

They are both good though... it won't make a big difference if you choose one over the other.

</comment></comment></comment><comment><USER7> Bower and Grunt. Dunno how I lived without them.

Bower is fantastic for dependency management. This is apparent as soon as you use it to manage the reqs for your project, but becomes even more awesome when you start publishing your own code, even if it's something not many other people use. Right now I have a bootstrap like Sass framework that I built and use between five or six projects. Not too big, but each one of those projects is pretty popular and actively edited. I needed a way to make sure everything updated well and could be temporarily stalled while I worked on better releases. Bower does all that.

Grunt is just my workhorse. Bower may install my files, but I need them moved around into certain folders in my project. Grunt handles that with a line or two. I also use it to watch my sass files and rebuild my static sites when changes to the templates or JS files occur. Since I publish some of my code to github I have grunt commands to auto tag and version my git repo and build, merge and publish a gh-pages branch so my documentation is kept up to speed. It also minifies whatever files I need minified/uglified and adds some license and documentation to the top of the files.

Almost all of these things I used to do manually or hand separate processes for.

<comment><USER6> You should replace bower with npm/browserify and grunt with gulp. Trust me.

<comment><USER8> i'm not sure how browserify replaces bower?

<comment><USER9> It (or something like it) is a requirement for using node modules in the browser

</comment></comment></comment></comment><comment><USER10> Current preferred setup is:

\- npm for javascript dependencies

\- vendor dir for sass deps (I've had problems with Bower don't run enough deps to put up with it)

\- Webpack [1] and some shell scripts for builds. Webpack does all the hard/coordinated stuff and the scripts copy files. I've used Rake, Grunt, and Gulp with Browserify to do the same things and find my current setup works better.

[1] [https://github.com/petehunt/webpack- howto](https://github.com/petehunt/webpack-howto)

\- Sass. I strongly dislike Less.

\- React with Bacon

\- Jest for testing. I'm not completely thrilled with this. It's awesome when it works but I've also spent half a day tracking down a bug that turned out to not be a bug and instead an artifact of the Jest module loader.

\- Vim with my own set of javascript + library UltiSnips snippets. Tip: when you're writing library snippets, write them as e.g. 'react.snippets' and NOT 'javascript_react.snippets'. This prevents the various library snippets from interfering with each other. Vim supports a file having multiple simultaneous filetypes using a dotted notation `:set ft=javascript.react` and you can use ftdetect to automate the setting.

</comment><comment><USER11> I love [http://hammerformac.com](http://hammerformac.com)

It's like having a precompiler for _everything_ that does live-rebuild/reload, and creates deployable builds of front end code.

None of the individual things that Hammer does automatically is actually _hard_ , but the fact that I don't have to think about firing up a bunch of watch commands before getting to work is awesome.

<comment><USER12> What are some free alternatives to this, or to LiveReload?

</comment></comment><comment><USER13> Few weeks ago, I've written an article about my 5 favorite front-end tools: [http://thenextweb.com/dd/2014/05/29/5-great-front-end- develo...](http://thenextweb.com/dd/2014/05/29/5-great-front-end-developer- tools-try/)

</comment><comment><USER14> Here is my setup:

        - SublimeText 3
             SublimeLinter (plugin)
        - <USER2>
        - <USER3>
            gulp-concat
            gulp-uglify
            gulp-ng-annotate
            gulp-connect
            gulp-watch
            gulp-livereload
            gulp-less

         - <USER4>

</comment><comment><USER15> Qt.

I know that's probably not what you meant, I just wanted to remind people that there's a world outside of the browser.

<comment><USER16> It would be great then if you would take the time to explain why it is invaluable to you. Thanks.

</comment></comment><comment><USER17> Tools:

Browserify [1]. You have all the npm packages available, and your modules are compatible with Node. This allows you to easily test your modules, or reuse some of your modules in the browser, the CLI and a webserver for example.

Stylus [2] is great. Compared to Sass, I think it's easier, more or equally powerful, and more future-proof. It's basically a programming language on top of CSS, while Sass looks more like another language that produces CSS. It's also written in JS, so you can easily write your own plugins (as npm modules).

Browserify and Stylus are also quite nice if your code is component-oriented.

This is how you import a component in Browserify:

      require('my-component')

And in Stylus:

      @require 'my-component'

For the build step, I always use Make because it's everywhere except Windows, and I switch on gulp [3] if things get complicated or if I need Windows compatibility.

I'm using tape [4] and testling [5] (locally) for tests. Simple.

jspage [6] (I'm the author) is a simple tool I often use to transform some JS into a page. Useful for quick tests if you work in the CLI.

Services:

Cloudup [7] is nice for quick screenshot sharing. On OS X, I just use the built-in tool to make a screenshot, and an URL is immediately copied to the clipboard, I just have to paste it to someone. The delay between the moment when you take the screenshot and the moment when the other person loads the page is usually enough for the screenshot to be uploaded and displayed.

scri.ch [8] (I wrote this tool) is a simple drawing tool I'm using to share visual ideas, especially in GitHub issues (just add .png to an URL to get the image). I also use it to make quick interface elements that I can integrate into a web mockup.

      [1] http://browserify.org/
      [2] http://learnboost.github.io/stylus/
      [3] http://gulpjs.com/
      [4] https://github.com/substack/tape
      [5] https://ci.testling.com/
      [6] https://github.com/bpierre/jspage
      [7] https://cloudup.com/
      [8] http://scri.ch/

<comment><USER18> > _Stylus is great. Compared to Sass, I think it's easier, more or equally > powerful_

In what ways is Stylus more powerful than Sass?

<comment><USER10> I'm a different person but I did use and prefer Stylus for a while.

When Stylus was created it was definitely more powerful than Sass. The syntactic flexibility of mixin invocation lets you define your own css properties and override how others work transparently. It also had a better story for defining in-language functions and whatnot.

Since TJ stopped working on Stylus the Sass guys have continued adding features. Using @extend can significantly reduce the size of the output CSS file, the ability to pass blocks into mixins was added, and SassScript roughly matches stylus' language. I consider Sass to be more powerful but someone using a different/older feature set could easily argue the other way.

The sass community is also larger/more prolific so you have sass frameworks (not that I generally use them but they're there) and things like the Team Sass github org doing interesting/random things.

<comment><USER17> I agree with the last part, of course the community is a strong advantage for Sass. @extend is in Stylus too, but it supports any selectors (last time I checked, Sass's @extend was only supporting classes).

</comment></comment></comment></comment><comment><USER19> That's a great question. Can anyone say something about their .NET front-end workflow? Do you use only VS built-ins ? Or perhaps you've found a way to use browserify, node, etc. efficiently whend creating UI in the MS world? So that, when your work is done, it is easy to move your stuff to project files and back (if necessary to correct something) ?

</comment><comment><USER20> Composer, and this (quick, dirty) shell script I wrote to build a basic composer web app setup (including /public with an index.php which loads the autoloader and an .htaccess which auto-routes to it.)

[https://gist.github.com/kennethrapp/701c275ff0a2349fc51f](https://gist.github.com/kennethrapp/701c275ff0a2349fc51f)

</comment><comment><USER21> I have a question here, has anyone tried to create a task runner in plain shell (as bash script maybe). I imagine it could perform similar/same tasks as GruntJS, with maybe a bit more speed. At the cost of being slightly more complicated and I'd need to update/install dependencies manually. Just a thought.

<comment><USER5> Sounds like Make.

You can also use npm-scripts for basic shell commands. You can rely on NPM- authored tasks and have them listed as a devDependency, so that users don't need to install anything manually.

      //create a UMD build for the browser
      "scripts": {
        "bundle": "browserify index.js -s foo > build/foo.js",
        "minify": "uglifyjs build/foo.js > build/foo.min.js",
        "build": "npm run bundle && npm run minify"
      }

Now a user just needs to run this to build your app:

        npm run build

<comment><USER22> This will certainly work in an exclusively *nix environment. However, if you need your build system to be Windows-compatible, you'll need to go with something like Grunt.

<comment><USER23> My team decided to just forget about Windows, and only use Linux or OSX. It is so much more convenient when you can rely on Bash, Make, and Unix conventions. (It is interesting discovering the slight incompatibilities between GNU core utils and OSX core utils, though, but usually the GNU versions just have extra features.)

Make plays nicely with npm once you set the PATH to include ./node_modules/.bin . Watching is the only thing Make can't do, so I usually set up a very simple Gruntfile that watches the source files, launches a livereload server, and just calls `make` when anything changes.

</comment></comment></comment></comment><comment><USER24> I use yeoman for a lot of thing. In my strict frontend workflow I use the gulp-webapp generator.

This is fast, really easy and powerful.

</comment><comment><USER25> [http://mixture.io](http://mixture.io) is worth a look :)

</comment><comment><USER26> [http://yeoman.io/](http://yeoman.io/)

\+ (shameless plug) [http://htmlshell.com/](http://htmlshell.com/) (if I need to generate 5-line snippets)

</comment><comment><AUTHOR> Personally, I've only recently learned about Bower and Grunt, so I can't particularly evangelize for them. However, a basic tool which offer similar functionality, which I certainly can give love to, it the nentuts+ fetch package for Sublime Text 2/3\. It allows you to, as the GIT repo so concisely puts it: Fetch the latest version of remote files and zip packages. It's great!

[https://github.com/weslly/Nettuts-Fetch](https://github.com/weslly/Nettuts- Fetch)

</comment><comment><USER27> Ember CLI is pretty dope [https://github.com/stefanpenner/ember- cli](https://github.com/stefanpenner/ember-cli) if you are using Ember.

<comment><USER28> I agree, but the canonical link is now [http://www.ember- cli.com/](http://www.ember-cli.com/) :)

<comment><USER9> That design is very.. retro?

</comment></comment></comment><comment><USER29> \- Webpack for building, watching, optimizing / bundling

\- npm for dependency management; notable package:

\- jstransform for transforming ES6/ES7 & JSX to JS

All on a heavily React-based stack.

</comment><comment><USER30> I love usemin. It is really simple and works perfect for my workflow. In development, it allows me to have all my js and css files referenced normally. In my build process, usemin concats all the js and css files, minifies them, and replaces the references to them to the minified concatenated resource. You don't have to have any script running watching your files for changes or anything like that.

</comment><comment> sehr<USER2>
Browserify - Common JS kicks ass. <USER3>
Most of the non js assets I regularly use (normalize css, bootstrap) are all available on NPM nowadays, so I was able to get rid of bower (thank _god_ ).

</comment><comment><USER31> Adding to OP's question: Does anyone know of any good reads for writing maintainable JS?

<comment><USER9> Maintainable JavaScript - Zakas [0]

Testable JavaScript - Trostler [1]

Both fairly recent and for the most part, useful.

[0] - [http://www.amazon.com/Maintainable-JavaScript-Nicholas-C- Zak...](http://www.amazon.com/Maintainable-JavaScript-Nicholas-C- Zakas/dp/1449327680)

[1] - [http://www.amazon.com/Testable-JavaScript-Mark-Ethan- Trostle...](http://www.amazon.com/Testable-JavaScript-Mark-Ethan- Trostler/dp/1449323391/ref=pd_sim_b_1?ie=UTF8&refRID=125HM4BH9E78W7A3Y2EC)

<comment><USER32> Depending on your end-goal, I would also suggest:

Secrets of the JavaScript Ninja [0]

The Principles of Object-Oriented JavaScript [1]

[0] [http://amzn.to/1xl6Huq](http://amzn.to/1xl6Huq)

[1] [http://amzn.to/1nLAVa0](http://amzn.to/1nLAVa0)

</comment></comment></comment><comment><USER33> npm, bower, gulp, shippable, webstorm, git, chrome, bitbucket.

<comment><USER30> +1 for webstorm. Very powerful IDE especially if your backend is node

</comment></comment><comment><USER34> npm, broccoli, ember-cli, emberjs, chrome

</comment><comment><USER35> js_of_ocaml, fswatch to rebuild when source files change.

</comment><comment><USER36> Why is npm indispensable?

</comment><comment><USER37> \- eclipse

\- npm

\- firefox

\- firebug

\- grunt

\- git

\- jenkins

\- javascriptmvc</comment>


MIT 6.006: Algorithms in Python - <AUTHOR> http://courses.csail.mit.edu/6.006/spring11/notes.shtml <comment><USER2> It's a bit misleading to describe this as "algorithms in python". You'll find that the course is almost entirely theoretical (as it should be) and that there is a small implementation component for each problem set that just happens to be in Python.

</comment><comment><USER3> You might also want to check out [http://ocw.mit.edu/courses/electrical- engineering-and-comput...](http://ocw.mit.edu/courses/electrical-engineering- and-computer-science/6-046j-introduction-to-algorithms- sma-5503-fall-2005/video-lectures/) .

</comment><comment><USER4> does anyone know of a directory of all MIT CS lectures which may not be available on OCW? would be great to have such a list. extra brownie points for Python... :)

<comment><USER5> <http://student.mit.edu/catalog/m6a.html>

</comment></comment><comment><USER6> Erik Demaine great lecturer.

<comment><USER7> This is an understatement.

Erik Demaine is absolutely fascinating. He does brilliant work, and has a great style. I saw that he and Vi Hart once co-authored a paper together-- can you imagine the offspring they could produce?

</comment></comment><comment><USER8> Always, Always been a fan of algorithms taught in Python.

</comment><comment><USER9> Waiting for the video lectures...

<comment><USER10> We're actually producing a whole new set of 6.006 video lectures this fall for OCW! (There'll also be some amazing new and reorganized material.)

<comment><USER11> Does the new ones are based on python as supporting language? what all things have changed in this new set? And lastly, any timeline?

Btw. I am Super Excited to hear this :D

<comment><USER10> Yes, it will still be taught using Python. Almost all of the undergraduate CS courses are moving from Scheme or Java to Python if they haven't already. (One notable exception is the excellent 6.172, about Making Things Fast(tm), which uses C and Cilk.)

The videos will be recorded this fall semester; Erik will be lecturing again, along with the equally awesome Srini Devadas. In the past, when Erik has recorded his own lectures, I recall that they were posted as soon as they were edited. Every time I've worked with OCW, though, one of their staff members comes in and collects materials at the end of the semester.

I'm not sure exactly what the material differences will be; that's the lecturers' call (way above my pay grade!). If you want more than 6.006 offers, though, check out 6.046, which is the follow-on undergraduate algorithms course.

Since we're doing as much of our planning now as possible, I'm curious: what sorts of things do you wish we'd include? Does anyone have suggestions?

<comment><AUTHOR> I'd love to see the entire course in the format of that first lecture linked above, i.e you start with a naive implementation and gradually improve it both algorithmically and with language-specific hacks until you get orders of magnitude faster version working on your machine, not on paper.

Make every homework a contest on the fastest implementation,e.g. see Tim Bray's Wide Finder benchmark: <http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results>

Python is great for teaching, but I'd let them do the optimizations in any language.

Use problems from your current research as examples/assignments, rather than boring textbook problems.

Let them work with real data: [http://www.quora.com/Programming- Challenges-1/What-are-some-...](http://www.quora.com/Programming- Challenges-1/What-are-some-good-toy-problems-in-data-science) , [http://www.quora.com/Data/Where-can-I-get-large-datasets- ope...](http://www.quora.com/Data/Where-can-I-get-large-datasets-open-to-the- public)

Add parallel algorithms to the mix. Ask to parallelize serial algorithms that you explain in the lecture. They should at least start thinking about programming for multicore and clusters, they will thank you for that later.

</comment></comment></comment></comment></comment><comment><USER12> Could Khan do each of these in about 7 minutes?

<comment><USER12> Seriously. The thing that always irritated me about university lectures, especially when presented online is that the material covered in 50 minutes could likely be covered in 7. But who would pay $30k for that?

Thanks for the down votes, though.

<comment><USER13> Too terse. It turns out that some points cannot be made in one Tweet, just as other points cannot be made in seven minutes.

And you need to be a bit more generous to those who still admire fine old art forms like the classic long lecture. It is a genre. It used to be _the_ genre, and now it is just one, but the masters of the big lecture were and are great, and a lot of them aren't going to master the new genre - they were born too late, perhaps - so enjoy them for what they are. Use the high-speed button if you must.

All that said: Yes, you're right, the central awesomeness of Khan is not Khan himself or his lectures - people have rightly pointed out that Khan isn't the teacher to end all teachers - but his relentless pushing of this new genre, a genre that relies on the presence of ubiquitous handheld portable video players. In a world where everyone on the bus and in line at the supermarket has a smartphone, a traditional lecture, with lots of throat-clearing and repetition and class mechanics ("before I tell you anything useful let me talk about the TA assignments") and a long recap at the start of every lecture to let the people who slept through the last lecture catch up... it's tedious. Cut out half of it, deliver the rest in chunks, build a replay system that makes it easy to navigate to and play the individual chunks, and suddenly you're in the 21st century. I've been waiting for this to happen ever since I first used YouTube, and countless YouTube teachers have pioneered the technique; Khan is finally doing the evangelization.

I keep wishing, probably in vain, that TV would go the same way. I put off watching _Mythbusters_ for years because I just couldn't stand the editing: shows are edited for people who tune in and out constantly, so every five minute chunk has one minute of pure review of stuff _you just saw ten minutes ago_ , two minutes of new material intercut with one minute's worth of stuff that you have already seen, and thirty seconds of previews for things that you will see fifteen minutes from now.</comment></comment></comment>


How Far Back in Time Could You Travel and Still Understand English? - <AUTHOR> http://sploid.gizmodo.com/how-far-back-in-time-could-you-travel-and-still-underst-1764826914 <comment><USER2> FWIW, the Shakespeare example used modern theatrical pronunciation. [https://www.youtube.com/watch?v=gPlpphT7n9s](https://www.youtube.com/watch?v=gPlpphT7n9s) shows the difference between that and the original pronunciation.</comment>


OpenBSD vmm/vmd Update [pdf] - <AUTHOR> http://bhyvecon.org/bhyvecon2016-Mike.pdf <comment><USER2> Reyk Floeter's paper explains more about the implementation of the userland side, vmd(8), including its privsep design and the use of pledge(2):

[http://bhyvecon.org/bhyvecon2016-Reyk.pdf](http://bhyvecon.org/bhyvecon2016-Reyk.pdf)

OpenBSD's vmm(4) isn't related to FreeBSD bhyve, but Mike and Reyk were invited to talk about it in Tokyo. :-)

</comment><comment><USER3> vmctl(8) docs don't mention send/receive commands.

Curious what exactly those do.

[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD- current/man8/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD- current/man8/vmctl.8)

<comment><USER4> The way I understand it, it's not there, currently, more like something they want to support eventually.

</comment></comment><comment><USER5> With the current hype seeming to have moved from full VMs to containers, would there be more interest in porting Jails to OpenBSD?

Historically chroot and systrace have been felt to be "good enough" but they have in my experience been tedious to set up.

<comment><USER6> if there is one thing I've learned from being in the OpenBSD community for the past 10+ years it's that current hype is of little to no interest to the folks writing code.

</comment></comment><comment><USER7> I know that this is somewhat off the topic, but does anyone have anything I can read about implementing memory managers?

<comment><USER8> OSDev is a very good resource:

[http://wiki.osdev.org/Memory_management](http://wiki.osdev.org/Memory_management)

<comment><USER7> That deals a lot with theory, I am in need of some implementations that work. I've found things that don't work, but I need something I can start and play with.

Nothing really seems available which seems sad.

<comment><USER9> UVM, the virtual memory subsystem in BSDs, is actually very nicely explained in Charles Cranor's disertation. An abridged version was presented at USENIX: [https://www.usenix.org/legacy/event/usenix99/full_papers/cra...](https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf) , and if you google around, you can find the full thesis.

</comment></comment></comment></comment><comment><USER8> "– Support advanced processor features, but don't require them"

I like that a lot but I'd like to know it can do emulation.</comment>


Ask HN: Still in Use of Browser Bookmarks? - <AUTHOR> Today I found myself creating bookmarks bar folders on Chrome first time for the last year. I put there some references on Peter Thiel, logical fallacies and a couple of Reddit users' profiles for my further articles to be written.<p>Do you have some magic skills in managing your browser bookmarks? <comment><USER2> I have no magic skills. Essentially, I just bookmark anything that I want to read again. I used to use folders but now I just bookmark things.

</comment><comment><USER3> I organize by category. I have a few dozen categories arranged alphabetically.

<comment><AUTHOR> Do you have any system behind the process of creating the categories themselves? Food, personalities, linear algebra, logical fallacies, mystery containers?</comment></comment>


Build your own drink mixing robot - <AUTHOR> http://yujiangtham.com/2014/05/25/build-your-very-own-drink-mixing-robot-part-1/ <comment><USER2> I've always thought something like this would be a fun idea to build a cocktail bar around. 80% of making a great cocktail is precisely measuring and combining high quality ingredients. .

If you spent some time making a very attractive machine that was fun for patrons to watch, mixed great drinks that were finished with a human touch, it could be a really interesting draw. I imagine a place with a beautiful/badass MIT-made drink-mixing machine would do quite well in Kendall square.

Create list of 8-10 interesting drinks that change weekly, that source from perhaps a dozen different liquors/fresh juices. The machines selects one of 4 glasses that was already clean, could precisely measure/mix/shake the drink leaving the bartender to garnish, present, squeeze fresh lemons into a container. I think you could have a quality experience.

<comment><USER3> Even better, you can make a recipe API, and given a set of ingredients and some configuration, anyone can suggest a drink or pick one if available, so every robot mix drinker makes the exact same cocktail in any bar.

Use case: I like my Old Fashioned strong with a slice of lemon instead of orange. Make recipe, put online. Go to any bar with robot mixer: same Old Fashioned everywhere!.

</comment></comment><comment><USER4> I've always thought some kind of automated drink mixing system would be good for busy inner city cocktail bars. You can still have a bar where people can sit and watch someone mix drinks, but the rest of the venue can be tables with table service. The orders from the tables are taken by a person and gets sent to the kitchen where the drinks are made by machine. This will retain the personal touch of people attending to tables personally, and allow them to serve drinks often, promptly and consistently.

<comment><USER5> I don't mean this in a disrespectful way, but what kinds of drinks are you drinking and where are you drinking them? Yes, a robotic mixer might work in a crappy bar for standard bar drinks like a Rum and Coke, Long Island Iced Tea, etc., but anything beyond the standard pour-and-serve is probably best done by the human touch, especially if you're charging big city prices for them.

That said, there are some places that do use quick mixers to mix up the classics. Garduños, a huge Albuquerque, NM mexican restaurant (as seen in Breaking Bad, season 5!) uses pre-mixed margarita mix from a keg and dispenses it with a typical bartender's soda gun. They've realized that most people who order "well" margaritas aren't that discerning and appreciate the consistency that a factory-mixed 'rita delivers. Garduños serves them by the gallon and the pre-mix saves them lots of bartender time when they're mixing their most popular cocktail.

This would never fly in a nice bar, though. These days, most big city bars are chasing the money and the money is in "craft cocktails". It's all about the ingredients and the customized drinks that are tailored to the customer's preferences. Bartenders are making a big show out of things like twisting a slice of orange peel to release its oils. The presentation is hugely important here and a robotic mixer just doesn't have the right vibe, in my opinion.

<comment><USER6> I'm not buying the "robots can't make drinks" argument.

Restaurant automation was big in the 1960s and 70s, but it eventually became a flop. The technology mostly worked, but in the end, customers came more for the "culture" of the restaurant or bar. That is, to chat up the waitress, have a short conversation with the bartender, and most importantly, to not feel lonely.

Part of the "big city prices" is the exclusivity that place delivers, not how fine the process for making the current hot drink is.

Restaurants and bars aren't like most businesses. They don't just deliver product. They deliver some sense of shared culture, some sense of exclusivity, and some sense of 'here is where my kind of people belong.' That is also why we mock chain restaurants, some of which deliver perfectly fine food, but are seen as too 'cookie cutter' for the social experience we demand.

I say bring on the robots. I go to a lot of live music shows and waiting on drinks takes far too long and heaven forbid I get the "too cool for you" bartender and his weird douchbaggery on top of the drink I want. Maybe the bartender role will go the way of the elevator operator or travel agent role. Or higher end places will keep it and the rest will have a bartender sysadmin position to make sure everything keeps running, fills up supply, orders everything, calls service, etc.

<comment><USER7> They'll probably always need some human around for liability reasons. That is unless the robot bartender is going to add some sort of breathalyzer component to see if people have had too much.

Also unless it's a club it likely would need to scan the person's ID and confirm whether or not the person was who the ID mentioned adding some complexity to the robot that otherwise wouldn't be required for just serving drinks.

The sysadmin person you mentioned could definitely take on that liability role in addition to anything else he needs to do to support the robot.

</comment></comment></comment></comment><comment><USER8> Nice! Still got a ways to catch up with these guys though:

[http://www.roboexotica.org/](http://www.roboexotica.org/)

Includes regularly-scheduled party!

<comment><USER9> Wow, this and the OP are incredibly sick.

<comment><AUTHOR> Thanks for sharing! Really cool drink robots in the link! :)

</comment></comment></comment><comment><USER10> Very cool! From a health perspective, has anyone looked into whether these homemade machines for food/drink are safe for consumption? I see that the tubing in the materials list is FDA-approved, but has there been any work done on the other stuff? And with alcohol specifically, are there any potential complications?

<comment><USER11> One of the large benefits of peristaltic pumps is that the only thing that the liquid touches is the tube.

<comment><USER10> Ah, that's great. For those wondering how: [https://en.wikipedia.org/wiki/File:Peristaltic_pump.gif](https://en.wikipedia.org/wiki/File:Peristaltic_pump.gif)

</comment></comment></comment><comment><USER12> awesome, yujiang! it's been cool to see all the hardware stuff you've been hacking over the past few months, sad i missed this your party (and the bar mixvah)!

</comment><comment><USER13> SmartBar has been around a few years with a ready commercial product:

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

They've found some traction with places like cruise ships and hotel conference facilities. They can drop one of these at a cocktail hour with a preset spend limit and the machine will happily pour drinks until the tab is maxxed out.

</comment><comment><USER14> Consider a kickstarter, I'd love to buy one.

<comment><USER15> Actually, there's one similar, happening now: [https://www.kickstarter.com/projects/barobot/barobot-a- cockt...](https://www.kickstarter.com/projects/barobot/barobot-a-cocktail- mixing-robot)

<comment><USER16> And another that ended not long ago: [https://www.kickstarter.com/projects/partyrobotics/bartendro...](https://www.kickstarter.com/projects/partyrobotics/bartendro- a-cocktail-dispensing-robot)

</comment></comment></comment><comment><USER11> Awesome. I'd really love to see one of these that's good enough to actually use at scale at a large party. This one looks closer than a lot of the others that I've seen. Perhaps higher quality peristaltic pumps (higher flow rate, less noise) in combination with more ingredient chambers would push it over the edge.

</comment><comment><USER17> We really need this for Soylent, and I remember there was talk about this on the Soylent forums soon after they got going.

Does anyone know specifically what the issues are to creating a Soylent bot? Or is it in the works?

</comment><comment><USER18> Aren't the linked peristaltic pumps a little bit too slow for this purpose? It would take 3 minutes to fill 300ml of soft drink on top of 200ml vodka.

<comment><USER5> It would take quite a pump to match the speed of a skilled bartender with a soda gun in one hand and a vodka bottle in the other.

<comment><USER19> You might be surprised at what compressed air and a liquid siphon tube can do with a vodka bottle. 100 psi rated, extremely fast acting air valves are not that cheap and you need to filter and regulate the air and slow leaks make a mess and some dripping is inevitable, so "the scene" tends to now use tubing pumps as seen in the linked article.

Another tech thats been popular over the years is just tipping the bottle, which has the advantage of putting on quite a show and the disadvantage (or maybe not?) of splashing. You need a beefy servo because the center of gravity and torque are going to vary as the bottle empties.

Finally another tech often implemented in these robots is running the receptacle on an accurate-ish lab scale. Gram level accuracy is probably good enough although 0.1g accuracy would be better.

Its an old idea thats been around since at least the 80s home computer era, its been fun watching reimplementations and new ideas and new techs.

<comment><USER20> I've always preferred the compressed air approach, but mostly because of cost - those peristaltic pumps are pretty pricy if you want to get 12ish bottles in there. I was under the impression that you could use relatively cheap pneumatic solenoids like this [http://www.amazon.com/Vdc-Normally-Closed- Solenoid-Valve/dp/...](http://www.amazon.com/Vdc-Normally-Closed-Solenoid- Valve/dp/B007D1U64E/ref=zg_bs_1265148011_4) at ~$5 rather than ~$14. Do you think that it's important to get high quality valves? My plan was to use a scale and do some feedback control to compensate.

<comment><USER19> Hmm those are cheap, at $5 the old aerospace approach of a parallel/series high reliability network sounds like the cheapest way to prevent slow leaks. Draw 4 valves with two in series and two strings in parallel and no failure mode of any individual valve either stuck open or stuck closed can cause an overall mission fail. Another way to deal with slow leaks is a small intentional air leak on the top of the liquor bottle and trust your weight scale feedback because the output flow rate will be lower but how much lower will depend on the intentional air leak. So 10% of incoming air leaks out, well, thats OK if it prevents slow dribble.

WRT to quality valves if you have a slow leak in the air input valve, even just a drip per minute, you'll slowly drain the bottle while it sits there. A more complicated arrangement with more valves can vent the bottle when its not supposed to be pumping which helps.

Your scale idea is excellent and I've seen it done. If you're sufficiently motivated its a great platform to play with PID controllers or at least PD (not I) control theory.

For a literature search I've seen this kind of machine in make magazine maybe in the 00s or at least a couple years ago and in some 80s era home computer magazines. It fell out of favor in the 90s or maybe I wasn't paying attention.

Advanced systems put a slight vacuum on the delivery hose to prevent dribbling although there's obvious cross contamination fears. From memory this was part of the reason the "tip the whole bottle with a R/C servo" guy took that approach, side from being visually more stunning. I remember that guy writing about an air traffic control issue where you can't have the neck of two bottles in the same airspace simultaneously, so extra delay timing is critical, can't immediately drop one bottle at the same instant one is lifting up.

I also recall reading about a design involving "hit the wine-in-a-box button with a servo horn" although that had variable flow rate problems and splashing issues, which might be worked around.

<comment><USER20> The parallel/series approach sounds really interesting - I'll have to look at that. On the other hand, if you wanted to reduce valve count, you could even do charlie-plexing! Then you can get 2*sqrt(N) nice valves to control N bottles. That would be really cool. Now somebody's just got to build the 100 bottle bartending robot.

</comment></comment></comment></comment></comment></comment><comment><USER21> You do not seem to put the emphasis on what's interesting: Is the drink actually any good?

Great job, obviously!

</comment><comment><USER22> You still have to put in the ice youself. Perhaps version 2.0 will have this feature :P

</comment><comment><USER23> You should monetize it soon. I would be one of your first customer. Great Job!

</comment><comment><USER24> This is now my summer project. Thank you!

</comment><comment><USER25> I'll have a soylent and vodka.</comment>


Sendgrid.com unavailable, mail delays (EU traffic still routed via US) - <AUTHOR> https://support.sendgrid.com/hc/en-us/articles/204405288-18-Mar-Sendgrid-com-unavailable-mail-delays

<comment><AUTHOR> Europe latency issues still unresolved (after 2 days) to blame probably the data center! [https://support.sendgrid.com/hc/en- us/articles/204368438-16-...](https://support.sendgrid.com/hc/en- us/articles/204368438-16-18-Mar-Europe-Latency-Increase)</comment>


Jobs, Back at Apple, Focuses on New Tablet - <AUTHOR> http://online.wsj.com/article/SB125115760997755251.html?mod=djemalertTECH <comment><USER2> _Since then, Apple has updated several of its product lines, including the iPhone and its Macintosh laptops, but hasn't launched an entirely new category._

I find it amusing that "not launching an entirely new category" of product in a two year period is notable.

</comment><comment><USER3> Come on, can we stop upvoting the stupid Apple Tablet stories? Yes, we all know they're working on a tablet and we all know they can keep all relevant and interesting info secret, feeding the press nothing but enough vague scraps to keep themselves in the news.

So I ask you, unless you see actual specs and pictures, please don't upvote these stories.

<comment><USER4> After reading this "article", I completely agree. It's a series of "people familiar with the matter" and quotes from analysts.

Said analysts bring immense insight like:

\- "As devices become more expensive, your ability to make them mass market declines," said Toni Sacconaghi, an analyst with Sanford C. Bernstein & Co.

\- Analysts say how well an Apple tablet sells will depend on price, which most believe will be between $399, the price of a high-end iPod touch, and $999, the price of the cheapest MacBook laptop.

\- Apple watchers expect the tablet to debut at the end of this year or early next year.

</comment></comment><comment><USER5> Google link for those of us who don't subscribe: [http://www.google.com/url?q=http://online.wsj.com/article/SB...](http://www.google.com/url?q=http://online.wsj.com/article/SB125115760997755251.html)

</comment><comment><USER6> Odd, the article is starting as: "EMBARGOED!Just a few months" What did some editor add 'embargoed' to the article?

<comment><USER7> For those who aren't familiar with embargoes, it basically just means there was an agreement not to publish the article until some point in the future (e.g. tonight at 6 PM), so that's probably just a reminder to whoever runs the online portion of WSJ and they forgot to remove it.

A bit strange to see it here though, as usually the agreement is between the author and the company they're covering, but it sounds like Apple wanted nothing to do with the story in the first place. My guess is that WSJ also uses 'embargoed' when they're holding a story to publish it alongside the print edition.

</comment></comment><comment><USER8> I hope this thing doesn't use the iPhone OS. That thing is an abomination, an insult to hackers everywhere.

</comment><comment><USER9> Maybe it's really an interactive remote for the next generation Apple TV.

<comment><USER10> You know there already is one, yes?

<http://www.apple.com/itunes/remote/>

</comment></comment><comment><USER11> Newton2?

<comment><USER12> "New2n"! :)

<comment><USER11> iNewton :(

</comment></comment></comment><comment><USER13> Apple will announce the tablet at CES 2010.</comment>


Finland Will End Its Experiment with Universal Basic Income - <AUTHOR> http://time.com/5252049/finland-to-end-universal-basic-income/ <comment><USER2> Discussed earlier:

[https://news.ycombinator.com/item?id=16874921](https://news.ycombinator.com/item?id=16874921)

</comment><comment><USER3> What good is an experiment applied to a small group of people and only for a limited time? The people that get it aren't going to adjust their long term behavior and the local economy certainly isn't going to change in response.

<comment><USER4> Well, we have no alternative. We can't afford an experiment that funds a ton of people and lasts for a long time. No matter how abundantly confident the people of HN may be that BI is the way to go, one of the fundamental lessons of science over the past couple of centuries is that your "abundant confidence" doesn't count for squat in the real world.

If BI can't prove itself out in a smaller environment, we on no account can afford to risk our entire economy on it.

That said, I'm not saying this was necessarily a viable test of the idea. On the other hand, if it really is a great idea that is going to save civilization, it really ought to have the characteristic that it is still a good idea that is an improvement on the status quo even when applied in the small, such that everybody wants to continue the experiment and expand it, not shut it down. The slow drip of failed BI experiments, even if they didn't "really test BI", is becoming non-trivial evidence against the idea. An idea that only works if we wake up one day and transition the entire national economy at once, or worse, even the entire global economy (which the combination of "open borders" and BI could require, if "open borders" includes handing out BI to everyone who crosses the border), is a non-starter. Even if in some abstract sense it would work, we can't ever attain enough confidence in the plan to make it a rational choice.

There are certainly things that have the curve that if done a bit make things worse, but make things better if done wholeheartedly. However, there's a lot more things that people _think_ have that curve but actually make things worse the more they are done. It is impossible to tell the two apart from here, and the abundance of bad ideas should give one pause before making a huge commitment. The twentieth century is strewn with the wreckage of economies that made that mistake, and the twenty-first century hasn't stopped, either. We can really only consider interventions that work in the small for our changes in the large. (And always keeping an eye out for the interventions that worked in the small but failed in the large!)

<comment><USER5> Simply select 2000 18 year olds and give them BI for life. That isn't all that expensive even in worst case and would actually show if BI could work.

<comment><USER6> Pretty sure you can find 2000 18 year olds with a trust fund or part of a Native American Indian tribe that distributes gaming revenue.

<comment><USER7> "Coming from a rich family" or "part of a Native American tribe" is not a wide enough distribution of people to draw conclusions. Any failures / successes could be down to the environment and may not be able to be extrapolated to the rest of society at large.

<comment><USER8> On the other hand, if you're wondering if people who after the end of highschool, are able to finish college without having to get a minimum wage job to pay rent and for college, are doing better in life after college (and what measured amount better), the data already exists and there are far more than 2000 subjects.

</comment></comment></comment></comment></comment></comment><comment><USER9> I'm not convinced these big bang experiments, in the context of a wider economy not organised around the concept, are that useful.

For me one of this big advantages of BI is not enabling more people to 'drop out' of the productive economy and become artist such. It's actually the way in which it subsidises low income jobs. One of the big problems we have at the moment is low paying work being squeezed out of the economy through automation and increases in the minimum wage. A basic Income enables more people dropping out of the labour force to get back into it, because with a BI low paying jobs become a more viable way to earn a living. This gets people out of the poverty trap and also makes businesses dependent on low wage work more viable. It could be a real shot in the arm for the employment sectors that the most vulnerable people in our economy depend on.

On that basis, rather than pick a few thousand people to give a large BI to, why not start by providing a very modest BI to everybody. Fund it by equally modest tax increases, so it's revenue neutral. You could start with on the order of a hundred bucks (quid, whatever) a month. If a BI is going to have a beneficial effect, then even at this level it ought to do some measurable good.

</comment><comment><USER10> If this was an experiment, what were the results? What was being measured?

<comment><USER11> According to the article, it will end in January 2019 (the government decided not to fund extending it), so results can be expected in a year or so.</comment></comment>


Browser Extensions Standard - <AUTHOR> https://browserext.github.io/browserext/ <comment><USER2> Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters?

This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of.

Having it be a standard adds security but strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on -- sometimes literally, if you're going through a curated store. Is that a net win? I'm not sure.

<comment><USER3> In general, if your software supports plugins, you can:

1\. Have plugins with ultimate power (meaning that plugins can change everything, no encapsulation) 2\. Stable API/ABI (meaning that plugins written for version 1 will work with version 2) 3\. A refactorable code base.

You can pick only two out of three.

Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess support for years (causing it to have worse performance and security), and now wants to move to 2 and 3.

Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a stable Kernel ABI - they chose 1 and 3.

<comment><USER4> There is one plausible solution to this inequality: the Unix philosophy. Small parts, loosely coupled. Individual parts can't be significantly changed or removed, but they can be deprecated and better alternatives added. Because the parts themselves are small, they're less likely to have errors and replacing them is cheap.

Rich Hickey also has a talk on this. And there's also an overlap with CRDTs (basically you have a distributed system unless you can refactor everything atomically).

</comment></comment></comment><comment><USER5> Finally! WebExtensions ([https://developer.mozilla.org/en-US/Add- ons/WebExtensions](https://developer.mozilla.org/en-US/Add-ons/WebExtensions)) have slowly been becoming an adhoc standard for a little while now, but with a few tricky small differences here and there between browsers (e.g. [https://developer.mozilla.org/en-US/Add- ons/WebExtensions/Ch...](https://developer.mozilla.org/en-US/Add- ons/WebExtensions/Chrome_incompatibilities)). So far it's just been Firefox and Edge slowly building a close approximation of Chrome's existing API, but a proper standard for this would be great, and make it much clearer what extension developers can _depend_ on, and what's optional.

Right now you basically write your extension once (probably for Chrome), and then port it to the others, often with various small manual changes or workarounds for incompatibilities. It's much better than it used to be, but still pretty inconvenient and error prone.

I can see at least a couple of differences with current implementations though, like using the `browserext://` protocol instead of `moz-extension://` and `chrome-extension://`. Does anybody more involved with this have a summary of the differences between this spec and Firefox, Edge and Chrome's implementations?

<comment><USER6> I'm not very involved, but on top of the Chrome base API both Firefox and Edge have a bunch of additional APIs IIRC (I _think_ Firefox supports all of the Chrome APIs but I'm not sure). The intent is to have the same manifest format so basic extensions work everywhere, but extensions can use browser-specific APIs that fit within the same general framework too.

<comment><USER7> > I think Firefox supports all of the Chrome APIs but I'm not sure

They support quite a few but not all. in addition there is a promise based version of each of the APIs that you can use in firefox under the browser namespace instead of the chrome namespace. (with a polyfill on npm too if you want that in chrome)

</comment></comment></comment><comment><USER8> The only problem which Mozilla didn't think about or hasn't given much value to is the huge number of add-ons that are going to die or just stop working when they completely switch to WebExtensions (as there's just no replacement to the previous API in them). One of the Firefox's USPs was its addons which could modify the browser behavior and UI in any manner. It's all going to go, and Mozilla is moving closer to becoming a Chrome clone (albeit open).

For example, a hugely useful feature for me was TabGroups (Panorama) which they removed from the main browser to make it an external add-on, and even that will stop working soon [0]. Similarly, there are add-ons which modify the browser's inbuilt 'Find in page' behavior in Firefox. Looks like even they are not WebExtension compatible.

[0] : [https://addons.mozilla.org/en-US/firefox/addon/tab-groups- pa...](https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/)

<comment><USER9> Mozilla has given this _a lot_ of thought, and realized it is _extremely valuable_. But the value does not dwarf the downsides.

XUL extensions would block most of the Servo work, as an obvious example. You can't rely on the browser internals if those are changing underneath you.

<comment><USER8> Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way, for example. But they found killing all of the valuable add-ons of years worth of work of so many developers justified.

<comment><USER10> > they'd have pushed for replacement of XUL APIs in WebExtensions in a non- > blocking way

Which "they" did, and are. Some APIs are more amenable to such replacement than others. For example, APIs that allow you to modify any part of the browser UI in an arbitrary way are not so amenable _and_ have the problem of breaking any time the internal structure of the UI changes. Which has, in the past, prevented improvements to the internal structure of the UI...

It's really easy to see only one side of this (the downside of extensions breaking, or the upside of not having your implementation severely constrained by extensions that keep depending on internal details they shouldn't depend on). But there are in fact people who've thought long and hard about both sides of this.

<comment><USER11> Except the downsides are mostly for the users (extensions stop working) while the upsides are mostly for the browser developers. (Better ability to refactor and update)

<comment><USER10> The upsides are for users as well: better performance, less memory usage, better ability to implement web standards. Browser developers aren't just breaking extensions for the fun of it, but because they're in the way of actually producing a better product; the goal is to produce said better product.

The upsides are just somewhat more diffuse than the downsides: the former apply to all users, while the latter only to those who have extensions that stop working.

</comment></comment></comment></comment></comment></comment><comment><USER11> As a developer, I'd really like if I could publish an extension as a single archive file and have users load it into whatever (compliant) browser they like - however, the standard doesn't seem to actually support this. When it comes to packaging, there is nothing more than a vague acknowledgment:

 _Browser extensions MAY be distributed and subsequently loaded as individual files or via a container, such as a .zip archive. Regardless of the packaging format, these containers MUST contain the following: [manifest.json, Necessary JavaScript files ( <filename>.js)] [...]

Browser vendors MAY require that extension packages include a digital signature. The signature MAY indicate the source of the extension, such as a distribution store or the extension's publisher. This aspect of packaging varies by browser, and browser implementers MAY enforce different requirements._

I guess that's a concesson to all the politics surrounding app stores, but it's disappointing nevertheless.

<comment><USER12> Unfortunately that would be practically difficult with Chrome only allowing extensions downloaded from the Chrome Web Store.

<comment><USER13> The package format could apply to how extensions are deployed to the store at least.

Also, I know it's possible to run third-party extensions in developer mode.

</comment></comment></comment><comment><USER14> As a chrome extension developer I really like this. Previously I didn't develop extensions for other browsers because I would have to learn another ecosystem. Now it could be pretty simple to do.

I also like that all of the asynchronous API calls are returning Promises. Chrome API is still using callbacks. This also means that some time will pass while this is even added to chrome. I expect that there will be a polyfill library that translates the new API calls to legacy browser API calls.

</comment><comment><USER15> Sorry for not bringing anything of value to the discussion but: Heck. Yes! I love Firefox for going in this direction. The politics of embracing Chrome's extension APIs and standardising upon them must have been astounding.

I can't wait to port my extension to Firefox. Firefox is seeming like a more and more viable option to Chrome.

</comment><comment><USER16> It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.

<comment><USER17> Well, that sounds like the historical Firefox. If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on. Worked like a charm for the first 10 years, not so much afterwards because it became a maintenance nightmare.

That's actually the main reason for which Firefox is moving away from XUL add- ons and towards more restricted WebExtensions.

<comment><USER18> > If you look at the source code of Firefox, just about everything except > Gecko is a XUL add-on

That's not really true at all. Most of the Firefox UI was written in JS (and XUL and XBL), but not as add-ons.

It would have been great if it _were_ true, because not only do you get the reconfigurability the parent commenter writes about, but there are even better advantages: it would also have meant the Firefox team themselves would have had to confront the poor APIs exposed to extension authors and the poor practices about breaking things. The reality is everyone just touched browser.js (or what have you) to make it do what they wanted.† Had that not been the case, the deprecation of old-style toolkit add-ons might have happened long ago and a good replacement created. What happened instead is the worst from both ends: a sickly add-ons ecosystem built on top of fragile XUL- based extensions hobbled along for years, and now that they are obsoleted, they are given a replacement that is decidedly not good.

When Robcee announced he'd gotten the imprimatur to ship devtools with Firefox, I made an impassioned plea for it to be developed and shipped it as a built-in add-on, for exactly these reasons, and because it would have allowed faster development iteration and provided an easier contribution path (no need to ever waste hours rebuilding nightly, or asking for the same from a casual contributor who wants to submit a patch but doesn't work for a manager with an @mozilla.com address). No dice.

† Not to mention tons of XPCOM junk _not_ related to rendering or parsing or the JS runtime that was nevertheless implemented in C++ and would need updates to the core if ever wanting to anything non-trivial.

</comment></comment></comment><comment><USER19> Does anybody know whether the Google Chrome / Chromium team and the Mozilla team are squarely behind this standardization effort? What about the Apple Safari team?

There's only one rep from Google in the community group. There don't seem to be any from Apple.

[1990s paranoia mode] this could be another Microsoft effort to embrace and suffocate [/1990s paranoia mode]

<comment><USER19> I've been working on web extensions for multiple browsers lately.

Chrome and Firefox have workable ecosystems and accept more or less the same code, but package it differently.

Edge accepts almost the same code, but they had to change the "chrome" namespace to "browser". I suppose it was a question of pride. Also, Edge doesn't have a workable way to publish and to inline-install web extensions.

Safari accepts similar code to the rest, but organized differently. They have a slow and ponderous process for approving extensions for their store. They don't offer anything remotely resembling inline installation.

<comment><USER6> > but they had to change the "chrome" namespace to "browser"

It's weird, because Firefox internally has had the "chrome" namespace long before Google Chrome _existed_.

In browser terminology the browser "chrome" is the stuff that's outside the browser engine -- the stuff that doesn't handle loading/laying out/rendering/javascripting a page. I.e. the tab strip, URL bar, bookmarks, context menus, settings, etc.

IIRC (very unsure of this, but have heard it from different non-google sources) the name "Google Chrome" is actually a joke on this because it had the _least_ chrome amongst browsers of the time (remember the toolbar and status bar?)

<comment><USER20> > IIRC (very unsure of this, but have heard it from different non-google > sources) the name "Google Chrome" is actually a joke on this because it had > the least chrome amongst browsers of the time (remember the toolbar and > status bar?)

Well, that and it was Google.com's "chrome".

</comment></comment></comment></comment><comment><USER21> Part of the reason why we have different browsers is the variety of features they support. A browser extension inherently is closer to the unique part of browsers that make them different.

What value does this really provide? The times that I've gotten into browser extensions were really working with features that are unique to the given browser.

<comment><USER22> There's an argument that while rendering engines are huge, monolithic undertakings, the actual browsers wrapped around them are fairly trivial. Assuming they use the same rendering engine under the hood, a relatively lightweight, tightly integrated platform-native browser (i.e. Safari or Gnome Web) might be a better user experience than a cross-platform behemoth like Chrome.

Extension support and depth of extension library have traditionally been the big pain point with switching to a minority browser. Moving extension support into a browser independent standard removes a lot of the selective pressure toward a monoculture.

</comment></comment><comment><USER23> It would be really nice if you could blacklist websites from using extensions in Safari, e.g. banking websites.

There are lots of useful extensions out there that would be nice to use, but I'm concerned if they became compromised (which happens regularly[1]) they might hijack my data.

Safari has a great feature that stops extensions from being able to read or transmit anything from websites you visit, which is great, but limits the effectiveness of a lot of ad blockers.

[1] [https://news.ycombinator.com/item?id=14888010](https://news.ycombinator.com/item?id=14888010) (just 2 days ago!)

</comment><comment><USER24> Looks a really good idea

</comment><comment><USER25> But will Google allow this to happen, as it would strip them a huge selling point for Chrome?

<comment><USER26> Please elaborate. What selling point for Chrome are you talking about?

<comment><USER9> The add-on ecosystem of Chrome currently dwarfs Firefoxes. Firefox extensions used to be more capable, but there's just more and certainly more NEW ones for Chrome.

(I'm sure this was an important consideration for Mozilla as well - it reduced the supposed value of their "more powerful" XUL extension system, as in practice you can often find a Chrome extension to do what you want, but not a Firefox one)

<comment><USER26> But Firefox can already run WebExtensions (aka Chrome extensions).

So how does this change anything?

<comment><USER9> It can.

But it can't keep XUL compatibility and do major overhauls of the browser.

If XUL compatibility doesn't even get you a clear advantage in the add-ons area, should it block modernizing the browser?

Firefox can't be the browser that people use only because they're stuck on it because they have extensions that changes how the browser works. Think about that for a bit.

<comment><USER26> I know all about the issues with Firefox, the new WebExtensions and how the "old" XUL extensions which let you do "anything" are being phased out.

I just don't see how any of that is relevant to the original comment I replied to:

> But will Google allow this to happen, as it would strip them a huge selling > point for Chrome?

In what way would standardizing WebExtensions, which are already supported by all modern browsers (sans Safari), strip Chrome of selling points?

Why should Google have to "allow" this?

<comment><USER9> Chrome currently has the largest amount of extensions, which is an advantage for that browser.

Standardized WebExtensions dilute that, because they allow easy ports to the other browsers.

<comment><USER27> I think the point is more, in what way does google have any power to stop other browsers from implementing this API?

<comment><USER9> They don't. Unless you want to claim API's are copyrightable, but there are some downsides to that :-)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> Cute idea, but I will eat a broom before this actually becomes reality.

<comment><USER9> Not sure what you mean by this, but this (like most modern web standards, and I'm not even sure of the modern part) is just documenting what the implementations are _already doing_.

Mozilla and Microsoft are specifically re-implementing the Chrome Extensions API, and documenting it.

<comment><USER29> Eating a broom is a German saying: «Eher fress ich einen Besen...!».

<comment><USER30> Thank you! I was just about to ask about the origins of that phrase (which I've never heard before).</comment></comment></comment></comment>


Scientists extract genetic information from a 1.77M-year-old rhino tooth - <AUTHOR> https://www.sciencedaily.com/releases/2019/09/190911142731.htm <comment><USER2> What ever happened to the 70 million year old soft tissue miraculously discovered of a t-rex a decade ago?

[http://www.nbcnews.com/id/7285683/ns/technology_and_science-...](http://www.nbcnews.com/id/7285683/ns/technology_and_science- science/t/scientists-recover-t-rex-soft-tissue/)

Was it delicious? Also, was there any DNA recoverable through this newer method?

</comment><comment><AUTHOR> Early Pleistocene enamel proteome from Dmanisi resolves Stephanorhinus phylogeny [https://www.nature.com/articles/s41586-019-1555-y](https://www.nature.com/articles/s41586-019-1555-y)

</comment><comment><USER3> dumb question: what can scientists do with this besides studying the DNA data? Can they now clone that animal?

<comment><USER4> Not a dumb question. No, we can't clone it. It will be an incomplete genome, it's just a subset of the animal's entire DNA sequence, and it's reconstructed from proteins. We've recovered some words from the ashes, and so we can tell what language the book was in, and where in history that book fits in with the language (comparing those words with other books with similar words), but we can't reconstruct the whole book yet.

<comment><USER5> > We've recovered some words from the ashes, and so we can tell what language > the book was in, and where in history that book fits in with the language > (comparing those words with other books with similar words), but we can't > reconstruct the whole book yet.

If they had other teeth (from the same specimen or different ones of the same species), would they be able to just combine them to fill in the gaps?

To follow your metaphor, to me this sounds like finding different copies of the same printing, same edition, same book and combining them all to make a complete book. Does the metaphor fall apart?

<comment><USER6> Consider the size of the DNA "books": for example, the human genome is around 3 GB (uncompressed), much bigger than a single book on your shelf: King James Bible as plain text is around 4 MB (uncompressed), so it's a factor of roughly 1000 times (being always copied in every cell of your body!) and we have many complete copies and versions of older bibles but we still can't completely reconstruct too old versions. But we can have a reasonable reconstruction of the "tree" of the development of the known bibles.

And having just a single page from a bible can tell you quite good where that bible fits in the tree of all known bibles.

<comment><USER5> Thank you! I hadn't considered the size or amount missing from a given "book," that makes it much clearer.

</comment></comment></comment></comment></comment><comment><USER7> I usually welcome editing the title to be in accordance with the guidelines but tbh you guys went a bit overboard on this one. Previous version of the title clearly indicated that it is about a tooth or an ancient rhinoceros, but "enamel from Stephanorhinus"? Not very helpful.

<comment><AUTHOR> I did what I could.

</comment></comment><comment><USER8> Side note: When looking for HN posts, I tend to enjoy the ones where I know <4 words in the title.

DNA has always been such a fascinating topic to me. In school, we had such a limited look into it and yet it seemed to be _the_ thing in what makes us "us". I really hope as a society we continue to push the boundaries of our knowledge to see what DNA can tell us. And out of teeth? That is just so awesome.

<comment><USER9> For others who are having trouble understating the title, it basically translates as: "Set of proteins in bit of tooth from very old rhino from Georgia (the Caucuses) enables genetic classification of some related species."

</comment></comment><comment><USER10> it's the first time in years I've read a sentence where I didn't know 1/3 of the words, thank you :)

<comment><USER11> Reverse clickbait.

<comment><USER12> No way, this title is perfect HackerNews clickbait. I was baited, and I was not disappointed by the article. Or at least the abstract, which was as far as I got. TLDR: They figured out how to use tooth enable to make genetic associations between fossils, and learn some other things. And it's a lot more reliable for old fossils than DNA!

Edit: Title at the time of writing my comment is "Early Pleistocene enamel proteome from Dmanisi resolves Stephanorhinus phylogeny" which is the actual title from the article

</comment></comment></comment><comment><USER13> This summary on ScienceDaily is much more comprehensible and also is not paywalled:

[https://www.sciencedaily.com/releases/2019/09/190911142731.h...](https://www.sciencedaily.com/releases/2019/09/190911142731.htm)

</comment><comment><USER14> That escalated quickly

</comment><comment><USER15> Oh yeah? and did they get the Rhino's consent?</comment>


Bitcoin 0.8.6 Released: Updates Block Size Limits, Free Transactions, OS X Bugs - <AUTHOR> http://thegenesisblock.com/bitcoin-0-8-6-released-updates-block-size-limits-free-transactions-osx-bugs/ <comment><USER2> Bitcoin is about to break 1 Billion difficulty.

The leap in difficulty must mean all the 500-600Ghash/sec 28nm ASICs are coming online.

<comment><USER3> Given that there has been a 8x growth in price, miners must still be profitable at this point? If I were an ASIC supplier, I would be delaying shipping and "alpha testing" those hardware in times like this

<comment><USER4> > * If I were an ASIC supplier, I would be delaying shipping and "alpha > testing" those hardware in times like this*

I'm glad that you're not an ASIC supplier, because that's fraudulent and dishonest.

<comment><USER5> Implying the ASIC suppliers aren't?

</comment></comment></comment></comment><comment><USER6> Genuine question: Does this mean Btc is not so decentralized after all? Could they possibly decide one day to release an update to exercise ultimate control/power over btc?

<comment><USER7> It's certainly a point of trust, but ultimately it's the miners who decide how Bitcoin works. So far this has predominantly worked by them using software from bitcoin.org and upgrading it relatively frequently, but this would probably change very quickly once they stop thinking of the bitcoin.org developers as working in their interest.

</comment></comment><comment><USER8> No one claimed the 10BTC bug bounty for the OSX client, so its all a matter of hoping things are fixed

<comment><USER9> This seems like a reasonably strong claim - and has the post title, "Claiming Bitcoin's Bug Bounty":

[http://hackingdistributed.com/2013/11/27/bitcoin- leveldb/](http://hackingdistributed.com/2013/11/27/bitcoin-leveldb/)

The corruption explained there matched the pattern seen in representative cases supplied by the core team.

The core team may not have yet _awarded_ the bounty, and there were a few other possibly contributing factors regarding proper use of LevelDB on OSX before the above work... but there's certainly a strong case made that a real fix has been discovered and deployed.

</comment></comment><comment><USER10> By lifting min output for free transction does the bitcoin network become more vulnerable to DDOS?

</comment><comment><USER11> Seems kind if weird that Bitcoin (actually bitcoind) itself would be dependent on a google-developed database solution that isn't open source, and not only that, has non-determinate behavior, depending on the host system..

<comment><USER12> Why do you think LevelDB isn't open source? [https://code.google.com/p/leveldb/](https://code.google.com/p/leveldb/)

<comment><USER11> Because it has dependencies on libs that are not open source, so that means "closed" as propagated across this "open" system.

<comment><USER12> I was assuming you were mistaken, but it's starting to look like you're just making things up. LevelDB has no dependencies other the Snappy compression codec, which is both optional and BSD-licensed.</comment></comment></comment></comment>


Help – hosted app company - <AUTHOR>

Recently someone posted a platform that would let you build hosted apps. It included security, a spreadsheet, contacts, and an API to customize it. I thought it was cool at the time, but had no need. Now I have a need. Can anyone in the hive mind help me out? <comment><USER2> How long ago?

I monitor HN for the word spreadsheet, but can't think of anything that matches your description. Have you got more details.

Will this work? www.cellmaster.com.au - I have a few early adopters using it.

What is the problem you want to solve?</comment>


Computer chips made of wood promise greener electronics - <AUTHOR> http://www.infoworld.com/article/2926806/components-processors/computer-chips-made-of-wood-promise-greener-electronics.html

<comment><USER3> "cellulose nanofibril" ... "The researchers coated the CNF with epoxy"

So it's not actually wood then. It's cellulose with epoxy.

This is not in the slightest "greener".

"Fungi and moisture that exist in the wild are needed for the chips to begin to decompose"

The chips are encapsulated in a plastic package, they are not going to have fungi or moisture near them.

And the silicon in a normal chip is not really a recycling problem - <USER2> planet is basically made of the stuff.

This is a solution looking for a problem, and I'm quite certain this is the last we'll ever hear of it.</comment>


Should Startups Focus on Profitability or Not? - <AUTHOR> http://www.bothsidesofthetable.com/2011/12/27/should-startups-focus-on-profitability-or-not/ <comment><USER2> One issue many founders never think of is that if you get VC and focus on growth and not profit, you are putting yourself in a riskier position where your shares could be worthless.

If the company ever sells, they will definitely be looking at profit when it comes to valuation and if it's over-valued, VC gets paid out first.

I think many startup founders have it backwards: They have a good idea and they try to shoe-horn in a business model (that sometimes works).

Instead, come up with the business model first and then come up with a great idea around it. I've done this with my last two companies and I was profitable from day 1.</comment>


Ask HN: Interesting things to do with old smartphones? - <AUTHOR> <comment><USER2> I usually keep my previous phone whenever I get a new one so I have a backup in case I break/lose my main one and it takes a little while to get a replacement.

Other than that, I was going to use an old iPhone or Android phone as a wall- mounted touch panel for my Hue lights or to run media apps to cast to one or more Chromecasts around the house. The original plan was to put the phone in a 3-gang box in the wall with some foam or other material to hold it in place. Then I attempted to use my dremel to rout out an opening in a blank plastic wall plate so the phone was held in place but the screen was accessible.

Unfortunately my dremel skills aren't good enough to the point where I could get one looking good enough that I'd want it on the wall. I guess I should just have one 3d printed but I've slept on it after the initial disappointment.

Additionally, I wouldn't be able to mount the power supply in the wall if I want it to be safe/up to code so I would need to run the wire down behind the wall and have it exit out of a notch in the receptacle wall plate below it near the floor with the wall wart plugged in. Still not very attractive so there are definitely shortcomings with this concept.

In the end, it's just been easier to use our existing phones since they're always close at hand and my ambition comes and goes with projects like this. It's a real shame that there don't seem to be any ready-to-buy, relatively universal wall mounts for charging and using smartphones or tablets this way. I've seen some but they're usually specific to one model of phone or tablet and they tend to be pretty expensive and ugly.

<comment><USER3> I have a stack of partially broken Nexus 5s, along with the magnetic/sticky QI chargers. That's my solution, though it doesn't look totally integrated, it allows for some mobility and doesn't look awful.

I do need a better cable-management solution, though.

</comment></comment><comment><USER4> Install BotBrew and use it as FTP/Web/File Server.

Use it as a Chromecast controller.

Maybe build a cool robo/drone/tool using Arduino and use your phone to control it.

Maybe, as a paperweight too? Even a non-functional phone would work here! :D

</comment><comment><USER5> You can also use it to build a telepresence robot leveraging the android os. Here is the one my friends and I built for a tech event. [http://akhilspassion.blogspot.co.id/2014/10/worlds- cheapest-...](http://akhilspassion.blogspot.co.id/2014/10/worlds-cheapest- telepresence-robot.html) Let me know if you want the code / design.

</comment><comment><USER6> With something like this: [https://www.adafruit.com/product/2264](https://www.adafruit.com/product/2264)

You can easily connect a lot of things to your mobile and automate them. The phone already has a lot of sensors so I would think more along the line of "which motors can I connect my phone to?". You could build a robot for example...

</comment><comment><USER7> If we could flash some educational stuff on them and pass them to some poor children to learn from (and monitor their scores) - it would make a cool project. I would like to work on this next year (hopefully).

</comment><comment><USER8> This 'Show HN' decided to make old smartphones into an inexpensive car/fleet tracking solution:

[1] [https://news.ycombinator.com/item?id=12240542](https://news.ycombinator.com/item?id=12240542)

[2] [http://gping.io/](http://gping.io/)

</comment><comment><USER5> Use for home improvement. Can hang in the wall to show current weather, motivational quotes, old photos etc in a beautiful UI.

</comment><comment><USER9> dedicated google cardboard viewer!

</comment><comment><USER10> Security cameras.

</comment><comment><USER11> Work on adding support to Linux mainline for them, so people can eventually run distros other than Android.

</comment><comment><USER12> You can install an app like Torque and use it with a car dongle for monitor your car

</comment><comment><USER13> use it as a music player device in your car maybe ? Most smartphones work well past their intended usage time. Its better to repurpose it for specific uses like playing music or for maps.

</comment><comment><USER14> Trap shooting.

(I know, it's probably bad for the environment...)</comment>


Academics Write Rubbish Nobody Reads - <AUTHOR> https://fee.org/articles/academics-write-rubbish-nobody-reads?utm_content=buffer1988d&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> Depends on the field, but a lot of this is a result of the "publish or perish" capitalistic model poisoning academia. You can't go to any university today without feeling the effects of a _massively_ over-bloated bureaucracy and administration. Before this massive bloat, most universities were controlled and run by professors believe it or not.

<comment><USER3> But were their papers read by more people 50 years ago than now?</comment></comment>