Update on Async Rendering - <AUTHOR> https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html <comment><USER2> > 17.0: Remove componentWillMount, componentWillReceiveProps, and > componentWillUpdate . (Only the new "UNSAFE_" lifecycle names will work from > this point forward.)

Wow, I try to use those as little as possible because there's always a bit of a smell, but I suspect there's a lot of code out there that will be getting a second look now. Kudos to the React team for explaining the rationale and migration path(s) in detail. React has consistently made me write better code, however begrudgingly.

<comment><USER3> When I first started using React, I kept trying to use componentWillMount, componentWillReceiveProps, and componentWillUpdate... I kept getting stuck in infinite loops... new prop updates state which re-renders the component which means "new props" updates state which re-renders component etc. Or something like that....

Now my react components are a lot simpler and I don't try anything fancy. The parents tend to handle the data fetching and they pass it down to the children components which are often stateless components. So I only use constructor(props) and render() plus custom functions. It keeps it cleaner but I also have more components as a result. Some of which do very little.

So I agree, those functions smell and looked more useful upon first glance than they actually were.

<comment><USER4> I used them mostly for server side rendering, if I remeber correctly.

componentDidMount will fire only on the client and componentWillMount on client and server.

Since the server rendered stuff wasn't interactive I could only do a subset of the things the client allowed, so I would do these in componentWillMount and the rest in componentDidMount only on the client.

<comment><USER5> If there's some specific use case we're missing in the blog post please let us know!

`componentWillMount` is technically equivalent to the constructor so there's nothing you could do on the server you couldn't do in the constructor instead.

[https://reactjs.org/blog/2018/03/27/update-on-async- renderin...](https://reactjs.org/blog/2018/03/27/update-on-async- rendering.html#other-scenarios)

<comment><USER4> I know, but I often avoid meddling with constructors. Passing the right stuff to super etc.

</comment></comment></comment></comment></comment><comment><USER6> To go along with this blog post, a 16.3 release candidate has just been published to npm.

        yarn add react@next react-dom@next

Please let us know if you encounter any problems!

</comment><comment><USER7> I was a little worried until I read the replacement functions which are basically word-for-word descriptions of what I use the functions for:

getSnapshotBeforeUpdate, getDerivedStateFromProps

</comment><comment><USER8> React is such a mess.

> These lifecycle methods have often been misunderstood and subtly misused; > furthermore, we anticipate that their potential misuse may be more > problematic with async rendering.

I hate it when library authors blame users (consuming developers in this case) for their blunders. Almost all lifecycle methods in React are confusing and contrived. The state mechanisms are becoming so convoluted (and overly generalized), no wonder we're ending up with gobbledygook like "getSnapshotBeforeUpdate(...)."

It's also pretty funny (or sad) to see no mention of SSR. Just a few months ago I spent literally weeks trying to figure out how to do server-side rendering with React. I ended up populating data via componentWillMount on the back-end. Terrible solution, but hey, it's the only one React has. Now, they suggest moving data-population in componentDidMount.. but guess what?

This _will not work_ on the server-side because technically components _never mount_ when doing SSR.

<comment><USER9> I don't get it. They admitted the methods were confusing and then made them more explicit. And all you have to add is that they're blaming people for being confused?

</comment></comment><comment><USER10> I hope this feeling passes, but I get nervous when code example syntax starts looking _really_ foreign to me. Whether accurate or not, my brain is kind of in a place of, "okay so ES6 cleaned up a lot, we're all kind of settling on Webpack, npm, certain various toolsets and best practices. I don't feel constantly overwhelmed anymore, can we not rush into another flurry of change?"

On the other hand, it looks like we're streamlining some verbosity. I just hope we can be okay with the right balance and we don't end up with a _really_ terse looking language.

<comment><USER11> FYI, the examples are partially written in Typescript not ES6... so they should look foreign.

<comment><USER12> What parts are in Typescript? This looked like all ES6 to me.

<comment><USER11> Never mind, they updated the post. As of my post the first few examples had some type annotations in the form `methodName(varName: type, ...)`, which I assumed was TS. All the examples are plain ES6 now.

</comment></comment></comment></comment><comment><USER13> Interesting mention of create-subscription[1], first time I have heard of such a library/api. Seems it's part of official react repo. Looks like a great piece of utility for interfacing rxjs/xstream etc. Observables. I guess this may replace recompose[2]'s Observable utilities as it's officially endorsed by react team.

Current react ecosystem broadly speakings splits on state management solutions in two styles: 1\. Single Observable-like source of truth (redux store) 2\. Multi-Observables (relay, appolo, mobx)

It will be interesting to see if `create-subscription` catches on, and whether library authors will start exporting subscriptions as public apis.

[1] [https://www.npmjs.com/package/create- subscription](https://www.npmjs.com/package/create-subscription)

[2] [https://github.com/acdlite/recompose/blob/master/docs/API.md...](https://github.com/acdlite/recompose/blob/master/docs/API.md#observable- utilities)

<comment><USER14> That's because it's a new addon library from the React team, intended to help handle several tricky bits of timing and behavior in how updates get passed to React.

</comment></comment><comment><USER15> Hang on, I use componentWillReceiveProps in just about every large non- function component I build.... I just counted 50 times in one of my applications.

and its going as soon as V17? Too early.

<comment><USER16> The post says the UNSAFE_ versions will continue to work in V17

<comment><USER15> I like my code to be safe.

<comment><USER17> The functionality is the same, it's just being marked as dangerous to use. Your code is just as (un)safe as before.

</comment></comment></comment></comment><comment><USER18> For async data loading for components, you can use this library today: [https://github.com/davnicwil/react- frontload](https://github.com/davnicwil/react-frontload) (npm react- frontload). I'm the author.

It lets you define a promise-returning data loader function for any component at any depth in the tree, which will run synchronously on the server and asynchronously on the client.

All you have to do is wrap your app in a provider, and add a single extra line of code to the server (since the sync server rendering relies on running the render once, waiting, then running again once all data is loaded for every component in the tree). You can find much more detail and examples in the blogpost linked from the github repo.

I'm really excited about async data loading coming to 'native' React, I essentially wrote react-frontload as a polyfill for this feature and hopefully my library won't be necessary any more once it's released. But for now, and in the future for projects that won't be able to update to the latest React, there it is. I've been pretty happy using it in production, and I hope it's useful for others too!

<comment><USER19> This is not how Suspense works. It doesn't just add loading states to your component, so a new primitive is needed and a polyfill won't do. With Suspense if a component renders async data, you can simply wait (notice, different from showing a loader) for it to finish.

In essence, React has a new primitive where calling setState will try to render the tree, but only flush changes to the DOM once all the components in the tree have finished loading. If you call setState again during this process (the app is still usable while waiting), and changes are to be made on the same portion of the tree that's currently loading async data, then React will simply dismiss the old tree from ever rendering - fixing race conditions in a natural/clever way.

<comment><USER18> Thanks. I've yet to look into the details, but my intuition was that Suspense could be a 'native' solution for synchronous rendering _on the server_ \- this is basically the missing feature in React itself that I was talking about needing to polyfill - essentially via a wasteful workaround that requires two server renders to be run instead of one.

The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve - what react- frontload does though is gets the same component to also synchronously load that same data (using the same function) on server render. This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together. That's the problem that react-frontload solves - the client side loader thing is up to you to implement, even with react-frontload.

What I'm hoping is that it _may_ be possible to go back to writing this stuff manually on certain components, because it'll be simple enough with Suspense - or at least just make the implementation of react-frontload much simpler and carry on using it as syntax sugar (it's quite nice to just define an async data loading function via a HOC, for instance - you obviously wouldn't get that having to hand code lifecycle methods for each component).

<comment><USER5> Suspense is both for client and server.

 _> The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve_

The problem Suspense is solving on the client is not straightforward. But you'll need to see my demo (second part of this talk[1]). It's very hard to talk about in abstract without seeing it.

The big difference Suspense brings is the ability to _wait with the whole state transition_ until all leaves are ready. Think transitioning between pages (that need data) is as easy as updating state in the parent, and React takes care of "waiting" for the page to be ready before displaying it (or falling back to a placeholder).

 _> This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together_

Suspense takes care of that, you don't need to manually collect Promises.

[1]: [https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-...](https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-16.html)

<comment><USER18> Cool - I will definitely go actually figure out what Suspense does in detail. Thanks for the link!

Now you've got me thinking, and you're right. Even in a client-only case, the simple spinner-until-data-loaded pattern works for a solo component just fine, but doesn't at all account for waiting for children, etc, without implicit dependencies between parent and child. If you've got stuff like that going on, then yes this is a pretty complex problem.

It does definitely seem like Suspense is going to remove most of the complexity involved in the 'synchronous' server render problem, especially with regards to manual promise collection. This is awesome work :-)

</comment></comment></comment></comment></comment><comment><USER15> The Context API is of most interest for me.

I love Redux but I find myself using it less than I want to because so much stuff has to be put in place any time I want to store some stuff.

</comment><comment><USER20> Can someone explain the types of bugs and pitfalls one ends up having when using componentWillMount, componentWillReceiveProps, and componentWillUpdate?

<comment><USER6> The RFC for getDerivedStateFromProps ([https://github.com/reactjs/rfcs/blob/master/text/0006-static...](https://github.com/reactjs/rfcs/blob/master/text/0006-static- lifecycle-methods.md#common-problems)) mentions a few!

• Initializing Flux stores in componentWillMount. It's often unclear whether this is an actual problem or just a potential one (eg if the store or its dependencies change in the future). Because of this uncertainty, it should be avoided.

• Adding event listeners/subscriptions in componentWillMount and removing them in componentWillUnmount. This causes leaks if the initial render is interrupted (or errors) before completion.

• Non-idempotent external function calls during componentWillMount, componentWillUpdate, componentWillReceiveProps, or render (eg registering callbacks that may be invoked multiple times, initializing or configuring shared controllers in such a way as to trigger invariants, etc.)

Edit: For formatting

</comment></comment><comment><USER21> From the post it looks like getDerivedStateFromProps does not receive the old props as an argument. I can think of cases where that would be helpful, has this been considered?

<comment><USER22> I don't think you need it - since you're deriving state from props you can just derive from the new props and compare to the old state. At least I believe that's the reasoning.

<comment><USER21> In my use case, the component receives the URL of a resource as a prop, and it re-fetches the resource from a backend when the URL changes. I'd like to avoid the expensive fetch when it's some other prop that changed.

Copying the URL to the state will work, although it's a bit more verbose.

<comment><USER22> That's probably something that belongs in `componentDidUpdate`, you'll have access to `prevProps` there to compare whether you need to trigger a new fetch. I don't believe that `getDerivedStateFromProps` should have any side- effects.

</comment></comment></comment></comment><comment><USER23> The suspense demo is fantastic, and I really can't wait to get 16.3 into production code. The async rendering clean up and the new Context API make my heart sing.

<comment><USER6> The suspense demo is fantastic! But that won't be a part of 16.3 - maybe 16.4!

16.3 does have some goodies though- new context API, forwardRef, etc.

</comment></comment><comment><USER24> I hate using componentWillReceiveProps but always end up doing so because it seems to be the easiest with redux. The static function replacement seems very natural.

<comment><USER25> I'm not shilling, but this is something I definitely don't miss using Mobx.

edit: Ooops, I thought the commenter was referring to shouldcomponentupdate. Sorry for the confusion, please downvote this out of the discussion!

<comment><USER26> What is the alternative? For when you have a stateful component that "reacts" to new parameters.

<comment><USER25> Mobx uses observables to monitor what properties you read and collections you enumerate during your render method.

It then uses that information to implement shouldComponentUpdate for you. Each render call refreshes the data use by shouldComponentUpdate.

It gives you 100% percise updating of react components based on state, for free.

<comment><USER26> Were we not talking about componentWillReceiveProps, not shouldComponentUpdate?

<comment><USER25> Shoot, my bad. Sorry for the confusion. That is a common common complaint with redux, so I read into it.

<comment><USER26> No worries, I was just confused what you meant. :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> I wonder if they considered a new base class instead, for example reactAsyncComponent? That way developer as to declare his component as async- safe explicitly, without all that hard to follow rename thing. Engine could recognize async classes and perform rendering differently for them.

<comment><USER5> Yes, we considered it. Two arguments against this:

1\. A single "async component" is useless because the power of async rendering is in letting React coordinate the work _of the whole tree_. As long as just one leaf isn't async-compatible, the whole tree isn't.

2\. In practice most components already _are_ async-compatible. So we don't want to hold off progress by forcing people to explicitly specify it. Instead the plan is to outlaw patterns that we know _won't_ work.

Hope this makes sense.

<comment><USER27> It does, thanks. Hopefully there will be a set of dev warnings, tests or sth that a developer can read or run that will help him verify whether the component tree is "async-ready".

BTW, I've watched your jsconf, great presentation, can't wait to use all those goodies (also love HN for a chance of response straight from react core team :)

<comment><USER5> >Hopefully there will be a set of dev warnings, tests or sth that a developer can read or run that will help him verify whether the component tree is "async-ready".

We'll offer a <StrictMode> component in React 16.3 that warns about some unsafe patterns (like legacy lifecycles and a few other issues). Later on we'll provide more testing tools for libraries.

</comment></comment></comment></comment><comment><USER28> This is a bold, dangerous move. I can get on board with these lifecycle methods being abused, and instituting changes to the library to correct them. However, I suspect there's an unimaginable amount of code that will need re- written to accommodate these changes. Is that a feasible expectation? Would it have been feasible to re-brand the library (or components) to support async rendering (with async components having that different API)? I don't know; I"m all in on React so I really hope this doesn't result in community split.

<comment><USER14> As the post says, the migration will be handled gradually. All of the semi- deprecated `componentWill` lifecycles will continue to work as-is as long as you're on React 16.x. They'll start warning about using them in a later 16.x release. If you rename them to `UNSAFE_componentWill`, they'll continue to work the same way, and there will be a codemod released to do that transformation automatically. There will also be a `<StrictMode>` component built in to React that you can explicitly put around parts of your component tree to help locate these usages.

<comment><USER6> Just chiming in to note that the codemod has already been released: [https://github.com/reactjs/react-codemod#rename-unsafe- lifec...](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles)

We used it internally (at Facebook) several weeks ago to update ~14,000 components that used the unsafe lifecycles.

</comment></comment></comment><comment><USER29> Where can I read about the internals that make this work? For example, how does the scheduler work? Does it still compute a tree for an old setstate or does it unschedule existing computations when a new high priority setstate ones in?

Update:

I took a look at their work on fibers. It looks like they are manually deciding on what is or is not enough computation to perform in a fiber. This is fine, but it will require some careful attention by the react team.

It would be neat if they could use web workers for some of this.

</comment><comment><USER30> Great work!

Could be a good idea to try draw some diagrams too =)

<comment><USER5> We made a few!

[https://mobile.twitter.com/acdlite/status/977291318324948992](https://mobile.twitter.com/acdlite/status/977291318324948992) [https://mobile.twitter.com/acdlite/status/978412930973687808](https://mobile.twitter.com/acdlite/status/978412930973687808)

Will put them in some future blog post.

<comment><USER30> Awesome! I did see these.

An official life cycle flow would be awesome too.

In the past, when teaching other developers, I just throw a dart at one of the many google image search results that try show the flow.

</comment></comment></comment><comment><USER31> This goes directly against their own versioning policy of abusing cliffs and bringing everyone along: [https://reactjs.org/blog/2016/02/19/new-versioning- scheme.ht...](https://reactjs.org/blog/2016/02/19/new-versioning-scheme.html)

Quoting from that page:

> Therefore it is important that we don't just upgrade our own codebases but > that we bring our whole community with us. We take the upgrade path very > seriously - for everyone.

> If we're not careful, we can hit a cliff where nobody upgrades. This has > happened to many software project ecosystems in the past.

> Therefore, we're committed to making it easy for most components and > libraries built on top of React to be compatible with two major versions at > the same time.

I'm not sure if I'm reading them and the diagrams in that page correctly, but looks like the deprecation should happen at 17 and removal at 18 according to it?

<comment><USER32> > Minor revision releases will include deprecation warnings and tips for how > to upgrade an API or pattern that will be removed or changed in the future.

16.3 is including dep warnings and tips to upgrade, check.

> We will continue to release codemods for common patterns to make automatic > upgrades of your codebase easier.

Probably will be there closer to 17 release.

> Once we've reached the end of life for a particular major version, we'll > release a new major version where all deprecated APIs have been remove

Once 16.x end of life is reached, the next major version, 17, will remove the deprecated APIs, check.

They are literally following exactly what they said.

<comment><USER5> Note 16.3 doesn't even include warnings. We are only adding support for the new aliases at this point, but won't fire warnings until the biggest ecosystem libraries have updated with recommendations in the blog post.

Yes, there will also be a codemod for the "UNSAFE_" rename.

<comment><USER6> One of the main focuses of 16.3 is to enable open source libraries to update their code in advance of deprecation warnings. (We're trying to go one step beyond SEMVER- so that application developers don't have to be bothered by warnings in third party code that they can't change.)

And the codemod has already been released: [https://github.com/reactjs/react- codemod#rename-unsafe-lifec...](https://github.com/reactjs/react- codemod#rename-unsafe-lifecycles)

We've used it internally (at Facebook) to update ~14,000 components already, so it's well tested.

</comment></comment></comment></comment><comment><USER33> getDerivedStateFromProps , getSnapshotBeforeUpdate

Java is leaking on the client side ...

<comment><USER34> Unfair and ignorant comment.

They are descriptive function names, that's all.

"derived state from props" 4 words.

"snapshot before update" 3 words.

If you get an allergic reaction from that it's just you.

</comment></comment><comment><USER35> Why call it "UNSAFE_" if there isn't really anything unsafe about it? I get it, they don't want people using those functions, but why should they decide what work best for other developers and use shady tactics like dishonestly calling something they don't want to be used "unsafe" just so that it causes uneasiness and raises red flags with devs that aren't intimately familiar with React? Facebook is known for its underhanded tactics and React is no exception, they tried to kill patent disputes with its licensing in the past. Now they're trying to control how their library is used in a very deceitful way.

<comment><USER5> _> Why call it "UNSAFE_" if there isn't really anything unsafe about it_

After seeing thousands of React components and responding to thousands of issue reports, we know which patterns often get people in trouble. Some of these patterns indicated bad design on our part, and we want to fix those issues.

We are adding safer alternatives for these use cases that don't have those pitfalls. Importantly, we want to clearly communicate that these existing methods cause problems _and these problems will become more noticeable in future versions of React that will support asynchronous rendering_.

I gave a talk about what "asynchronous rendering" means for React, and about exciting new long-requested features it enables.[1] I encourage you to watch it if you're curious about our motivations. These methods are incompatible with it, hence they're "unsafe". Since the risk of them being unsafe grows with time, we decided it's worth adding a prefix to call them out in the product code.

We're trying to do best by our community and I'm sorry if we're falling short of that. We set up an RFC repository[2] a few months ago so you're welcome to give us feedback on the future changes.

[1]: [https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-...](https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-16.html)

[2]: [https://github.com/reactjs/rfcs](https://github.com/reactjs/rfcs)

<comment><USER35> Why not just deprecate this API in addition to providing a better way to perform operations commonly invoked this way?

<comment><USER6> We are trying to strike a balance between supporting huge legacy apps that cannot be rewritten- (something Facebook has a lot of)- and encouraging safe/bug-free coding practices for future apps. In this case, we felt the right balance was to preserve legacy functionality while using a name that would hopefully discourage new usage (so as to avoid the potential pitfalls inherent in the legacy API).

And we provided a codemod to help with the "huge legacy apps": [https://github.com/reactjs/react-codemod#rename-unsafe- lifec...](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles)

We've run it internally already to update ~14,000 components.</comment></comment></comment></comment>


Guns, Government & the Fallacy of Cyber-Utopianism - <AUTHOR> http://www.metamorphblog.com/2011/01/guns-government-fallacy-cyber-utopianism.html

<comment><USER2> I thought that cyber-utopianism died in the 1990s. If any utopians still remain then the Egyptian shutdown should be a massive wakeup call, demonstrating that the internet is far less resilient than many had been led to believe. In the Egyptian case there was no possibility to "route around censorship" if access is denied at the most fundamental level.

China, using a variety of tactics, has been quite successful at stifling the sort of radical democratisation which the cyber-utopians of yore believed in.</comment>


Ask HN: how can one submit links to bitly's engineering blog? - <AUTHOR>

I tried submitting a link to bitly's new NSQ project here: http://news.ycombinator.com/item?id=4634723
It appears that HN auto kills any bitly.com link. Is there any way around this?
For those interested, the link in question is:
http://word.bitly.com/post/33232969144/nsq <comment><USER2> Email PG.

It looks like a link shortener, but this is new.</comment>


Download Safari 4 - Official Release - <AUTHOR> http://www.apple.com/safari/?4finalrelease

<comment><AUTHOR> Sorry for the link manipulation, but an article about Safari for Windows links to the same URI.

</comment><comment><USER2> The biggest change I've seen so far is that those funky Chrome-style tabs are gone. I never knew why Apple copied those in the first place.

The new tabs don't look so great either, though.

<comment><USER3> At least with the new ones, compared to the beta, you can change the ordering around again.

<comment><USER4> You always could, but you needed to drag the little move handle in the top- right corner. (Looks like three diagonal lines.)

<comment><USER3> Ah - didn't know that, thanks. Not very discoverable though - glad they changed it.</comment></comment></comment></comment>


What Car Thieves Think of the Club (2010) - <AUTHOR> http://freakonomics.com/2010/06/08/what-car-thieves-think-of-the-club/ <comment><USER2> If improving your own security produces a negative externality then education also produces a negative externality. You're "harming" other people by becoming more employable than them. Personal hygiene produces a negative externality because you might become more attractive than somebody. Physical fitness produces a negative externality because you might get chased by a bear and not be the slowest. Doing anything that improves your chances in competition counts, and there are very few areas of life with no competition.

IMO such a loose definition is meaningless, and the word should be reserved for cases where you are actually doing harm. In the case of improved car security it's the car thieves who are doing harm.

<comment><USER3> It's better to define "externality" as including all impacts on everyone but yourself, and accept that some amount of negative externality is inevitable. That allows you to differentiate cases like (in the article) Lojack, which produces a positive externality, from the Club which theoretically produces a negative externality.

<comment><USER2> You can already distinguish between positive and zero. If you lump zero in with negative then you're losing information, and you're violating common sense in a way that makes people lose respect for the field in general.

</comment></comment></comment><comment><USER4> I have the world's most effective anti-theft device, there is research on this, in my car and this device saved me thousands on the retail price of the vehicle.

The mystery device is a manual transmission.

<comment><USER5> My 1997 Civic was stolen despite having a manual transmission that sometimes is faulty. I've also had two Honda del Sols stolen, both were stick shifts. Doesn't seem to help all that much.

<comment><USER6> The mid-late 90s Civics and Del Sols are highly sought after among Honda fans! The ones with B18 VTEC motors even more so. That's why your cars were stolen despite having a stick shift.

It's even worse for the Honda CRX.

<comment><USER7> This may make sense in the context of the enthusiast market, but I somehow doubt the average car thief is that tuned in to gearhead culture.

<comment><USER8> You'd be wrong. Car thieves aren't stealing cars to re-sell them on a lot, they are stealing them for parts for unscrupulous buyers, and street racers are a great market.

I used to own an Acura Integra. The rear spoiler was ripped off several times (carefully, so it could be re-attached to another car), and the car itself was stolen twice - the first time it was recovered in one piece, the second time it was a bare chassis without even wheels.

The Integra motor had a 10,000 rpm redline and had a cult following among Honda enthusiasts. It could be retrofitted into any Civic.

<comment><USER9> WRT the bare chasis Integra when the police called you how did they break the news to you?

<comment><USER8> From my recollection, they didn't have much to say. The car was abandoned in Hillside, NJ just outside of Newark, at the time at least car theft was rampant there so the police were pretty matter of fact about the whole thing. The car got impounded, and it felt like the impound lot and the police department were conspiring to keep it there (like, to get the car out, you had to get a release from the police department on the other side of town from an office with very limited hours, which was only good for one day, and then make it back across town before the impound lot office closed for the day.

I recall my insurance company ended up paying more than the car was worth (before the theft) in impound fees, before even they could get it out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Back in the 90s I had a club (a girlfriend bought it for me for Valentine's Day, because it was red.) After a while I stopped locking it when I put it on, reasoning that if someone was determined enough to see it and still break into the car thinking they could get past it then there was no real point in actually locking it.

<comment><USER11> I used to do that as well. One day I came back to my jeep and the club was stolen but not the jeep. Wasn't sure what to make of that but laugh. Never bothered getting another one.

</comment></comment><comment><USER12> I saw a car with the club the other day - this first I have seen in I can't even remember how long. The car was in rough shape. Real rough. I mused to my wife that perhaps the car was there to protect the club.

<comment><USER13> Generally speaking, older vehicles are much easier to steal than newer vehicles. I have a friend with an 1980s Toyota truck who clubs it wherever he goes, not because it's a nice truck, not because he can't afford to lose it, but rather because it will definitely get stolen if he doesn't club it. Without a club, his truck can be stolen in under a minute by any layman using a little more than a flathead. Before he got the club, it was stolen multiple times -- usually turning up a week later, abandoned somewhere, and/or used as a shelter by a homeless person.

<comment><USER14> Adam Corolla tells a story of an old Nissan pickup he had when he was younger and poorer. It was so easy to steal he wired in a hidden switch to power the fuel pump, truck was stolen a couple of times and he would just walk a couple of blocks to where it was abandoned. I believe he also painted the stereo brown to as a deterrence to thieves looking for stereos to sell.

<comment><USER15> The fuel pump thing is very common for Jeep owners.

</comment></comment></comment></comment><comment> V-2 For what it's worth, it reminded me of a passage in a novel (I can't remember which one) by an Ukrainian writer Serhiy Zhadan.

In the story he contained an observation on how in blockhouses people on the first floor secure their balconies with bars to protect their flats against burglars.

These bars, however, make for a perfect ladder right onto the balcony on the second floor :) So then people on the second floor are forced towards doing the same thing, and so on all the way up.

</comment><comment><USER16> I had a coworker who secured his car with a Club, and this is exactly what happened. The thieves even left the club behind in his parking space. The next night they came back and stole his rental.

<comment><USER17> Damn. So what did he do to piss those guys off?

</comment></comment><comment><USER18> it's been a long time since I've seen one, so maybe the lock has changed (used to be a simple doubled sided wafer lock), but in the past it was a lot faster to pick the club open than to saw through a steering wheel. see also the club buster[1].

1\. [http://www.clubbuster.com/](http://www.clubbuster.com/)

<comment><USER19> Funny how the About page markets this tool to:

      LOCKSMITHS
      TOW TRUCK OPERATORS
      AUTOMOBILE REPOSSESSION PROFESSIONALS
      FIREMEN & PUBLIC SAFETY SERVICES ....

Yeah, right :).

<comment><USER20> Easy & FUN to use!

</comment></comment></comment><comment><USER21> Most cars are stolen by non pro car thieves. They're stolen based on opportunity and whether or not its in an area where under 25s might need transpo. They're going to steal the easiest thing, because they're often just looking for transpo.

We lived on a street frequented by under 25s at night and used clubs on our cars. They were never stolen, but the neighbors who had easier to steal vehicles such as Dodge Caravan were taken quite often.

You're not going to stop a pro.

<comment><USER22> > You're not going to stop a pro.

The only thing stopping a pro is to have an uninteresting car. My idea is to have a car good enough not to be easily stolen for a joyride but uninteresting enough for a pro.

</comment></comment><comment><USER23> At one time in America, keys from one car would unlock, if not start, many thousands of similar cars because of similar or same key bitting. It's interesting that German cars of the same era were harder to break into because of worse economics for lower classes, more car thefts and therefore more secure vehicles... meanwhile American cars weren't really locked that much because post-WW2 boom times were so good, and so, less theft, especially in small towns where everyone knew each other and theft would risk becoming a shunned criminal outlaw.

</comment><comment><USER24> Knew a guy who used the club with his late model Corvette back in the nineties. He went in a store and when he came out his Corvette was gone and smack dab center of the parking spot he had was the club. Almost like the thief was mocking him.

</comment><comment><USER25> IMO the club is absolute junk, but is probably enough to deter mosy entry level kids who were taking cars to joyride in the 80s.

</comment><comment> V-2 _> And do not pass too quickly over the fact that a car company hires car thieves for consultation. If you are a businessperson, do you regularly engage those who wish to do you harm?_

It hardly shocks people when it's about cybersecurity.

I'd also nitpick about car thieves wishing to harm the car companies. They're actually harming car owners, or possibly insurance companies. They do not "wish" to harm car companies. It's arguably not even an _unintended side effect_ of what they do.

Car companies might actually benefit from you having to buy another car once yours is suddenly gone. Sure, the stolen one will be sold to someone else, but on average the victim of the theft is wealthier than the person who'll buy their stolen car - which essentially means more rather than less extra money is likely to get pumped into the pockets of car companies at the end. (You presumably had a good car, you can afford buying a new one - the person who bought yours would have been unlikely to buy a new one anyway).

<comment><USER26> The risk of theft lowers the expected value of having the car. I'll never buy one of those $1000 bikes because of the risk of theft, nice as they might be. I'll go to Wal-Mart.

</comment></comment><comment><USER27> People regularly confuse "security through obscurity" with "obscuring your security". The first is bad, the second is powerful.

Even before I read about the hacksaw (long ago) I knew clubs by themselves were bad cause they were visible. They reveal intel to the attacker. Intel the attacker can take and, in safe environment, at their leisure, devise way to defeat it. If the attacker doesn't know what countermeasures there are, (or are common) they can't defeat them. GPS trackers can be hidden, but car thieves know about them so they can counter (say by getting car into faraday cage ASAP, or using radio wave detector to track it down and disable. So, you have to be more creative, unusual.

Where the club could be useful is a honey pot. Put it on the worthless (to you) car you want stolen so the more valuable (to you) car is skipped over.

Maybe bait car has secondary devices for tracking that thieves will be less likely to look for since it had the club and and multiple defenses are unexpected.

</comment><comment><USER28> This touches on a pet peeve of mine: almost every person who uses the Club puts it on wrong.

The long part of the bar is meant to go down and to the left between the door and the floor, to make the steering wheel harder to turn.

Everybody attaches it with the long part sticking up in the air.

<comment><USER29> When almost every person does it wrong, the problem isn't the person.

<comment><USER30> There's a limit to this principle. There's not always something you can fix to prevent people from abusing your product or system.

Are the instructions for the Club bad, or what? I'm usually the first person to say "you don't need to propose an alternative for your criticism to be valid". I think in this case, however, where the validity of the criticism is predicated in the existence of alternatives, you really need to give one.

<comment><USER31> Sounds like the club needs more "affordances" to help the user.

Maybe a sticker with ↑up↑ and ↓down↓ printed on it, in such a way that the text is upside down if the club is locked incorrectly.

</comment></comment></comment></comment><comment><USER32> Interestingly, the article later admitted the club made it easier for the autio thieves so it was a positive externality after all.

</comment><comment><USER33> This is a just-so story. Sounds good, totally bereft of actual data or analysis. Par for the course for freakonomics.

<comment><USER34> It's a blog entry with an anecdote that came from a write in in response to a story. You were expecting something else from a short blog post?

<comment><USER35> I think the parent is throwing shade on the book as well. Can't say I disagree with the opinion.

</comment></comment></comment><comment><USER36> How do companies find criminals to request help from?

<comment><USER37> Convictions are public record, so it presumably wouldn't be too hard to reach out to people when they're released from prison.

</comment></comment><comment><USER38> Yeah, we all knew this back in 1980's . . . successful thieves would actually leave the club in the front lawn next to the curb as a laughing momento

</comment><comment><USER39> Hidden sleeping gas canister that deploys when engine starts without a secret switch deactivating (bluetooth or regular) - alerts you when it does.

Worst case you forget to turn it off and fall asleep a couple hours.

<comment><USER40> Sleeping gas?</comment></comment>


Why Aren't There More Scientists? Money - <AUTHOR> http://phenomena.nationalgeographic.com/2016/04/29/why-we-dont-produce-more-scientists-a-one-word-explanation/ <comment><USER3> As a former professional scientist (I will always be a scientist, just not one who earns a living from science), the problem is not money directly, but the encouragement of students into becoming professional scientists when there is no money to support them when they finish their training.

<comment><USER4> Ideally, we would want essentially everyone interested in pursuing science to do so, and succeed. No?

You seem to be saying that we should rather limit the number of scientists than pay for the ones we can train.

<comment><USER5> > You seem to be saying that we should rather limit the number of scientists > than pay for the ones we can train.

This is still an open question. At least in biomedical sciences, there's been an explosion in the number of PhDs awarded. Biomedical postdocs get paid ~$40k/year on average, and it's increasingly likely they'll be stuck in that position for 10+ years (or you'll leave for a non-science job). I luckily won't have to go through that, but most of my friends are.

An alternative is produce less, better paid, better trained scientists.

<comment><USER6> I'm sure comp sci could use some of them. Hopefully we can start attracting the same amount of women as Bio* fields, that would do a lot to redistribute STEM labour towards better compensation and alleviate supply issues in the market (on both ends).

<comment><USER7> The amount of STEM PhDs is a mere blip compared to software engineer demand.

</comment></comment></comment></comment></comment><comment><USER8> A little over a week ago, HN pondered a question based on essentially the opposite premise: "Why do so many people continue to pursue doctorates?" [0]

The submission garnered some unbelievably sour comments about graduate research (the top comment, in particular).

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

<comment><USER9> > unbelievably sour

Thanks for the pointer. Just checked, and I don't find that sour at all, only mildly realistic.

There's a reality distortion field generator running somewhere ...

<comment><USER10> Reality distortion field generator? That sure sounds like curiosity-driven research--- get out of here and write a real grant!

<comment><USER11> Curiosity?! Pah. Outmoded victorian values. Curiosity killed the cat.

Now keep your head down and publish the good facts we give you.

</comment></comment></comment></comment><comment><USER12> Basically we have no problem paying a lawyer who profits from adversarial divorces $400K per year; but people blanche at scientists with PHDs getting more than $100K-$150K per year.

So we've ended up with more lawyers and less scientists.

<comment><USER13> There is no divorce lawyer making a $400k salary. If they make that much, they are entrepreneurs. There are plenty of PhD entrepreneurs who make millions a year. Compare apples to apples.

<comment><USER12> I didn't actually type "salary" in my original post...

I don't really know enough about how lawyer partnerships work as a legal entity, to be able to definitely say 1 way or the other.

Would a large Boston firm with multiple partners, that was financially successful, pay a partner in a firm $1 million a year? Yes, easily; but is the partnership just "how lawyers do things" or "entrepreneurship"? I can't say.

"According to the Boston sources whom we interview, a competent divorce litigator in Boston earns a minimum of $1 million per year. Is that sufficient compensation for a loss of illusions regarding human nature? Only you can decide!"

From Philg's (Philip Greenspun, another famous LISP user) site here: [https://blogs.harvard.edu/philg/2015/07/28/divorce- litigator...](https://blogs.harvard.edu/philg/2015/07/28/divorce-litigator-on- the-bill-cosby-mess/) (his comment #6)

<comment><USER14> IMO partners are closer to "legal management." So at that point the engineering equivalent would be "engineering management." Directors and VPs of engineering firms probably earn in the range of $1 million. Some very very senior engineers at FB/Microsoft/Google probably earn that much as well (principal engineer-level)

</comment></comment></comment></comment><comment><USER15> Money would help but so would dismantling the feudal system that controls it. Remember the guy who cured ulcers? His story is an insight into how dysfunctional science is.

<comment><USER16> Which guy, and what's the story?

<comment><USER17> There were two guys.

Barry Marshall and Robin Warren.

</comment></comment></comment><comment><USER18> What does the average postdoc make in STEM? Something like 40k. Wanting a family and having to be a slave to the job for pennies on the dollar was a big disensentive for me. Also, I would never move away from Canada and I feel le there were even fewer opportunities here.

<comment><USER19> Postdoc is a temporary job. It's a segue between training and an independent position. The pay rate is not very important because you're not supposed to do it for more than two or three years. Then it's up or out.

<comment><USER20> In many science disciplines it's not uncommon for someone to do two or ever three postdocs while looking for more permanent employment. The underlying cause is the same reason people settle for the low pay and poor job security of being an adjunct: there isn't much else you can do, just work hard, hope, and wait.

As the article mentions, even if you do grab the brass ring, a lot of your time and energy ends of being spent on writing grants and management. My first job out of college was working for an ecologist. Her entire NSF grant was $70k over 5 years. Out of that she had to pay my room and board at a remote field location as well as my salary. There was almost nothing left over for equipment and supplies. It was always a question whether the money would come through to allow her to continue doing her research.

</comment></comment></comment><comment><USER21> The problem is most scientists now days aren't real scientists. They are closer to laboratory workers or even bureaucrats. What we need to do is reform science as a whole, the very methodology's that we accept for science. Science does not = scientific method, that's a small subset, but we've become deluded into thinking that's all science is. Until we see science as more, scientists will be limited

</comment><comment><USER22> I wanted to be a scientist and study physics. I found that working with computers paid better than being a scientist unless one beco es popular.

</comment><comment><USER23> Seeing a kindergarten friend of mine being among the top 10 in ecology and living like a hobbo like his friends and doing spectacular research and not giving up, I don't think it is money.

I think it is the pressure of company fueled academism in bending the research to censor research that is the real problem.

Corpo and governement are censoring and fighting research by underfunding and noising the environment with shitty science made to make a point.

Don't tell me Science could not detect the diesel gate sooner, yes they could, but government preferred to fund diesel optimistic research.

Don't tell me the thyroid problem happening in every nuclear polluted region could not be detected sooner (Eastern Europa, Japan...) they were. But, it has been silenced by focusing on the cancers.

Don't tell me Fourier books on the contribution of human activity to the global warming of earth (1824) was not written, and thus that this knowledge is "new".

Science, like justice, should be independent from government and economical powers.

Universities should be autonomous.

<comment><USER11> It was certainly money that kept me out.

Does he have rich, supportive parents, by any chance?

<comment><USER23> no, he is ready to live like a hobbo and make a lot of sacrifices most people don't.

<comment><USER11> In that case, good for him. I'm likewise prepared to live like a hobo and have done my time being homeless and having a bundle of tags to sleep in to my name - but I had financial dependents which precluded any selfish endeavour. Such is reality for many.

</comment></comment></comment></comment><comment><USER24> We have a _lot_ of scientists. Just the US government spends 140+ billion per year and 1.4 trillion per decade on R&D. The problem is we simply try and push more people into those fields than we are willing to pay for. Research is important in the short and long term, but I think the U.S. would be better off focusing more on infrastructure and less on research.

A few pipes to move fresh water from dry to wet areas of the country would not cost all that much. A few more subways in major city's could do a lot. 10% or 14 billion could go to projects that more than pay for themselves in a few years.

PS: Yes, a big chunk of that is military R&D, they can also get cut.

<comment><USER3> There is no lack of resources to support science, just a lack of political will to fund it. When it comes to government funding there is not a set amount of funding for each area. If there is political will it will get funded.

The scientist who help kill the SSC [1] found this out the hard way - <USER2> thought that the money would flow back into other areas of science, but in the end it just went back into the main budget and no other area of science got more money

1\. [https://en.wikipedia.org/wiki/Timeline_of_peptic_ulcer_disea...](https://en.wikipedia.org/wiki/Timeline_of_peptic_ulcer_disease_and_Helicobacter_pylori)

</comment></comment><comment><USER25> I get the feeling that any scientific jobs that actually pay in accordance with their merit are those that have been entirely consumed by current industrial pursuits.

</comment><comment><USER26> Uh, why does "This means that my work will never result in a marketable product, a useful machine, a prescribable pill, a formidable weapon, or any direct gain." imply "she's the real deal" in any way? If your definition of science includes "completely useless for all practical purposes", of course there's not going to be very much money.

<comment><USER27> "All practical purposes" for a discovery is not always immediately apparent.

</comment></comment><comment><USER28> What if there was no tenure and the pie would be re-divided based on performance every year? If that would disproportionately help the more productive scientists, wouldn't that help attract more funding for science and make the pie bigger for everyone? Why can't science work like the rest of the world?

<comment><USER29> I've thought that a rolling tenure system would be cool. Depending on how risky your research is, you can apply for 5, 10, 15, or 20 year chunks of time in which you are guaranteed a position at the University. This would allow professors to take on longer term weird or crazy research projects, but would prevent professors from defacto retiring immediately after hitting associate professor.

<comment><USER30> What is the purpose of the rolling tenure? If the finite length is meant to serve as a stick, I would argue that it is useless. People who do good fundamental research do it because there is nothing else that gives them the satisfaction. Yes there may be a few who defacto retire after hitting the assuared tenure, but if this rolling tenure becomes the norm that would add additional unnecessary risk to most. Fundamental research is risky, and we need people to go down the wrong and useless path to mark it such to keep others from going down that route. The finite length tenure is not conducive to the risk taking process.

</comment></comment></comment><comment><USER31> It's old hat to complain about lack of money in science. Instead, ask, how can I fund my knowledge producing project? "Public funds" is not always the answer.

</comment><comment><USER32> Lately I have binged on the television show "Fringe"(2008–2013). Good example of science gone off the deep end.

[http://www.imdb.com/title/tt1119644/](http://www.imdb.com/title/tt1119644/)

</comment><comment><USER33> I can't help but see publicly-funded science as deprecated in favor of market- driven science. There's simply too many fields for government largesse to really be able to fund in force. I wish it didn't have to be so subject to the whims of popular opinion, but really, I can't think of a better way.

<comment><USER34> Markets do a terrible job of funding basic research because it rarely pays off within commercial timeframes. Or even lifetimes. But it's obviously vital to a society long-term.

<comment><USER33> I agree, but like I said, I can't think of a more politically acceptable alternative. Maybe one day science will get sexy again and POTUS will be able to do Obamacare for science. Until then it's up to the markets.

<comment><USER34> Is charity a market mechanism? I honestly don't know. But apparently there has been a trend toward more private funding of basic research:

[http://blogs.scientificamerican.com/the-curious- wavefunction...](http://blogs.scientificamerican.com/the-curious- wavefunction/are-we-entering-a-golden-era-of-private-science-funding/)

<comment><USER33> It is. There is competition for altruism and organized processes oriented around collecting it.</comment></comment></comment></comment></comment>


Show HN: How to Use GitHub Gists as a Free Headless CMS - <AUTHOR> https://epiphany.pub/@seisvelas/Github-Gists-as-a-(free)-Headless-CMS <comment><USER2> Woah this is pretty powerful. It also appears the [1] github repositories api supports this too.

So you could have a structured repo containing all your posts instead of gists... Not quite relational, but better!

[1] [https://developer.github.com/v3/repos/contents/](https://developer.github.com/v3/repos/contents/)

<comment><USER3> See also [https://coisas.alhur.es/](https://coisas.alhur.es/) for an app that turns your GitHub repo into a real CMS.

</comment></comment><comment><USER4> bl.ocks.org has been functioning this way for years, allowing to show-case code.

For example, [https://bl.ocks.org/mbostock/7881887](https://bl.ocks.org/mbostock/7881887) is rendered from the content found in [https://gist.github.com/mbostock/7881887](https://gist.github.com/mbostock/7881887).

</comment><comment><USER5> Awesome idea! It made me realize that GitHub Gists could be used as a free non relational DB, with the proper setup perhaps even private. I'm working on a FOSS project manager (release date TBD), I'll look into this for sure!

</comment><comment><USER6> this is super cool!</comment>


Do photos online help sell homes faster? - <AUTHOR> http://8z.com/blog/do-photos-help-sell-homes/

<comment><USER2> A possible confusion of correlation and causation. A house with more picturesque traits tends to be photographed more, and it's also more likely to sell more quickly than a house with fewer picturesque traits.

Somehow I think this scientific critique won't sway those who believe more photos = faster sales, regardless of other factors.

<comment><AUTHOR> You are correct, it is a correlation, not a causation. I think I mentioned that in the disclaimers.

It is really hard to control for all the variables (price, motivation of seller, location, who the listing agent knows, what style of home is hot), but all other things being equal, it's better to have more photos for a listing. In fact, since it is one of the easiest things to control (it's a lot easier to snap 25 photos than change the price point of a house) I'd argue it is one of the things home sellers should expect.

Would love to hear your suggestions on making this more rigorous. Off the top of my head, it'd be interesting to list a set of same homes twice, once with few photos and once with many photos, and see what the difference in response was. Unfortunately, that is a bit beyond my scope for the time being.

<comment><USER2> > Would love to hear your suggestions on making this more rigorous.

That's easy:

1\. A scientific study differs from an unscientific one in a number of ways, one of which is the presence of a control group.

2\. To create a control for this hypothesis, create one MLS listing with photos, and another MLS listing without (if that's possible). See which one produces the desired result.

3\. In lieu of (2) above, if that's not practical, do a classic Web A/B test -- create two versions of a web-based advertisement for a property, one with photos, one without (or one with more and one with fewer photos), each with a click-through. Then simply count clicks. This way, you don't have to track the outcomes, only logged clicks, which means you get results faster.

Item (3) above can also test varying advertising content, not just the photo issue. It's quite common to use A/B testing in Web design, so some of the infrastructure may already be present in the server. The key to the method is to randomly choose between two or three page designs when an URL request arrives at the server, and track the outcomes keyed to the designs.

This approach would give you a more scientific result, because it's based on a comparison in which _the only thing changed is the thing being measured_ \-- same property, different number of photos. Same property, different description.

Before closing, I have to tell my favorite real estate joke (which I invented). An agent visits a "distressed" property and is almost overwhelmed by the smell of the interior -- it literally smells as though there are mushrooms growing in the walls.

But our hero always thinks positively. He returns to the office and begins writing the listing. A long pause as he tries to think of a way to put a positive spin on the property. Finally a light bulb appears over his head, and he begins typing. The first word: "Breathtaking!"

<comment><AUTHOR> Thanks for the joke!

I appreciate your comments. I like the idea of option number two, because it still gets to the end goal--a sale. It'd be a bigger project than I want to take on, though.

Option number three gauges interest in a scientific manner, but assumes that interest is a valid proxy for the end goal of a sale. I'm not sure how true that assumption is.

I've window shopped homes that I had no intention (nor capability) of buying. My employer one had a record day because one of the homes on the site was a football player's and had gotten mentioned in an ESPN blog. In both cases, interest was only vaguely related to purchase capability.

Testing all the way to the end of the funnel (home sale) is key, and difficult.

<comment><USER2> > It'd be a bigger project than I want to take on, though.

In that case, use the above outline as a litmus test for those who claim real evidence for a particular strategy -- just ask, "Have you done any A/B testing?" It has the advantage of putting the conversation on a quasi- scientific footing, and it impresses people too. :)

> Option number three gauges interest in a scientific manner, but assumes that > interest is a valid proxy for the end goal of a sale. I'm not sure how true > that assumption is.

Yes, fair enough. But remember that online advertising pays by the click, so someone, somewhere believes it's a valid measure of future sales, even if the click is all there is.

Maybe 500 people click, and only one buys. The outcome is still related to the click-through rate, and the pay-per-click scheme still works. If there was any serious doubt about the value of paying for clicks, people would refuse to pay -- they would try some other approach to online advertising and metrics.

> Testing all the way to the end of the funnel (home sale) is key, and > difficult.

Absolutely. You would have to interrogate the buyers, and I venture to guess no one will want to push that idea.</comment></comment></comment></comment></comment>


Pokémon Go Is Coming to Apple Watch - <AUTHOR> https://www.polygon.com/2016/9/7/12836838/pokemon-go-apple-watch-ios <comment><USER2> "... activity goals set by the player. During a walk, it registers the distance and calories burned." Interesting - are they transitioning Pokemon GO to a peripheral activity? No longer the primary focus, but simply a side minigame to otherwise analog activities.

Also, the $35 peripheral seems to be too little too late. I can only imagine the piles of money they could have made if the hardware could have been available when EVERYONE was playing playing Pokemon GO.</comment>


The 'oh sh_t' moment that Nokia decided to abandon MeeGo - <AUTHOR> http://www.engadget.com/2011/06/02/the-oh-sh_t-moment-that-nokia-decided-to-abandon-meego/ <comment><USER2> Here's the original article [http://www.businessweek.com/magazine/content/11_24/b42320567...](http://www.businessweek.com/magazine/content/11_24/b4232056703101.htm)

<comment><USER3> Engadget does an amazingly bad job of linking the original article. You would think that the sentence 'Bloomberg Businessweek just published an amazingly thorough piece on Nokia' would have a link in it, but it doesn't.

No where on the page do they link to the start of the original story. The 'source' button links to the page/paragraph that the quote is from, but that isn't exactly the same as linking to the front of the other article.

The only links in the content go back to other Engadget stories. I'd say its bad etiquette.

<comment><USER4> Engadget always has a source link at the bottom of the article. They don't link to anything but themselves in the article text for SEO reasons. Also note that the word "Source" at the bottom of the article is not text but an image – also for SEO reasons. (I don't, however, know what that's supposed to help.)

This is a truly disgusting practice. The good thing about it is that once you know what's going on, it's relatively unproblematic. Whenever someone directs me to Engadget I know where I have to click. (In a funny twist, once you know where it is, finding the source is actually easier than when it is hiding in the article text.)

<comment><USER5> I will tell you how that practice might help for SEO purpose. A page has a limited link juice which gets distributed more or less equally to all links on the page. So if the article links to external page, some of that link juice flows to it. Why not rather limit it to your own internal pages?

<comment><USER6> If that's the case, why not just use rel="nofollow"?

</comment></comment></comment></comment></comment><comment><USER7> I honestly don't know why they feel like need to release a huge number of devices to compete against Apple and Android. Apple releases _one_ every, what, 15 months? And for Android, it seems you really only need ~3 devices (one with a keyboard, and two without at different prince points) to make a dent into the target market for Android.

It maybe that MeeGo was going even slower than that, but that's also their fault for deciding to more or less completely ditch Maemo instead of investing resources into that back from 2008 onward. If you look at what they had with the 770 a year and half before the iPhone, and the N800 5 months before, Nokia could have been huge. Instead they stuck with Symbian without really putting the correct work into it. And now they're stuck with Windows Mobile it seems.

I'm not sure what it all really means, besides a reminder it really doesn't make sense to attach yourself too much for companies. What they do can change on a dime.

<comment><USER8> Completely disagree about needing devices. Apple only makes one [phone] device per year, but Apple is losing market share to Android every month. Having a single device might be a good formula for profitability or user experience, but it's not the road to an empire.

Compare to Android. It's not just about form factors. It's about hardware freshness. Android has had dual core, LTE, and double the ram for months. There are Android phones with 3D screens and 3D cameras. The iPhone 4 is looking long in the tooth. And the iPhone 4S will just be catching up to the Galaxy S 2.

If I had to point to one reason why Apple is trading at such a low multiple it's because Apple is making too few devices to maintain leadership. Apple's market share has peaked unless it starts acting very un-Apple.

<comment><USER7> I mean, it's not that Nokia was only going to be releasing three devices before 2014, it was three MeeGo devices. I guess you could argue one/year is too slow to keep up, but they were going to continue to release Symbian phones.

And I'm not sure if much of that "hardware freshness" is really what's getting Android market share. Are there (sizable numbers of) people buying a phone because it has a 3D camera?

It may have made sense for Nokia to ditch MeeGo, but I think I was actually intending to mostly complain about how they got themselves into the corner.

<comment><USER8> Are people buying Android over iPhone because of a 3D camera? Probably not. Because Android is the only way to get LTE? Definitely, this is a big one. Because Android is the only way to get a dual core CPU? Definitely.

Not to mention the form factors which are also pretty important. Some people demand a keyboard. Other people want a huge screen. That's just not an option with iOS. There's also brand momentum. Everyone that isn't Apple has loaned Google its brand by putting Android inside.

As for MeeGo's viability I think it's a moot point. Even if MeeGo was perfect Nokia would be in an uphill battle. Look at webOS, critically regarded as the best competitor to iOS. HP has a near zero market share. You either need to be the very best by far, i.e. Apple, or you need to have the rest of the industry behind you, i.e. Android.

The fact Nokia looked at Windows Phone 7 and Android considered them equals makes me question Elop's decision making. The article also has a telling quote when Elop says he couldn't reach someone because the other guy was "probably testing an Android device that day."

Elop might as well have decided to build personal computers with OS/2 Warp in the 1990's because IBM gave him a big check and Windows is humorously unreliable. I'm sure that would have been a great business decision.

</comment></comment></comment></comment><comment><USER9> This, is a classic management lesson. Take stock. Confer with key stakeholders and the engineers. Draw a composite picture of the state of the system. And take a painful decision to abandon your approach, hopefully in time. Much as I liked 'Meego' as an idea, and much as I like Nokia as a phone company( Symbian phones were incredibly useful. And the hardware and design is always top class.), this was a correct decision. I hope Nokia can find its feet again and dazzle us with some amazing phones again.

<comment><USER10> _Symbian phones were incredibly useful. And the hardware and design is always top class._

What's keeping Nokia from playing the same game that HTC is? Is it entirely manufacturing/labor costs?

From the article: _"MeeGo had been the collective hope of the company," he says, "and we'd come to the conclusion that the emperor had no clothes. It's not a nice thing."_

Maybe the culture and social organization of a company is analogous to its autonomic nervous system? A shock to that is very risky and not to be undertaken lightly.

<comment><USER9> Because Nokia R&D spend is 8 times that of HTC, and 5 times of Apple for that matter.[1] Nokia needs the flexibility with the OS. In an ideal world, Nokia most certainly should make an OS by themselves, but clearly that didn't happen, so they choose the one that gives them the most flexibility to do what they want, much more than just putting a custom UI on top. And yes, the shock is risky. But the way things were going, very necessary.

[1][http://www.itpro.co.uk/630721/nokia-r-d-spend-outweighs- appl...](http://www.itpro.co.uk/630721/nokia-r-d-spend-outweighs-apple-and- htc)

<comment><USER11> What flexibility? According to Microsoft, WinMo7 is allowing less flexibility than Android, that being one of its selling points (less fragmentation).

<comment><USER9> From the article, "To that point, Microsoft had forced handset makers to obey strict rules about how they could customize Windows Phone 7, and they wanted the same from Nokia. Not only did Nokia respond that it wanted the right to innovate freely, it asked Microsoft to commit to using Nokia technology as a foundation of the Windows Phone platform, particularly its detailed Navteq maps database."

</comment></comment></comment></comment></comment><comment><USER12> I've never heard a Linux distro, especially one based on an existing distro, and made by people who have already made one before, only working on 3 pieces of hardware in 4 years. Could anyone explain this?

<comment><USER13> I suspect the answer is some combination of (a) getting device drivers to work on highly specialized hardware in spite of extreme memory/CPU constraints; (b) developing a user interface (and the widget toolkit for developers to use, etc.) that doesn't suck.

When my company was acquired by Nokia we had a choice of company-issued phones, and of course most of the geeks picked N900s (which ran Maemo, a Meego predecessor). After a few weeks using the N900 I was like "well, as a handheld Linux computer, it's OK, but as a _phone_... meh."

<comment><USER12> I have been using an N900 for almost a year, and I think it's a great "phone". Excellent voice quality, great microphone, easy to call people, and the best reception I've had with any device. It works well with all my hands-free stuff, and it works very well as a "phone".

What complaints do you have?

<comment><USER14> Posting this on an n900... Very low battery life, bad touch screen, sluggish ui. Why on earth did they cripple the default shell? The keyboard is pretty nice. When someone is calling you, the answer and decline button jump around in the screen, and I always hit the wrong one. This is because of the orientation sensor and the slow ui rearrange. Most browsing frustrations go away when you start using Opera as the browser. Most of the bugs in the builtin apps could have been fixed relatively easily, but I guess they restarted with a different ui paradigm after N900. Never used android or iphone so don't know how bad they are.

<comment><USER12> The battery life is certainly an issue, but I find the UI just as fast as the equivalent Android. I also love the touchscreen because of the stylus.

You can prevent the orientation sensor from making things jump by forcing either portrait or landscape mode in the phone-ui application.

Most of those bugs in the apps have been fixed in the Community SSU: <http://wiki.maemo.org/Community_SSU>

</comment></comment></comment></comment></comment><comment><USER15> Shades of SGI getting killed off due to the actions of Rick Belluzzo; this was after he scotched the development of PA-RISC because of his view that Microsoft was going to take over the world... the difference being that Belluzzo joined MSFT after proving his ability to destroy MSFT's competition.

<http://www.theregister.co.uk/2006/05/13/sgi_belluzzo/> <http://en.wikipedia.org/wiki/Richard_Belluzzo>

A cynical view would be that MSFT is happy to see their management jump to their competitors...

<comment><USER16> >A cynical view would be that MSFT is happy to see their management jump to their competitors...

Yea, I know: <http://news.ycombinator.com/item?id=2209064>

</comment></comment><comment><USER17> The only surprise there is that it took a whole day and a meeting with the new CEO to work this out.

It was common knowledge amongst anyone who tried it that MeeGo was no where near ready for consumers, and it was reasonably clear that the hardware platform they were aiming at wasn't 100% sure either.

<comment><USER18> It's often surprising in a large organization how much goes on that upper management is unaware of, either through incompetence or malice. I don't know enough about the specifics of this situation, but sometimes "everyone" knows that a product isn't going to ship in time, but maybe the product manager doesn't want to broadcast this fact for fear of his job. If his manager is asleep at the wheel, this kind of thing can happen. I'm guessing that the new CEO simply did something the previous CEO didn't do: ask the right questions.

<comment><USER19> We having a saying here that once you make Director or VP, they force-feed you "stupid pills" that cause you to lose your mind.

I'm sure everyone has stories.

</comment></comment></comment><comment><USER20> _"Nokia is now on track to release at least one Windows Phone handset in 2011 with a dozen more in 2012."_

A dozen!

With a dozen models on the market how are customers supposed to choose?

Nokia should slow down and put as much TLC as possible into 1 or 2 products next year. Make each immaculate instead of figuring you can fix your mistakes in next month's model.

<comment><USER21> Has having numerous models from a variety of manufacturers really hurt Android in terms of sales ?

<comment><USER22> Are you suggesting that the number of models of an item that a company produces should in some way be comparable to the total number of models on the market?

<comment><USER21> I'm not sure what you mean, sorry.

What I was trying to say was that I don't think having 12 models is going to make things confusing for consumers or be detrimental to sales.

HTC/Samsung/Motorola releases a lot of Android phones in a given year and it hasn't hurt their sales.

Edit: It must be noted that it isn't likely that any single market will have a dozen Nokia models available to the public.

</comment></comment></comment></comment><comment><USER23> I don't understand this article. It's claimed that the company realized they cannot meet their scheduled goals with MeeGo, so instead they switch to Windows Phone. Yet the article call the latter "an OS still struggling to find traction in the heated smartphone market."

If that is true why would they think it could solve their problem?

<comment><USER17> Because WinPhone is a finished operating system, unlike MeeGo.

Nokia's problem was they couldn't get a competitive product out _quickly_ enough. WinPhone gives them a chance, MeeGo wouldn't have shipped in decent numbers until _2014_.

</comment></comment><comment><USER24> What I often wonder is why didn't Nokia decide to try its hand on both Android and Windows Phone 7? Samsung has managed to do this while keeping its in house platform intact. Experiment and see what finds uptake rather than bet a huge corporation on a single platform.

</comment><comment><USER25> Lies and deceit.

Elop is a former employee of Microsoft and has huge share in that company. His reason to be at Nokia was to bring it to Microsofts lap and so destroy MeeGo and Qt.

<comment><USER26> He sold all of his Microsoft shares and bought 150,000 of Nokia. [http://www.businessinsider.com/nokia-ceo-elop-sells-all- micr...](http://www.businessinsider.com/nokia-ceo-elop-sells-all-microsoft- shares-buys-nokia-2011-2)</comment></comment>


Show NH: Anonymous Christmas Gift Exchange - <AUTHOR> http://santa2santa.com/

<comment><AUTHOR> This is my weekend project. I will be grateful for any feedback. You are also welcome to join the gift exchange.

Tech specs: linode/ubuntu, flask(python), jquery, twitter bootstrap.</comment>


Have you seen 'Back to the Future'? - <AUTHOR> http://enga.ge/products/have-you-seen-back-to-the-future/

<comment><AUTHOR> TL;DR: How to get people to stop at your startup's Tech Day booth -- use a movie tie-in and an opener that they'll likely answer "yes" to</comment>


Pocket Legends game generates 30 to 50% more revenue on Android than on iOS - <AUTHOR> http://tech.fortune.cnn.com/2011/03/08/for-some-developing-on-android-is-more-lucrative-than-ios

<comment><USER3> Who earns more might be good fanboy fodder, but surely the interesting question is when the extra revenue from the second platform outweighs the costs of cross-platform dev.

At that point you're just turning down free money if you stick to one platform and whether (as in this case) 55-60% of your income comes from one or the other isn't particularly interesting. Before you get to that point the dominant platform has a self-reinforcing lock-in effect where the users go where the games are and the games go where the users are.

I'd imagine this point gets reached sooner for corporate game developers who might be porting existing content from the Playstation anyway, and if they aren't are probably still using 3rd-party, cross-platform toolkits like Unreal engine and writing to OpenGL standards.

</comment><comment><USER4> There's something to be said for "Getting in on the ground floor." It's always a bit of a gamble: You may do amazing work, but if the platform dies your work dies with it. But you may also end up building a brand as one of the early successes in that market.

</comment><comment><USER5> It's awesome that they're making money. It's funny when making more revenue on Android than on iOS is national news.

<comment><USER6> But that's not the news.

The news is about the overall trend of Android surpassing iOS on metrics that people track and care about.

There was a period where newspapers were reporting about iPhone developers making big bucks. It wasn't news because a particular developer made some money but because it showed a new trend of iPhone becoming a new way of making good money for many people. The "new" part was why it was news (a new company making big bucks selling Windows software isn't news those days, even though there are still plenty of them).

Similarly, the current thinking today is that you can make more money on iOS. This article is newsworthy because it shows that this might be changing (granted one data point doesn't make a revolution, but one data point is more than zero and to get comprehensive picture we have to start with sharing single data points).

</comment></comment><comment><USER7> Showing that one developer makes more money on Android doesn't really prove anything. There are more games for iOS than Android so logically the games on Android should be making more money.

<comment><USER8> There is some truth to this, but it isn't that simple.

I was the only game of my genre for months and I made pretty good money. Then competitors started to flow in. Several of them. Each one gets better and better.

However, I've maintained steady to growing revenues from my game over the months.

There are a LOT of people getting Android phones still, and those people are putting games on their phones - especially since they can get bigger and bigger SD cards and just load them up with games.

<comment><USER9> Even on my 8GB original iPhone, space for games wasn't an issue. Space for music and photos was, but not games or other apps.

<comment><USER8> My kids all have 8GB iPods, no music or videos, just games, and they are starting to have to delete games now because they are running out of space.

Some of these games are getting huge.

</comment></comment></comment></comment><comment><USER10> Strictly by the numbers: iOS/iPhone is one of the least rewarding platforms/devices to target -- when revenue's the goal. These apps don't perform well vis a vis, say, boring old Windows or iOS/Mac or, increasingly, Android apps. If you're thinking about getting into iOS development with an eye towards Angry-Bird style profits, please read this first (and then the other dozen pieces of research on the same topic):

[http://communities-dominate.blogs.com/brands/2010/06/full- an...](http://communities-dominate.blogs.com/brands/2010/06/full-analysis-of- iphone-economics-its-bad-news-and-then-it-gets-worse.html)

Relevant quote:

 _That number times $1.95 per paid app gives the 'most typical app' the total revenues in its lifetime - the full two years of App Store existence - <USER2> $1,948 dollars. This is before Apple takes its cut of 30%, so we are left with $1,363 over two years or $682 per year. This is so 'successful' that half of all of the developers of the 164,250 apps - will actually earn LESS THAN THIS. Before you start to cry, remember, there is that Angry Bird game that had 4 million paid downloads and the Bewelled 2 game with 3 million paid downloads. Thats your math there, they are totally skewing the averages, and you are stuck in the 'long tail' indeed. Half of all developers will earn less than $682 per year. Do you still think this is a good business idea?_

EDIT: The mathematics are a little depressing, just something to keep in mind. Certainly a successful app is a successful app. Getting there on iOS seems to be a lottery proposition.

<comment><AUTHOR> I haven't seen any evidence that _any_ market manages to break the law of averages. Do you have any idea how much crappy Windows shareware is around making a lot less than $600?

The iOS Appstore (and now the Google Market) is important though, because it solves one of the big problems _individual developers_ had with other platforms: _distribution_.

</comment></comment><comment><USER11> I think it's demographics. Who owns an android phone, and what game would they buy? And how many competitors to this style game on the platform.

Meanwhile on iOS, the demographics are more flat, and additionally there are more choices for RPG/MMO style games than on android.

</comment><comment><USER12> This is all just BS marketing by Android(with our w/out fanboys).

Pocket Legends is a lame game on iOS. iOS has much better competition for the same genre as Pocket Legends.

The fact that it's doing so well on Android just logically should be embarrassing for Android but if you spin it right I guess it's easy to make it sound like something it isn't. You know, if you're being dishonest to your fellow man/developer doesn't pull your life karma down I guess.

<comment><USER13> Actually, it's a perfect illustration that a market with less competition allows for easier profits.

With a huge user base, and far fewer apps than iOS, as iOS proponents are so eager to point out, the android market is a great opportunity for developers. The rest of your comments regarding fanboys and karma do not merit response.

<comment><USER14> I deleted this game months ago because it is just a front to get players to purchase in-game crap with real cash. I moved onto better iOS games that focus on gameplay and not trying to get into my wallet.

This game is making more money on Android because it lacks other great games in the genre. While I applaud them for finding a way to improve their sales, it would be pretty wrongheaded for any developer to think that this is a long term profitable stance.</comment></comment></comment>


A small HTML5 experience with box2dweb and your webcam - <AUTHOR> http://youpinadi.github.io/itsrainingmen/

<comment><AUTHOR> Tested on Chrome only</comment>


Ask HN: When is a startup a startup? - <AUTHOR>

How do you define a startup?
When is a startup a startup?
ex: If I have an idea and I ask my parents for $1000, am I startup? <comment><USER2> > A startup company or startup is a company, a partnership or temporary > organization designed to search for a repeatable and scalable business > model.[1] These companies, generally newly created, are in a phase of > development and research for markets. The term became popular > internationally during the dot-com bubble when a great number of dot-com > companies were founded.

> Lately, the term startup has been associated mostly with technological > ventures designed for high-growth. Paul Graham, founder of one of the top > startup accelerators in the world, defines a startup as: "A startup is a > company designed to grow fast. Being newly founded does not in itself make a > company a startup. Nor is it necessary for a startup to work on technology, > or take venture funding, or have some sort of "exit." The only essential > thing is growth. Everything else we associate with startups follows from > growth."[2]

copied from [http://en.wikipedia.org/wiki/Startup_company](http://en.wikipedia.org/wiki/Startup_company)

[1] Blank, Steve (March 5, 2012). "Search versus Execute". Retrieved July 22, 2012.

[2] Graham, Paul (September, 2012). "Startup is growth". Retrieved Oct 18, 2012.

</comment><comment><USER3> A small business that is attempting to become a large one.

But really, talking about the meanings of words is pointless. Try asking a more practical question about the thing that consists of you having an idea and asking your parents for $1000.

<comment><AUTHOR> Thanks for the response. I have created a few low quality android apps and make about $30-40 a month. It is a hobby, hopefully something more in the future.

I'm just amazed at how freely the term 'startup' is used to label anything and everything.</comment></comment>


Estimating Flight Characteristics of Anomalous UAVs - <AUTHOR> https://www.preprints.org/manuscript/201908.0233/v1 <comment><USER2> Meanwhile, uncontacted Stone Age Tribe elders observes anomalous large bird possibly made out of shiny rocks in the sky traveling at faster than any bird flys or animal runs. It does not make noise like bird and it does not flap wings but makes low drowning sounds like a fast flowing river. It would be able to traverse to the big unknown mountain far off in the distance in minutes to hours.

Stone Age Tribe Hacker News drum circle meeting says that tribal elders smoked too much sacred pipe last night or maybe supreme elder tribal shaman has secretly made it out of shiny rocks and leaves. They ask, why would it fly like that in a straight line, doesn't the bird know that the world ends just over the horizon?

<comment><USER3> You seem to be sarcastically suggesting that it'd be dumb to dismiss such sightings because we have those planes today. It'd still be correct to dismiss the stone age sighting of something like a modern airplane, since they weren't around yet.

<comment><USER4> He mentioned uncontacted stone age people. That's a reference to tribes today who choose not to connect with the outside world. For example, the Sentinelese are said to not even have fire. They have metal now only because a few years ago a big freighter crashed on their island, which surely was perceived the same as a UFO crash would be to us.

<comment><USER5> There's a story that reaches the front page of HN from time to time of a Russian family that fled from Stalin into the Taiga sometime before the space race and were only found I think in the late 70ies.

One of the observations they had made from the wilderness was satellites, and IIRC they had figured out the objects had to be man made.

That story always touches me in more than one way.

</comment></comment></comment></comment><comment><USER6> This is the footage from the 2004 Nimitz Incident that is one case study in the paper:

[https://www.youtube.com/watch?v=6rWOtrke0HY](https://www.youtube.com/watch?v=6rWOtrke0HY)

This is another more compelling video, but was not covered in this paper (was from 2015):

[https://www.youtube.com/watch?v=wxVRg7LLaQA](https://www.youtube.com/watch?v=wxVRg7LLaQA)

The US Navy has certified that these videos are authentic, and were not for public release. [1]

1 - [https://time.com/5680192/navy-confirms-ufo-videos- real/](https://time.com/5680192/navy-confirms-ufo-videos-real/)

<comment><USER7> Having spent a few years in skeptic groups helping debunk aliens and yeti footage, I must say that these are refreshing documents: authenticated videos, sensors are specified, we even have original audio of one!

I would like to just ask something I may have missed: how did they shield themselves from the (very) classic error of mistaking something small and close, like a bird or a bug, for something big and distant? There is an abundance of footage of blurry insects close to a camera being mistaken for very fast alien ships.

I mean, this is supposedly locked by radars, why is the distance measured by those not given?

And I must say, reading the analysis of the Nimitz incident by this paper, it is a glorious case of over-analysis. They base themselves on an oral recollection of approximate values, add to it wild assumption ("Since we want a minimal power estimate, we took the acceleration as 5370 g and assumed that the UAV had a mass of 1000 kg.") and to unnecessarily complicated calculations to guess random things about this supposed vessel.

Also worthy of note is that this is part of a program [1] paid by a senator in the direction of a close friend, who is a UFO enthusiast, and had to justify spending 22 million USD with some things.

In such a case, I don't think they have an excuse for not having actual radar data as well. I suspect such data would dismiss cases as something easily identifiable like a meteorite.

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

<comment><USER8> We know for sure that at least the radar from E-2C Hawkeye plane in the area that had returned was confiscated by plainclothes officials who landed on the Nimitz via helicopter.

<comment><USER9> How do "we" know this?

<comment><USER8> Because the guy on the plane responsible for the data testified on camera that he was instructed to grab the the "bricks" (specialized hard drives) immediately upon landing and they were then confiscated and quickly flown off of the carrier rather than being stored in the safe as per usual.

Watch Histoy's Unidentified series.

<comment><USER9> Oh ok. I don't trust that story. Sounds like somebody is embellishing if not inventing things. It's unfortunate but this is my general experience with UFO events that get publicized. People confabulate stories that fit the alien origin and government conspiracy narrative.

Time to slink out now for me. I derive some entertainment from the puzzling over what a UFO might be. The ensuing unwarranted speculation into alien origins puts me off. And the people who posit a government conspiracy tend to assume just those origins.

</comment></comment></comment></comment></comment></comment><comment><USER10> > The observed flight characteristics of these craft are consistent with the > flight characteristics required for interstellar travel. That is, if these > observed accelerations were sustainable in space, then these craft could > easily reach relativistic speeds within a matter of minutes to hours and > cover interstellar distances in a matter of days to weeks, proper time.

The authors are not actually suggesting that the craft are flying faster than light speed, they are arrogantly defining the reference frame of a traveler aboard the ship as "proper time". It would still take over 4 years to get to Alpha Centauri from our perspective.

<comment><USER11> "That is, if these observed accelerations were sustainable in space"

If the observed accelerations of my car were sustainable in space, I'd be able to do interstellar travel pretty easily.

Stack this up with the other crazy assumptions made in this piece (check out the first comment, for instance). You want to assume high tech has 1000G acceleration? OK, you know, sure, fine. But it _also_ moves through the air at _massively_ supersonic speeds without causing friction or sonic booms? That's another _separate_ piece of technology that's basically magic. (Honestly not even sure which I find less believable!)

And then this amazing advanced technology is flying around is moving around on that flight pattern because... uhh... why would any aircraft fly that way again? Look at that flight path. What possible use could that have?

I've never heard even a sketch of a motive that suggests _why_ these craft would fly in such crazy patterns around aircraft that isn't better met by some other approach, that is, whatever goals something flying such an astonishing craft may have, they could simply obtain directly.

The theory that these are "technologically advanced craft" requires an _incredibly_ precise combination of high technological skill matched with utter ineptitude and stupidity, beyond merely "oh we just don't understand their goals". This is not intelligence acting in ways we don't understand; this is lack of intelligence.

<comment><USER8> Please see exactly how these objects were tracked before you degrade these researchers work. They're using the scientific method but you are not.

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

<comment><USER11> They may be using the form of the scientific method, but they are not using the substance. I value the latter much, much, much more than the former.

</comment></comment></comment></comment><comment><USER12> This is a fun paper. I wish they had done some work to acknowledge and/or dismiss other potential reasons for the appearance of the UAVs, like instrumental, environmental, etc.

The section that implies that they can just assume they are flying physical objects because the observers are professionals is pretty weak.

<comment><USER13> They do acknowledge potential issues: "these observations are either fabricated or seriously in error, or that these craft exhibit technology far more advanced than any known craft on Earth."

And their selection process: "These encounters were selected from a subset of cases for which there were multiple professional witnesses observing the craft in multiple modalities (including sight, radar, infrared imaging, etc.)."

Some of the cases have multiple witnesses and video of the objects. You can look at it yourself.

<comment><USER12> As someone who has published a lot of peer reviewed physics papers none of how this is presented feels rigorous. It's fine to muse about the "what if" here but they don't present this work that way, in my opinion, as they appear to be reinforcing their work with witnesses and not science.

Nothing really wrong with that in general but personally I'd rather see an attempt to dismiss as many other possibilities as possible.

I would love to see a thorough analysis and understanding of how the sensor pod works, as well as the software it runs to see if it could be contributing to anomalous measurements in the HUD. An exploration of any local environmental data, astrological, optical, and chemical reasons something may appear the way it does in the sensor data.

I'd much prefer a release of the entire data set of raw sensor information along with it.

<comment><USER14> So, basically all the stuff that's impossible to get 15 years after it happened. Yes it would be great to scientifically eliminate all other possibilities. But it's probably not going to happen. The paper is an attempt to treat the subject matter seriously with the limited amount of tangible information still available.

<comment><USER12> Why should that data be impossible to get? They seemed aware of the exceptional nature of what they were observing, I would be surprised if the data wasn't archived somewhere.

</comment></comment></comment></comment></comment><comment><USER15> From the comments: [https://www.metabunk.org/2004-uss-nimitz-tic-tac-ufo-flir- fo...](https://www.metabunk.org/2004-uss-nimitz-tic-tac-ufo-flir-footage- flir1.t9190/page-8#post-222154)

pretty good discussion

<comment><USER8> People explanations on that thread are weak AF.

</comment></comment><comment><USER16> I'm disappointed that the authors don't even consider that the observations might be of rare atmospheric phenomena. Some of those (red sprites, etc.) look unreal.

What the Navy observed also sounds an awful lot like WWII "foo fighters". Occam's Razor tells me it's probably some sort of natural phenomenon that happens to be attracted to planes for some reason.

<comment><USER17> What natural phenomenon would be attracted to planes?

<comment><USER16> I don't know for sure. I'm not a physicist. I would assume it could be the metal in the plane, vortices created by its motion through the air, changes to the Earth's magnetic field caused by the metallic object moving through it, something like that.

</comment></comment></comment><comment><USER8> If you're interested to know more about exactly what was the wide and varied spectrum of sophisticated technology that tracked these ET crafts following the Nimitz group over six days I've compiled a list here:

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

<comment><USER18> FYI your post was flagged and you're risking a hellban trying to promote it.

<comment><USER8> Thanks for the heads up

</comment></comment></comment><comment><USER19> Can the link be updated to the (open access) peer reviewed article?

[https://www.mdpi.com/1099-4300/21/10/939](https://www.mdpi.com/1099-4300/21/10/939)</comment>


Hacker with terminal illness seeks to opt out of death - <AUTHOR> http://aaronwinborn.com/blogs/aaron/open-source-software-developer-terminal-illness-hopes-opt-out-death

<comment><USER2> Reddit has a thread by Bill Gates (thisisbillgates). Why not write him, he is a humanitarian who will surely help you.

[http://www.reddit.com/r/IAmA/comments/18bhme/im_bill_gates_c...](http://www.reddit.com/r/IAmA/comments/18bhme/im_bill_gates_cochair_of_the_bill_melinda_gates/)

</comment><comment><USER3> God speed aaron.</comment>


I Have a Weird Idea How to Get Data into Cars - <AUTHOR> http://jalopnik.com/i-have-a-weird-idea-how-to-get-data-into-cars-but-i-ha-1792494407 <comment><AUTHOR> Interesting from the perspective of a gedanken experiment, but there are obviously much more efficient, less expensive ways to transmit data.</comment>