Google's Eddystone – a flexible, open-source iBeacon alternative - <AUTHOR> http://arstechnica.com/gadgets/2015/07/meet-googles-eddystone-a-flexible-open-source-ibeacon-fighter/ <comment><USER2> This is a really interesting idea. iBeacon is way too inflexible in what you can encode in it.

I really dislike the decision to make it part of the Play API (as opposed to standard Android), as it ends up not being really open after all.

I wish they would also document their packet format. At least they write that they support parallel operation as Eddystone + iBeacon [1], which means that they probably use the BLE "advertisement" frame for the iBeacon and the BLE "scan response" for the Eddystone data. With both frames limited to 29 bytes, there is not much space to toy around.

[0] [http://developer.radiusnetworks.com/2015/07/14/introducing-e...](http://developer.radiusnetworks.com/2015/07/14/introducing- eddystone.html)

[1] [http://altbeacon.github.io/android-beacon- library/eddystone-...](http://altbeacon.github.io/android-beacon- library/eddystone-support.html)

<comment><USER3> Binding things to the Play API has been an unfortunate compromise for Android; their product partners have not been forthcoming on continued device support, so google has had to bundle more and more as an updatable package rather than as part of the core OS. It's a shame that it's been this way, but in the prisoners dilemma of older device support, LG/Samsung/Etc have chosen to rat many, many times, and Google had to do something.

<comment><USER4> It would be nice if the bits of Play Services that could be open sourced were open sourced.

<comment><USER3> Bits like this can be and are open sourced; they're just not as usable open sourced, because obviously they're yet another library to grab and install. All the code you need to interface with it seems to exist on github, though not in nearly as pretty a package.

</comment></comment></comment></comment><comment><USER5> > The name "Eddystone" might sound a little weird, but Google says it's named > after the Eddystone Lighthouse in the UK

Damnit Google! Naming things after light-houses is our "thing"![1][2][3][4] :-)

All joking aside this sounds like a pretty cool project. And anything that helps keep as much IoT infrastructure open-source as possible, is a Good Thing in our book. I'm actually really hoping this catches on and displaces iBeacon as much as possible.

[1]: [https://github.com/fogbeam/Quoddy/](https://github.com/fogbeam/Quoddy/)

[2]: [https://github.com/fogbeam/Neddick/](https://github.com/fogbeam/Neddick/)

[3]: [https://github.com/fogbeam/Heceta/](https://github.com/fogbeam/Heceta/)

[4]: [https://github.com/fogbeam/Hatteras/](https://github.com/fogbeam/Hatteras/)

<comment><USER6> Funny the things you stumble across when reading through user comments. Love what you're doing.

In your 'travels', have you come across the need to integrate your services with the TechnologyOne line of products?

Information insight is a problem the company I work for struggles with immensely.

<comment><USER5> I'm not familiar with TechnologyOne's products, but I'll look them up. If you'd like to talk about it offline, feel free to drop me an email. email@example.com

</comment></comment></comment><comment><USER7> This looks really cool, in particular the telemetry packet is a nice idea for transmitting sensor data with BLE broadcast packets. Using that you can 'passively' read many nearby sensors without having to connect to them. I've had some similar ideas and played around with doing similar things using a nRF51822 (like a BLE radio + little cortex M0 chip) but ran into a ton of trouble with the BLE API's of various operating systems (like CoreBluetooth on OSX and bluez 5.3 on Linux).

In particular most BLE implementations like CoreBluetooth and bluez have a lot of caching and assume that a device's broadcast & advertisement data rarely changes. This causes a ton of trouble when you put frequently changing data in broadcast packets since you can easily get stale or cached data instead of the most recent broadcast. I'd love to know if the Eddystone developers ran into similar issues with their telemetry packets and had any workarounds.

<comment><USER8> This isn't a problem with the BLE implementations. It's in the BLE specification!

> Duplicate advertising reports are not required to be sent to the Host. A > duplicate advertising report is an advertising report for the same device > address while the Link Layer stays in the Scanning State. The advertising > data may change; advertising data or scan response data is not considered > significant when determining duplicate advertising reports.

Advertising really is designed to advertise the presence of a device. It isn't for putting data in - for that you should connect to the device.

<comment><USER7> I'd argue its an omission or mistake with the spec then. Being able to passively collect sensor data without connecting to a device is very handy as it allows many devices to read data from many local sensors. If they all have to connect to each sensor then there's contention over the connection (only one device can connect to a sensor at a time) and it wastes power to setup and tear down the connection constantly (negating the whole point of BLE).

If advertising isn't for putting data then arguably iBeacon, URI Beacon, Eddystone, etc. go against the spirit of the BLE spec.

</comment></comment></comment><comment><USER9> The pity is that BLE on Android has sucked, horribly badly, consistently. Google needs to have their hardware have a minimum level of support for basic stuff, and then we can talk.

In contrast, Apple's BLE implementation is robust and works well for since the iPhone 4S, and reliably on all the newer platforms

<comment><USER10> Could you please elaborate on where the suckiness lies? Was it particular devices, or particular phone manufacturers? Or was it something wrong with the Android BLE APIs?

<comment><USER9> Everywhere possible: 1) Different levels of support on different hardware 2) Doesn't support half the BLE spec (Peripheral) 3) Limited functionality on the Central side, only supported 4 Peripherals last time I checked 5) Buggy in general

Just like we don't trust Apple to build cloud services that don't suck, we don't trust Google to build a consistent hardware/OS experience across Android. This is stuff that is not sexy, but it has to be done, and it's exactly what you expect to be done by a company that doesn't have 30+ years in building their own hardware + OS.

</comment></comment></comment><comment><USER11> Eddystone for dummies: [https://www.youtube.com/watch?v=jSDnf4In6QI](https://www.youtube.com/watch?v=jSDnf4In6QI)

</comment><comment><USER12> > _Google gets the best of both worlds here. As an open source project, > Eddystone gets lots of hardware support from vendors, but if developers want > to give users the best experience and have an easier time themselves, they > have to submit to the walled garden. Eddystone doesn 't need to be tied to > Google though, and if developers want to use their own cloud solution or > client API_

This is a killer. This isn't really open source at all [0]. Google controls the eco-system, and has most of the other vendors at its mercy (like how they flip search algorithms, give Google products a prominent listing in the search page, blacklist developers/websites etc). More than Search, its the mobile OS and API monopoly that Google is trying to build that's going to hurt even more.

I work on AOSP, and I think it is ridiculous that Google owns so much of the eco-system [1] and continues to get praised for being "open" as well; very much like how this article seems to be praising them now.

Besides, whatever happened to proposing to a central body and getting stuff standardized (I get that its political and slow, and no ones like slow)? Google works with W3C to get stuff in the HTTP standard [2], with ECMA too [3], but seems to have problem engaging standards body for other things where it has a near monopoly. Not long after Chrome has taken over a large market share, Google would start treating W3C the same, if it hasn't doing been that already [4].

[0] [http://techcrunch.com/2009/12/22/google-open-when- convenient...](http://techcrunch.com/2009/12/22/google-open-when-convenient/)

[1] [http://arstechnica.com/gadgets/2013/10/googles-iron-grip- on-...](http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android- controlling-open-source-by-any-means-necessary/)

[2] [http://www.tomsguide.com/us/google-spdy-http- internet-w3c,ne...](http://www.tomsguide.com/us/google-spdy-http- internet-w3c,news-13990.html)

[3] [https://brendaneich.com/2015/06/from-asm-js-to- webassembly/](https://brendaneich.com/2015/06/from-asm-js-to-webassembly/)

[4] [http://www.neowin.net/news/microsofts-pointer-events- becomes...](http://www.neowin.net/news/microsofts-pointer-events- becomes-w3c-standard-google-and-apple-play-hardball)

 _/ rant /offtopic_

<comment><USER13> >I work on AOSP, and I think it is ridiculous that Google owns so much of the eco-system [1] and continues to get praised for being "open" as well; very much like how this article seems to be praising them now.

They own so much of the ecosystem because they produce 99% of the code. It continues to amaze me how ungrateful people are to Google and their AOSP project considering they're the ones spending millions on R&D each year, yet that still isn't enough for the vocal pro RMS minority.

<comment><USER12> So are countless other companies (Mozilla, Segment, Facebook, Netflix) and individual developers open sourcing their code the right way unlike Google which seems to be using that as either to gather community consensus or to attract businesses (Hey! You're not tied to us, just roll your own Google Play Store equivalent, and replicate Google Play Services, and you're done, its all too easy, and if you don't trust us, fork the project, its all open source! But you know what... if you don't sign the OHA we'd not provide any support, and if you do sign the OHA, then you must install our closed source apps).

If you worked with AOSP, you'd rather be more frustrated than grateful. Google is getting a lot of the bugs fixed for free! And its model has none of the downsides. Mind you, Google doesn't develop AOSP in the open. It releases source drops every other month or so, I think. There's a rumour that their internal branch and one that's open sourced isn't the same. If you'd recall, Google refused to release code for Android for Tablets (honeycomb) at all. So that's there too.

<comment><USER13> What part of Google's AOSP do you disagree with? Is it that they don't perform every single commit in public or is it that their services aren't open sourced? As for your reference to the Google Play Store - this makes no sense at all. It's a service hosted and maintained on Google servers. Did you really expect Google to give this service away to any competitor that decides to fork Android?

>But you know what... if you don't sign the OHA we'd not provide any support, and if you do sign the OHA, then you must install our closed source apps).

Why would Google support a version of Android that refuses to pass the CTS? Do you really think Google would allow a device to use their services that was incompatible with Android? Also, why else would a company join the OHA other than to get the Google Apps and Services?

>If you'd recall, Google refused to release code for Android for Tablets (honeycomb) at all.

The code wasn't in a state to be released as it was incomplete. When they pushed ICS out they also included the Honeycomb source. So, it was released eventually.

>Google is getting a lot of the bugs fixed for free!

Would you by chance know the percentage of bugs fixed by people not employed by Google? I'm going to guess that percentage is very very low.

<comment><USER12> There's no real collaboration with external parties as far as I am aware ala the Node Foundation, the Linux Foundation etc;

And even if a device passes CTS, Google would not automagically hand you the keys to the Google Play Services kingdom.

As for Play Store / Play Services is concerned, they've been moving a lot of code to closed-sourced APKs. For instance, the default browser was open source, now the default browser that's Chrome isn't. The default keyboard was, now it isn't. The Camera app was, now it isn't. They started out being more open than where they are now. And that's my beef with AOSP.

I don't have the count of number of bugs non-Google employees fix. The percentages may be negligible, but the impact is high-- They do seem to be looking at mods elsewhere (swipe to dismiss notification? battery percentage in the status bar? open apps from lockscreen? CyanogenMod had them first), and they did just brought in Knox from Samsung recently.

Also, I am not asking for free Play Store support, no sir; I am asking for an open and standardized integration of multiple appstores and related services. But I guess that's not possible (see first line), and elaborate hacks such as MicroG need to be put in place [https://github.com/microg](https://github.com/microg) (a loosing battle, IMO).

<comment><USER14> > And even if a device passes CTS, Google would not automagically hand you the > keys to the Google Play Services kingdom.

Why they should give it? CTS has nothing to do with Play Services

<comment><USER12> I know. It was in response to what the other fellow HNer commented: "Why would Google support a version of Android that refuses to pass the CTS? Do you really think Google would allow a device to use their services that was incompatible with Android"

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> This really needed to happen to help push the physical web forward. Beacons by the suppliers have just been too expensive. Last year at Full Frontal Conf, Scott Jenson said URIBeacons would cost 'a fiver'...but the cheapest I've ever seen has been $15 each (and that's in bulk).

Really glad to see this! Hopefully soon I'll be able to buy dozens of these on the cheap for a serious project.

<comment><USER16> You can definitely get the hardware for <$15 in bulk if you source it yourself. There's a huge variation in quality though, as with most of the China stuff. If you're willing to deal with the caveats&lock-in of the Gimbal Beacons you can get those for $5.

Feel free to hit me with beacon questions, I've got a bunch of varieties sitting on my desk right now.

<comment><USER17> what are the caveats of Gimbal?

<comment><USER16> Shorter range, proprietary setup/configuration process, cycle IDs (crashing some android bluetooth stacks). They really want you to pay for the backend - wouldn't be surprised if they're sold at cost.

The batteries don't last as long as advertised either, but that's pretty much been true for all of the devices I've tested.

</comment></comment></comment></comment><comment><USER18> Yea but as long as iPhones are locked down so they can only talk to iBeacons then no other BLE beacon is going anywhere.

</comment><comment><USER8> This still has their weird URL encoding scheme though. To use it you have to own a very short domain on a common TLD. Kind of limiting.

</comment><comment><USER19> I hope I'll be able to upgrade my Texas Instruments' SensorTag to be Eddystone compatible in the future.

<comment><USER20> Yesterday, I received some HM-10 BLE boards I ordered a bit ago. I hope the firmware will be updated, but I'm not holding my breath.

<comment><USER21> Yeah, same situation here.

</comment></comment></comment><comment><USER22> Maybe offtopic, but does anyone here knows how to manufacture iBeacons?

</comment><comment><USER23> So is the major advantage of Eddystone that Google will implement it and won't sue you for using it in ways they don't like?

Eddystone isn't alone; there's AltBeacon, which is also an 'open' alternative: [http://altbeacon.org/](http://altbeacon.org/) Though it looks like they might be 'merging' with Eddystone.

AltBeacon was born out of Apple giving Radius Networks a cease & desist about a year ago for reverse-engineering the iBeacon protocol and distributing an open-source Android toolkit (with paid enhancements) for iBeacons: [http://beekn.net/2014/07/ibeacon-for- android/](http://beekn.net/2014/07/ibeacon-for-android/)

The Android iBeacon code used to be on Github but is no longer there. IMO the core "infringement" (if there really is any) is about 10-20 lines of Java that unpacks an iBeacon (major, minor, uuid) from a byte buffer and another bit of Java that aims to map RSSI to Apple's simple model for estimating iBeacon distances. The library did wrap the functionality in a nice background- threaded interface, and their API is distinct from Apple's. On the iPhone, there's a BLE daemon that powers iBeacon and is rather crashy (at least as of iOS8). The Radius Networks solution was clearly distinct. The story would be a textbook example of Apple's legal department hurting open innovation except for the detail that Radius Networks was offering a paid developer product atop the open source offering. (But I doubt they were making much money from it).

There are a lot of problems with iBeacon technology:

* A lot of people have bluetooth off. The surveys out there have a lot of variance, and you typically have a 50/50 chance that a user with a very modern smartphone will have BLE enabled.

* Droid battery usage isn't _too_ bad, but Apple's solution has a distinct advantage because the BLE daemon powering the feature can interop more closely with iOS and eat less CPU. It's really hard to get a consistent experience on both platforms.

* To do anything productive with the iBeacon (major, minor, UUID), you probably want to ping a webservice, which will be hard unless you have free wifi or you've made fancy deals with carriers (or Apple). And if there's wifi, you might as well just try to use _that_ as a beacon (ala PayPal's product).

* You probably /dont/ want to have iBeacons trigger any sort of immediate advert or notification unless the user has previously opted in to the service. A lot of users are starting to _not_ grant notification and other privs by default. Most users also do NOT like background location stuff. There are definitely user segments that differ, but you'll likely need to do a great deal of customer research to validate using iBeacon. If your app is payments, there's already NFC. If your app is marketing, you might get higher engagement with Augmented Reality or something tied to some other location service (ala Amex & 4sq).

</comment><comment><USER24> The problem with Google is that you don't know if any product/service they launch will still be supported in a few years' time, or if the product/engineering team will lose interest and move on to build the next shiny thing.

<comment><USER25> This meme is getting tired.

Plenty of other companies EOL products.

<comment><USER24> It's not a meme, it's a cliché. And it's a cliché because it's true.

Edit: Coincidentally: [https://news.ycombinator.com/item?id=9888387](https://news.ycombinator.com/item?id=9888387)</comment></comment></comment>


Judge: Apple must help US hack San Bernardino killer's phone - <AUTHOR> http://www.sfgate.com/business/technology/article/Judge-Apple-must-help-US-hack-San-Bernardino-6835058.php <comment><USER2> It would be really nice if these AP blurbs linked to the primary source. Another article[1] is a little more in-depth and mentions a 40-page filing by the prosecution, but doesn't link to it. Ten minutes of searching yielded me nothing.

I really want to see the arguments made by the prosecution and the judge's reasons for approving this. Without that information, there's not much to engage with.

1\. [http://www.nbcnews.com/storyline/san-bernardino- shooting/jud...](http://www.nbcnews.com/storyline/san-bernardino- shooting/judge-forces-apple-help-unlock-san-bernardino-shooter-iphone-n519701)

<comment><USER3> Looks like the article linked from the main thread on this has it: [https://news.ycombinator.com/item?id=11114756](https://news.ycombinator.com/item?id=11114756).

<comment><USER2> Found it: [https://assets.documentcloud.org/documents/2714005/SB- Shoote...](https://assets.documentcloud.org/documents/2714005/SB-Shooter- Order-Compelling-Apple-Asst-iPhone.pdf)

Thanks!

</comment></comment></comment><comment><USER4> If device makers can do this, then presumably anybody can, which suggests a huge security vulnerability in so-called "encrypted" devices which are only protected by an easily brute-forced 4-digit PIN.

<comment><USER2> Not necessarily. Only Apple has the code signing key to update the OS. They'd probably update the phone with a special version of iOS that lacked the erasure feature. Even then, decryption isn't guaranteed. The owner may have used a longer passphrase.

</comment></comment><comment><USER5> Does it brick the hardware protecting the secret key, or could it be attacked by saving and restoring the flash storage (or replacing it with simulated storage)?</comment>


China IP address link to South Korea cyber-attack - <AUTHOR> http://www.bbc.co.uk/news/world-asia-21873017 <comment><USER2> ssh -D8080 -L3389:southkoreanupdatedistributionserver.kr:3389 -lfakeuser suspiciouschineseserver.cn

Hey, instant proxy and remote desktop tunnel. I wonder what movies they have on Netflix China? I wonder what the weather's like in south korea?

( _ahem_ Obviously I'm simplifying and failing badly at being funny ... although if you don't recognize those SSH flags, you should look them up. VERY useful.)</comment>


Blender 2.78 released - <AUTHOR> https://www.blender.org/features/2-78/ <comment><USER2> Blender has been an incredibly useful tool and I use it almost every day. The number of things it can do is remarkable. Video editing, 3d modeling, animation, physics simulations, ray tracing, procedural texture generation, camera tracking, 2d image editing, character rigs, particle systems, the list goes on and on. The Blender Foundation continues to push out theses amazing updates despite the fact they only have a handful of people working full time. Blender is truly something special.

</comment><comment><USER3> Blender is very much the Emacs equivalent for 3D editing software. It had a kernel of functionality written in C but the majority of the functionality is actually written in Python, which means there is really robust support for extensions and plugins.

Also like Emacs, the UI changes based on what mode you are currently in, which is super confusing at first because it is often not clear which mode you need to be in to accomplish some operation.

Also like Emacs, they have managed to cram an amazing amount of functionality into the program so it seems to do everything, and is rock solid (it would never crash, when 3DS Max would crash 3-4 times a day).

It's not for everyone, but it is very powerful.

<comment><USER2> Blender on Linux is rock solid. Blender on windows isn't bad, but it does crash on me occasionally. It's funny, four years ago this wasn't at all the case. I can't tell you how much work I've lost from older versions crashing.

</comment></comment><comment><USER4> I really, really like Blender. I use it only as a hobbyist, but pretty reliably once a year it's super useful - modeling furniture in my apartment before moving, making visualizations, even playing with little artistic ideas.

Contrary to some other comments here, I like the interface. My only experience with competing software was ~8 years ago, but I find blender's interface faster and intuitive once you get over a slight learning hump.

<comment><USER5> I love Blender, and I also like the interface and like you I use it probably once a year. Unfortunately I do forget how it works each time and end up going back to my copy of the Blender book.

</comment></comment><comment><USER6> Just wanted to point out that Blender also has a surprisingly decent video editing workflow. The usual caveats about the weird user interface and steep learning curve still apply, but I gave it about two days of practice and am very happy with the results.

Someone wrote a review claiming that Blender was the least painful way to edit video on Linux. I'm not sure if that was/is still true, but after trying two or three crash-tastic alternatives, I'm willing to believe it.

<comment><USER7> I haven't tried the blender video editor, but Kdenlive has gone a looong way from the crash-all-the-time days to a modern and intuitive video editor (for a hobbyist at least).

<comment><USER8> Unfortunately on my xenial it still crashes so often that it's basically useless. I had to put together a short video recently and, after checking out all the available options, I ended up using the free version of Lightworks. I didn't try Blender though.

</comment></comment></comment><comment><USER9> The interface is the one thing that has kept me far away from Blender. Maya has many faults but, in the end, it has a UI philosophy that let's you reach escape velocity once you understand it. I have given Blender a chance many times, and every time, its interface makes my head hurt. It has improved, for sure, but still doesn't beat Maya in many ways. This is in now way a wish of poor luck to Blender as a project.

<comment><USER10> This is the big problem with Blender. The interface lacks an artist's eye for what to prioritise and group, what to hide away in a menu with what and what to have out in the open for easy access. It's an incredible piece of software, but it has the steepest learning curve out of everything because of this. And 3D in general is the steepest learning curve of all without having to fight the gui.

ZBrush is similar at the opposite end of the spectrum, with it's own language and gui priorities, but at least it's entirely customisable.

<comment><USER11> Blender is COMPLETELY customizable. It's open source. Most of the time you can right click on something, and open the source code inside of Blender to update it to what you want. I don't normally do that as I make my own add ons instead.

<comment><USER10> Good for you, problem with that for me is I'm not a programer, I'm an artist and this is why Blender isn't used in studios.

</comment></comment></comment></comment><comment><USER12> A Blender point release seems to have as many features as a pair of any other piece of FOSS software major releases.

</comment><comment><USER13> Blender is fantastic. Not only the modelling package is great and free (compared to the alternatives, aren't exactly cheap) and plugins are numerous and really good on average. Then beyond that, the renderer Cycles is GPU powered, and a beast, also for free. I've been using Blender every day for the last 2 years and I can't recommend it enough. Yes the UI will drive you mad at first until you get the hang of it. It's gotten better, but it's still different, at first.

</comment><comment><USER14> The single greatest way to increase adoption is to support the Maya and 3ds max camera tumble controls, basic transform and extrude hotkeys.

<comment><USER15> I've heard that Maya and 3ds max are miles ahead when it comes to the actual manipulating of 3d objects and that Blender essentially has a steep learning curve compared to those two. That someone who has experience with Maya or 3ds has a lot harder time learning Blender than vice versa.

<comment><USER16> Blender's biggest weakness compared to 3DS Max, IMO, is the relative lack of non-destructive editing options.

Specifically, Max unifies (many) editing operations on the modifier stack. An object is the result of a sequence of operations on meshes/paths/patches/etc, from a root creation facility.

In Max you can take a torus, say, apply materials, move it about, distort the mesh, apply physics settings, and then go back to the first modifier and change the torus' inner radius.

In Blender, although you can parametrically create a torus with the same options as in Max and customize those settings _immediately_ afterwards, once you edit the created mesh in any way - or even just select another object - you can't edit those settings any more: it becomes "just a mesh".

Max has mesh editing as a stage in the modifier stack (it _also_ has Blender- style "real" mesh editing). You can layer multiple mesh edits on top of each other and toggle each off or whatever you like. Blender can _do_ the same thing, but as shape keys. Both applications can make the same edits to a mesh, but in Blender they can't apply at different points in the modifier stack: they're all effectively applied before all the actual modifiers.

<comment><USER17> Non-destructive editing is overrated imho. In fact, one of the reasons I used Blender to model instead of Maya was its _destructive_ editing features. Even though I had a full, legal access to a Maya workstation through college, I preferred Blender. I found that most of the time, Maya's construction history was more of a hindrance, and if your scene file started acting funny for a reason you couldn't figure out, you just had to delete all the construction history. For this reason, working in Maya always felt a little precarious, and Blender's relatively crude modifier stack felt more predictable.

Now, I was doing 3d, cartoony animation when I was working in Maya, and one could argue that non-destructive tools aren't that applicable to that context anyways. Fair enough -- if you need to change the inner radius of a torus after you've distorted the whole torus, Blender has a fairly mature add-on called sverchok: [https://github.com/nortikin/sverchok](https://github.com/nortikin/sverchok)

</comment></comment></comment></comment><comment><USER18> This seems like an incredible amount of features in a single release, especially for such complex software. (I don't use 3D software, including Blender, so I may be wrong).

Does anyone know what their codebase health is like, and how they retain the ability to ship so much?

<comment><USER17> It is an incredible amount of features, but Blender goes through a lot of updates with mostly bug fixes as well. I know a lot of the added features in this release (Spherical Stereo, Bendy Bones) underwent development for quite a while, and the fact that they've stabilized around the same time might be more coincidence than anything else. As far as codebase health and its sustainability, I think the role of the Blender Foundation, and a very enthusiastic community has made Blender what it is today. Plus there open movie/games has disproportionately shaped its development.

</comment></comment><comment><USER19> A lot of people got problems with the interface of Blender. Comming from 3dsmax I also did.

What helped me a lot is to learn all keys. I even printed out a shortcut cheat sheet.

Then I followed a moddeling tutorial and now I can say it's maybe the best software I ever used.

But the key to learning Blender is to learn to use your keyboard.

</comment><comment><USER20> How's Blender's support for WebGL? I use Three.js quite a bit to make fun little animations, and for what it is I think it's the bees' knees. But for me, the lack of GUI means it remains slightly more time-consuming to be anything more than a labor of love.

<comment><USER17> While Blender doesn't directly support WebGL, there is a very popular add-on that exports to WebGL called blend4web. www.blend4web.com.

<comment><USER21> What do you think about the Three.js editor?

A common workflow is to use the Blender Three.js exporter for exporting models, then compose the scene with the Three.js editor, and do the rest in code.

<comment><USER17> I don't have an opinion on the Three.js editor as I've never really used it. In fact I've only really played with the basic Three.js code. Looks pretty cool though -- who knows, maybe that's the next big open source 3d thing! There's even some VR sculpt features there -- pretty damn cool!

The main reason I prefer Blend4Web is because I've been using Blender for about 10 years, and for better or worse, it's the devil I know. Blend4Web development tries to follow Blender versions as closely as possible too, which means there's never any exporting issues. That said, if I was collaborating with artists, and they were using other 3d authoring tools, then Three.js might make more sense.

</comment></comment></comment></comment><comment><USER11> I have been using Blender on and off since around 1999. I initially struggled and kept my 3ds Max. After the 2.5 update it has been uphill since then. I now use it as my primary 3d application. (I am mainly an animator but do everything else.)

It's interface, once understood is blazing fast to me. Yes it has caveats. So does every other big 3d package. I prefer some of the ways that Maya does things, and other times the way Blender does things. (I will never go back to the crashing fits of 3ds max, so much lost work.) But in the end it's the same as all the other tools. You just need to keep at it and it will become second nature.

The UI idea of no overlapping windows is probably my favorite feature of Blender's GUI. The ability to split windows and swap them to ANY part of Blender allows you to set it up exactly how you want, plus you can save your workspaces. Set it up once and forget it.

I can agree that some common commands have obscure shortcuts, but EVERYTHING is customizable. I do mean everything. (Side note, not everything is customizable in Python. :*( But most things are.) I have my own tool panel for all of my animation tools, I have custom shortcuts that overwrite some shortcuts that I never use. In the end I'm faster because of it's UI. Most of all I feel like I have a custom studio proprietary software because of how customizable it is, with just a tiny bit of Python knowledge. I don't claim to be a good programmer, but if you can write some html, you can customize Blender till you get what you want. Heck you can even make Popups/overlapping windows with 1 hotkey + mouse gesture.

I may be an advocate of Blender, but I have used just about all 3d packages and can gladly say that I'm happy with my experiences with Blender. (Since 2.5)

</comment><comment><USER22> Blender can do a lot, but I really hate the interface. I'll stick with C4D.

<comment><USER23> it's an unbelievably bad interface, I mean to the point that it's unbelievably bad even for experts [EDIT: for the sake of the thread I'll keep this, but I shouldn't speak for "experts" \- only myself and the days I poured into it.] It's not about being, erm, "differently intuitive", or requiring learning - it's simply broken. Imagine if while you were typing into this text box (as I am) the cursor would randomly move up a line, down a line, right a character or left a character and you had to manually put it to where you wanted the next character to go - the cursor didn't stay at the end of the line you were typing, as one might "expect". (This is just an analogy for nothing working the way anyone might reasonably use it.)

That's how broken blender is. It's hideously painful. If this text box were Blender, it would have taken me about 148 minutes to type this reply, with a random adjustment or undo or redo every letter of the way, I would have been fighting with this text box the whole way.

<comment><USER24> I think you just never got the hang of the interface. A lot of people really like it. I used to use Maya. It's very different. I prefer Blender's interface, personally, and can get things done very quickly and smoothly with it.

if Maya is emacs, Blender is vim. Neither of them are Sketchup, and neither are trying to be.

By the way: I used to hate vi, cause I never gave it a chance. Recently I buckled down and learned how to use it. Now I think it's awesome, and I've hardly scratched the surface. But I finally got over the steep hump, and it was worth it.

<comment><USER25> With Blender, it's more than that. I've been a 3D person for almost 30 years, and I've never encountered an interface as user-hostile as Blender's. Never. In 2001, it took me less than a week to get super-productive with Maya, and it was like a dream. Just off to the races. I use Blender constantly now. I did get the hang of it, and I'm very productive with it now. I still consider it hostile. It fights the user every single step of the way until you learn all of its irrationality by brute force.

<comment><USER23> I agree with this sentiment and nobody should downvote it - it's not unusual. The downvotes might be due to the fact that this article is about a blender release so will attract readers as expected.

</comment></comment></comment></comment></comment><comment><USER26> Blender is great. The best thing for me is that you can automate everything. The API is very good.

</comment><comment><USER27> I was working with Blender for the last few months and it can be quite confusing. Yesterday I had this weird occurrence where I had call bpy.ops.object.select_all(action='DESELECT') everytime before changing the matrix_world.translation values of some meshes. (Even though I didn't select anything in between). It took me hours to find out why the meshes weren't moving correctly.

I guess Blender is not perfect for using it with python only.

</comment><comment><USER28> Blender 2.78 cannot use png images as textures. Jpg images work fine, but png images render out as pink.. .. Any help??</comment>


Ask HN: How do you buy your first BitCoin (or altercoin)? - <AUTHOR> At the moment I'm not interested in mining, but I'd like to try things out with cryptocurrencies, especially with BitCoin. I've created a wallet with Electrum (seed + passphrase), what's next?<p>How do you buy your first coins? <comment><USER2> i didnt buy them personally, i mined my coins way back in the day but the simplest way is to find someone local who can just sell you some or head to your closest bitcoin ATM to get coins instantly. local bitcoins is an option but im not a fan of it, prices are usually high and its generally a pain.

the other way is via an exchange like kraken or coinbase, you will need to verify your ID with them before you can use the service (usually a photo of your passport and a photo of you holding your bank card) one you are authorised you can link your bank account and transfer funds to the exchange, once the funds clear in just buy as many coins as you want and move them out to a safe wallet

if you just want to grab some coins quickly and with the minimum of fuss a bitcoin ATM is probably your best bet

<comment><AUTHOR> I wasn't aware that bitcoin ATM is a thing, thanks! It happens that there is one in my city, which is a great option.

Any suggestion on how to approach business/merchant accounts (where lack of privacy is less of an issue)?</comment></comment>


Alan Turing in America - <AUTHOR> https://medium.com/cantors-paradise/alan-turing-in-america-db0104c965dc <comment><USER2> Interesting that he had to travel 5 days by ship to cross the atlantic and then had to wait hours in quarantine/immigration only to be swindled by a taxi driver in new york. Reminds one how relatively recent air travel really is and how NY taxi drivers have always been crooks.

> Turing's approach to the problem would be the solution that has endured, > likely due to Church's solution's reliance on his so-called λ-calculus

So-called λ-calculus? Isn't that rather dismissive of λ-calculus. λ-calculus contributed not only to mathematics/computer science, but also, logic, linguistics, etc. Not to mention its practical contributions in many programming languages. And as long as the Church-Turing theorem endures, church's so-called λ-calculus will endure as well.

Interesting article nonetheless. I wonder if Turing's correspondences are available to the public online?

<comment><USER3> > So-called λ-calculus? Isn't that rather dismissive of λ-calculus.

There's an article somewhere about how EU bureaucrats mis-understood what 'co- called' means idiomatically and started to put it in lots of documents just meaning innocently 'that is called' and how they caused offence.

That's probably what's happening here - the author doesn't know idiomatic English.

<comment><USER4> A quick Google search brings up this hilarious document: [https://www.eca.europa.eu/Other%20publications/EN_TERMINOLOG...](https://www.eca.europa.eu/Other%20publications/EN_TERMINOLOGY_PUBLICATION/EN_TERMINOLOGY_PUBLICATION.pdf)

The section on the misuse of 'so-called' is on page 54.

</comment></comment></comment><comment><USER5> I don't know why but I'm always fascinated by quotidian details of the lives of people I admire; the excerpt about his being swindled by a taxi driver was marvelous.

</comment><comment><USER6> Don't forget his camping trips and bike rides with Lawrence Waterhouse, as documented in Cryptonomicon!

</comment><comment><USER7> > By the end of the war, it appears that Turing's view of America and > Americans had sufficiently soured to where he refused to return ever again

I read somewhere opposite, I do not remember source.

At that time he was forced to take strong medication and had his security clearance removed. He could only continue his work at US, but he was not allowed to immigrate due to criminal charges.

<comment><USER8> I'd have thought he'd be unable to _e_migrate as he'd shown himself to be a massive security liability; his apparent predilection for teenagers/young men would leave him open to a [further?] honeypot.</comment></comment>


Just Say No to Detroit - <AUTHOR> http://online.wsj.com/article/SB122669746125629365.html <comment><USER2> "We would do better to set this money on fire rather than using it to keep these dying firms on life support"

That is probably the best quote I've read in a very long time.

It's so true.

<comment><USER3> Yes, you would be doing better by torching the money. You'd restrain inflation slightly.</comment></comment>


Show HN: TrueSight: small and fast hex editor for Linux/Windows - <AUTHOR> https://mydatasoftware.com/ <comment><AUTHOR> I'm not very satisfied with the state of hex editors on Linux and wanted to write my own to provide an alternative choice. Free editors that are most popular can get the job done, but their appearance often hurt the eyes or they aren't designed to work with huge files. Most of the commercial editors happen to exist only on Windows and it's not uncommon to have a dedicated Windows VM only to be able to run a few programs that can inspect some files.

I think Linux is about technological literacy so I don't see why Linux should have so small choice of technical tools.

Bonus feature is that it's not based on Electron ;), it's old fashioned C++ + Qt.</comment>


At Long Last, Facebook Releases an iPad App - <AUTHOR> http://bits.blogs.nytimes.com/2011/10/10/at-long-last-facebook-releases-an-ipad-app/

<comment><USER2> Now it's online

</comment><comment><USER3> I had heard the release was held up because of negotiations with Apple over other issues. It seemed like Apple and Facebook didn't get along. Steve Jobs describe integrating facebook with ping as not happening because of the "onerous" terms of service. Also Apple integrated twitter, not facebook into ios. Is it possible that it's because Steve Jobs is dead that it's released?

</comment><comment><USER4> Here's the page: <https://www.facebook.com/mobile/ipad>

It links to the current app, so I guess Apple hasn't pushed out the update yet.

</comment><comment><USER5> Vintage Facebook. Trumpet the launch, but do absolutely nothing to make sure that the user will have a good experience trying to get the app.

<comment><USER6> And if the screenshots are accurate, I'd say FB still has some UI work to do.

</comment></comment><comment><USER7> I don't see it in the App Store yet...

<comment><USER8> I didn't either.</comment></comment>


Comparison of encrypted Git remote implementations (2017) - <AUTHOR> http://ptspts.blogspot.com/2017/10/comparison-of-encrypted-git-remote.html?m=1 <comment><USER2> I see git-crypt missing from the comparison

<comment><AUTHOR> It might be interesting to answer the same questions for `git-crypt`!

I also listen to `git-secrets`... but I don't know much more!

</comment></comment><comment><USER3> Can somebody explain how collaboration works in conjunction with encrypt locally before push?

<comment><USER4> You use a shared key I guess.

I had a look how keybase does it [1] but they don't say in that blog post. But in their post about encyrpted group chat and chat bots they do say there is a shred key for the group caht.

[1] - [https://keybase.io/blog/encrypted-git-for- everyone](https://keybase.io/blog/encrypted-git-for-everyone)</comment></comment>


Outsmarting the compiler: Short story about optimization - <AUTHOR> http://dpzmick.com/2017/05/25/outsmarting-the-compiler/ <comment><USER2> When looking at code performance, it's important to remember that conditional branches are almost always cheap _inside microbenchmarks_ , because the CPU can figure out when the same branches get taken on every loop... but far more expensive in the real world. A similar issue applies to cache: Your code might fit inside the L1 cache in your benchmarks, but when it's used in the real world you get cache misses since the rest of the program accesses data too.

</comment><comment><USER3> > Then, a bit later, we need to very quickly finish populating the structs.

I am finding it extremely hard to envision a circumstance where this is a bottleneck for anything. Care to clarify the context?

I also find the struct layout really odd; why not just move c?

Your benchmarks are also probably broken; branch predictors use global state so will almost certainly predict fine the way you've used things. You need to _repopulate_ a significantly-sized _array_ each time with randomly chosen values. You can't use the same array because it'll be learnt, and you can't use a short array because it'll be predicted globally.

<comment><AUTHOR> I'll give that benchmark trick a try. Thanks for the feedback.

For some additional context, these structs are packed wire-line protocol structs. In reality the padding bytes are full of other fun details.

<comment><USER3> The question for context is how this became something you want to optimise. It seems almost anything else you do with the values would cost more than the part you tried to optimise.

<comment><AUTHOR> Very little is done with these values in the fast path. The application in question is basically a smart proxy that performs a very minimal amount of formatting. Most of the code in the fast path is pretty linear so I was curious if there were any good way to keep this particular case conditional free.

But, you are right that it probably doesn't matter. The minimal benchmarking I did convinced us that there wouldn't be much of a cost. The code that actually ended up being committed to our project has the branch.

</comment></comment></comment></comment><comment><USER4> Quick upvote for a well designed mobile friendly site. The last few HN posts I read were awful on mobile.

<comment><AUTHOR> Thanks! I started with a fork of this Jekyll site: [https://github.com/johnotander/pixyll](https://github.com/johnotander/pixyll) so I can't take much credit for the design

</comment></comment><comment><USER5> This is not so much "outsmarting the compiler" as "working with the compiler" \- tweaking code to trigger certain optimizations/generate particular output. The missing part, of course, is showing that these optimizations actually help...

<comment><AUTHOR> In this case I don't think that being clever can actually help us much. I have some microbenchmarks towards the end of the post that are not very indicative of any performance gained by writing this "clever" code.

</comment></comment><comment><USER6> How does this wrapper and each variant connect together? I supposed he would include a pointer to the actual struct in the wrapper, but I just see payload (that I'm gonna assume needs to be written to that array with padding in the actual struct).

For me, a wrapper includes the original thing and just wraps stuff around it. How does this work here? May also be a question to the author, I suppose now...

<comment><USER5> In this wrapper, the payload[] field holds an instance of either struct A or of struct B - that is, the wrapper is "prepended" to the actual data.

</comment></comment><comment><USER7> So why wouldn't you just put c before the arr[padding#] chars?

<comment><AUTHOR> In the real world version of this problem the padding bytes contain some real values and the structs are both written straight to a network line (protocol is defined externally)

</comment></comment><comment><USER8> gcc warning: ISO C++ forbids zero-size array 'payload' [-Wpedantic]

clang warning: flexible array members are a C99 feature [-Wc99-extensions]

is this still the case?

<comment><AUTHOR> Try compiling with c++11 turned on.

<comment><USER8> I used -std=c++14

<comment><USER9> Use -std=gnu++14 then.

</comment></comment></comment></comment><comment><USER10> Outsmarting the compiler: A short story about optimisation:

"Don't."

The end.

(Basically, as the story shows, with this kind of micro-optimization you may or may not beat the compiler but you're almost certainly wasting your time compared with more effective optimization methods, like rethinking the problem.)

<comment><USER11> This is stupid because it categorically denies the business case for micro- optomization.

Yet, a business case might exist when the library is heavily utilized, or often when a compiler isn't able to produce the correct code.

There are also cases primarily, in finance, where single threaded low-latency distinguishes competing groups. Some of those guys count every nanosecond.

The techniques described here ( and in other places) are universally applicable.

<comment><USER12> I recently played around with some code I wrote in college [1] which involves a pair of intertwined functions. I decided to play around with the SSE extensions on modern CPUs and write a vectorized version of the code.

Try as I might, I could _not_ beat GCC [2], which used non-vectorized code. I chalk it up to not knowing how best to write optimized x86 code anymore (it's been years since I did any real assembly language programming) and I might be hitting some scheduling or pipeline issues, I just don't know.

[1] I described the code years ago here: [http://boston.conman.org/2004/06/09.2](http://boston.conman.org/2004/06/09.2)

[2] I beat clang easily though.</comment></comment></comment>