Apple is betting on augmented reality - <AUTHOR> https://www.bloomberg.com/news/articles/2017-03-20/apple-s-next-big-thing <comment><USER2> I'm impressed by the ability of the press to take any new tech idea and spin that into Apple being the latent dark horse that will win the category.

Off the top of my head I can think of streaming TV, a physical TV set, AI, and self-driving cars.

Is there any evidence Apple has any advantage over the already quite competent, well-funded players who have already demonstrated significant progress in this area?

<comment><USER3> AR will become mainstream at the point people see it as the norm in public.

Apple's core advantage is that they set the standard for mobile smart devices and consumer will follow them if they're able to gain momentum.

Question at that point swings back to how they'll try to do it, which becomes highly speculative.

If I had to guess, they'll morph the iPhone to a AR device like the morphed the iPod to a phone; meaning the first step is to add AR to the iPhone and gain traction.

<comment><USER4> The iPhone already is an AR device though, and one of its first major apps was an AR application - Layar, back in 2009. One of its major apps has an AR component (Pokemon Go).

I could see them making a Google Cardboard-like mounting bracket / dock for the iphone I guess, maybe with better cameras and sensors.

<comment><USER5> I think Google Glass is more where they will go. Except, just like the first iPhone, they will make it actually look like a normal pair of sunglasses. Apple has NEVER made new products, but they have refined existing products at key times to come out with something amazing. iPod, iPad, iPhone were not the first, but they were breakthrough staples that rules their area. Apple Glasses would do the same if done right.

<comment><USER6> > _Except, just like the first iPhone, they will make it actually look like a > normal pair of sunglasses._

Not going to happen (any time soon). That's an insurmountable engineering challenge for the foreseeable future.

<comment><USER7> Let's get specific: How long do you think it will be before Apple release iGlasses? 10 years?

<comment><USER6> I'm not sure when they will release a product in the vein of "iGlasses", but I'm certain they won't release an AR device that "looks like a normal pair of sunglasses" within 10 years. This isn't a situation where incremental progress will make this possible, there would need to be a fundamental breakthrough in battery and GPU efficiency that, while possible, is not necessary inevitable and definitely not on track within a predictable timeline.

<comment><USER8> What do you think about solving this with wireless power transfer? There has been some promising research recently into extending the range of resonant inductive coupling.

It's nobody's ideal, but a clip-on/necklace style power solution might be sellable to the public if the value proposition of the glasses is good enough.

<comment><USER6> A future where resonance charging equipment is safe, functionally practical and ubiquitous is sort of a breakthrough scenario in and of itself, but even then, you're still talking about a technology that is somewhat out of reach. Even if we can squeeze the necessary GPU power into the form factor of "a normal pair of sunglasses", consider the additional heat dissipation requirements of a device as thin as normal glasses that is also in a state of perpetual charge, especially when we take into account the human face's particular sensitivity to heat.

Maybe very thick oversized (by today's standards) frames will come into style and something like that will be on the border of possibility, but it seems like a real stretch within the next 10 years.

<comment><USER8> After thinking it over a bit, I'm going to take the other side of the bet.

We agree that power consumption is a limiting factor no matter what. In my imagined system, only something on the order of 1W would be delivered to the glasses. Delivering 1W over 10cm with large-ish coil area at >50% efficiency using NFMR isn't really a breakthrough, but it's _only_ a way of eliminating the LiPo bulk and nothing more.

The thing is, I don't think we're near the boundary of power efficiency even with today's silicon. The way forward is to push all the feature tracking and other low-level vision tasks down to the ASIC level, while accepting some strict limitations on the rendering side. So a lot of it comes down to scope of features. Its most immediately useful applications are little more than a glorified HUD -- project some GPS data here or an info overlay there. Blit a video source on top of a marker, that sort of thing.

This sort of practical product, by 2027, I'll say yes. Mindblowing, transform- your-world stuff? No. But let's see what happens...

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I love reading paragraphs like this:

 _The global market for AR products will surge 80 percent to $165 billion by 2024, according to researcher Global Market Insights. But Apple really has no choice, says Gene Munster, a founding partner at Loup Ventures who covered the company for many years as an analyst. Over time, Munster says, AR devices will replace the iPhone._

Oh, OK. Glad we've got all that sorted.

<comment><USER10> It's 2017, and e-books didn't replaces paper books, tablets didn't replace textbooks or laptops, gamers still use their PCs (it's not dead!), and consoles are still a thing despite the popularity of mobile games.

<comment><USER11> It's 2017, e-books have hugely affected the paper book market, tablets have hugely affected the textbook and laptop markets. PCs are no longer a growing as a market and are actually shrinking a bit. Consoles aren't as lucrative as they used to be because of the popularity of mobile gaming.

Anyone in this industry who doesn't try to look ahead will be caught with their pants down. The byline:

> CEO Tim Cook is betting on augmented reality, a cousin of VR that he > believes will keep his company on top and may even supplant the iPhone.

This is a completely reasonable statement in that context, it isn't as strong as Munster's quote above, but it probably wasn't meant to be that strong anyways.

<comment><USER9> Gene Munster, of course, is uniquely talented at predicting what Apple is going to do:

[https://9to5mac.com/2011/10/24/analysts-apple-prototyping- te...](https://9to5mac.com/2011/10/24/analysts-apple-prototyping-television- set-for-a-2012-launch-but-it-wont-come-cheap/)

[https://9to5mac.com/2015/05/19/munster-apple-television- retr...](https://9to5mac.com/2015/05/19/munster-apple-television-retraction/)

</comment></comment></comment></comment><comment><USER12> There are a lot of skeptical comments in this thread, but remember: Apple has revolutionized past industries like phones and tablets where other competitors failed miserably. A compelling AR product can and will exist eventually, and all this article is saying is that Apple will be competing in the AR field.

An aside, but I can imagine AR done right being extremely useful. I love the idea of being able to instantly have access to information on my phone, but it always requires typing or voice input. I could totally see just looking at something and tapping a button triggering a card that says "that thing you're looking at is this."

While that's just my dream, I'd much rather see people experimenting with new technologies rather than forgoing it with "Apple can't do X right, how can they do Y?" If anything, it could be because Apple is working on Y that X is taking a backseat for a while.

<comment><USER13> Before, Apple used to be led by a product visionary. Now it's led by a supply chain expert.

I seriously doubt Apple will develop another revolutionary product with the new leadership. My prediction is that paradigm shifting AR products will come from a product-driven organization, though Apple may buy them out and scale it...

<comment><USER14> I also have some very serious doubts about Tim Cook's abilities as a CEO.

However, it's quite obvious that AR is the next UX frontier:

Historic UX frontiers:

#1: text/console/terminal

#2: Graphical UI with a mouse (Apple sorta owned this at first)

#3: Mobile graphical UI with a capacitive touch screen (Apple owned this, at first)

#3.5 VR (but putting on a helmet is quite a bit too hardcore for mass adoption)

#4: AR

This progression is because of the 3.5 VR step quite obvious even to Tim Cook. So, I don't really doubt the claims that he's been doubling down on AR @ Apple. It all makes sense.

And once he has given the command, I have no doubt that the Apple company has enough talented people in each of the required competency areas to pull it off.

Perhaps the most important thing here is that a) Apple has lots of money, b) Apple/Cook has lots and lots of pressure to come up with the new thing.

I think we currently are in that particular place that doesn't require lots and lots of executive vision and taste.

<comment><USER13> Right - identifying AR as a hot area is easy, but formulating what that looks like requires vision. Money and talent will deliver the Palm Pilot (1997), vision will deliver an iPhone (2007).

My take on UX frontiers:

#1 text console #2 mouse & keyboard #3 touchscreen #4 camera & microphone

I think we're at the beginning of #4, and starting to see this in categories like messaging, social networks, dating, and e-commerce. I consider overlaying AR elements to a live camera feed to be a subset of this shift, but by no means the defining aspect of this new method to interact with machines.

<comment><USER14> > Right - identifying AR as a hot area is easy, but formulating what that > looks like requires vision.

Good point. And an relevant parallel between Sculley's Newton and Cook's potential "AR innovation project".

However - I get the feeling that it's a bit different from the mobile/touch UI revolution. That required lots of vision in terms of software and design. In AR I think there's really a _lot_ of low-hanging fruit in terms of UX/design - once the trick part; the AR hardware has been solved.

<comment><USER13> Thanks!

What low-hanging fruit do you see for AR?

</comment></comment></comment></comment></comment></comment><comment><USER15> I just don't see this happening, for a number of reasons related to the way Apple designs hardware - as unobtrusive, natural extensions of what we already do that you can hold but also toss aside as required.

And also because most of the "evidence" listed in the article has many other, simpler, uses in Apple's "incremental improvement" juggernaut. They can keep adding minor popular (and less risky) features without building in-your-face solutions that have uncertain acceptance.

Bloomberg might well be becoming the new Gizmodo as far as Apple coverage is concerned.

</comment><comment><USER16> > Run by a former Dolby Laboratories executive, the group includes engineers > who worked on the Oculus and HoloLens virtual reality headsets sold by > Facebook and Microsoft as well as digital-effects wizards from Hollywood.

The entire focus of the article is AR, yet the author classifies HoloLens as a "virtual reality headset". This is sure to be embarrassing when he realizes the size of the gaffe.

</comment><comment><USER17> I tend to be a skeptic with these types of technology but I must admit I've seen a video of supposed HoloLens footage (and even if it wasn't, it would do as a concept), that made me wonder.

This is the video I'm talking about: [https://www.youtube.com/watch?v=7mtS_224mKU](https://www.youtube.com/watch?v=7mtS_224mKU)

Now it's super flimsy and everything, but I guess those technologies are best imagined as they would look like if all hardware quirks were solved. I can definitely see a future where, instead of a desktop/laptop/tablet, you put on glasses and see an unlimited amount of virtual, arbitrarily-sized, floating monitors in front of you. Forget the 3D-gimmmicks, even. That alone sounds cool and useful. It's 2030 tech more than 2020 tech, probably, but I can see a future where this works.

<comment><USER18> There are two things to keep in mind when watching videos recorded through the HoloLens:

1\. The frame rate and image stability are much better in person. The HoloLens has to cut the rendering frame rate in half to be able to record video through its front-facing camera because the camera and the display share a bus. So what you see is significantly degraded.

2\. The constrained field of view is much more noticeable in person. With the video, you don't get to see anything out of the bounds of the frame, so there is no reminder that we can't "see" everything. Also, we are used to watching videos, so we don't think about the fact that we can't turn our eyes and look in different directions. What you see is significantly more generous to the HoloLens than reality.

I think the combination of the two factors generally makes the video an "accurate" representation of the HoloLens, even if it's not terribly "precise".

I don't consider the current iteration of the HoloLens to be a usable device. Comparably, the HTC Vive is a much better experience, one that is capable of providing to users an experience that is worth the drawbacks and the extra effort necessary to deal with them. The HoloLens is more effort than it is worth.

But on the other hand, tethered, completely opaque systems that require external tracking hardware for head and limbs are clearly a dead-end technology, even if that dead end is 5+ years from now. The end goal with mixed-reality technology is clearly in the HoloLen's lineage, not Vive or Rift or even Meta 2.

</comment></comment><comment><USER19> I'd rather want a new Mac Pro VR with a $20,000+ price tag. They should make something cool, and not this crippled stuff. Completely new virtual OS with built-in virtual programming language. Etc. Go crazy. Make it so that this is the workspace of the future for every professional. It's been too long that we have had to glimpse through these tiny windows. Break us free.

<comment><USER20> Yeah, seriously! Skip the car research. Bring us a virtual alternative that enables us to vastly reduce our need to travel! This is probably the closest we can ever get to teleportation. Why should I have to travel to various cities on either coast every few weeks to meet with clients? We should all be able to meet in a virtual space that allows us to connect nearly as intimately as an in person visit. The fact that we can do it far more often, would probably make for an even better relationship than we currently have with yearly live visits and lots of conference calls in between.

<comment><USER21> Probably for the same reason you're having to travel despite the telephone, FaceTime, secondlife, and email being invented. Telepresence isn't the same as physical presence, and the act of costing you is an important social signal itself. VR won't change that.

</comment></comment></comment><comment><USER22> And how are people supposed to develop for this new technology if they haven't released a Mac pro for nearly 4 years, and graphic card support is well behind Windows?

<comment><USER23> Probably via ThunderBolt3 connected eGPUs and whatever GPU comes in the next iMac update. Graphics card support isn't that difficult of a problem to solve. It'll never be on par with Windows but it doesn't have to be either. There are already a lot of AR/VR capable GPUs supported on macOS via the included AMD drivers and NVIDIA's third party drivers. It's probably a moot point though because they could just support testing on the AR device itself or perhaps with any other iOS devices with a similar GPU.

<comment><USER24> If only there were some way to get rid of all the cables! Could you, I don't know, and plug the GPU _directly into a socket_ on your computer?? Then put everything inside a bigger box to keep it all tidy and clean.

I wonder if Apple is secretly working on something like that.

<comment><USER25> Apple just freshly created that problem by abandoning tech that wouldn't have required those cables.

Maybe they'll re-introduce it some day and call it revolutionary.

</comment></comment></comment></comment><comment><USER26> If you're counting on the iPhone of AR, expect to wait. The state of the art is more at the palm pilot stage.

There's too many bleeding edge technologies, both software and hardware related, that have to come together before a sleek and affordable consumer grade device can really be a thing.

I look at a company like Magic Leap, and it's disappointing to see how much money has been dumped on them. Now they have to build a consumer grade device to justify their valuation, and I don't think it's possible anytime soon. I think they should be working with a fraction of the capital they've received and be focusing on a killer enterprise app that some industry might be willing to pay $5000 per unit for a clunky and unfashionable device.

<comment><USER27> The _only_ thing iPhone needs to become the best AR device on the market is rock solid low-latency positional tracking, low latency camera, and custom silicon for overlaying simple 3d graphics over the camera feed while using low power.

They don't need a headset.

They don't need stereo.

They don't need lightfield projection.

They just need an iPhone that feels like a handheld portal into augmented reality. I see no reason why they couldn't do that this year.

Heck, if they add positional tracking to the AirPods, it'll even feel immersive.

</comment></comment><comment><USER28> People have such a fundamental misunderstanding of Apple's business model. They do not invent—they refine. You won't see Apple release a VR/AR product because they simply haven't been in the market long enough. Their strategy has never been about being the first or even an early mover in a new technology.

It has always been about taking technologies which have been on the market for a substantial amount of time and iterating on a version that gets all the small details right until it reaches their very high internal standards for usability. Apple isn't interested in being the first to do something, they're interested in being the first to do something _right_.

</comment><comment><USER29> Although I am skeptical that Apple will bring out a good, furnished AR product, I am afraid that they might actually be successful because developers have often showed a good inclination towards making apps for Apple devices, and it is one of the primary reasons why Apple has been really successful in what they do, they have apps. Microsoft's HoloLens uses apps from their Windows Store and those that they made themselves, which is a very big limitation for them, and when both devices are out in public and ready for use, Apple will probably get a much larger influx of apps for their device than other AR/VR products. Even failed Apple devices are good money-makers for Apple, and apps are one of the main reasons for it.

The only reason I see Apple failing in the AR and VR field is their lack of data. Apple refuses to save data from their users, and although it is something I admire about them, it is what drives Machine Learning and Artificial Intelligence. Google and Microsoft is successful in this area because of the data they collect (via their Search engines and other OS services), which Apple does not. It is one of the reasons why Siri is competitively weaker than it's counterparts on Android and Windows, because it does not have a good data-driven Machine Learning backend, and unless Apple starts changing their policy on the type of data they collect and use from their devices, their AR/VR devices will go the same way, that is they will be successful in the amount of sales they make, but will be the weakest in terms of functionality and services they can provide.

<comment><USER18> > Microsoft's HoloLens uses apps from their Windows Store and those that they > made themselves, which is a very big limitation for them, and when both > devices are out in public and ready for use, Apple's devices will probably > be more successful.

What does the current state of the various app stores have to do with AR? By that, I mean, AR applications are so fundamentally and significantly different than 2D apps that back catalogs are meaningless. Any new player to the AR ecosystem is starting with an essentially empty app store, regardless of whether or on they deploy it on top of a pre-existing, successful app store. We can effectively say that Microsoft has the largest AR app store in the world.

And, we can expect Windows Store to grow as they push Windows Holographic and their tethered, cheaper VR displays (the Hololens is still a $3000 "dev kit"). Apple is not just starting from behind, they haven't even started yet.

<comment><USER29> Apple does have more registered developers than any other company right now. It is why Apple is able to get a larger portion of the consumer market than other devices even when they arrive late. Just take Apple's Watch and it's competitors for instance (Android wear and Microsoft Band).

</comment></comment></comment><comment><USER30> I suppose this is as good a thread as any to again make the claim that I don't think AI will be anything but a toy before AR is mainstream. For whatever reason right now the fashionable thing in tech is to pretend we don't have incredibly sophisticated and powerful meat brains in our heads and the best, most economical, and most feasible way forward is to completely eliminate it from every equation and replace it with silicon. When in truth the melding of silicon (binary) computers is easier and results in something much more powerful (and much sooner) than just silicon.

I'm fully aware computers will eventually outpace us. But the economic and human potential of human/computer augmentation is enormous and will likely last decades or even centuries in the "near" term. At some point we'll shed our obsessive fascination with denigrating humans as "old'n'busted" and remember just how incredible people can be.

</comment><comment><USER31> > While the smartphone will do the heavy lifting, beaming 3D content to the > glasses will consume a lot of power, so prolonging battery life will be > crucial.

The compute required for the AR or VR experience that would satisfy Apple isn't going to happen on battery power. Perhaps the headset can be battery powered and tetherless. I think the base unit would have to be a new Mac Pro.

> Content is key too.

Stating the obvious. But less obvious is to define exactly what one means by "Content" in this new realm. Simple things like "games" and "movies" aren't going to attract new customers to the new realm. What I expect from Apple here is a paradigm shift like was the iPhone.

</comment><comment><USER32> "Baidu goes all in on AI."

"Apple is betting on augmented reality."

What's next? "Facebook doubles down on human cybernetic enhancement"?

<comment><USER33> > What's next?

Uber folds.

</comment></comment><comment><USER34> when Apple looks at a technology it means the tech is ripe for mass production.

They can see profit here, i'm sure it will be a similar price to existing products, but the price has gone down enough for Apple's type of profit margin.

<comment><USER34> also apple are not desperate to make a quick buck, they'll spend 10 years on R&D on something till they think Starbucksers will be prepared to part with their cash.

<comment><USER4> And they're willing to let go of an idea - like the car, TV, etc that they have probably spent a nontrivial amount of money into. Or postpone it for a few years, like the ipad which was conceived well before the iphone.

</comment></comment></comment><comment><USER35> As an Apple fan, this smells like the Apple car rumours. Moonshot projects to retain talent perhaps?

Either way, AR is more suited to Apple than VR, even if more of a technical challenge.

</comment><comment><USER36> My BMW had a rather rudimentary HUD (they've since gotten a lot better). I think something like that for personal use would be really cool: the ability to look via some glasses or something at an object and see wikipedia snippets or the like. Or turn by turn directions as I walk without looking at a phone, pretty cool.

</comment><comment><USER37> I think Apple could leverage it's supply chain in this market very well. The product is small, intimate, and needs to work well with a minimalist interface. With the right sort of eye tracking, it could optimize CPU/GPU time only where the user is actually looking.

</comment><comment><USER38> Wait. I thought that was wearables? No wait, the TV, or was it cars? Oh gosh I've lost track.

</comment><comment><USER39> _" The global market for AR products will surge 80 percent to $165 billion by 2024"_

So, current market is $32 billion a year? Where is that market? Mostly military and for professionals, I would guess?

</comment><comment><USER40> I think Apple's play here should be around making iPhones amazing online clothes shopping devices. I would kill for a way to see how shoes or a shirt would fit before buying them online.

<comment><USER41> [https://www.mtailor.com](https://www.mtailor.com)

I've used this for a few flannel and dress shirts. It works pretty well.

I initially thought Amazon has to buy this. They would dominate retail if they can flip those last remaining shoppers for clothes who need to buy in person in order to try on clothes.

This app has incrementally improved over time, and added products. Initially you could only buy shirts. Now they have pants, suits and just recently added jeans. There's a lot of potential there...

<comment><USER42> That tagline perfectly targets a man with certain feelings on masculinity: "Stop Wearing Another Man's Clothing." I get that it is another way to present the idea of having clothes tailored, but it makes me think of how I used to trick my son into eating his all of his dinner by asking if he was man enough to eat it all or not.

</comment></comment></comment><comment><USER43> lets have apple get their bread n' butter stuff right first. Like how unplugging a USBC -> Displayport cable causes my macbook to crash requiring a hard boot, several times a day.

</comment><comment><USER44> I'd honestly be more interested in them focusing on existing products. I'm still skeptical of VR/AR really becoming mainstream. The best AR app so far is what? Pokemon Go?

</comment><comment><USER45> Apple will likely ship an AR device this year using the tech they've acquired from metaio/primeSense. All signs are indicating an AR-enabled iPhone 8.

</comment><comment><USER46> i'm excited to see what comes next for AR/VR, but without any prototype or demonstration, it seems more like investor fodder than real tech.

</comment><comment><USER47> Worked so well for Goggle and Microsoft so far.

<comment><USER48> Like with smartphones. Google and Microsoft do the hard work and then Apple swoops in and claims to have invented stuff.

<comment><USER11> > Like with smartphones. Google and Microsoft do the hard work and then Apple > swoops in with something that consumers actually want to buy.

FTFY.

</comment></comment></comment><comment><USER49> I have friends in VR and apple has tried recruiter them last year. It wasn't for their development experience. Only their VR work.

</comment><comment><USER50> Could this be just a decoy strategy from Apple while they work on something more tangible? AR is not a smaller disc or faster processor, AR does not exist - yet - and may very well never exist due to physical constraints (you can not paint black etc).

<comment><USER51> I'm not sure what you're talking about. AR _already_ exists:

[https://www.microsoft.com/microsoft-hololens/en- us](https://www.microsoft.com/microsoft-hololens/en-us)

It isn't necessarily useful but it exists.

As for whether this is a decoy strategy... Apple aren't even promoting this so it's not a strategy on their part; it's just information pieced together from hirings, anecdotes and guesses.

<comment><USER52> Makes sense for Apple to spend some resources investigating potential large & new technologies, even if they don't produce a product. The field _will_ shift when AR and self-driving cars and [insert intriguing vaporware here] arrive, so Apple should take a good hard look at the impact, if not the product potential, before they're too far behind the curve.

</comment></comment></comment><comment><USER53>
        One of the features Apple is exploring is the ability to take a picture and then change
        the depth of the photograph or the depth of specific objects in the picture later; another
        would isolate an object in the image, such as a person's head, and allow it to be tilted
        180 degrees. A different feature in development would use augmented reality to place
        virtual effects and objects on a person, much the way Snapchat works.

Oh come on.

I'm completely unimpressed to hear Apple working on AR if that's the best they can do.

It's a fabulously hard problem that no one has come close to solving; and to be fair, if they poured R&D $$$ into it, maybe they could make something out of it...

...but you know, since I can't use a Vive or Occulus on a mac, because of the ancient ass version of opengl they support, and the ridiculous on going split between vulkan and metal, I'm kind of unimpressed by the weight of their technical prowess at this point.

I don't believe it. General consumer AR won't come from Apple.</comment>


Someone is funding a Kickstarter for Mac and Cheese - <AUTHOR> https://www.kickstarter.com/projects/1889822567/just-want-to-make-some-good-mac-and-cheese

<comment><USER2> This is the Mac and Cheese the world needs AND deserves.

</comment><comment><USER3> A joke is only funny the first time. Exceptions to this are very rare. This is not one of them.

<comment><USER4> I feel like the first was more art project than joke. I agree that recreating it isn't of much value.</comment></comment>


Don't Tag My Cow - <AUTHOR> http://www.nytimes.com/2009/03/11/opinion/11hayes.html <comment><USER2> Seems easy enough to just say "farms with more than X animals".</comment>


Offer HN: Help with ActionScript 3 - <AUTHOR>

Many or most developers I've spoken to have little or no familiarity with ActionScript.<p>I've spent two years working primarily in ActionScript 3. So if you have any questions about the language, about Flex, about Flash Player/AIR, about best practices, and so forth, I'll try to answer them. <comment><USER2> Free book idea, which I got close to writing a few chapters of during the height of my ActionScript programming heyday: _Flash for Programmers._

Getting started with Flash development is difficult for CS-trained programmers. Most tutorials seem aimed at designers or animators. I haven't seen a good description of the end-to-end tool suite for flash or a list of best practices (e.g., using Flash for animated assets, exporting to a SWC and importing symbols as objects).

<comment><AUTHOR> That's definitely true, about the small intersection between {Flash fluent people} and {CS/software engineering fluent people}. My last company tried to find such people several times without success.

And indeed, that also means that many or most of the AS3/Flash resources out there are geared towards the copy-and-paste crowd.

</comment></comment><comment><USER3> Would you mind taking a look at [http://github.com/nfriedly/Javascript-Flash- Cookies/blob/mas...](http://github.com/nfriedly/Javascript-Flash- Cookies/blob/master/src/Storage.as) and letting me know if anything could be improved. For one thing, I think I have more try/catch statements than I need, but I'm not really sure what can throw errors.

(This is a flash cookies library. My company doesn't use it to invade people's privacy, but I know it could be used for that. If you don't want to contribute to something like that, I'd understand.)

Either way, thanks for the offer!

<comment><AUTHOR> I haven't worked with Flash cookies so I have no feedback about that domain specifically. There are plenty of legitimate uses for them, so there's no need to add a disclaimer!

The Flex references do a pretty good job of documenting what errors are thrown by various library methods. I recommend doing error handling at the first point where an error can be thrown, because AS3's unchecked error system makes it difficult to otherwise ensure that errors don't unintentionally propagate all the way up the stack.

Often, all you will care about is success/failure of a call. That appears to be true in your code. In that case, you might as well Don't Repeat Yourself: just catch(error:Error), and proceed. If you want to record which particular error occurred, you can log error.message or flash.utils.getQualifiedClassName(error). Tangentially, that also futureproofs you against changes to the API like additional Error types that may be thrown.

</comment></comment><comment><USER4> This is such an excellent offer! I would definitely need your help.

I've been working on a project of mine, where I need to the webcam to take a photograph of the user. something like chatroulette, but i need users to take only the photo. then send it back to my server where i'll do further processing.

I am an ActionScript noob, so any help in libraries/sample code or approaches that you could offer would be immensly helpful.

Thanks!

<comment><AUTHOR> I haven't worked with webcams. I imagine the AS3 docs, and the included examples, should cover your use case: <http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/>

For sending the photo, you probably want to look at URLRequest: [http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/fl...](http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/URLRequest.html)

A solution might look like this:

1) Set up your server to accept HTTP POST requests which include a photo, in whatever data format you plan to transmit them

2) Obtain the image data from your webcam (I have no particular insight into this)

3) Create a URLRequest

4) Assign the URLRequest's 'url' property as appropriate

5) Assign the URLRequest's 'data' property to to the image data

6) Set the URLRequest's 'method' property to URLRequestMethod.POST

7) Set other URLRequest properties, like ' requestHeaders', as appropriate

8) Add event handlers to the URLRequest as appropriate

9) Call the URLRequest's load()

</comment></comment><comment><USER5> I've been working on this one webapp for quite some time, also. I'd love some help with drag & drop between two datagrids where any changes push a specific ID as an array to the database.

It's one of those things where you have been stuck for 3 days and are willing to pay someone move on.

<comment><AUTHOR> I'd be happy to talk more about it. dsgant at gmail

</comment></comment><comment><USER6> Do you know if there exists a set of template files or code for an demo iPhone UI?

I'd like to do an 'animated prototype' of my app - and Flash is definitely the solution - but it would be nice if someone has already done the basic animations (moving screens, button states, etc).

<comment><AUTHOR> I don't know about iPhone-anything, but Flex offers a lot of the UI niceties you describe.

<comment><USER6> Thanks, I'll look into it!

</comment></comment></comment><comment><USER7> I've been working on this webapp for quite sometime and I'd love to have some help with pyAMF + Flex best practices.

<comment><AUTHOR> I haven't dealt with pyAMF but I have worked with AMF serialization. Do you have any particular questions about AMF?</comment></comment>


Writing a Microservice in Rust - <AUTHOR> http://www.goldsborough.me/rust/web/tutorial/2018/01/20/17-01-11-writing_a_microservice_in_rust/ <comment><USER2> Minor nitpick:

> Immutability (const) by default

The author clearly knows this, but others may not, so: immutability and "const" aren't the same thing. Const typically prevents name rebinding (as the type system permits). Immutability is the presumption that the whole data structure can't be mutated by default (though there are usually ways to mutate cheaply--without bulk copying, that is--provided by most immutable data APIs).

Const works like this:

      not_const int[] foo = [123, 456]
      const int[] bar = [456,789]
      foo = [1,2,3]     // no problem; rebinding is allowed if it meets the 'int' type constraint.
      bar = [1,2,3]     // compile error!

Immutability, _as typically defined_ (there's a bit of a semantic debate here sometimes) prevents changes to the contents of complex data structures:

      mut int[] foo = [123, 456]
      not_mut int[] bar = [456,789]
      foo[0] = 789    // no problem; mutation is allowed so long as it's with valid types.
      bar[0] = 123    // compile error!

Edit: missed a space.

<comment><USER3> _Const typically prevents name rebinding (as the type system permits)._

In C++ you can only call `const` methods through a const binding. `const` methods mark `this` const, so such methods cannot modify member variables. (Minus all escape hatches, such as `const_cast`.)

 _The author clearly knows this, [...] Immutability is the presumption that the whole data structure can 't be mutated by default_

The situation in Rust is a bit more complex. Rust distinguishes between interior and exterior mutability.

`let mut` bindings and `&mut` references exhibit exterior mutability - you can call methods that borrow `self` mutably (`&mut self`). Whereas `let` bindings and `&` references cannot. By the way, you can simply use moves to introduce exterior mutability for data that you own:

        let a = Vec::new();
        // Not allowed: a.push(1);

        // Move the vector.
        let mut b = a;
        b.push(1);

Even even if a data type uses an immutable binding or reference, it could still mutate that data structure if it has interior mutability (you just can't call methods that use self mutably). See the following small example, which uses an immutable binding to call a method that mutates the internal state of the struct.

[https://play.rust- lang.org/?gist=6816dc9a03aca1e779f08443224...](https://play.rust- lang.org/?gist=6816dc9a03aca1e779f08443224bee18&version=stable)

The downside of interior mutability is that borrowing rules are enforced at run-time rather than compile-time.

<comment><USER4> C++ also has the `mutable` as a way to achieve something akin to internal mutability

</comment></comment></comment><comment><USER5> _With microservice, I mean an application that speaks HTTP, accepts requests, speaks to a database, returns a response (possibly serving HTML), packaged up in a Docker container and ready to be dropped somewhere in the cloud._

Huh? That's a CRUD app. A "microservice" is a service which is a component of a larger service. Usually a service run by the same organization. Many microservices don't speak HTTP; they use Google protocol buffers or something similarly efficient. Serving a Facebook page involves about a hundred microservices, and they don't talk HTTP to each other.

<comment><USER6> Thank you for the explanation, I never understood this. I wonder how many people do though (is everyone on the same page about this, usually?).

<comment><USER7> A microservice is about the _size_ of a service, not about the underlying technology. This service has few endpoints, and so is a microservice. This also isn't a CRUD app, as it has no delete, for example. It only has the CR of CRUD.

<comment><USER8> > A microservice is about the size of a service

Is it? Isn't it a purely organizational paradigm where each teams are responsible for a specific service and clear API boundaries are defined between teams? rather than the "size" of an application? (which is hard to quantify, if my app does AI and needs 100,000 line of code for a single endpoint, is it still micro?).

That's why I believe "micro" is an unfortunate qualifier what is essentially basic SOA.

<comment><USER7> I see them as different axes. A service can be small, and it can be the only service. SOA means your larger service is comprised of smaller services, but says nothing about the size of those services.

An URL shortener is a micro service without SOA. A huge web application with four services that are half a million LOC each is SOA, but not micro services.

I wonder what Martin Folwer has to say...

<comment><USER9> > How big is a microservice?[0]

> Although "microservice" has become a popular name for this architectural > style, its name does lead to an unfortunate focus on the size of service, > and arguments about what constitutes "micro". In our conversations with > microservice practitioners, we see a range of sizes of services. The largest > sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole > team can be fed by two pizzas), meaning no more than a dozen people. On the > smaller size scale we've seen setups where a team of half-a-dozen would > support half-a-dozen services.

> This leads to the question of whether there are sufficiently large > differences within this size range that the service-per-dozen-people and > service-per-person sizes shouldn't be lumped under one microservices label. > At the moment we think it's better to group them together, but it's > certainly possible that we'll change our mind as we explore this style > further.

[0][https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html)

<comment><USER7> Thanks! I was on mobile so it was a bit awkward. I'll have to revise my understanding :)

<comment><USER4> For what it's worth, I much prefer your version. It emphasises the similarities between "empterprisey" SOA and the "cool hip" Microservice, while also highlighting one of the bigger differences.

People get too caught up in "how small is micro", which is just silly extremism.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I'm waiting for the service to be a bit more consistent to blog about it, but we've started with a friend to write a webservice in rocket and it's been a total pleasure

It may be useful to some people, as we've most of the feature you find in a "real life" service

       * database connection
       * schema creation
       * json handling
       * pagination
       * some endpoints are non-json
       * support for CORS
       * automated isolation test (i.e we test the service as a blackbox)
       * generation of a minimal bin-only docker image that with travis-ci
       * self-contained dev environment (vagrant up and you're good to go)

[https://github.com/allan-simon/sentence-aligner- rust](https://github.com/allan-simon/sentence-aligner-rust)

<comment><USER11> The only catch I've had with Rocket is that it relies on nightly. This can create issues with other libraries, and it is constantly requiring new versions of the nightly version.

If you're going to use Rocket, I recommend pinning the Rocket version in a Cargo.lock, and setting a specific version of nightly with rustup override.

</comment></comment><comment><USER12> Strikes me as having quite a big cognitive overhead. I wouldn't try using this in unless being cornered by performance considerations or wanting a pure rust software architecture.

<comment><USER13> Why? Even writing micro service in C++ is dead simple these days:

1\. write the service specification in Thrift.

2\. Generate the server and client stub with the framework.

3\. Write the service functions.

4\. Most probably you'd need to include some database/cache libraries. Poco project does a fairly good job.

5\. Add some more logging and metric libraries.

6\. General tools/libs are available in poco and folly.

7\. If you are messing with REST, Microsoft Rest SDK and Facebook Proxygen is already providing a very solid foundation. High performance servers are already written. You just need to fill the call backs and configure the thread pools.

Why do you consider this more difficult than doing the same in Go? You just need some intermediate C++ knowledge for above tasks. No need to touch template programming, manually managing threads, ...

<comment><USER14> How come on every thread showing an example of how to do something in Rust there's a staunch C++ defender thinking the whole world should be using their language? C++ is a complex beast that due to its age has quite a number of disadvantages and no two codebases I've seen are the same - a measure of a language is its simplicity and C++ subjectively isn't thus. If you like C++ that's fine; doesn't mean you can't do it in Rust as well.

I think it's good that other languages are evolving that are safer, make it easier to do concurrency, have an idiomatic style and still are performant whilst removing legacy cruft. It's the natural evolution of things. Every C++ team I've been on debates every feature usage (e.g. auto/lambdas/etc) where one team's good code is another's bad idea due to sheer amount of legacy features vs new ways, what language constructs are good vs completely bad ideas (everyone has completely different opinions), how should I import libraries, what build tool to use, etc.

<comment><USER15> The commenter to which you're replying is arguing that the cognitive overhead in developing a microservice _even in C++_ isn't so bad compared to, say, Go.

It doesn't seem to be an advertisement for C++ or a condemnation of Rust.

<comment><USER14> > Why? Even writing micro service in C++ is dead simple these days

Apologies to the commenter then. I misread that to be a "why bother?" to the original blog post and do this instead. All tech has its pros and cons and trying other things can be good too.

</comment></comment></comment></comment></comment><comment><USER16> That does seem a bit painful to me. Maybe it will get better with some Rust macro DSL though...

<comment><USER17> > That does seem a bit painful to me.

It's because it's written using a low level library. Here's the first two sections (the http handling part) in Rocket:

        #![feature(plugin, custom_derive)]
        #![plugin(rocket_codegen)]

        extern crate rocket;

        use rocket::request::Form;

        #[derive(FromForm, Debug)]
        struct NewMessage {
            username: String,
            message: String,
        }

        #[derive(FromForm, Debug)]
        struct TimeRange {
            before: Option<i64>,
            after: Option<i64>,
        }

        #[post("/", data="<message>")]
        fn message_create(message: Form<NewMessage>) -> String {
            format!("{:?}", message)
        }

        #[get("/?<times>")]
        fn message_query(times: TimeRange) -> String {
            format!("{:?}", times)
        }

        fn main() {
            rocket::ignite()
                .mount("/", routes![message_create, message_query])
                .launch();
        }

<comment><USER18> That code looks awful, sorry but rust syntax is horrible. I want to like rust but after a couple months of trying I hate the syntax and the over complicated nature of the language.

<comment><USER19> Disclaimer: I'm not in the 'rust community' (nor would I want to be!). I'm not an evangelist for it, and I'm not very good at it. I like the language though. Anyway...

I really think people need to get over syntax. I don't find rust particularly good looking either, but I get over that because I like the semantics and it sits in a nice place in the ecosystem of programming languages. Likewise i don't like how C# uses PascalCase everywhere, or puts opening braces on its own line - yet when I program in C#, I adhere to those conventions.

Syntax is incredibly subjective, and also superficial. If you think the semantics of a language suck or are not a fit for what you are doing - that's a reasonable conversation. But you really shouldn't limit your language choice based on non-alphanumeric characters or whatever your objection is.

<comment><USER18> > Syntax is incredibly subjective, and also superficial. If you think the > semantics of a language suck or are not a fit for what you are doing - > that's a reasonable conversation. But you really shouldn't limit your > language choice based on non-alphanumeric characters or whatever your > objection is.

I like the semantics of Rust, I actually use Rust, and plan on continuing to do so. I still hate the syntax and module system though.

</comment></comment></comment></comment></comment><comment><USER20> I made a very simple web service with Rocket (see [https://github.com/MrBuddyCasino/alexa- auth](https://github.com/MrBuddyCasino/alexa-auth)), which is better but still - I'd go for Kotlin or Go instead if performance requirements allow it.

<comment><USER21> Why Kotlin but not Java?

<comment><USER22> \- JVM is a good platform? Aka if you can think about it, it's probably been done in JVM and/or Java.

\- Java's GC is highly customizable?

\- It's one of top contenders in most web related benchmarks (see: [https://www.techempower.com/benchmarks/#section=data-r15&hw=...](https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=json))

<comment><USER23> Kotlin runs on the JVM too, and easily interops with Java libraries and frameworks. So all three of your points apply equally to Kotlin as they do to Java.

</comment></comment></comment></comment><comment><USER24> I haver been looking at Rust as a replacement for a c microserver I made,

I have a thing that listens as root and serves as a user dictated by their id.

so it's

        as root:
           on connect fork:
               forked process:
                  read request to determine ID
                  drop privileges to UID and GID of ID
                  process request

Because of the root component I want it to do as little as possible while being root, which c is good for. but it's also probably riddled with holes, only some of which I am aware.

<comment><USER25> Is it public? Can I take a look?

<comment><USER24> There's a version of some vintage at [https://github.com/Lerc/userserv](https://github.com/Lerc/userserv) (it's terrible, don't judge me)

It has node bits there but they aren't necessary for the basic static serving. If it gets a WebSocket connection it punts it on to node.

<comment><USER26> Had a quick glance and your code is littered with unchecked function calls and potential overflows.

Also: Cookie:../../../<filename>

Where <filename> is a file starting with a value that's interpreted as a valid uid by atoi(). You're saved by a NULL pointer deref when the unchecked getpwuid() fails if the resulting uid is >0 but invalid (unless you're running it on a system where NULL is mapped to readable memory).

<comment><USER24> Hey! I said don't judge me :-)

The reality is that I only wrote as much as I needed to go back to working on the project I needed it for. It works for the 'Everything is fine' case, which is what I needed to go back to developing the client side. Even a hint of malicious intent could probably bring it to it's knees.

But therein lies the rub. Is it worth hardening it or should I just go to Rust where most of those things just won't pop up?

<comment><USER27> So... did you use HTTP because the client side required it or it made the client side much easier, or was that just what came to mind? Because this seems to be _exactly_ the type of thing I would generally use the default OpenSSH installaction on the box for, pre-shared keys, and possibly even setting a specific shell on the specified public key on the user side on the server to prevent random shell access.

There's some really interesting advanced features of OpenSSH that most people will never have need for, but you can come up with some really interesting solutions. For example, you could also use a single remote account that allows SSH access and has a separate public key for each user that sets an environment var for the target desires user, and restrict the command run to sudo with that environment variable defining to run as that specific user, and make sure sudo is configured for the users allowed.

A microservice isn't a bad idea, it's just interesting how many ways there usually are to accomplish what seems like odd, specific custom workflow in most UNIX environments.

<comment><USER24> Client side was all browser. [https://github.com/Lerc/notanos](https://github.com/Lerc/notanos) also incomplete. I go back and add things to it from time to time. It's my long term toy project.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Shouldn't RUST_LOG use "microservice_rs" instead of "microservice"? the "_rs" is a crate name.

Another thing, in a make_post_response stub function I think it's better to use StatusCode::NotImplemented instead of NotFound (when trying this code I thought the match did not work correctly as everything returned NotFound).

</comment><comment><USER29> The amount of ad network traffic rolling off of this page is staggering.

Made more amazing by the fact that only one ad shows on the entire page.

</comment><comment><USER30> Excellent guide, something that I'll need in near future.

I wonder why the author chose hyper instead of iron though...

<comment><USER31> I'm pretty sure Iron is no longer maintained.

<comment><USER32> Yea unfortunately Iron isn't actively maintained anymore.

</comment></comment></comment><comment><USER33> Diesel is a synchronous library, so the post's database functions make a blocking call and then return a future which, of course, doesn't make them asynchronous. They'd still block the event loop.

You could fix this by passing a `&futures_cpupool::CpuPool` into your database functions and wrapping the post's function bodies in `pool.spawn_fn(|| { ... })` so that they execute on a different thread and return a future of their result.

To have a global IO pool that you pass into fns, you can store it in the Service struct:

        struct Microservice { io_pool: CpuPool }

Now you can access it in your service's handler (the call() fn) with `self.io_pool`.

<comment><USER34> I've never touched Rust or Diesel... but what is the point of a synchronous library that makes blocking calls _and returns futures_?

(I mean - why futures, if the call was blocking and presumably have a real result to return?)

<comment><USER35> Diesel doesn't return futures, the author of the blog post returned a future and the person that you commented on is pointing out that that's pointless because Diesel is synchronous.</comment></comment></comment>


Ask HN: What is your experience with Stripe Atlas? - <AUTHOR> How hard is to deal with tax/legal issues? How helpful Stripe's customer support/community is? Is LLC option suitable for a bunch of side projects that one would want to throw under the same "roof"? Would like to hear about your experiences. <comment><USER2> We ([https://mightyscout.com](https://mightyscout.com)) started off on Stripe Atlas when they first launched in 2016. We started as a C-corp, as was the default at the time, but since we never wanted to raise money and didn't want to incur double-taxation, we converted to an S-corp. Nowadays they offer an LLC and that's the option we'd take if we started today.

Since 2016, we've had to interface multiple times with lawyers, accountants, the State of Delaware. Let me be honest: I absolutely loathe dealing with this kind of crap, I just want to build awesome products.

Stripe Atlas has integrations with various accounting and law firms/services, to the point where you can email atlas@${firmname}.com and expect a real human to carefully read your problem and forward it to the right entity. I _love_ that. We recently filed our Delaware taxes incorrectly and received a scary- sounding notice from the State. I emailed Atlas for help and they figured it out, pointed me in the right direction, and the person on that end didn't charge us to make the amendment.

In 2011 I started a company and back then our only recourse was LegalZoom, which was an expensive and unhappy experience. Now that I've worked with Atlas for a year and a half, I hope incorporating companies will be just as easy (and inexpensive) as Atlas has made it.

</comment><comment><USER3> I previously worked at a company that was one of the largest in the online Incorporation space, and have used a bunch of others. I feel pretty familiar with all of the offerings and was _exceptionally_ satisfied with my Atlas experience for a number of reasons:

As folks have said, they are fantastic with support - very responsive and detail-oriented. The incorporation documents are easily accessible through their online dashboard & I don't have to go hunting for all of the additional corporate documentation. Their partnerships, such as with AWS, makes it very worthwhile if you're going to be experimenting with their partners' services. They have a great community - forums and slack, along with meetups and dinners - this, in my opinion, is unparalleled with the other competitors.

My thoughts on the downsides are that some of their partners have hidden fees - we ended up closing our Silicon Valley Bank account as they have some pretty steep fees and switched to a no-fee provider (Capital One Spark). The Atlas team was very responsive in helping us out with this, but it was a bit of a disappointment to discover this. I recognize that SVB has to make money, but the "flat rate" for Atlas didn't entirely translate to "flat rate forever" for me here. Granted this might be more advanced, but we ended up having to use another platform for managing our cap table. Some other providers, like Clerky offer this, but I realize that this might not be a priority for development for the Atlas team to develop.

All in all, would definitely recommend.

</comment><comment><USER4> Going through the experience right now for my startup. It needs a _lot_ more clarity of where you are in the process, what's next, etc. There is a lot at stake here and one needs reassurance that he/she is not messing anything up.

Also, modifying the application introduces a long turn-around (the system needs to re-generate the documents). In perspective, a couple of typos cost us 3-4 days in the process.

Side note: signing the paperwork with my trackpad on docusign makes signatures look like a 3-year-old has signed the contracts. It would be great to be able to upload a scanned image of my signature (granted, this is a docusign limitation).

<comment><USER5> There are many paths you can take if it's a human touch that you are after but none of those will get you there for $500. If you think Atlas could better explain that then I agree with your comment but I never once got the impression that there'd be any hand-holding along the way.

<comment><USER4> A simple live webchat on the dashboard would go a long way, for example. If you haven't done this before (and know the pitfalls of wrong decisions at this stage), the process seems deceivingly easy. A good example on how to do this right might be Credit Karma's Tax product - amazing (& proactive) guidance along the process.

</comment></comment></comment><comment><USER6> For simple e-commerce websites, Stripe is a fantastic and simple option. If you're trying to do anything remotely interesting with money, Stripe probably isn't for you. Stripe rejected two of our applications for a standard Stripe usage, and they rejected another of our applications for Stripe Atlas. All three applications were completely separate products, using payments in different ways from each other.

They told us that our two applications interfered with their acceptable-use policy[0]. The application for Stripe Atlas was rejected because it interfered with the goals of Stripe's bank(s).

Stripe isn't in control of how their product is used, their product exists almost entirely at the whim of the banking network which Stripe depends on. In my experience, I have learned to avoid Stripe for any use-case which isn't a simple E-commerce site. Stripe is incredibly limiting and, evidently, their primary goal is to avoid risk at the expense of innovation.

We ended up folding all three products, and are considering rejuvenating the third product with cryptocurrency payments instead of dealing with credit cards and banking networks. No doubt, using cryptocurrency payments for our application would be simpler and less limiting. It would just be us and our customers at that point, which is how it should have been all along.

[0] [https://stripe.com/us/prohibited- businesses](https://stripe.com/us/prohibited-businesses)

<comment><USER7> > We ended up folding all three products, and are considering rejuvenating the > third product with cryptocurrency payments instead of dealing with credit > cards and banking networks.

So does it mean the problem was not Stripe, but you could not get account in any of the payment processors due to the nature of your product?

<comment><USER6> Braintree supported two of our apps. We didn't try with the third.

</comment></comment></comment><comment><USER8> I created a business through Atlas this spring, and it was great. The community aspect is really cool and active (it's basically a forum of other Atlas founders).

</comment><comment><USER9> I used Stripe Atlas earlier this year to incorporate Chatdog ([https://chat.dog](https://chat.dog)) and it has been a good experience so far. Stripe's customer support is responsive and helpful. I'd highly recommend it!

</comment><comment><USER10> I always worry about legal implications. Living in California, the legal advice I see always tells me to incorporate in my state of residence. Could having a Delaware LLC be seen as tax evasion by the IRS or the Franchise Tax Board?

<comment><USER11> It's totally legal and normal to start a corporation in any state in the US you choose and Delaware is by far the most common for tech companies.

However, California is especially tax-hungry and will penalize you for doing this if you live here. If you choose to register in another state instead and thus avoid the $800 CA fee, they will just charge you an $800 foreign corporation tax (minimum) for "operating" in California anyway.

<comment><USER12> > If you choose to register in another state instead and thus avoid the $800 > CA fee, they will just charge you an $800 foreign corporation tax (minimum) > for "operating" in California anyway.

I did not know that. Just found this regarding what you've stated. [https://www.lexology.com/library/detail.aspx?g=d29c2a6b-4422...](https://www.lexology.com/library/detail.aspx?g=d29c2a6b-4422-490f-addc-1044c5c0358e)

How is the "operating" state determined for 100% online business, ex: a job board.

</comment></comment></comment><comment><USER13> Most people outside the US are probably committing tax fraud in their home country.

I suggest you take some legal counsel.

CFCs/POEMs/TIEAs will get you busted in no time.</comment>


Idris - pure functional programming language with dependent types - <AUTHOR> http://idris-lang.org/ <comment><USER2> Very nice, haven't heard of this before. I think an ideal target for a dependently typed language is scientific array programming, so that you can ensure the sizes of your matrix and array operations check out before performing long-running tasks. If a good array library can be built (e.g. port Haskell's Repa) then it might provide a great foundation for this.

<comment><USER3> With type level naturals recently added to GHC, statically checked arrays are already implementable in Haskell.

* <http://hackage.haskell.org/package/vector-static>

* <http://hackage.haskell.org/package/hmatrix-static>

A nice next step would be to optimize out additional runtime bounds checks.

<comment><USER2> Very nice! I really look forward to using something like that.

</comment></comment></comment><comment><USER4> I love the concept, but the tutorial somewhat puts me off (admission: I only read the first third).

I mean, using an "element from a finite set" to index a vector? Back home, we use natural numbers for that. Idris _also_ has natural numbers, but somehow we still have to, essentially, use the "finite set of values we don't care about, but that we can order if we want to since, after all, the set has a finite number of elements" concept for what's essentially an array lookup.

Why can't there be a type of "natural numbers under N"?

Or am I all misunderstanding things, and _is_ the "finite set" exactly that type, just explained in a very not straight forward way?

Also, impressively, the author claims it has C-style speed. Does that mean that looking up a value in a vector by means of an element in a finite set is actually translated to a single *(vect+index)? (in C-terms)

<comment><USER5> That is indeed exactly what Fin is. The first n natural numbers is a finite set of n elements after all. I'll elaborate a bit in the tutorial. I guess the trouble with writing a tutorial when you're completely familiar with a language is that it's hard to know what will and won't make sense!

There'd also be nothing wrong to use a natural number, along with a proof that it's bounded by the length, to index the vector.

I don't think I've claimed it has C-style speed anywhere. At least, not in general - we have observed it in some cases though, and it is a goal to make it as efficient as possible. Dependent types plus partial evaluation gives you some nice opportunities for optimisation. Early days yet...

<comment><USER4> _That is indeed exactly what Fin is. The first n natural numbers is a finite set of n elements after all._

Ah, right! I must admit that it feels like an odd definition to me indeed. I see how "the first n natural numbers" is a finite set of n elements, but I don't see how the reverse is true. I mean, look here, a finite set of n elements: {1, 1, 1, 1}. 4 elements, and they're all valued 1. They're also not ordered. So your concept of taking an element from a finite set (in this case, let's say, 1, or maybe 1 instead) to uniquely identify an element in a vector sounds a bit odd to me :-)

Clearly, I'm the noob here, and maybe in this stage Idris just isn't meant for people not on Lambda the Ultimate, but if not, it's good that you intend do something about it :-)

Cause once again, I love the concept, and I'd love to program with this.

<comment><USER6> The set {1, 1, 1, 1} has only one element, 1.

<comment><USER4> Oh fuck. Bags and sets.

I'm an idiot!

And that only 3 years out of university :-(

</comment></comment></comment></comment></comment><comment><USER7> Down for me, google cache: [http://webcache.googleusercontent.com/search?q=cache:dtmf_mG...](http://webcache.googleusercontent.com/search?q=cache:dtmf_mGqwA4J:idris- lang.org)

<comment><USER5> Sorry about that, it's back now...

</comment></comment><comment><USER8> Is this, by any chance, specifically tailored to programming control systems for time machines[1]?

[1]: <http://tardis.wikia.com/wiki/Idris>

</comment><comment><USER9> Am I correct in my understanding of these types?

      Vect a n = vector of a with known length n
      (n ** Vect a n) = vector of a with unknown length n

When I think of it this way it's obvious why filter takes a Vect and returns a pair. Though it seems ugly to have to write each vector function to take both "static" and "dynamic" vectors.

<comment><USER5> That's right.

You don't normally need to write each vector function both ways. If you can statically know the length (which you normally do in practice, at least in my experience) then you can write down a more precise type. filter serves as an example of what you might do when you need to compute an index dynamically.

</comment></comment><comment><USER10> This looks really cool. I haven't looked into dependently typed languages in depth, but this is the first one I've seen that looks like a programming language to write programs in.</comment>


Regin: Top-tier espionage tool enables stealthy surveillance - <AUTHOR> http://www.symantec.com/connect/blogs/regin-top-tier-espionage-tool-enables-stealthy-surveillance <comment><USER3> The list of infected countries might tell us a thing about the attacker:

Russia and Saudi Arabia at the top: classical US intelligence targets. Pakistan and Afghanistan: Likely anti-islamists effort. Austria, Belgium, Iran: Opec, IEAE, tons of EU-institutions - someone who wants better intel about the nuclear talks with Iran?

Ireland, Mexico, India: Hard to find political reasons for those countries, but if you look at it economically: Ireland is the main hub for US companies into the EU, Mexico is a neighbouring country to the US, India: rival to China

My totally far-fetched guess would be that this trojan comes from the NSA or the GCHQ, I don't see China caring that much about Saudi Arabia and AfPak.

<comment><USER4> It's funny to me that we posit attackers building malware of such sophistication that they can only be nation-state in stature, while at the same time supposing that they know so little about the AV industry that they could be revealed by a heat map of the countries their malware was spotted in.

How about: it's Russia, Russia doesn't care about infecting hosts in its own country (in fact, they may prefer to do so; those might be their targets), and, while Russia surely does have an aggressive program of intrusions into the US [and China], they don't use this particular piece of malware to execute it?

I have no reason to believe it's Russia. I just think: that story is as plausible as the others being tossed around this thread.

If I have a bias about the origin being the US, hand to God, it's that I'd like to believe my tax dollars can pay for better malware than this. I have, for what it's worth to the thread, absolutely no doubt in my mind that the US has _stuff like this_ in the field.

I'd really like to believe it was Latvia.

<comment><USER5> Expectedly, tptacek is all over the infosec thread, arrogantly dissuading the public from the notion of a possible involvement of the US intelligence community :)

<comment><USER6> Actually he's attempting to dissuade people from leaping to conclusions based on little-to-no data and their own biases.

He doesn't say it's not the US, he just says that the data is not enough to support that conclusion.

It might be time for another HN article on Bayes' Theorem.

</comment></comment></comment></comment><comment><USER7> [Edit: I missed the PDF whitepaper before writing this comment. It doesn't answer all my questions bit I'll give them credit for a really nice detailed whitepaper.]

This article makes me very suspicious of Symantec. How long have they known about this, really? Are they just releasing this information now as a marketing reaction to recent discoveries by competing firms?

The vaguely written timeline says in passive voice that Regin has been observed since 2008. By who? Why are we just hearing about it now? I wouldn't blame them for keeping some discoveries quiet for a while so they can do some stealth research, but the timing here really smells like they are being PR driven instead of being driven by doing what's best for the overall security community.

What would inspire much more confidence would be a story of how this was discovered, and how the discovery and research played out, as we have seen for some other malware. Instead this looks like they have know about this for a long time, and now for reasons they aren't going to disclose, they have decided, or have been given permission, to reveal some of what they know.

<comment><USER8> > Why are we just hearing about it now?

Once malware is identified properly antivirus firms will usually go through their detection archives and pull out earlier hits.

The reason why they don't see them sooner is because they get tends to hundreds of thousands of new threats each week and don't have time to go through each one.

Mikko from F-Secure also reported on Twitter that they found Regin[0]. The same thing happen with Stuxnet, and just about every other malware - it is why these firms will keep and check the archives of new detected threats.

As for your general suspicions, this is endemic with infosec since there is a natural conflict of interest where those doing the research and reporting on it are also selling solutions.

If it makes you feel any less suspicious, the research departments within these antivirus firms are generally isolated from parts of the companies involved in sales and marketing. They are usually small teams that just go out and publish information on cool things they find - although there is often a race to be the _first_ to dissect and publish the details of new malware (which is why you wouldn't sit on knowledge of a new threat).

[0] [https://twitter.com/mikko/status/536624310035939328](https://twitter.com/mikko/status/536624310035939328)

<comment><USER9> _The same thing happen with Stuxnet, and just about every other malware - <USER2> is why these firms will keep and check the archives of new detected threats._

My favorite is how Stuxnet was discovered just after Win2000 ended support.

So what made Symantec, McAfee, etc so horrible BTW?

</comment></comment></comment><comment> vezzy-fnord On a less related note, beyond the shiny GUI layer, just how advanced is today's antivirus software anyway?

Do they still primarily rely on signature detection? I know that modern systems also perform what's broadly titled "heuristic analysis", but I'm not sure what that specifically entails. Is there any form of system call tracing, sandboxing, file monitoring or what?

<comment><USER10> Heuristics look at what a process is doing. For example, a very simple heuristic rule may look like this:

if a process does the following:

       Open another .exe file then

          Writes to that .exe file

             Close that .exe file

Then it's a virus.

Such 'rules' are then used by the detection engine of the anti-virus software, if a program triggers any of these rules it is often labeled as a 'generic' Trojan or virus. Often this tracking is achieved by 'hooking' syscalls of your operating system. But some anti-virus programs also employ emulation and/or sandboxing. Comodo is an example that does sandboxing.

Recent developments in anti-virus are what's called 'host-based protection'. Instead of relying on blacklists, such as heuristics and signatures, a custom made 'profile'(whitelist) of the host is made which looks at which applications are installed and what they should be doing. For example: your browser should never attempts to start another process. If it does it means something is wrong.

Such host based approaches can detect unknown threats/exploits as they happen. If your browser is exploited and tries to download and execute malware, the system will detect it because it was previously established that your browser has no business starting other applications.

</comment></comment><comment><USER11> This is equally fascinating and terrifying. The infection vector is still unknown, and they haven't even been able to recover the 64 bit version.

Neither China nor the USA is among the ten countries with most infections.

<comment><USER12> The infection vector is most certainly dynamic and varies by case and with time. Just need a fresh zeroday to make target machine execute the dropper.

</comment></comment><comment><USER13> >>> Its capabilities and the level of resources behind Regin indicate that it is one of the main cyberespionage tools used by a nation state.

Wow. Just wow.

It should not surprise us, but I wonder what the reaction was when people first realised telephones could be and were being tapped?

<comment><USER14> I remember enjoying this blog post on AT&T's amicus brief in the _Olmstead_ case:

[https://www.eff.org/deeplinks/2007/08/how-ma-bell-fought- you...](https://www.eff.org/deeplinks/2007/08/how-ma-bell-fought-your- privacy-80-years-ago)

The most awesome comment from AT&T was that "this telephone system offers a means of espionage to which general warrants and writs of assistance were the puniest instruments of tyranny and oppression".

<comment><USER13> This is pretty good for the 1920's

[I]t is better that a few criminals escape than that the privacies of life of all the people be exposed to the agents of the government, who will act at their own discretion, the honest and the dishonest, unauthorized and unrestrained by courts

Yes.

</comment></comment></comment><comment><USER4> _and alternative encryption in the form of a variant of RC5, which isn't commonly used_

RC5 is uncommon because it's a crappy old 1990s cipher. If its use is suggestive of anything, it's probably cryptographic incompetence.

<comment><USER15> Let's not jump to conclusions. If Symantec's characterization of the sophistication of this malware is accurate, then surely they could have afforded some crypto expertise.

First, can we agree that any encryption algorithm better than a Caesar cipher is good enough _for this particular application_? That's because nobody who's analyzing this malware is going to bother with cryptanalysis because there's an easier approach. The encrypted data has to get decrypted before it runs. Therefore, you watch the execution with a debugger until it gets decrypted and executed, and then just capture the plaintext data (and the key if you want).

Given that resisting serious cryptanalysis is off the table, I can suggest several reasons for RC5:

\- It has much smaller code size (500 bytes vs 15000 for AES).

\- It's less vulnerable to fingerprinting. That is, anti-virus software might have checks for AES but not RC5. The malware writer would _know_ this because they actually tested their malware against all the anti-virus products and found that none of them have signature or heuristic checks for RC5 but do against AES. (I'm just fleshing out the thought; I don't know if AV software checks for AES and RC5.)

\- AES runs faster than RC5 in general, but maybe the particular platform or instruction set for this malware makes RC5 faster.

<comment><USER4> I'm having trouble parsing this comment. Your suggestion is that the author is sophisticated _and that 's why they chose RC5_? RC5 is a broken 1990s cipher. If the authors wanted to minimize code size, they'd have used a native stream cipher, not a 64-bit block cipher.

I'm also having trouble with the idea that the author of this trojan might be GCHQ or NSA (or sponsored by them), but that cryptanalytic techniques from the late 1970s are off the table.

<comment><USER15> > _the author is sophisticated and that 's why they chose RC5_

I'm saying that because the author is sophisticated, they know that the strength of the algorithm doesn't matter (so long as it's not something ridiculously simple).

DES, AES, RC5, RC6, whatever. They're all good enough because Symantec (or whoever is analyzing the malware) is going to get the plaintext no matter what. Symantec is not going to do any cryptanalysis whatsoever. Symantec is going to run the sample malware in a debugger and watch it get decrypted. The malware _must_ decrypt itself in order to run.

<comment><USER16> The malware must decrypt _the parts_ that it runs. (There's an obfuscation technique that's apparently quite strong in existence, but it produces gigabyte executables for simple 5-condition if statements you can brute force by hand, so it's ludicrously impractical.)

This could be worse. It could have encrypted routines for which the commands are the decryption keys. It doesn't appear to be particularly polymorphic. If there's a BIOS/PCI dropper, it's (sadly) long gone here.

</comment></comment></comment></comment></comment><comment><USER17> I think the thing that's most frightening here is that those who created this thing have had 6 years to iterate and improve on the design before being discovered, so what has been found may just be the tip of the iceberg.

</comment><comment><AUTHOR> "As always, attribution is difficult with cases like this. Our belief is that this malware, for a change, isn't coming from Russia or China."

[https://www.f-secure.com/weblog/archives/00002766.html](https://www.f-secure.com/weblog/archives/00002766.html)

"Securelist - Regin: Nation-state ownage of GSM networks"

[http://securelist.com/blog/research/67741/regin-nation- state...](http://securelist.com/blog/research/67741/regin-nation-state-ownage- of-gsm-networks/)

</comment><comment><USER18> Amazing how Symantec use this to push their software rather than providing even a clue to determining whether you're infected or not. Never miss an opportunity to cash in, I suppose.

<comment><USER19> There are some details in the whitepaper.

I don't think this post comes off as an attempt to make more money.

Rather, I think it's applaudable that they release information on threats from governments (and not only traditional spyware/virus).

Since this is (probably) built by a government, one can be certain that a government somewhere (presumably Western, given the infected countries) is upset about the release. And they didn't cave in to that, which is good.

<comment><USER20> I would guess they didn't cave because no Government has registered their upset at this. If they did, it would be pretty clear which Government it was - making me think the Government in question has few levers to pull against Symantec.

<comment><USER21> I disagree. Symantec is one of the few companies on the planet that has had to deal with this exact situation before: Stuxnet.

By late 2010, Synametic had come to the conclusion that Stuxnet was most probably a joint US/Israeli malware project, designed to disrupt Iran's quest for a nuclear bomb. [1]

Just try and imagine that the gravity of that moment. They had stumbled into an international covert action involving weapons of mass destruction. I mean the closest thing I can even compare this with is fiction (the "too many secrets"/"using the magic box" scene in the movie Sneakers). But this wasn't fiction, and Symantec researchers and management had to decide what to do.

They could have just shut up and said nothing. After all they were a US company, forbidden by law to even to do business in Iran. But they didn't do that. Rightly or wrongly, they published their findings in a whitepaper and told the world about it.

I think Synmantec has earned the benefit of the doubt when dealing with state sponsored malware.

[1] [http://www.wired.com/2011/07/how-digital-detectives- decipher...](http://www.wired.com/2011/07/how-digital-detectives-deciphered- stuxnet/all/)

</comment></comment></comment></comment><comment><USER22> How are these things named?

Is "Regin" or "Stuxnet" a string somewhere? Do the researchers make the names up?

(And, what do the creators think of the name their tool is given vs. what they called it.)

<comment><USER8> Stuxnet: named for files .stub (where config was stored) and mrxnet.sys (main driver), by Microsoft

Duqu: named for the "~DQ-" temporary files it created, by researchers in Hungary who found it and wrote report

Flame: is from a routine called "InstallFlame", so the malware name is likely same between discoverers and writers.

The naming convention is usually to find a unique identifier used in the malware. Portmanteau's are common. We often don't find out what the writers name was, although both Stuxnet and Flame were part of Operation Olympic Games[0]

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

</comment></comment><comment><USER23> Nice story.

But this is HN: Now how do we ensure our servers are unaffected?

<comment><USER24> Looking at the PDF it appears that it's Windows specific.

<comment><USER25> Exactly. I read through the page twice trying to simply determine "is this interesting to me at all".

No, it's not. As usual, you can thwart "nation state" malware by simply not running Windows.

Wake me when there's malware for FreeBSD (seriously - it would change my world).

<comment><USER11> I'm sorry, but this seems incredibly naive. Stuff like this, which is apparently used against designated targets, surfaces because Symantec and similar companies casts an incredibly wide net looking for odd stuff in the wild.

Few does this at a large scale for Linux, and I guess nobody does it for FreeBSD. But just because noone has caught sophisticated malware from a nation state in the wild doesn't mean it isn't there. So even if the code doesn't apply to you, the determination this shows from the attacker, would if you have something to hide.

Do you seriously expect the NSA (or their chinese counter parts) just to give up and go home if a target they are interested in happens to use something else than Windows?

<comment><USER25> No, no ... certainly running a non-windows OS does not protect you from the actual nation-state.

But the takeaway here is how we should update our threat levels and paranoia levels as a result of this new knowledge.

In this case, as usual, it appears to be "not much".

</comment></comment></comment></comment></comment><comment><USER26> So... Symantec found this years ago. New version is out. Symantec is allowed to publish the "news"...

</comment><comment><USER27> That kind of information should be published by the CIA, FBI, NSA, ... themselves instead of destroying Democracy with their secret gag orders. "I'm not allowed to say that I'm not allowed to say anything". Can it still get worse than it already is? Any random terrorist is more honorable than the Feds. At least they're not lying about being terrorists.

</comment><comment><USER28> No five eyes in that list.</comment>


Tell HN: Vancouver, Canada Startup Hackathon Oct 8-10th - <AUTHOR>

Vancouver Hackers: I will be hosting a 100% free startup hackathon/startup weekend-style event October 8th through 10th at The Network Hub in downtown Vancouver.
Other events want to charge $75 per person to attend but we think money adds a big barrier for many hackers (especially those in college/university). If you're interested and free that weekend, I've setup a simple form to gauge interest and see if we can fill up the space.
We will be working out beer and caffeine sponsors but everyone will be responsible for their own food/snacks. The location is right on the edge of Gastown, endless options for places to eat and drink. We're also above a 24 hour Waves Coffee and right across the street from a Blenz Coffee.
Please apply if you can come out for the whole weekend. You can pick up a new project or work on existing ones in a great environment.
I've had a quick chat with Colin Percival (cperciva) and he will be coming out on Saturday night to give a talk.
Event page: http://verev.com/vancouver-hackathon/ <comment><USER2> _I've had a quick chat with Colin Percival (cperciva) and he will be coming out on Saturday night to give a talk._

I'm not 100% certain what the talk is going to be about yet, but I'll be there and speaking about something. :-)

I may also be able to stick around to provide some free security / cryptography consultation if there's any interest.

</comment><comment><USER3> OK. So, I just put together that this event is competing head-to-head with Startup Weekend. <http://vancouver.startupweekend.org>

That seems a little rude. I'm with you that $75 tickets are steep, and hacker unfriendly, but it seems like 2 competing hackathons are going to spread our city's finite dev talent really thin. I can't see how this leads to a better experience for SW or your event.

Wouldn't it be better to have spread these events out? If people think SW is too expensive, they'll wait. If they want to contribute to both, shouldn't they have the option?

<comment><USER4> Hmm... definitely agree with nick. The hacker community in Vancouver is already so small that there's no need to do both on the same weekend.

I also agree $75 is quite steep, so I've talked to the SW folks about working together somehow & getting a better discount for scrappy entrepreneurs & hackers (while preserving the high $75 for business & "marketing" folk who tend to hijack hacker events here in Vancouver). They're all for it!

So far, we got a 20% discount off for Startup Digest readers (code: startupdigest), but I'm sure we can get even more.

</comment></comment><comment><AUTHOR> Clickable link: <http://verev.com/vancouver-hackathon/>

If you're not from Vancouver, please pass on the link to any friends you may have up here.

</comment><comment><USER5> Hmmm, sounds like it's going to be right before I launch my App. Might be a good way to get some feedback and meet other hackers.

</comment><comment><USER6> Applied. Sounds like a great opportunity to meet some other hackers from around Vancouver.

</comment><comment><USER3> Nice work, Michael. The city needs more events like this.

</comment><comment><USER7> This event... it was made for me!

<comment><AUTHOR> I look forward to seeing you there :)

Do you mind passing this around to other Vancouver hackers you know? I posted this at a terrible time and it fell the off the homepage already (huge fail on my part).

<comment><USER7> Damn. I'll do what I can.

</comment></comment></comment><comment><USER8> I'm back in the UK for 2 weeks out of the last year and I miss this. D'Oh.

<comment><AUTHOR> Based on the feedback we've gotten so far, a lot of people are interested in this kind of event. If everything goes well we will definitely be doing something similar again in the future.

<comment><USER8> Great to hear!</comment></comment></comment>


Google Scanned Objects by GoogleResearch - <AUTHOR> https://app.ignitionrobotics.org/GoogleResearch/fuel/collections/Google%20Scanned%20Objects <comment><USER2> Who knows what tool they have used to create those models ?</comment>


When cops become robbers - <AUTHOR> http://www.bbc.com/news/resources/idt-sh/when_cops_become_robbers <comment><USER2> This does not surprise me at all. The corrupt politicians of Baltimore destroyed the PD years ago. I personally know people who left that PD and started new careers elsewhere (leaving policing altogether) because they didn't want to be part of a dirty organization.

Baltimore probably needs to do what Camden, NJ did and rebuild the PD from scratch.

[https://world.wng.org/2018/03/camden_s_new_day](https://world.wng.org/2018/03/camden_s_new_day)</comment>


Coronavirus pandemic threatens to knock $1T off global economy - <AUTHOR> https://www.newscientist.com/article/2235697-coronavirus-pandemic-threatens-to-knock-1-trillion-off-global-economy/ <comment><AUTHOR> Why governments around the world do not invest in pandemic preventions?

Wouldn't it be better to invest let's say 100 billion rather than losing a trillions?</comment>