3D interfaces are usually worse than 2D interfaces - <AUTHOR> https://www.facebook.com/permalink.php?story_fbid=2407256322842204&id=100006735798590 <comment><USER2> I've been working in AR/VR for a few years now and fairly convinced of this. In fact, beyond the OS interlace I'd say this is true of presenting most data. The usefulness of most interfaces is that they abstract something real. Part of the value of abstraction is the removal of most the extraneous aspects of a problem. Removing a whole dimension removes a lot of data that may be extraneous.

Maps are one very good example of this. A map is partially so powerful because it removes a ton of information you probably don't care about. Occasionally would you like to know a house is up a steep hill before you drive there? Sure. But most of the time who cares. And if you really need elevation data, there's a special map for that. A map which actually shows you information about grade in much clearer way than even a 3D model would (being as humans are actually really bad at guessing a grade by looking at a real slope).

<comment><USER3> I think it's more than that. As Carmack observes, you don't _see_ in 3D. You see two 2D planes that your brain extracts a certain amount of depth information from. As a UI goes, you can't actually freely use that third dimension, because as soon as one element obscures another, either the front element is too opaque to see through, in which case the second might as well not be there, or the opacity is not 100% in which case it just gets confusing fast.

You've really got something more like 2.1d to work with with humans; intefaces need to take that into account, and maybe sometimes use that .1d depth dimension to provide light hinting, but not depend on it.

So you're not _removing_ a dimension... you're _acknowledging it doesn 't exist._ There isn't really a "third dimension" here to take advantage of. It may be visually impressive if something flies from far away to up close, but in interface terms, all that has happened is that the z-buffer values shifted, but the interface still has the same number of square radians available that it did before.

The depth information is a lot more like an additional color than an additional spatial dimension. UIs are _better_ with color hinting available when used well, but there's not much _fundamental_ difference between a color 2D interface and a monochrome 2D interface. Proof that it isn't much is that there are some people who use settings to set their phone to monochrome, and the result is at worst occasionally inconvenient, not crippling. Compare with trying to go from a 2D interface to a 1D interface, which would be utterly crippling and destroy a huge swathe of current UI paradigms.

To truly "see in 3D" would require a fourth-dimension perspective. A 4D person could use a 3D display arbitrarily, because they can freely see the entire 3D space, including seeing things inside opaque spheres, etc, just like we can look at a 2D display and see the inside of circles and boxes freely. They have access to all sorts of paradigms we don't, just like no 2D designer would ever come up with a "text box", even though it fits on the 2D plane, because no 2D user could see inside the text box to see what's in it.

(This is one of those cases where the mere act of typing it out improved my understanding of the topic. I didn't have the "depth information is really just another color" idea going in, but the more I think about it the more sense it makes, in terms of the amount of information that channel can carry. Just like color, it's not quite 0, but you can't really stuff _all_ that much in there.)

<comment><USER2> True, almost any interface that overlaps helpful data in layers or stacks is usually terrible. Hell, I don't even like desktop computer GUIs that allow you to have stacks of windows. I'd rather see one thing at a time and cycle between them. Or have a picker view.

That said we do actually get quite a bit out of that ability to see depth. People who lose depth perception have quite a hard time adapting to the world. And our spatial understanding seems to go beyond our vision. That to me is where a 3D interface might be really powerful. Sometimes things which we struggle to decode in 2D are just intuitive in 3D like knots or the run of wires or pipes.

As I said elsewhere in this thread I think the 3D interfaces that are really going to be powerful haven't occurred to us yet. And I believe that what we'll find in time is that there are things which 3D interfaces are tremendously advantagous for and using anything else will feel like a hinderance. But those will be things for which 2D interfaces don't already do an amazing job.

<comment><USER3> Carmack already mentioned the existence of "true 3D" content, for which you get a 3D interface whether you like it or not, so to speak, so I didn't go into that.

But making everything 3D, because VR, is as silly as when the gaming industry made everything 3D, resulting in entire console libraries full of games that looked like shit even at the time, pushing 4 or 5 frames per second and having other incredible compromises, when the same consoles are monsters of 2D performance. As nice as it may be to have truly 3D content available in psuedo-real space, there's no reason to insist that when you want to set the shininess of a given pipe that you need a huge skueomorphic switch as big as an old car stick shift that you can visibly pull popping out of your UI or something when all you need is a slider. (If anything, I'd think minimalism in a VR environment is a good idea, both to contrast the other content and to prevent detracting from it.)

I think that's probably the kind of crap Carmack is complaining about. We've already been around the same loop a couple of times already, and 3D, albeit on 2D surfaces, was one of them, so it's fair to look to the past instances of such BS and maybe this time try to move along the curve a bit faster. I'd say that if we can get this nonsense out of the way faster rather than slower, we're more likely to get to the truly useful 3D stuff that doesn't exist yet. Otherwise we risk 3D interfaces becoming something like the Wiimote, which IMHO was actually a really useful tool that has become despised solely because it was badly misused by so many games, because motion controls. (Another example we've already been through.)

<comment><USER4> Your points are excellent, classic.

One other hypothetical use of a 3D interface is as a way to conceptualize "true N-dimensional" data. A 3D experience indeed doesn't help any rational conceptualize of a rational situation but it might, maybe, allow you to mobilize the unconscious reflexes humans have for dealing with regular 3d space. But all this might also a 90s cyberpunk fantasy.

</comment></comment></comment></comment></comment><comment><USER5> I recently posted some comments by Dave Ackley about 2D versus 3D, which I'll repeat here:

David Ackley, who developed the two-dimensional CA-like "Moveable Feast Machine" architecture for "Robust First Computing", touched on moving from 2D to 3D in his retirement talk:

[https://youtu.be/YtzKgTxtVH8?t=3780](https://youtu.be/YtzKgTxtVH8?t=3780)

"Well 3D is the number one question. And my answer is, depending on what mood I'm in, we need to crawl before we fly."

"Or I say, I need to actually preserve one dimension to build the thing and fix it. Imagine if you had a three-dimensional computer, how you can actually fix something in the middle of it? It's going to be a bit of a challenge."

"So fundamentally, I'm just keeping the third dimension in my back pocket, to do other engineering. I think it would be relatively easy to imaging taking a 2D model like this, and having a finite number of layers of it, sort of a 2.1D model, where there would be a little local communication up and down, and then it was indefinitely scalable in two dimensions."

"And I think that might in fact be quite powerful. Beyond that you think about things like what about wrap-around torus connectivity rooowaaah, non-euclidian dwooraaah, aaah uuh, they say you can do that if you want, but you have to respect indefinite scalability. Our world is 3D, and you can make little tricks to make toruses embedded in a thing, but it has other consequences."

Here's more stuff about the Moveable Feast Machine:

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

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

The most amazing mind blowing demo is Robust-first Computing: Distributed City Generation:

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

And a paper about how that works:

[https://www.cs.unm.edu/~ackley/papers/paper_tsmall1_11_24.pd...](https://www.cs.unm.edu/~ackley/papers/paper_tsmall1_11_24.pd..).

Plus there's a lot more here:

[https://movablefeastmachine.org/](https://movablefeastmachine.org/)

Now he's working on a hardware implementation of indefinitely scalable robust first computing:

[https://www.youtube.com/channel/UC1M91QuLZfCzHjBMEKvIc-A](https://www.youtube.com/channel/UC1M91QuLZfCzHjBMEKvIc-A)

</comment><comment><USER6> I think there is a severe lack of imagination going on here. A pencil is a 3D interface.

This is as good a time as any to post this eight-year old gem from Bret Victor: [http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi...](http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/)

<comment><USER7> > A pencil is a 3D interface.

Is it? I'd say the VR analogue of a pencil is a pointing device, which makes the user interface the VR analogue of _paper_. And paper is fundamentally a 2D interface. There are some 3D actions like turning a page, but those are secondary and rare. You can move and rotate the paper as a whole in 3D, and that's useful, but the same functionality can easily be added to VR 2D interfaces.

On the other hand, there are other types of art that are fundamentally 3D, such as sculpture and pottery – but both of those rely on feeling a 3D object with your hands, which partially bypasses the 2D limitation of vision, but isn't yet possible to emulate in VR.

Then again, there's also the common VR toy of a "pencil" that doodles in thin air, which is certainly interesting... though I'm not sure how well it generalizes to more abstract user interfaces. If you're using such a system, you have to constantly rotate the object you're drawing, and/or move your body around, in order to properly perceive the object in 3D. This is kind of a pain. If your primary goal is to create a 3D object, it's an unavoidable pain and the benefit is well worth it; but if what you're interacting with is just an abstract interface meant to manipulate something non-spatial, it's probably better to avoid.

<comment><USER8> > both of those rely on feeling a 3D object with your hands, which partially > bypasses the 2D limitation of vision, but isn't yet possible to emulate in > VR.

That's the entire point of the comment you're responding to and the reason for Dynamicland.

<comment><USER7> If so, it was off topic. John Carmack's post was about VR interfaces, and I interpreted the parent comment in that context. In any case, I would contest that bypassing the limitations of vision, specifically, represents a significant part of the reason for Dynamicland.

<comment><USER8> If you "would contest" that, it's because you _still_ haven't read the essay that was linked in the putatively off-topic comment you were "responding" to, _after eight years_. And, yeah, you could try to redefine "VR" and even "3D interfaces" (the _actual_ topic) as being strictly limited to "binocular video responding to a head tracker", but even "VR" researchers have been researching haptic and kinesthetic feedback from a zillion angles for a lot more than eight years, so I don't think it's off-topic at all.

</comment></comment></comment></comment></comment><comment><USER9> Yes... but no...

Resemblance to reality as UI design smell... Just because we have head tracking and stereo display, doesn't mean a UI should at all resemble reality. Years ago, when cell phones were new, and UI design was focused on onboarding novice users in an untrained culture, there was the idea of skeuomorphic ui design - the app should resemble the familiar physical thing. The calendar app should have lined pages, that flip around a spiral binding, surrounded by a textured leather margin. We don't do that anymore. It would be silly. As is 3D UI's resembling "spear chucking" reality. So yes, tossing xterms in the air, and 3D UI's that resemble VR games, are both common and bad ideas. Quietly assuming VR-gaming-like things cover the entire 3D UI design space, and drawing conclusions built on that assumption, is another common and bad idea.

> Splitting information across multiple depths is harmful

Frequently jumping between dissimilar depths is harmful. Less frequent, sliding, and similar depths, can be wonderful, allowing much denser and easily accessible presentation of information. I so wish my laptop had a native 3D display... DIY anaglyph and shutter glasses are a pain.

A general takeaway is... Much current commentary about "VR", is coming from a community focused on a particular niche, current VR gaming. One with particular and severe, constraints and priorities... that very don't characterize the entirety of a much larger design space. And that community, and commentary, has been _really_ bad at maintaining awareness of that. So it's on you.

<comment><USER10> Do you have links to example 3D UIs that you're talking about?

<comment><USER11> Not OP but the team at Leap Motion [1] has some very interesting demos. 3D UI's re-imagined from the ground up. Weirdly, because now everything is 3D, the best you can do is try to mimic actually 3D things perhaps, something that didn't work in 2D at all?

[1] [https://www.youtube.com/watch?v=7m6J8W6Ib4w](https://www.youtube.com/watch?v=7m6J8W6Ib4w)

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

<comment><USER9> They're fun demos. And perhaps from the perspective of say mobile, they're kind of reasonable. Rotating your wrist? Waving your arm to press a button? Waving your arm to move a window? Not all that odd when holding a phone.

But from the perspective of laptops/desktops? What comes to my mind is: RSI; slowwwww, but maybe it's the touchpad version of a standing desk?; people use tiling window managers in part because waving a finger to place windows in 2D is _already_ too burdensome.

I've just now failed again to find nice video, but if you've ever seen it, picture a professional artist tooling along on a Cintiq at insane speed. Stylus, and two handed multitouch flying. Zipping through enormous menus. Twitch gesturing through radial menus. Stylus input with pressure and tilt and rotation. Now imagine that interactive area was several centimeters high. And imagine transparent layers of content above the screen (you might sort of get a feel, by moving a semi-transparent window in front of another, and switch between reading one and the other, back and forth). Imagine a 3D visual environment extending below and above the screen. And around it, throughout the room. Now imagine your keyboard does multitouch, and instead of art, that's your code.

</comment></comment></comment></comment><comment><USER12> John Carmack:

> Last year, I argued that cylindrical panels were surprisingly effective, and > we should embrace them for VR Shell UI. There was a lot of push back about > giving up the flexibility of putting UI wherever you want in 3D, and > curtailing the imagined future world of even more 3D interfaces, but the > argument for objectively higher quality with the native TimeWarp layer > projection kept it from being a completely abstract design question.

Perhaps something similar to this in 2D interfaces: I miss the original iOS' embossed buttons with highlights and shadows that made their clickable-ness clear, and find the text links we have now inferior. Older people I know who have used iOS from the beginning also lament this change.

<comment><USER10> Yes, many modern UIs are anti-UX dark-patterns of past.

</comment></comment><comment><USER13> I worked in a media tech lab that experimented with how to tell stories in VR. The truth we encountered was that there was very little that VR did to enhance storytelling. There's a lot of hyperbolic arguments that sound good, but don't pan out in practice.

Reading Carmack's argument does make me wonder how much is objectively true and how much is because we're trying to bootstrap a generation of 2D interface users into 3D. Will this be one of those things that a generation of kids raised in VR will roll their eyes at? I don't know.

</comment><comment><USER14> I generally agree.

I like keyboard interfaces for non-spatial input over a mouse because fingers require less effort to move than arms and wrists. They can also move faster. These problems are made worse in 3D.

I see 3D being useful in 2 cases:

1) Adding depth allows more keeping of context. This is similar to zooming in and out by pinching to keep the context. But with 3D you lose less peripheral view and occlude less of the surround content. Our brains are better wired for spatial processing in 3D.

2) Fitt's Law predicts that the time required to rapidly move to a target area is a function of the ratio between the distance to the target and the width of the target. By adding another dimensions we can get objects closer and reduce the distance.

</comment><comment><USER15> Cylindrical panels, TimeWarp, Medium, Quill

What is he talking about? Do Facebook posts not allow links?

<comment><USER16> Cylindrical panels - I believe he's talking about positioning 2D surfaces along the inside of a imaginary cylinder centered around the user. Like this: [https://youtu.be/SvP_RI_S-bw?t=7](https://youtu.be/SvP_RI_S-bw?t=7)

TimeWarp - A technology for reducing percieved latency in VR. [https://uploadvr.com/reprojection- explained/](https://uploadvr.com/reprojection-explained/)

Medium - A VR sculpting app. [https://www.oculus.com/medium/](https://www.oculus.com/medium/)

Quill - A VR drawing app. [https://www.oculus.com/experiences/rift/1118609381580656/](https://www.oculus.com/experiences/rift/1118609381580656/)

<comment><USER17> I can't watch the video now, but does it explain why the inside of a cylinder rather than the inside of a sphere? This was my question after reading the OP; if you truly want the UI to be equidistant from a single point (the user's head) in two dimensions, it seems like a sphere is the obvious choice there.

<comment><USER18> My guess here would not be to have the entire interface equidistant from the user, but, rather, to have the equivalent of a wrap around monitor.

We're already used to having flat screens to interact with and simply curving the display doesn't, in my experience with a curved monitor, have any detrimental effect on your ability to view the display.

Beyond that, in a mathematical sense, a square and a cylinder are very topologically similar. Of note is that the relative size and shape of things on the surface are well preserved[1] as you don't need to significantly deform a square to turn it into a cylinder.

This is not the case for a sphere.

As a practical demonstration, take a piece of paper and draw some boxes on it before wrapping it around a reasonably sized ball. You'll see that the boxes (particularly the larger boxes) become deformed in a way that likely will make them seem to "bulge out". As far as I'm aware, the effect happens to any regular polygon wrapped around a sphere. The same thing will happen to any interface that attempts to project onto a sphere.

So, given that:

a) we're already used to flat interfaces

b) curving that interface into a semi-cylinder doesn't[2] have any detrimental effects

c) that traditional square interfaces don't map directly/cleanly onto a sphere

It's easy to conclude that a cylindrical interface is probably the simplest to make and easiest to understand interface. It requires the smallest amount of work to make and the least learning on the part of the user.

1: Obviously, things on the cylinder will be curved, but the 2 dimensional shape is still consistent.

2: for me, at least

</comment></comment></comment></comment><comment><USER19> I think most of us who get into data visualization go through a "3D all the things!" phase. I certainly did. But eventually I had to accept that the tradeoffs just aren't worth it. Occlusion is a serious problem. Our brains simply process 2D much more efficiently.

Obviously volumetric data is an exception.

</comment><comment><USER20> Well, yes. Ever since the old SGI 3D file browser [1], a true 3D interface approach has been terrible. Tilt Brush is probably the best success so far.[2] Even that, though, isn't very good for artistic work. It's just finger- painting in 3D.

Without force feedback, human positioning in 3D space is terrible. Maybe if we get usable VR gloves with force feedback, so you can grab a knob or lever and feel the movement, stops, and detents, it could be workable.

[1] [https://en.wikipedia.org/wiki/Fsn_(file_manager)](https://en.wikipedia.org/wiki/Fsn_\(file_manager\))

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

<comment><USER21> Check out this Smarter Every Day introduction to the HaptX force feedback glove from last year.[1] The guy thought VR was stupid until he used the glove, then was instantly immersed. They've packed a lot of sensory feedback into it.

Once force feedback hits, translating 2D onscreen control surfaces to 3D models will be both trivial and worthwhile, at least in the niche realm of virtual audio devices. Touchscreens have already made them much more playable, and things like TouchOSC allow for some customization. I'd love to have something like the Reason rack[2] in a space where I could use all 10 fingers instead of 1 mouse pointer to interact with it.

[1] [https://youtu.be/OK2y4Z5IkZ0](https://youtu.be/OK2y4Z5IkZ0)

[2] [https://images.app.goo.gl/37FMUZ6kfgTb5rPf6](https://images.app.goo.gl/37FMUZ6kfgTb5rPf6)

</comment></comment><comment><USER22> > Splitting information across multiple depths is harmful, because your eyes > need to re-verge (and, we wish, re-focus). > It may be worse in VR, because > you have to fight the lack of actual focus change. With varifocal we would > be back to just the badness of the real world, but no better. This is > fundamental to the way humans work.

This point on the eye focus changes caused while viewing 3D interfaces (as opposed to 2D interfaces) is a very well-founded one.

</comment><comment><USER23> the key is to use a 3d interface when the data is actually 3d, and only then. 3d: Level designing / modeling, physics, anything with spatial relationships 2d: Options menu, scripting and logic, numbers and info

since we read in 2d it's always going to be easier to parse

</comment><comment><USER24> He's right that changing your depth focus is more taxing, but I wonder what's healthiest for the eyes? Maybe it would be good to for the eyes to change focus depth while wearing VR headsets? If I stare at my monitor too long without breaks my eyes definitely get lethargic while trying to focus into the distance. (General tip: every 20 minutes stare at something at least 20 feet away for 20 seconds.)

<comment><USER25> Curved monitors are basically meeting the same need - to maintain the same focal depth as one looks side to side, shifting between windows, applications, etc.

I did find a few papers with a quick search that covers the topic for monitors. I would assume there is some carryover of any kind of finding about curved monitor ergonomics to the cylindrical view idea in VR.

See [https://pdfs.semanticscholar.org/d1c0/3f54a46b5fefc27b7a4207...](https://pdfs.semanticscholar.org/d1c0/3f54a46b5fefc27b7a4207fec7cf7634e6ea.pdf) and [https://www.tandfonline.com/doi/pdf/10.1080/15980316.2015.11...](https://www.tandfonline.com/doi/pdf/10.1080/15980316.2015.1111847) for example.

</comment></comment><comment><USER26> It's really interesting to see Carmack post this opinion (especially as it is two years old). I trust his insight and way of doing things, so it's fascinating to see even a glimpse of how he operates in a larger company where clearly their objectives and opinions won't always match his own.

I wonder in general if he's still bullish on Oculus (perhaps he is with VR in general though).

</comment><comment><USER27> I having been using the cylindrical layout shown here:

[https://arcan-fe.com/2018/03/29/safespaces-an-open-source- vr...](https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr-) desktop/

for a few weeks now - far from full time as the HMD display, lenses (CV1 here) and positioning/rotation tracking are not good enough with the open source driver but it feels really close. Except for some tweaking and extra "spacing" between the focus window and the side windows, it works exactly as I want it to. I added some customisation so the 'layers' do not exist at different depths but on different arcs on the same layer. Switching "workspaces" simply rotates these layers to the 12 o clock position. Biggest problem right now is not having front cameras to see what my hands are doing.

</comment><comment><USER28> One interesting fenomene is that focused 2d images appear to be more high res. It would be cool if a 3d UI vould somehow know in real time what we focus on and put that plane in focus. Somehow we can see if another human or animal is focusing in on us, so it might be possible for a computer to also see what we focus on.

</comment><comment><USER29> media molecule's Dreams has the most impressive user interface i've ever used. it uses 2d panels laid out in 3d space but the panels can be anchored and resized in screen space, object space or world space and it's extremely intuitive. i highly recommend people interested in ux/ui check it out

<comment><USER14> Looks very inefficient.

Pressing a key on a keyboard works better than using spatial input from a pointer device for those cases. To click a button/icon there is a feedback loop that requires vision processing, correction, anticipation, and hand eye coordination. You have to iterate many times in this loop to move to the correct location. Often the refresh latency makes this problem even harder.

This problem is better understood when you have a virtual keyboard and only a single pointer.

Ctrl/Cmd-C is easier and faster than moving the mouse to Edit -> Copy.

Creative professionals rely on physical keyboards and buttons on the mouse for actions and only use spatial input for things that are spatially relevant (pan, placement, zoom, rotation, selecting surfaces, edges, vertices, etc).

<comment><USER20> _Creative professionals rely on physical keyboards and buttons on the mouse for actions and only use spatial input for things that are spatially relevant (pan, placement, zoom, rotation, selecting surfaces, edges, vertices, etc)._

That used to be true. Autodesk put a lot of effort into interfaces for engineering in 3D. In Inventor, you only need the keyboard to enter numbers or names. They managed to do it all with the mouse. Try Fusion 360 to see this; there's a free demo.

<comment><USER14> You mean the right-click radial context menus? Yes, those are really nice. They require much less of a feedback loop and often don't require any visual processing at all. They are also more gesture based not buttons. The affordance is very generous compared to buttons and icons.

I use a 3DConnexion Space Navigator (6 DOF) in my left hand and mouse in my right for selection when using Fusion 360 and often use the gestures on the mouse.

I guess that brings up an exception. The context switching cost. Moving from pointer to keyboard is very slow so gestures really help out in that regard. If my hand is already on the keyboard then I have less reason to want to use the gestures.

<comment><USER20> That, plus the ability to rotate, pan and zoom while you're in the middle of a selection. That's a huge win. In 3D work, you often need to select 2 or more things, and those things may be small and need precise selection. Precision multiple selection is hard.

Before this was worked out, most 3D programs offered four panes, with three axial projections, usually wireframe, plus a solid perspective view. Just so you could select. Now we only need one big 3D pane.

</comment></comment></comment></comment></comment><comment><USER30> It probably needs to be pointed out that this is a post from John Carmack. I almost didn't click on it due to the facebook.com domain but spotted his name in the comments here. Obviously Carmack is still highly regarded and respected in the industry and his opinions quite rightly hold a lot of weight, despite his current choice of employer / platform.

</comment><comment><USER31> Here's another nice article from June 2018 touching on many of the same points:

[https://hackernoon.com/predictions-from-the-first-ar- os-9440...](https://hackernoon.com/predictions-from-the-first-ar- os-94407773cc9)

>The way we organise our physical world is probably more relevant to AR than how we organise our 2D interfaces. ...

</comment><comment><USER32> I first misunderstood this as interfaces in 3D _games_ , and it doesn't really change the supposition.

Interacting with most AAA title UI is an exercise in extreme frustration. Days Gone's menu is like someone developed a fetish for prezto.js.

It's pretty, but also pretty unintuitive.

Also beside the point a bit.

</comment><comment><USER33> I feel like this needs examples. What exactly is he recommending as a gold standard?

<comment><USER34> 2d interface on the inside of a cylinder that surrounds the user, it seems. Perhaps not all the way around.

<comment><USER35> That makes sense -- switching depths is more taxing (and gets weirder in VR, since you're not actually changing your eyes' point of focus), but a 2D cylinder gives you as much horizontal space as you could possibly get.

</comment></comment></comment><comment><USER36> I was angered by the title (a bit clickbaity, as context is king for a UI), but upon reading agree 100% with the title.

</comment><comment><USER37> Of course. We can't see 3 dimensions; we can only see what can be projected onto a portion of a spheroid.

</comment><comment><USER38> The point is abstraction, more sensory dimensions is very unlikely to provide there.

</comment><comment><USER39> Imagine if we interacted with everything we encounter every day on a single 2D plane.

</comment><comment><USER40> Facebook?! John Carmack doesn't have a blog? :(

<comment><USER41> John currently works for Facebook as CTO of Oculus.

<comment><USER42> thats too bad as their interface is absolute garbage.</comment></comment></comment>


Dotmole – A Web app that learns new unknown faces on it's own - <AUTHOR> Hello community! I've built a full-fledged security surveillance software that recognises faces and also learns from the new faces and saves only motion detected part in the system.
. I would love to know your review and work on it:) <comment><AUTHOR> Here's a link to the website: [https://www.dotmole.co](https://www.dotmole.co)</comment>


Show HN: VclGenie a JSON to VCL Generator Written in Scala - <AUTHOR> https://github.com/iheartradio/vclgenie/ <comment><AUTHOR> Author here. This was really started as a fun side project, so I am sure there are tons of bugs, etc. Feedback welcome !</comment>


Is CrossFit Killing Us?  - <AUTHOR> http://www.outsideonline.com/fitness/strength-and-power-training/Growing-Pains-CrossFit-Injuries-On-the-Rise.html

<comment><USER2> I'm always surprised when professional (in this case Physiotherapists) say things like "we're seeing an x% increase in cases involving...".

CrossFit is growing massively, of course they are going to see increased cases. The military saying 16% of their test group were injured during their study. But if they had chosen to study running, they would likely have a similar or larger percentage of injured atheletes, if the 70% of runners will sustain an injury each year is to be believed.

I don't do CrossFit anymore, and am not a fan, but it's just becoming a whipping boy at this point.</comment>


Cargo Cult - <AUTHOR> https://en.wikipedia.org/wiki/Cargo_cult <comment><AUTHOR> "Cult members worshiped certain unspecified Americans having the name "John Frum" or "Tom Navy" who they claimed had brought cargo to their island during World War II and who they identified as being the spiritual entity who would provide cargo to them in the future.[14]"</comment>


Rapid prototyping, static site generation and so much more - <AUTHOR> http://mixture.io/

<comment><AUTHOR> If you try it out, don't forget the docs on [http://docs.mixture.io/](http://docs.mixture.io/)</comment>


$98 Linux Laptop - The HiVision miniNote - <AUTHOR> http://techvideoblog.com/ifa/98-linux-laptop-the-hivision-mininote <comment><USER2> At the risk of downmods I'm going to complain that the first three letters of any product's name should not be HiV. Especially since at a glance it looks like the i is capital.

<comment><USER3> Almost as bad as the i.Beat Blaxx MP3 player ([http://www.engadget.com/2007/08/24/trekstor-showcases-i- beat...](http://www.engadget.com/2007/08/24/trekstor-showcases-i-beat-blaxx- portable-media-player/))

</comment></comment><comment><AUTHOR> Drawbacks -- Adobe doesn't support MIPS processors, so this laptop can only run the FOSS versions of flash and .pdf. That's still more flash support than the iPhone.

<comment><USER4> Its got a pretty anemic processor, so I don't think the lack of flash will be that devastating. It wouldn't run it very well anyway.

<comment><USER5> Assuming it's the NB0700 from the manufacturer's page: <http://hvsco.com/sp_qx.asp?id=75> It has a VIA C7-M 1.6GHz. Assuming this RISC is comparable to the 900MHz CISC intel processor of the eeePC, the eeePC is fine for (most) flash, including (some) games.

Flashlessness is a killer IMHO.

<comment><USER6> The XO has a hard time with Flash, but can sort of almost play YouTube low quality videos. It's got a 400MHz CPU. So, I'd say a 900MHz equivalent will definitely play most low-bandwidth Flash content.

And, I'm not sure I agree that not having it makes the system useless...I lived without video on the web for the first two years or so that I was on the net (using an Amiga--Real video was the format du jour back then, and they obviously did not have an Amiga player). It was still a seriously useful part of my life. While I think it'll have to have video for US buyers, since YouTube is such a core part of the online experience now, it wouldn't for folks in places where real broadband is not yet available. Without broadband video isn't useful option, anyway.

<comment><USER5> Hey, I didn't mean it would be useless, just a killer for mainstream success. I gravely agree that more internet --> less productivity. :-(

</comment></comment></comment></comment></comment><comment><USER7> The text is a bit low on details, but on the video they say the current (pink) version is $120 and the October (black) version is $98. You can also see a spec sheet:

PWS700A/PWS700B

CPU: 400 Mhz 32 bit

RAM: 128M/64M

NAND FLASH: 1GB

OS: Linux or WinCE

Display: 7" WVGA 800x480

Network: Wireless Lan 802.11b/g

      10/100M Ethernet Controller

</comment><comment><USER8> What game changing does a $98 laptop do? (Apart from the OLPC mission.)

For example, does anyone think that laptop price is holding back mobile phone business models for laptops (free with broadband)?

<comment><USER6> _What game changing does a $98 laptop do? (Apart from the OLPC mission.)_

Why do you need more than the OLPC mission? That's a pretty damned audacious thing. Getting network-capable computers into the hands of an entire class of people that couldn't have owned one is _huge_. For the folks who are choosing between a white MacBook or a black one, this changes nothing. For folks who could never afford a MacBook, this is the difference between being connected and not being connected.

 _For example, does anyone think that laptop price is holding back mobile phone business models for laptops (free with broadband)?_

I have no idea what this question means in relation to this laptop. Given that the iPhone is a $600+ device being sold for $200 with contract, and that $600 laptops exist today and have existed for a few years, I'd say the broadband companies, in general, don't find the "give away a computer in exchange for a longterm contract" model appealing, or they would already be doing it. It was tried in the past with free desktop machines, and everybody saw that the deal was a bad one for consumers, and so those ISPs went out of business or changed to a different model. I think it has to be a business that looks more like mobile for this kind of monetization to work--people are accustomed to getting "free" phones, and they're also accustomed to long terms. Mobile is a historically abusive industry, so no one complains about the abuse. Of course, since the shake out in ISPs a few years ago, and consolidation down to just a few carriers, the level of abusive contracts and terms is getting higher...so maybe there will be a subsidized laptop deal soon, once AT&T and the cable companies have finished consolidating and shutting down the last of the real competition in the space.

Anyway, I think your question has nothing to do with what changes when a WiFi- capable laptop is available for $98. You're thinking way too much about _your_ habits and expenditures. This device is not for you, or any of the folks you hang out with.

<comment><USER8> _Why do you need more than the OLPC mission? That's a pretty damned audacious thing._

I didn't mean to imply anything about the benefits of availability in low- income countries or the OLPC mission. My question intention was more along the lines of: 'apart from the obvious.' Naturally, affordability for the remaining (majority) of the world that cannot afford a laptop is the important consequence of decreasing costs.

What I meant was as the cost of a usable, connected laptop or laptop-like machines approaches zero, what changes (if any) can we expect in the behaviour of existing laptop users. Any new uses, products and such that might come out of this?

<comment><USER9> Text based services are going to be big for a while; small screens and keyboards and being on the go with wonky access and low bandwidth will mean that it's worthwhile to get a text version of what you're after.

Wireless bridges and bulletin board access points might be selling better (a bulletin board ap is one that has local storage and no backhaul bandwidth, it's sort of like a wiki restricted to a particular physical location).

Laptop Decor will become ever more important.

Most schools will require laptops, or just provide them.

Coworking Coffee Houses will become a distinct and recognizable place.

Legal documents on the web will be more common as the expectation will become that everyone has access.

Homeless people will hack for food. (hack in both senses of the word)

Festival registrations, solar power packs, campfire computing; Burning Man tech will go mainstream.

Field programmable gear will go big, your car, your house, your dogs collar will all expect to be told what to do over a usb port.

</comment></comment></comment></comment><comment><USER10> I always find these announcements frustrating if you can't actually buy the product.

By the time, it gets to the US, it will probably be $300.

</comment><comment><USER11> Chinese Engineers have done a very nice job! They design a low ressources but dynamic netbook.Now, they can go forward. First, they have to implement a mini OS displaying directly the homepage browser after a few seconds boot as Splashtop.Secondly,to allow alternative energy supplies as FreePlay(solar,dynamo,AAcells).</comment>


Secret to longevity may lie in the microbiome and the gut - <AUTHOR> https://www.sciencedaily.com/releases/2018/05/180531114611.htm <comment><USER2> I'm a believer in the importance of the microbiome, but this study seems fishy:

* the authors have already started a company and pursued a patent on their ayurvedic-derived formulation

* the figure 1(a) in their paper ([https://www.nature.com/articles/s41598-018-25382-z#Fig1](https://www.nature.com/articles/s41598-018-25382-z#Fig1)) doesn't show a big difference from plain probiotics to their formulation, but does show some oddities in the Y-axis where, for the control group, there were clearly exactly just 10 flies' mortality measured (integer steps down), but apparently many, many more for other cases scaled to the 0-10 axis.

* it's unclear if the treatments/evaluations where blinded – the word 'blind' is not found in the Nature article

* the 1st comment on the Nature article wonders: "the control flies didn't live to their normal expected age or even close. What gives?"

(Perhaps the flies that lived longer just had more food in total?)

<comment><USER3> I would´t trust my nose to detect fishiness. These expermients simply need to be reproduced independently to be verified. Until then, it's anti-scientific to assume anything about fishiness. The reported facts do NOT PROVE that the results were forged.

<comment><USER4> Nobody is claiming that it does. They are indicating possible economic investment in the results and some questionable statistics. It is perfectly scientific to take these pieces of evidence and adjust the possibility of this study being fishy upwards.

<comment><USER3> Claiming the presented result as fishy based on the given argument is equivalent to claiming the data has been forged, the scientists are dishonnest and have unethical behavior. Unless the results are proven wrong, such claims of fishyness is defamatory. This is what I call judging by its nose. It's not because such behavior has become common place that it is correct and acceptable.

It would make a huge difference if the OP simply called to be cautious for the given reason. This preserves the status of unknown to the validity of the reported fact without taking position one way or the other.

It is very disapointing that people can't make the difference and I maintain that such behavior is anti-scientific. Claiming the opposit doesn't make your point true.

People who make claims like this fishyness are people who have a very high opinion on their ability to distinguish true from false facts just by guessing. That's monkey science.

<comment><USER2> 'Fishy' doesn't mean 'forged', just 'suspicious'.

The factors I mention – fast patenting/profit-seeking, odd axes/combinations to get a result, unclear blinding, inconsistency with other expected fly lifetimes – are all the kinds of things correlated with flimsy results. It's usually wishful thinking, not conscious forgery, that leads such authors to overlook the weaknesses in their setup when they get a publishable/profitable result.

I do have a high opinion of my ability to detect flimsy results from the details (or missing details!) of a scientific paper, from decades of reading and watching which results hold up, and which don't.

You're practicing scientism – sacralizing certain procedures, titles, or outlets – rather than science here. Science requires a high standard of proof, and recognizing patterns of misreporting. There's even a strong case to be made that "most published research findings are false":

[http://journals.plos.org/plosmedicine/article?id=10.1371/jou...](http://journals.plos.org/plosmedicine/article?id=10.1371/journal.pmed.0020124)

</comment></comment></comment></comment></comment><comment><USER5> I'm working in proximate space. Every research paper about nutrition in general and gut bacteria specifically should be assumed shit science.

<comment><USER6> Interested in learning more if you have time to expand. Cheers

<comment><USER5> Sure. I see 3 recurring issues with "nutritional research" I'm exposed to:

1\. Wayyyyy too much industry involvement, much of it not properly disclosed (OP here is a classical and representative example).

2\. Lots of research from relatively small and "less known" institutes, done by researchers with hard to verify credentials.

3\. Low scientific standards. That'd include:

      - Refusal to share data
      - Refusal to share data analysis methods
      - Not keeping the basics of a double-blinded test
      - No reproduction, and not even the possibility of independent reproducibility, as the methods are described so vaguely.

That's in a nutshell.

<comment><USER7> You identified the problem. What's the solution?

<comment><USER8> The solution is identification of bad methods and subsequent ignorance.

If only we had a metric for credible science that takes authors, institutions, publisher and funding sources into account....

<comment><USER9> This seems like a great idea - is there some reason this doesn't exist?

<comment><USER7> Something that takes only authors, publishers, and institutions into account sounds counterproductive.

I think it'd be better to have an agreement that only reporducible papers are credible. Ie data the paper is reported on (to include "cleaned" data) and any tools developed (software tools) must always be included. As well as funding for everything disclosed.

Ultimately though I think we may just be seeing the obsolescence of current statistical theory. Science needs hypotheses to be testable in "trustable" metrics. But there are too many loop holes if things like p-hacking are possible.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> In a few years we might look back at this period and think: oh, it was at the time when we thought gut bacteria was the solution to every health problem known to mankind.

Remember when it was vitamin D?

<comment><USER11> Maybe one day we'll realize that there is no single factor for good health. Maybe it's Vitamin D AND gut bacteria AND lot of other factors that are even individually different?

</comment></comment><comment><USER12> Advertisement of a herbal supplement.

</comment><comment><USER13> I think there's been very little evolutionary pressure to increase lifespan in creatures like fruit flies since despite their short lifespan few of them die from age related causes. I would assume it's pretty easy to increase the lifetime of short-lived creatures in a protected environment, and pretty unlikely that the methods which accomplish this would also extend the lives of long-lived creatures.

<comment><USER14> What do fruit flies usually die from?

<comment><USER15> Looks silly at first glance, but I think it is a very interesting question. Asking Google I found a lot of "they die", but no good research about the cause (admittedly, I only spend a few minutes). Only one other - still open - question on Quora: [https://www.quora.com/Has-anyone-tracked-the-cause-of- death-...](https://www.quora.com/Has-anyone-tracked-the-cause-of-death-in- fruit-fly-aging-studies) \-- The only answer says it has not been studied thoroughly, but it is from someone whose professional and job title ("Biomedical gerontologist, Chief Science Officer of SENS Foundation") sound like he would/should know.

I think it is _implied_ that the cause of death is ageing? What else would it be (lab fruit flies don't have predators)?

I found a hint here: [http://genomics.senescence.info/species/entry.php?species=Dr...](http://genomics.senescence.info/species/entry.php?species=Drosophila_melanogaster)

> _Little is known about causes of death in old fruit flies but cardiac ageing > has been reported [0981]._

That sentence indicates that the question is not very well researched?

If that is true I find it amazing that there are ageing studies, shouldn't their own cause of death be well-known?

To @gweinberg, if you are reading this, what do you base this on? You wrote

> _few of them die from age related causes_

</comment></comment></comment><comment><USER16> > Scientists fed fruit flies with a combination of probiotics and an herbal > supplement called Triphala that was able to prolong the flies' longevity by > 60 percent and protect them against chronic diseases associated with aging.

For comparison, dietary restriction increases longevity in rats and mice by up to 45%, but this may only be in lab animals

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3299887/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3299887/)

</comment><comment><USER17> Wait, it's an internet law that every article that asks if "<something> may be the solution to <some problem>" it is never the solution.

<comment><USER18> _Clickbait 's Law_

</comment></comment><comment><USER19> The topic microbime is definitely on the rise right now. It will soon reach mainstream media.

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=Microbiome)</comment>


Astronaut Selection Program - <AUTHOR> http://astronauts.nasa.gov/

<comment><USER2> Reminds me of the best excuse for weight loss I've ever heard from a friend: "I lied on my astronaut application, so now, I have to lose 20 pounds."

</comment><comment> dan-silver For high school and college students interested in internships - [https://intern.nasa.gov/ossi/web/public/main/index.cfm?solar...](https://intern.nasa.gov/ossi/web/public/main/index.cfm?solarAction=view&subAction=content&contentCode=HOME_PAGE_INTERNSHIPS)

This is a great way to meet astronauts and talk with the astro selection and training directors.

</comment><comment><USER3> NASA has 42 astronauts and no manned launch vehicles. Probably not a good employment choice.

Space-X, though...

<comment><USER4> ... will employ you for the rest of your life.

</comment></comment><comment><USER5> what is the point of having X, Y and Z requirements if a person without US citizenship will never be considered? Has this changed?</comment>


LumaFix64: Commodore 64 with less stripes - <AUTHOR> http://biosrhythm.com/?p=1340 <comment><USER2> I find it amazing people are still producing new things for the C64, yet we have computers a thousand times more powerful than that... in our pockets.

<comment><USER3> Not really, IMHO - the C64 is as if made for tinkering; if you want to design hardware to interact with or enhance a computer, the C64 is the place to go; just about every conceivable signal is easily accessible, a lot of the chips are in sockets, rather than soldered in (thus easily replaceable or, for that matter, simpler to break signals out of).

In addition, 6510 assembly is pretty straightforward getting into, so writing your own software to make use of the hardware you just designed and built is not unsurmountable for a hobbyist.

Heck, I still play with my C64 on occasion.

</comment></comment><comment><USER4> fewer stripes*

Sorry, couldn't restrain myself.

<comment><USER5> not really, it's the intensity of the stripes rather than their count that is reduced

<comment><USER6> So 'lesser'?</comment></comment></comment>


Reproducible Builds in Go - <AUTHOR> http://go-talks.appspot.com/github.com/davecheney/presentations/reproducible-builds.slide

<comment><USER2> Hi HN,

There was a video recorded at this meetup, but I'm not in control of that.

In the mean time, the getting started document [1] is the contents of the "demo time" slide.

1\. [https://github.com/constabulary/gb/blob/master/getting- start...](https://github.com/constabulary/gb/blob/master/getting-started.md)

<comment><USER3> Dave thanks for doing this. Not just for building the tool but for a very well thought out and convincing presentation.

I'm completely with you. My own solution has similar ideals (per project versioned deps) though a different solution. [https://github.com/joewalnes/go- getter/blob/master/README.md](https://github.com/joewalnes/go- getter/blob/master/README.md). Honestly I'm just glad others are finally talking about the elephant in the room.

</comment></comment><comment><USER4> One major limitation of this approach is that any project that wishes to vendor or lock their dependencies can no longer be used as a dependency for another project. From the gb GitHub:

> A project is the consumer of your own source code, and possibly dependencies > that your code consumes; nothing consumes the code from a project.

This seems to imply that any code _outside_ of a project (i.e. the code inside vendor/src) has no recourse for indicating the versions of their dependencies. This is nice in that it simplifies the problem, but to completely remove the ability for any and all libraries to indicate the versions of their dependencies seems unnecessarily restrictive. If I build a library for others to use, and I have a dependency, I want to be be able to lock to a specific version, or at least give my preference for a version.

Of course, this creates its own issues - what do you do when two libraries depend on two different versions of the same library? (Also known as the diamond dependency problem.) This is where the Go culture helps, where as long as you pick a later version, things are likely to work. But I'd rather have the tooling let me detect the two versions that the two libraries want, show that there is a mismatch, and give me the ability to override and pick one (probably the later one). Instead, the gb approach eliminates the ability for the libraries to even have the ability to indicate what version they would prefer, which makes it even more difficult to get a bunch of libraries that share dependencies to work correctly together.

godep ([https://github.com/tools/godep](https://github.com/tools/godep)) seems to have the best compromise: vendor dependencies without path rewriting (though with GOPATH rewriting), but also keep track of their versions in a Godep.json file. You can gracefully pick between conflicting versions upstream if need be.

<comment><USER5> +1 for godep w/o import path rewriting. It isn't addressed in the presentation at all, only using it with path rewriting is mention and all the problems associated with it are with the path rewriting.

IMO it is the best solution right now with just 1 issue, that it is not included with go. This is a pain with CI systems (e.g. Jenkins) where you have plugins to provide go itself, but have to figure out a way to get godep around to run your build. Right now I'm punting and just doing a go-get godep, then using it to build my project. I'm not happy with that though.

</comment></comment><comment><USER6> Sad to say so, but this really makes a lot of sense - and it's dead simple, something I really appreciate as a Gopher.

Suddenly you're able to have full control over a project, use private repos effortlessly (even with SSH protocol) and most importantly for me, not check in all the dependencies and their changes like with Godep, which just keeps up messing up the history although having nothing to do with the project.

Just Git submodules and you're done.

<comment><USER7>
        > Just Git submodules and you're done.

It would be a disaster if popular Go projects started using submodules, and consequently required users and contributors to play the submodule init/update/sync dance. Please, please -- prefer subtrees.

<comment><USER2> gb doesn't mandate any particular DVCS or DVCS strategy -- I understand it's a deeply personal issue for most.

People are smart, if they like the tool, they'll figure out how to integrate it into whatever DVCS they use.

</comment></comment></comment><comment><USER8> On slide 9 it says that enhancing the syntax for "import" would be a backwards-incompatible syntax change. Sure, old compilers wouldn't accept newer code, but newer compilers would accept old code without breaking the behavior.

Is Go's definition of "backwards compatible" different from the usual one?

<comment><USER9> The issue is more with older code not compiling on newer compilers if the syntax is changed. Go works on the basis of no breaking changes between major versions.

I guess theoretically it could be changed in such a way that both the older and newer syntax would be valid on newer compilers, but that adds additional complexity which is also an anti-Go idiom.

So sadly we're left with two alternatives: 1) code rewriting / generation, or 2) 3rd party compilers.

<comment><USER8> But it looks like Go has done similar things in the past. For example, the slicing operation gained an additional optional argument ([https://golang.org/doc/go1.2#three_index](https://golang.org/doc/go1.2#three_index)). It's not exactly the same thing, but it seems roughly in the same league of difficulty.

Based on what I'm reading, versioning is a serious pain point. Sure, you always have to make sure the payoff is worth the additional complexity (universally, not just in Go) but the author seems to categorically disqualify this option by incorrectly saying that it would break backwards compatibility.

<comment><USER9> _> But it looks like Go has done similar things in the past. For example, the slicing operation gained an additional optional argument ([https://golang.org/doc/go1.2#three_index](https://golang.org/doc/go1.2#three_index)). It's not exactly the same thing, but it seems roughly in the same league of difficulty._

It's not really same in my opinion. Slices already accepted multiple parameters - or even none. So adding another optional parameter doesn't affect the syntax. Where as import names are all stored in a single quoted string, so you'd have to rethink the entire structure of the import syntax (which leaves you with two import different methods of expressing imports - which is messy) or use some nasty kludge of including versioning within the import string.

What's more versioning is only half the story here. There's other issues with Go's imports that this author aims to resolve - such as the dependency on a static repo. Because import paths are based directly on the repo path (eg github.com) it makes it a pain to prototype code in a private repository before pushing changes public. And then there's issues with dependency on any specific resource (you can't use mirrored repos with _go get_ ), plus a whole slew of related issues regarding hard-coded repo paths.

So versioning is only half the story.

 _> Based on what I'm reading, versioning is a serious pain point. Sure, you always have to make sure the payoff is worth the additional complexity (universally, not just in Go) but the author seems to categorically disqualify this option by incorrectly saying that it would break backwards compatibility._

Well I've already argued that any clean solution would break backwards compatibility and any kludge would be messy and rather short sighted (plus potentially may not address the other issues with _go get_ and _import()_ ).

So I think it's a little misjudged for you to say he's "incorrect" in his opinion in the way that you have.

<comment><USER10> From what I gather the commenter is saying that a new compiler could accept this syntax:

          import "github.com/pkg/term" "{hash,tag,version}"

And this (old) syntax:

           import "github.com/pkg/term"

Meaning the language would be backwards compatible. But you're saying that this wouldn't be backwards compatible - why ?

<comment><USER9> Your method doesn't follow the same format as the rest of Go's syntax (eg comma delimited lists) which could break any 3rd party pre-parsers or other such tooling. So there's the potential break backwards compatibility there.

Plus lumping everything within the second set of quotes means you don't have idiomatic styling nor a simple method for the gofmt to validate since you have a list handled as a string. So it's not really a clean fix in my opinion (which was one of the other points I raised).

Whatever we bake into the language will be set in stone for all of the foreseeable future - regardless of whether it's a good change or bad change. So I tend to think it makes more sense to use 3rd party tooling to address this problem for now, and then bring whatever method seems to work the best into the official language specifications for Go 2.0. Other people's opinions might differ, but that's why I personally prefer the approach this author it taking.

<comment><USER8> _> Your method doesn't follow the same format as the rest of Go's syntax (eg comma delimited lists) which could break any 3rd party pre-parsers or other such tooling. So there's the potential break backwards compatibility there._

The new slicing syntax could have broken 3rd party pre-parsers or other tooling. Yet that change was considered backwards-compatible.

<comment><USER9> It could have done, but there's fewer tooling that parse slices (particularly at that point in time) than there are which parse import strings (there's lots and lots of tools that already do that!).

However the other key point is one I made earlier: slices already support a number of optional parameters so the language semantics didn't change even if the syntax of slices were expanded. adding 1 additional optional parameter to a property that already supports multiple optional parameters really isn't comparable to the import example which had a list of values represented in a new and completely non-idiomatic way (Ie initially without punctuation and then nested inside a string. Nothing else in Go follows that pattern, let alone the import strings already).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The link isn't working for me.

What we do is keep a copy of all packages we use and then assemble everything into a workspace as part of the automated build. Nothing is pulled from GitHub at build time. All those copies are versioned so you can have different projects use different versions. The dependencies are specified via some pre- existing build infrastructure but essentially there is one file in the project listing all the dependencies and where to find the packages.

Developers can still have their own personal workspace and build with different versions but the "real" build is always reproducible.

I think many people using Go or wanting to use Go in commercial/production environments are finding a little bit of impedance mismatch between the Go view of the world (the workspace and packages) and what their existing tooling does. It's not too terrible to deal with but it would be nice if we had a little more flexibility. go get could support some nicer/automated version of the above where you have the ability to download/mirror packages to a shared drive or to another source control system and pull from there to your workspace based on specific dependency versions. This is fairly minor friction though.

</comment><comment><USER12> Got my hopes up for deterministic builds, but then I read on slide 5:

         Out of scope: compiler doesn't produce byte for byte comparable binaries

<comment><USER2> There are others working on that problem.

I probably shouldn't have mentioned it; if I hadn't, you wouldn't have thought about it, and then nobody would have had their hopes dashed.

<comment><USER12> English isn't my first language, so when I read "reproducible" I thought "deterministic"; I also didn't think you'd be working on the "vendoring" problem since I thought it was a solved issue (which it isn't for all the reasons in the post). Anyways, thanks for your work.

<comment><USER2> I _think_ the compilers that produce elf output are _almost_ deterministic, at least when producing a fully static binary (no CGO).

I don't think that holds for mach-o or PE binaries, but I'm really speaking off the cuff here, as I said, others care about this and are working on it separately.

</comment></comment></comment></comment><comment><USER13> I love the presentation, but the GIL problem and Go's package problems aren't really even comparable. The GIL is an unfortunate consequence of the CPython implementation that can't really be solved without some serious hacks or computationally expensive workarounds. The Go "problem" is almost entirely an implementation problem; something evidenced by a simple fixed implementation.

Honestly, the entire presentation was nearly lost on me by the weird comparison at the beginning. I recovered, but seriously, very strange comparison for anyone who understands what the GIL represents.

Edit: And really, was github the best target to go to for availability when it came to developer downtime on the edited XKCD? Github's downtime is pretty near 0. I think I remember roughly an hour of downtime in 2014 in the super early morning, and nothing before that until 2012 maybe.

<comment><USER14> I interpreted the comic more as a statement about how important Github is to development than that it actually goes down all the time. So if it were down, that'd be a fine excuse to do nothing. :)

<comment><USER2> The important message on that slide is not the picture, but the words below it.

</comment></comment></comment><comment><USER15> I'm very excited about GB. GVM made working on multiple projects already a lot easier, but dependencies are still a huge pain... I don't know if GB is the best answer to the problem, but at least it's a big step forward and I'll definitely try it out.

</comment><comment><USER16> Go would hugely benefit from a hierarchical /.go in $GOPATH. This would allow for a robust versioning scheme, and allow the language to scale in the future.

<comment><USER2> Can you explain your idea in more detail ?

<comment><USER16> Think /.git, Dave.

       /.go
           vendors # map simple import name to explicit (ugly) path
           ... # other stuff for additional e.g. generate features

Hierarchical: Think OO-ish shadowing of .go directives and metainfo.

Is this clear?

<comment><USER2> > Is this clear?

not really

<comment><USER16>
        # </comment></comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----
        # general layout of the land
        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----
        $GOPATH/src/.go
        $GOPATH/src/.go/config
        $GOPATH/src/.go/vendors # for all projects

        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----
        # $GOPATH/.go/vendors sketch
        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----

        lib/mq = github.com/lib/pq@master
        mgo = labix.org/v2/mgo
        ... etc

        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----
        # specific project 1
        # uses the global version of package labix.org/mgo
        # uses a project specific package hotness
        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----

        $GOPATH/src/mygofoo
        $GOPATH/src/mygofoo/foo.go
        $GOPATH/src/mygofoo/.go
        $GOPATH/src/mygofoo/.go/vendors

        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----
        # foo.go fragment
        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----

        package mygofoo

        import (
            "mgo"       // version spec'd in global .go
            "lib/pq"    // version spec'd in project specific .go
            "hotness"   // version spec'd in project specific .go
            ...
         )
        ...

        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----
        # $GOPATH/src/mygofoo/.go/vendors sketch
        # </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>----

        lib/mq = github.com/lib/pq@experimental // lets pretend
        hotness = bitbucket.org/wiz/hotness@master
        ... etc

        # go tool

        > cd $GOPATH/src/mygofoo
        > go build -vendors
        using:
            mgo -> labix.org/v2/mgo
            lib/pq -> github.com/lib/pq@experimental
            hotness -> bitbucket.org/wiz/hotness@master
        >

        # go tool can obviously allow for command line mods of the .go

</comment><comment><USER17> I think I'll stick to using submodules and a Makefile with GOPATH set to the vendor directory. Hasn't failed me yet.

</comment><comment><USER18> Might be overkill, but for my large projects, I simply host my own gogs [1] instance and vendor in all my dependencies to that instance. I get reproducible builds, and I can bring in any updates I want manually when I'm ready for me.

1.[http://gogs.io/](http://gogs.io/)

</comment><comment><USER19> TL;DR: Don't use `go get` if you want reproducible builds.

It's early for me to tell, but looks like gb is something like a mix between a gvm (virtual env) and godep (vendorizing).

I'm skeptical about things like "don't use the standard, use my thing", but I will try it anyway.

<comment><USER7> The author has reasonable credibility/authority in the community. Definitely worth a look.

</comment></comment><comment><USER20> Reminds me of developing rails apps way back in the day before RVM gemsets or bundler came along. You'd vendor all the gems (& specific version for your app) into `vendor/gems` ala [http://nubyonrails.com/articles/2005/12/22/freeze-other- gems...](http://nubyonrails.com/articles/2005/12/22/freeze-other-gems-to- rails-lib-directory)

<comment><USER21> I still vendor all the gems, only I use Bundler to do it.

It's pretty much crazy not to, in my opinion. Stuff gets removed, and networks are unreliable, so locking/resolving dependencies to specific versions is insufficient.

<comment><USER20> Sorry yes, I meant it reminded me of vendoring gems _by hand_. I think everyone is vendoring gems via Bundler these days, because it would be insanity not to!

</comment></comment></comment><comment><USER22> It'd be nice if we could somehow use semver. I'd like to get patches automatically...

edit; if you downvoted, maybe comment and explain why?

</comment><comment><USER23> How is this different from godep[1] other than being the root of its own GOPATH and having a different naming convention for the location of vendored dependencies?

[1] - [https://github.com/tools/godep](https://github.com/tools/godep)

</comment><comment><USER19> @davecheney

Thanks for your work.

If I publish my project on github and use gb with it, then people who want to contribute have to install gb as well.

Do you think that in the future there is a chance to do the building of a gb project without the gb itself?

<comment><USER2> Maybe, but it's not something I'm focusing on.

</comment></comment><comment><USER24> If you're going to vendor everything anyways, I don't really see why you need a new tool. But IANAG, so maybe I missed something?

<comment><USER2> It's vendoring without rewriting, [http://go- talks.appspot.com/github.com/davecheney/presentati...](http://go- talks.appspot.com/github.com/davecheney/presentations/reproducible- builds.slide#25)

</comment></comment><comment><USER25> Yet another problem the go team refuses to see. Either the go team says "not our problem" then people are stuck with doing things multiple and incompatibles ways , or the go team says "we already solve the problem, vendoring" and the go team doesnt understand the problem at first place. That's the recurrent pattern with the Go team. Everything cannot be dealt with in userland, or you'll end up with fragmentation. And No , vendoring doesn't solve the problem.

<comment><USER26> But... almost every sentence in that comment is "not applicable" at best.

* the major players all solve this specific problem outside the lang core

* Dave Cheney is so involved with the project, you could easily consider him part of the "go team." Both in contributions and community pull.

* This very article is not about a problem, it's about a solution. It's literally Dave Cheney saying: wow, look at this important problem, and look at all the reasons why it's important. Here is a solution and all its pros and cons. Regardless of how you feel, the timing of your comment simply could not have been further off.

* More generally: Go is one of the most batteries-included languages I know. From the stdlib to the tooling (which is still part of the official release), it's all in there. When did you last try to create platform and architecture independent binaries without any prior knowledge in, I don't know; C? Even Python?

I really want to like this comment, believe me I do. But it is so out of tune with the article, I can't.

This article is almost literally about the opposite of everything you just wrote.

<comment><USER27> > * Dave Cheney is so involved with the project, you could easily consider him > part of the "go team." Both in contributions and community pull.

Wait, is he not officially part of the go team?

<comment><USER28> By "Go team", do you mean "Salary paid by Google"? Then no, I believe he works for Canonical...but he's pretty "core" in all other aspects.

</comment></comment></comment></comment><comment><USER29> The number of parallels between Go and Ruby keeps me entertained. Isn't this just rvm and bundler all over again?

<comment><USER30> Well, thankfully there's nothing like the nightmare 1.8.6 -> 1.9 switch, and it has loads of tools working with static code that ruby could never have.

</comment></comment><comment><USER31> Can somebody please share a mirror? App Engine instance seems like it has exceeded the quota. (lol)

</comment><comment><USER32> yet another try......

<comment><USER33> I attended the talk. Wait for the video, I personally found the Dave's arguments and reasoning convincing.</comment></comment>


Introducing Remodel – A tool for building and managing iOS model objects - <AUTHOR> https://code.facebook.com/posts/1154141864616569?__mref=message_bubble <comment><AUTHOR> Hi, my name is Andrew and I'm part of the team that just released a new open source tool from Facebook called Remodel.

It's a tool for people who write Objective-c and want to use immutable value objects in their code, which can be a pain to manage.

This is a tool we've had around for a long time in our fbobjc codebase and it's something we've found very useful.

I've lurked on HN for a while, but am new to posting and commenting, so I'm looking forward to answering some questions.

<comment><USER2> Thanks for sharing. I do have some questions, probably ones coming out of almost unfathomable ignorance, but hope you can answer.

Any plans for supporting Swift output? Or is that question completely missing the point of this tool (like, maybe with Swift its support for immutable value objects is already so good you don't need this?)

What is a .ts file?

Could this have been done instead with a new mogenerator template, or what is the limitation of mogenerator that would have prevented that?

Could this help with creating code for attributes with the Transformable data type?

I see there is a tiny bit in the readme about the workflow, but nothing about how that fits in to the usual Xcode workflow for working with models and their associated classes (in Xcode the word model refers to the xcmodel file(s) I believe, not the code, but you're using it in a more general way). What would be the Xcode workflow for using this, starting from an empty project with no xcmodel file, and proceeding until it's done?

<comment><AUTHOR> I had almost given up on getting any traffic here. So, I'm excited that I got some good questions. Let me try to answer them.

1\. It is kind of a bummer that we don't support Swift. As silly as it is, probably the main reason for this is that at FB we only really code in ObjC (at least for the near term), so we wouldn't have any local use cases (which both drive our development and help us validate that the concept is useful).

It is also true that the need for this type of system is a lot greater in ObjC. Like you said, Swift is awesome in terms of its support for immutable objects and it even supports something a lot like ADTS out of the box (they call them "Associated Values" in their enums).

Because Remodel makes these nice concepts available in Objective-C, it's a useful tool for people who like Swift but are, for whatever reason, working in a Objective-C codebase.

Also, at some point we may make a Swift output option and it would have value in terms of the plugins that can make simple operations like encoding / decoding or other basic helpers.

2\. A .ts file is a TypeScript file, which is a language that Microsft developed which compiles to JavaScript. TypeScript looks a lot like JavaSript, but it has types.

We chose TypeScript for the implementation of Remodel because we liked the fact that it's based on JavaScript which is extremely popular, well-known, and also suited toward functional programming. TypeScript uses JavaScript's familiar syntax but adds compile-time support for strong types and generics, filling in one of the major gaps in the language.

3\. I actually wasn't aware of mogenerator -- but looking through it, I can see that there is some overlap and also important differences.

One of the best benefits of Remodel is that once you start generating your models through it, people cannot add custom code to them.

This lines up with a big section in the blog about architecture ("Modeling Your Architecture"). To sum it up here: there are a lot of benefits to keeping models completely free of custom logic and instead putting that logic into behavior classes.

In mongenerator, however, it appears that every entity gets a subclass to add custom code, which is at odds with this philosophy.

There are also some differences around the focus on CoreData in mongenerator while Remodel objects are completely free of assumptions about how they're stored, transported, etc.

4\. Remodel generates simple encode/decode methods for you out of the box, and the plugin system we have could allow you to generate other transformation logic for your models.

I honestly don't work with CoreData that much, so I'd need more details to give a better answer to this question.

5\. You're right that we're not talking about xcmodels here. Overall, Remodel objects operate very much as vanilla Objective-C objects, so the workflow is pretty basic and familiar:

      * Create a .value file, for example MyModel.value:
      MyModel {
        NSString *prop1;
      }

      * Run '$ remodel-gen MyModel'
      * This yields 2 new files (MyModel.h and MyModel.m)
      * Add MyModel.h and MyModel.m to your project
      * Make behavior classes that use the Model for something interesting
      * That's pretty much it :)

There's no support right now for going back and forth between a .value file and a CoreData .xcmodel file. In theory that shouldn't be too hard to create if there's demand for it.

<comment><USER2> Cool, thanks for the great reply! That makes it much more clear. I'll look for the blog post you mentioned. Edit: oh duh it's the original link of the post I guess. (I had originally come here from the a github link which I thought was a dupe of this post, so I was confused... asked my original questions having seen only the github project).</comment></comment></comment></comment>


The Traveling Salesman with Simulated Annealing, R, and Shiny - <AUTHOR> http://toddwschneider.com/posts/traveling-salesman-with-simulated-annealing-r-and-shiny/ <comment><USER2> I once had a real life issue with the travelling salesman problem - I wanted to invite boutique fashion retailers to a conference in '09, and I thought the best way would be to tell them about it face to face. I mapped out the address of every single one on some app on top of Google Maps, and ended up optimizing based on how clustered different groups of businesses were, to minimize my walking time while maximizing number of visits.

<comment><USER3> That is so cool! I love HN for stories like this.

</comment></comment><comment><USER4> Of course the traveling salesman problem is _combinatorial optimization,_ and of course Uber, Lyft, Sidecar, etc. have such problems, as has long been the case for _dial a ride_.

And, for the case of trips regularly planned, e.g., using one car to get the same several people to work each day, would have a _deterministic_ problem. Of course, part of the problem would be which people shared which car.

Otherwise there is something of a _probabilistic_ problem where the driver gets a travel request at some random time for some random origin and destination and has to decide what to do, e.g., accept the offer or not and how to fit the offer in with what else he is doing.

Might be a lot of work, but might save some money and/or give better service to the customers.

At one time, my Ph.D. advisor wanted me to work on dial a ride scheduling. But I already had a problem I'd made good progress on and used that for my dissertation instead! One reason: For the problem I used, I could claim to have a solution that was _optimal_ in a quite strong sense, but for dial a ride any solution would be only a big mess probabilistically, some big mess that was just heuristic, and that could be evaluated only empirically. Bummer.

Now, I also have another problem! So, anyone who wants to work on combinatorial optimization and hope to get interest from Uber, Lyft, Sidecar, etc. -- go for it!

</comment><comment><USER4> Nice visualization of an application of simulated annealing.

We should keep in mind that the OP is doing the traveling salesman problem (TSP) in the plane. So we should recall the nice Karp result in about 1972: With meager assumptions on the probability distribution of the cities, for any number x, no matter how small, as the number of cities n goes to infinity, there is a simple approach that will come within x% of optimality with probability 1 - x.

This simple approach? Start by connecting the cities with a minimum spanning tree. Then for the TSP tour, just traverse the spanning tree except going directly to the next city in the tree traversal not already visited. That is, when following the tree would cause visiting a city a second time, just go directly, not following an arc in the tree, to the next city in the tree traversal not yet visited.

So intuitively the value is, for large n, get about as close, about as often as wish, and for small n just enumerate!

Intuitively what is going on is that one of the main challenges is identifying the appropriate _clusters_ of cities and, then, connecting the clusters, and the minimum spanning tree tends to find the right clusters.

Of course, there are at least two algorithms for finding minimum spanning trees, and as I recall both run in time proportional to n^2. So, we have a polynomial algorithm that is, for large n, for TSP in the plane, as close as we please.

For the "plane", I meant R^2, where R is the set of real numbers, that is, ordinary Euclidean 2-space. But Karp's approach also works the same in R^m for any positive integer m.

</comment><comment><USER5> This is awesome and I can see so many use cases with logistics in cities like NYC by using addresses, and not capitals, as waypoints.

I would love to see this applied to the NYC taxi data to see how to optimise taxi movements and see how much ridesharing would decrease car traffic.

Code is here: [https://github.com/toddwschneider/shiny- salesman](https://github.com/toddwschneider/shiny-salesman)

<comment> mck- I really don't mean to self-promote, but this is what we do: Route- Optimization-as-a-Service [1]

[1] [https://www.routific.com/developers](https://www.routific.com/developers)

<comment><USER6> How is the business like?

I kind of do the same thing but for a different sector, but we are not SaaS so would be nice to know.

</comment></comment></comment><comment><USER7> I enjoy finding retrospectively obvious details from essays like this: an optimal solution won't have any crossing paths, and simply swapping cities is a handy way to try detangling the path! The animated graphs make this plain, but is it required? Having never thought about the TSP much (and not really having the mathematical chops to prove it myself) I looked it up, and sure enough SO user lhf [0,1] had a link to a grindingly in-depth article about the problem [2].

[0] [http://stackoverflow.com/questions/2444125/crossing-edges- in...](http://stackoverflow.com/questions/2444125/crossing-edges-in-the- travelling-salesman-problem) [1] [http://stackoverflow.com/a/2444288](http://stackoverflow.com/a/2444288) [2] [http://www.ams.org/samplings/feature-column/fcarc- tsp](http://www.ams.org/samplings/feature-column/fcarc-tsp)

</comment><comment><USER8> Simulated annealing is used heavily in chip design automation (EDA). I first used it when writing a toy placement tool while taking a course on the subject.

Slide 5 of this deck shows some of the problems in chip-design, most of which have been heavily optimized by simulated annealing. [http://www.ispd.cc/slides/ISPD12Slides/ISPD12_3_2.pdf](http://www.ispd.cc/slides/ISPD12Slides/ISPD12_3_2.pdf)

I love the beauty of the analogy to annealing a metal in metallurgy, and how surprisingly well it translates into software. The fact that the result is non-deterministic, but always useful, makes me smile.

<comment><USER9> _The probability of accepting an inferior tour is a function of how much longer the candidate is compared to the current tour, and the temperature of the annealing process._

Shouldn't the distance of the "nearest" neighbor be a function of temperature, rather than (or at least in addition to) the probability of acceptance? Isn't that how simulated annealing can escape a local minimum far from better or global maxima? Intuitively that is how the real annealing process works.

<comment><USER8> One of the fundamental premises of simulated annealing is this "looking backwards" approach. It's for the sake of the sanity of the implementor. How do you modify scalar values that determine a random process in such a way that the outcome does not exceed some error condition? You can't (in general), that's why you turned to annealing in the first place. You were unable to control error bounds. Instead, you make a completely random guess and only accept it if it's within the current "acceptable" range. This is easy to implement and gives suprisigly good results.

</comment></comment></comment><comment><USER10> It's cool to see this kind of stuff. I used simulated annealing for my thesis on cellular network optimization back in college. Haven't used any algorithms like this since then, but they have their uses.

<comment><USER11> I used simulated annealing for my Master's thesis. I was trying to fit a differential equation to some experimental results. With small changes in the parameters, you could get huge changes in the solution of the DE. For some of the experiments, the parameters it chose fit almost perfectly. As a result, simulated annealing is one of the techniques I look at for highly non-linear optimization.

<comment><USER12> Simulated annealing is not required for non-linear optimization. It's useful for non-convex optimization. Non-linear but convex problems are trivial to solve with Newton's method - a simple example is finding the weights of an SVM.

<comment><USER11> True. But, in my case, I didn't know if it was convex. A small change of parameters could go from a feasible solution to an infeasible solution.

</comment></comment></comment></comment><comment><USER13> Presumably this could be extended to include, say, average flight costs and other modes of transport so you could work out the an optimally fast and cheap way to travel around the world?

<comment><USER14> It depends on how much you want to idealize things. If you add the assumption that all flights/trains/etc. are available every day, and the price never changes, then yes. In reality, trying to traverse a weighted graph optimally with a bunch of constraints (arrival times, how long to stay in each place, preference for difference modes of transit, transit times) is a whole field of research in math/CS. Operations research [1] is the study of optimizing processes with many interrelated factors.

1\. [http://en.wikipedia.org/wiki/Operations_research](http://en.wikipedia.org/wiki/Operations_research)

</comment></comment><comment><USER15> Wow, the article didn't even mention the "original" solve of the 48 US city problem (one in each state) in 1954 (they included Washington D.C., so 49 to be precise)! For those interested, Dantzig (creator of the simplex method), Fulkerson and Johnson made quite the stir when they tried out the TSP at Rand in California more than half a century ago in their paper, "Solution of a large scale traveling salesman problem" [1].

The paper contains a historical context of the problem and their methods towards finding and proving (important!) that their solution was in fact optimal.

For those interested in Dantzig, he was the famed PhD student who came late to class one day and wrote down two open problems mistakenly thinking it was homework. He ended up using those solutions as a portion of his PhD thesis [2].

Here's an excerpt from Dantzig himself:

 _It happened because during my first year at Berkeley I arrived late one day at one of [Jerzy] Neyman 's classes. On the blackboard there were two problems that I assumed had been assigned for homework. I copied them down. A few days later I apologized to Neyman for taking so long to do the homework — the problems seemed to be a little harder than usual. I asked him if he still wanted it. He told me to throw it on his desk. I did so reluctantly because his desk was covered with such a heap of papers that I feared my homework would be lost there forever. About six weeks later, one Sunday morning about eight o'clock, [my wife] Anne and I were awakened by someone banging on our front door. It was Neyman. He rushed in with papers in hand, all excited: "I've just written an introduction to one of your papers. Read it so I can send it out right away for publication." For a minute I had no idea what he was talking about. To make a long story short, the problems on the blackboard that I had solved thinking they were homework were in fact two famous unsolved problems in statistics. That was the first inkling I had that there was anything special about them.

A year later, when I began to worry about a thesis topic, Neyman just shrugged and told me to wrap the two problems in a binder and he would accept them as my thesis.

The second of the two problems, however, was not published until after World War II. It happened this way. Around 1950 I received a letter from Abraham Wald enclosing the final galley proofs of a paper of his about to go to press in the Annals of Mathematical Statistics. Someone had just pointed out to him that the main result in his paper was the same as the second "homework" problem solved in my thesis. I wrote back suggesting we publish jointly. He simply inserted my name as coauthor into the galley proof._

[1] [http://www.iro.umontreal.ca/~gendron/IFT6551/LECTURES/TSP.pd...](http://www.iro.umontreal.ca/~gendron/IFT6551/LECTURES/TSP.pdf)

[2] [http://www.snopes.com/college/homework/unsolvable.asp](http://www.snopes.com/college/homework/unsolvable.asp)

</comment><comment><USER16> Lovely site design and clear explanation of simulated annealing. I've always more or less equated hill climbing and simulated annealing. Your article makes the difference easy to understand. Thanks!

</comment><comment><USER17> I believe the effectiveness of search algorithms goes something like this:

Monte Carlo < Hill climbing < Simulated annealing < Genetic algorithm < Differential evolution

<comment><USER18> No. It's completely context dependent.

A hill-climbing algorithm will take the lunch of every algorithm listed here if you have a clean convex optimization problem.

<comment><USER17> Where would you find such a problem in the real world?

<comment><USER19> Absolutely everywhere, it is a common subproblem in many many algorithms. For example, the basin hopping algorithm (sister of SA) solves one at every step.

A specific example is in image deblurring via Tikhonov regularization, which involves minimizing a function that is provably convex for many physically realistic types of blurring.</comment></comment></comment></comment>


Tool Could Protect Your Photos from Facial Recognition - <AUTHOR> https://www.nytimes.com/2020/08/03/technology/fawkes-tool-protects-photos-from-facial-recognition.html <comment><USER2> [http://archive.is/H5jxM](http://archive.is/H5jxM)</comment>


Judge grants search warrant for Cambridge Analytica's offices - <AUTHOR> https://www.theguardian.com/news/2018/mar/23/judge-grants-search-warrant-for-cambridge-analyticas-offices <comment><USER2> Is there any reason to believe this isn't completely too late? 24 hours after the ICO announced she was _seeking_ a warrant, crates of documents were observed being unloaded from Cambridge Analytica's building. The offices weren't actually raided for an entire working week! Surely, with that kind of notice, they'd be idiots to leave anything incriminating lying around?

<comment><USER3> Most of the relevant information will be in digital form, and it would be quite difficult to destroy that evidence without a trace.

<comment><USER4> Why was facebook in the offices the very night this story broke then?

</comment></comment></comment><comment><USER5> How useful is a physical search warrant when much information is stored in the cloud? Wouldn't it be more useful to procure one for the cloud providers the company uses?

<comment><USER6> Also, CA has had days of warning that this search is coming. Plenty of time to clean up.

<comment><USER7> If such a clean-up leaves even the tiniest trace and the investigators are worth their salt, this will land people in jail for obstruction of justice. Doubt anyone wants to risk jail time in their already pretty screwed situation.

<comment><USER8> Obstruction of justice can be less bad for you than the offense concealed, so if the offense is bad enough, risking punishment for that may not be irrational if it offers a real chance of concealing another offense.

<comment><USER9> The thing is that once you get to criminal charges, everyone is looking out just for his own head. The IT guy who will be asked to delete files couldn't be gotten on election tampering, so he's not going to commit obstruction of justice. And if you delete files such that the files are gone but the fact that you deleted them remains, then the government can implicate you for literally anything, so unless it was the worst of the worst crimes like child sex trafficking you're probably better off pleading guilty to the offense.

<comment><USER10> If I were in charge of company that does what CA does, I'd specifically hire 'IT guys' that I have dirt on that is worse than any of this... Or I'd find dirt on people that my IT guy cares about.

I might be giving CA more credit than they're due in the smarts department, but considering that I'm just a dude making up scenarios, I find this particular one pretty plausible. And assuming the worst seems like a sensible approach in this case.

</comment></comment></comment></comment></comment></comment><comment><USER11> Which specific law does "the use of personal data and analytics for political purposes" violate?

<comment><USER12> None, intrinsically.

But, receiving, storing, and/or processing personal data _without consent_ is, in most situations, likely to be against the the Privacy and Electronic Communication Regulations and the Data Protection Act. Additionally, information about political affiliation.

The key point in this case is that CA didn't have consent. CA don't dispute this, but say that they believed at the time that they did. It _is_ a defence to show that you "exercised all due diligence" in complying.

ICO will be looking for not only evidence of the actual use of personal data, but also evidence regarding whether and to what extent CA were knowingly or recklessly non-compliant.</comment></comment>


Google shuts down Google wallet - <AUTHOR> http://finance.yahoo.com/video/google-gives-39-wallet-39-160000981.html?.tsrc=applewf

<comment><AUTHOR> seems like very odd timing considering Apple Pay was just recently launched. Is there an alternative android wallet everyone uses?

</comment><comment><USER2> I can't read yahoo here, but wallet.google.com works just fine. In fact, google uses it to pay android developers.</comment>