Rust borrow and lifetimes - <AUTHOR> http://arthurtw.github.io/2014/11/30/rust-borrow-lifetimes.html

<comment><USER2> That covers the easy cases for ownership and lifetimes. But it's apparently necessary in Rust to use "unsafe" code in libraries to implement basic structures like re-sizable arrays. This suggests a limitation of the ownership primitives.

I looked at this problem a decade ago for C/C++, and got as far as borrow semantics (I used the term "keep", as the opposite of borrow). But there were ownership cases I couldn't figure out a good way to handle. This sort of thing is why the C++ committee beat their head against the wall with "auto_ptr". Rust has the same problems, and the solutions don't seem to be entirely clean.

Living with strict single ownership semantics is hard. One amusing approach is to have an atomic "swap" as a primitive. Swap is safe as regards single ownership. With enough swaps, you can do things like move the contents of an array to a new, larger space. This is an inefficient way to do it, but easy to prove sound. "Move semantics" can be viewed as a special case of swap, where one of the moved pointers is known to be null.

It can be useful to view something like moving the contents of an array as a sequence of swaps, which are then optimized. If the destination array is all NULL at the start, each swap operation becomes a pointer copy followed by a store of NULL into the source pointer. Then, if we can show that all the swap operations are non-overlapping, we can do all the pointer copies before all the stores of NULL. Then, if the source buffer is about to be discarded and is never read again, we can omit the stores of NULL. Then if the pointer copies are all adjacent, they can be rolled up into one MOV operation.

This may be a way to avoid using "unsafe" so much.

<comment><USER3>
      > But it's apparently necessary in Rust to use "unsafe"
      > code in libraries to implement basic structures like
      > re-sizable arrays.

Efficient data structures are one domain where single-ownership prevents barriers to implementation, true. Your domain will determine how much unsafe code you need to deal with. For efficient data structures, you will need a large amount of unsafe code (probably a third to half of your code). For applications that need to really push the performance envelope, I expect you'll need around 10% unsafe code (this is a ballpark estimate for the amount of unsafe code in Servo, last I checked). For most domains I'd expect the volume of unsafe code to be less than 1% of your codebase (contrast this with C and C++, where by Rust's definition 100% of the codebase is unsafe).

      > Living with strict single ownership semantics is hard.

This is why Rust provides a reference-counted smart pointer (somewhat like C++'s shared_ptr) in the standard library, for those cases where multiple ownership is necessary and you don't want to manually wrangle raw pointers. There's unsafe code underlying it (the aforementioned raw pointer wrangling), but putting it in the stdlib means that it can be well-audited.

      > This may be a way to avoid using "unsafe" so much.

Rust tries very hard to give you the tools to avoid using `unsafe` blocks, but it's a thoroughly pragmatic language and so it knows that sometimes such code is unavoidable. If you could afford inefficiency in the name of 100% safety, you'd just be using a GC'd language. If it denied you efficiency in the name of dogmatic safety, you'd just go back to using C++. The complexity here is inherent to the domain. There must exist a compromise if we expect to ever make progress.

<comment><USER2> _If it denied you efficiency in the name of dogmatic safety, you 'd just go back to using C++._

For new work, most efforts are going forward to C# or D or Go or Java, all of which solve this problem by using a garbage collector. The claim for Rust is that it's memory-safe without a garbage collector. This claim does not appear to stand scrutiny. If 10% of a browser has to be "unsafe", the language is seriously flawed.

<comment><USER4> > For new work, most efforts are going forward to C# or D or Go or Java, all > of which solve this problem by using a garbage collector. The claim for Rust > is that it's memory-safe without a garbage collector.

In C#, D, Go, and Java, arrays are implemented as language primitives in the runtime. Their runtimes are implemented in raw C or C++ and are not formally verified. So my question is: Why is implementing an array in C as a language primitive safer than implementing it in the standard library via unsafe code?

There's a similar story for the swap operation. Rust in fact used to have a swap operation, as you suggested, but it was removed because such an operation can easily be implemented in the library. We could have moved the code back into the compiler, but how would that have made the language safer? (In fact, I would be tempted to argue that implementing language primitives in codegen is _less_ safe, since programmatically generating LLVM IR is more difficult than writing essentially C with a different syntax.)

<comment><USER5> You didn't really answer the question. The GP was asking, how can Rust claim to be "memory-safe" if 10% of _application_ code (e.g. Servo) is unsafe code. We can accept unsafe code in the standard libraries (equivalent to how C# or Java or Go are implemented), as it's reasonable to assume it will be extensively peer-reviewed and battle-tested.

<comment><USER4> You shouldn't be writing unsafe application code. If your applications needs new unsafe _abstractions_ (which you can think of as language extensions), then you can write those. But unsafe is absolutely not for application code.

(This is, as I explained downthread, part of the reason why I dislike going around quoting "X% of the code in Y app is unsafe." Your application code shouldn't be unsafe.)

</comment></comment></comment></comment></comment></comment><comment><USER6> The recent discussion about the word 'lifetime' in rust interests me, because it _is_ something I found confusing at first... but I still don't see any of the alternatives ('scope', 'lifespan', 'borrow bound') as being any meaningful improvement.

I think the lifetime guides should be more explicit about how memory management occurs.

Something like this:

        When the instance X of type T is freed in rust and its destructor (if any)
        is invoked, we refer to this as 'dropping' X.

        X will be dropped if:

        - It goes out of a scope
        - It's immediate parent is dropped

        *T in rust is a 'raw' pointer, like a C pointer.

        *T can result in a segmentation fault like in C, if the memory it points
        to has already been dropped (Use after free).

        &T is a special type in rust that prevents use after free errors by
        applying compile time guards enforcing safe usage.

        Typically the compile time guards are automatically determined using
        static analysis, but sometimes ambiguities require explicit hints when
        writing an API. In these cases it is necessary to hint to static type
        checker what the the appropriate lifetime for a &T is.

The existing lifetime definition:

        A lifetime is a static approximation of the span of
        execution during which the pointer is valid

Doesn't really cut it for me.

It needs to be explicit 1) that lifetimes are for the static type checker, and 2) that they are more than just for borrowed pointers.

For example, for a trait or closure, the lifetime is not the duration during which the pointer is valid. It's a _lower bound_ on the _possible lifetimes of other types_ that can go into either that closure or trait.

For example, to pass a closure to a thread it must be 'static, which means that the lower bound for any lifetime used in the closure is static. This for example:

        let foo = 0u;
        let bar = |:| { let y = foo + 1; ... }

The closure in this example has a lifetime which is <= the lifetime of foo, which it uses. This is < 'static, so bar cannot be 'static.

The same is true of structures and traits. A boxed trait Box<Foo + 'a> means the struct implementing Foo contained in the box must have an lifetime of _at least_ 'a.

It's almost like we have two completely separate ideas:

1) Lifetime <\--- The lifetime of a borrowed pointer

2) Lifetime _bound_ <\---- The lifetime on a closure, struct, trait, etc.

<comment><USER7> Memory management is tangential to borrowing.

I think scope is a great word, because my own important insight was that "lifetimes" represent the scope a borrowed reference lives in -- it's not really about the life of the value you borrow from.

Yes if you have a lifetime 'a, it will correspond to some reference on the stack in a scope somewhere up the callchain.

</comment></comment><comment><USER8> What I never see discussed is how this borrowing system works in the presence of global state. Can't you have two global variables that reference the same value? How do you then go about building indexes and things like that, is there a form of weak reference?

I don't know Rust, so the question may be non-sensical, still, an explanation would be much appreciated :)

<comment><USER7> * You can have thread-local storage, which is a form of "global" state for a whole task/thread.

* You can use Arc (Atomically reference counted smart pointer), to share immutable data with all your tasks, without needing any locking. You may generate this data, and either hand tasks an Arc pointer at their creation, or send it out using channels.

* You can use RWLock or Mutex to share owned data with limited/locked mutable access between several tasks. These types are smart wrappers that only allow access to their protected value while properly locked.

Oh, and fyi the borrow checker is strictly local to a function or method. Other features of the Rust language, like the type kinds Send and Sync, are involved in checking which values are safe to share between tasks. Normal rust references (&T) only point across tasks if you get them through one of the primitives Arc, Mutex, RWLock or similar.</comment></comment>


NASA wants you to redesign their UI - <AUTHOR> http://blogs.nasa.gov/cm/blog/nasadotgov/posts/post_1291732417239.html

<comment><USER2> It looks good. I like how you integrated links that would typically be found on the sidebar on the main page you land on.</comment>


Ask sama: Can you update "Startup Ideas We'd Like to Fund"? - <AUTHOR>

It seems like many of the ideas on the old list are still relevant but since it is over 5 years old I was wondering what YC is particularly interested in now. <comment><USER2> we may update this at some point, but really, we're just interested in funding the best founders to work on their best ideas. they likely have better ones than we do.

<comment><USER3> It might be worth mentioning your new RFS article [http://blog.samaltman.com/new-rfs-breakthrough- technologies](http://blog.samaltman.com/new-rfs-breakthrough-technologies)</comment></comment>


Ask HN: Learning Lisp? - <AUTHOR> Hi HN,
I see almost constant references to Lisp and how expressive it is here in the community. As a software engineer, I expect that learning Lisp thoroughly, starting from fundamental principles, all the way through advanced concepts, will improve my technical skills and apply to many problems. Since the community seems to be so enamored with Lisp, I thought this would be the best place to ask:
What are the best resources for learning Lisp? Particularly, basic principles, advanced concepts, and maybe a bit of historical context as well.
Books, online or otherwise, or any blogs or articles, YouTube lectures or talks -- anything that really concisely and clearly explains things. <comment><USER2> Structure and Interpretation of Computer Programs (aka SICP), available here [https://mitpress.mit.edu/sicp/full- text/book/book.html](https://mitpress.mit.edu/sicp/full-text/book/book.html)

Uses Scheme (which is a dialect of Lisp) as its teaching language. This book was used at MIT for their introductory programming course. It provides a fairly deep dive into the fundamentals of functional programming.

<comment><USER3> The lectures for SICP are also up on youtube: [0]

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

</comment></comment><comment><USER4> Some guy named Paul Graham wrote a book called "On Lisp".

[http://www.paulgraham.com/onlisp.html](http://www.paulgraham.com/onlisp.html)

It's a good introduction to the Lisp way of programming using Common Lisp.

</comment><comment><USER5> Go for Clojure if you want to explore Functional Programming, Clojure is 21st Century Lisp.

Some good resources: 1\. [https://github.com/hemanth/functional-programming- jargon](https://github.com/hemanth/functional-programming-jargon) 2\. [https://maryrosecook.com/blog/post/a-practical- introduction-...](https://maryrosecook.com/blog/post/a-practical-introduction- to-functional-programming) 3\. [http://www.secretgeek.net/lisp_truth](http://www.secretgeek.net/lisp_truth) 4\. [http://www.buildyourownlisp.com/](http://www.buildyourownlisp.com/) 5\. OS Written is Lisp: [https://github.com/froggey/Mezzano](https://github.com/froggey/Mezzano) 6\. For Clojure: [https://changelog.com/posts/rich-hickeys-greatest- hits](https://changelog.com/posts/rich-hickeys-greatest-hits) 7\. [http://yogthos.github.io/ClojureDistilled.html](http://yogthos.github.io/ClojureDistilled.html) 8\. SICP [https://mitpress.mit.edu/sicp/](https://mitpress.mit.edu/sicp/) 9\. Lisp [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

</comment><comment><USER6> [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

</comment><comment><USER7> I'd recommend [http://www.michaelnielsen.org/ddi/lisp-as-the-maxwells- equat...](http://www.michaelnielsen.org/ddi/lisp-as-the-maxwells-equations-of- software/) .

A couple of "lower level" explanations - [http://stevelosh.com/blog/2013/03/list-out-of- lambda/](http://stevelosh.com/blog/2013/03/list-out-of-lambda/) (a somewhat easier start) and [http://codon.com/programming-with- nothing](http://codon.com/programming-with-nothing) \- show where part of the power comes from.

</comment><comment><USER8> Emacs...

Largely written in Lisp and is a great resource. Also has SLIME which is a fantastic way to develop with Common Lisp.

Clojure support in Emacs (via Cider) is also great.

Emacs is often the first exposure that many get with Lisp (other than SICP).

In terms of nice Lisps to work with I think Clojure is more active as a community than any other dialect, and so it's useful for contemporary projects and generally getting help and support and so on.

</comment><comment><USER9> This article is good to get an idea what lisp is all about.

[http://www.defmacro.org/ramblings/lisp.html](http://www.defmacro.org/ramblings/lisp.html)

It compares lisp to XML. In that you are programming in a tree. Other languages must be parsed into a tree by the compiler, but with lisp you are already there from the get go.

Programming in a tree is the "magic" that's unique to lisp. And it is a big deal.

<comment><USER10> Lisp is awesome, but I think you're doing it a disservice by comparing it to XML, which is a technology that was derived straight from Satan's bottom. Lisp is elegant. XML, not so much.

<comment><USER11> It's useful to compare Lisp to XML from the data notation aspect. As in, look, we already had better ideas for tree-structured data being communicated in text, forty years before XML.

</comment></comment></comment><comment><USER12> Check out the edit mode called "parinfer" \-- [https://shaunlebron.github.io/parinfer/](https://shaunlebron.github.io/parinfer/)

It integrates nicely into a number of different editors and takes the initially weird parentheses right out

</comment><comment><USER13> [http://cliki.net/Getting+Started](http://cliki.net/Getting+Started)

[http://cliki.net/Online+Tutorial](http://cliki.net/Online+Tutorial)

</comment><comment><USER14> Others have mentioned the correct books.

When you need libraries: [https://www.quicklisp.org/beta/](https://www.quicklisp.org/beta/)</comment>


How Apple badly messed up with in-app purchases on Lion and didn't tell anyone - <AUTHOR> http://gorban.org/post/10455358440/apple-messed-up-in-app-purchases

<comment><USER2> My honest opinion is that the only solution here is to pack up and leave Apple's closed ecosystem, because they clearly don't care about their developers. If you are continuing to do business with them you are sending them a message that it's OK to continue to do this. If it's a Mac app, sell it on your own website; if it's an iOS app, rewrite it for Android and sell it there.

<comment><USER3> easier said than done. How do you distribute apps to people outside the app store?

<comment><USER4> The same way you did before there was an app store - through your website. As for Android, you can sell APKs through your site that people can sideload onto their phones.

<comment><USER3> I thought the terms of service were changed so that you can't sell directly ...

How does it work? Do you just send ipa files that the user is expected to import into itunes?

<comment><USER5> Yes, but jailbreak is required.

<comment><USER3> makes sense, but I thought w1ntermute was distributing using a non-JB channel

<comment><USER6> There are mechanisms for sideloading to a limited number of devices. Those mechanisms used to be trivially exploitable to authorize an infinite number of devices, but AFAIK, Apple locked it down a lot more and blocked developers that were doing it quite a while ago.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I can't stand apps that appear free but require an in-app purchase to work fully. It feels really dishonest to me.

Yuck.

<comment><USER8> It's more about defeating dishonesty actually.

You can download full version of apps for free very easily with a Jailbroken phone.

As a developer, by using in-app purchase you have a very good chance of defeating that loophole.

<comment><USER9> There is an inapp purchase cracker on cydia now... Most apps dont actually check to make sure you purchased the content.

<comment><USER5> Most iOS apps use a standard set of system calls to check if the item has been purchased. I assume the hack works by patching the systems calls to return YES to all queries about in-app purchase items. That's how I would do it if I was building something like that. There are no tokens or keys to validate... it's just "hey system, is this paid for? okay!"

<comment><USER10> There's an option to do server-side receipt validation. That should prevent a hack like that.

<comment><USER11> Also, checking for the purchase status of an item that can't be bought would be a cheap and easy place to start.

Easy to get around with a custom crack, but it should actually be pretty effective against a blanket 'just return yes' crack.

</comment></comment></comment></comment></comment></comment><comment><USER12> Slightly OT: I notice that your apps are for sale both in the App Store and through your own site.

I'd be interested in hearing about your experience maintaining your own sales/fulfillment channel while also taking advantage of Apple's. What advice would you give other developers?

Thanks

<comment><AUTHOR> Not sure I'd advise to those starting out today, except for the following cases: 1\. You consider enterprise or other large sales, which are not comfortable through Mac App Store. 2\. You want to participate in bundles or other promotions. Technically, you don't need a store for this but you need to create a version which can be licensed outside of Mac App Store.

Personally, I started selling ImageFramer (my first Mac application) in 2006, so we first had our own store and Mac App Store came second.

</comment></comment><comment><USER13> Exactly the way Google treats customers when it messes up. Google, Apple and all these big silicon valley companies suck at customer service.

<comment><USER14> I remember Google having reported various problems with their app store in the past, so the accusation is not valid, at least with respect to what we're discussing here.

</comment></comment><comment><USER15> I hit this with Pixelmator...I actually assumed it was their fault, and just uninstalled it and reinstalled it again, after which it worked fine.

I'm on Snow Leopard still though, so might not just be a Lion problem.

<comment><AUTHOR> In-app purchases don't existing in Snow Leopard. I think it was some other issue.

</comment></comment><comment><USER16> I experienced something similar with the iOS in-app purchases but I did avoid damage like bad reviews, etc. Details here: [http://crazyviraj.blogspot.com/2011/08/dont-let-apples- laten...](http://crazyviraj.blogspot.com/2011/08/dont-let-apples-latency-mess- with-your.html)

</comment><comment><USER17> Expecting anything more than this from Apple is deluding yourself.

If they can't get fixes out for security holes until they're in imminent danger of being in the spotlight (Pwn2Own - and that's only one example; Apple are especially notorious for only fixing things when it affects their public image), then expecting them to fix issues like this is extremely naive.

</comment><comment><USER18> Also, it should be known that in the SDK terms of use, Apple warns that it's a bad idea to tell the press when there's a problem, so developers are actually afraid of publicly complaining about Apple...

</comment><comment><USER19> You could have tested your in-app-purchase, yourself, and minimized the damage. #2020hindsight

<comment><AUTHOR> If you think we developers don't test in-app purchases before releasing, think again.

It's one the most critical parts of user's experience and certainly this is not a place where we'll just write code and ship without testing.

The problem is that it didn't happen for all transactions and appeared to work for some users but not for other. Sometimes it worked for some user on one machine but not on another.

And another developer who hit it with his app in testing didn't understand it was Apple's issue. He created another test-user Apple ID and it worked then so he supposed it was kind of a glitch related to his use of the previous test Apple ID. Really, the last thing you'd think is that Apple has bugs in the payment system.</comment></comment>


Crew Dragon [video] - <AUTHOR> http://www.spacex.com/crew-dragon <comment><USER2> SpaceX dramatization of the inside during a space flight: [https://www.youtube.com/watch?v=a1EB5BQpm7w](https://www.youtube.com/watch?v=a1EB5BQpm7w)

This spacecraft looks really nice. Amazing that a luxury ride like this will be the most _inexpensive_ option for American astronauts (at least, as far as we can tell right now).

<comment><USER3> > this will be the most inexpensive option

Why do you think so? Russians are charging a steep price because of their monopoly, but it doesn't mean they have similarly high costs. As soon as a competitor surfaces, they can reduce the price. Do you think SpaceX will be able to compete on price? Why?

<comment><USER4> > Why do you think so? Russians are charging a steep price because of their > monopoly, but it doesn't mean they have similarly high costs. As soon as a > competitor surfaces, they can reduce the price. Do you think SpaceX will be > able to compete on price? Why?

They built their platform from scratch. The Russians are using 1960s tech still.

It also helps SpaceX that Russia is always threatening to embargo exports of their rocket motors. Better to have a homegrown supplier versus being dependent on Vlad.

<comment><USER3> > They built their platform from scratch.

Yes, but SpaceX makes rather different ship from scratch. Crew Dragon should be nicer to ride than Soyuz - more space, better aerodynamics. But better qualities don't mean less price.

> The Russians are using 1960s tech still.

Yes, but that makes some tech more flight-proven and amortized over time. Like rockets - Soyuz and Proton are old, but quite inexpensive (albeit with reliability issues lately). At the same time, lots of internals of Soyuz were changed.

> It also helps SpaceX that Russia is always threatening to embargo exports of > their rocket motors.

Fully agree here. But that's not quite economical issue.

</comment></comment></comment></comment><comment><USER5> I hope nobody hits the "Deorbit Now" or "Cabin Depress" button with a stray foot :)

Also, I feel like the video is missing a Jony Ive Voiceover.

<comment><USER6> I think they should have had a button labeled "Recline Seat" in between those two...

</comment></comment><comment><USER7> The NASA division I interned at was tasked with creating better living spaces for astronauts. The division was decommissioned soon after my internship ended because astronauts more or less said, "We don't need more space. We get to be astronauts."

While I'm sure it's not the case, this seems like something SpaceX designed before talking to astronauts (and I doubt that's actually the case). However, it's a crew transport and not payload transport, so their space (volume, that is) considerations could be much less particular.

<comment><USER8> Yes. It does seem unnecessarily large inside.

They mention they have nice windows to get a good view of things. Might they be planning to use this capsule for space tourism? (i.e., send a few people up to do an orbit or two and give them a chance to get out of their seats and move about.)

[http://www.zmescience.com/space/spacex-reusable- rocket-100-t...](http://www.zmescience.com/space/spacex-reusable- rocket-100-times-cheaper-0432423/)

<comment><USER9> Its an early view. Once you cover the walls with compartments for storing random crap and add a bunch of people in there it'll definitely not look "unnecessarily large".

</comment></comment></comment><comment><USER10> > > [http://www.spacex.com/sites/spacex/files/images/dragon/inter...](http://www.spacex.com/sites/spacex/files/images/dragon/interior_6.jpg)

It seems like those are emergency signals... but I wonder what "DEORBIT NEXT" means?

And also... It seems like an interesting choice to not have physical buttons, especially if they are going to be in some sort of spacesuit.

<comment><USER11> I'm actually wondering what would be more reliable: a physical button or a digital one. I would like to see a comparison.

Of course, one could argue that in both cases it depends on the implementation. Nonetheless, I think it's fun to think about what kind of buttons would the average person prefer, when their life is on the line.

<comment><USER6> I was thinking the same thing - sure, it's cool to have a glossy touch screen and futuristic touch panels, but I can't count the number of times touch screens / buttons have gone wonky on me with everything from my cell phone, to my tablet, to my microwave, to my fridge, whereas the light switches in my house are about 50 years old and have yet to let me down...

</comment></comment></comment><comment><USER12> In ManualFlight mode, according to the upper left part of the screen in: [http://www.spacex.com/sites/spacex/files/images/dragon/inter...](http://www.spacex.com/sites/spacex/files/images/dragon/interior_4.jpg) it looks like it is showing the view from an external camera.

</comment><comment><USER13> "Crew Dragon's displays will provide real-time information on the state of the spacecraft's capabilities – anything from Dragon's position in space, _to possible destinations_ , to the environment on board."

Um, that's a use case?

"Mars? Screw that. Let's hit the ISS for lunch first."

</comment><comment><USER14> Aren't touch screens a bad idea when you want to be 100% sure you're hitting the right button or switch and don't want to make a mistake?

Especially during take off or re-entry I'd imagine a touch screen would be super hard to use in a violently shaking vehicle.

<comment><USER15> Do the astronauts even do much during the shaky part of takeoff?

</comment></comment><comment><USER16> I don't understand the criticism. I think it is safe to say the design process at a company like SpaceX is likely to follow best engineering practices.

Yes, that probably means astronauts --as well as other domain experts and stake holders-- are in the design loop.

Is this the final design? Probably not. Any engineer looking at this knows exactly what this is: An evolutionary step towards a solution.

Ease-up folks, you are being given a front seat to a pretty amazing moment in our history: Humans travelling and landing on another planet.

I, for one, can't wait.

I know it's a TV show, but holy crap, we are on our way...

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

...enjoy the ride.

</comment><comment><USER17> Kinda makes you wonder if it's not overly wasteful, the Soyuz capsule has almost no room to move in when all 3 passengers are seated, you need to crawl past the emergency parachutes (which are located inside the capsule).

Every system has a direct mechanical/elctro-mechanical connection override in case of an emergency and every thing is redundant to the point of mechanically operating the heat deflector and opening the chutes.

Touch screens and capacitive buttons are nice but that capsule has more room than an SUV while every other spacecraft we had had less leg room than flying coach so would be interesting to see what they've had to give up to get that.

<comment><USER18> Soyuz has more room in the orbit module. What you see in those Soyuz photos is not all the room there is, at least on orbit, if not during the trip through the atmosphere.

The ride to and from orbit itself doesn't take that long (measured in minutes) and indeed doesn't really require a lot of space for human passengers. The space is for the rest of the journey, which normally also should go by quickly (a couple hours), at least with the modern approach they use to get to the ISS, but can take longer depending on the exact circumstances (a couple days). The recent Soyuz trip to the ISS took two days instead of a couple hours because ISS had just completed an obviously unplanned debris avoidance maneuver.

<comment><USER17> I know but the orbit module doesn't go through re-entry it was also designed to either bring cargo or serve as temporary living / scientific quarters when the Soyuz was used for manned orbital flight rather than a ferry to Mir or to the ISS.

But and it's a big but the space is separated which means a great deal this means that the Soyuz orbital module can be used to bring cargo to the ISS the space in the Dragon capsule is really just wasted, there's no way there will be cargo in there no matter how well tied down during lift off no human flight program ever had anything in the cabin that wasn't a part of the space craft or needed for life support / emergency, so it's still a bloody waste of space.

</comment></comment></comment><comment><USER19> the interior design looks like it could have as well been named iDragon.

compare with : [http://www.esa.int/var/esa/storage/images/esa_multimedia/ima...](http://www.esa.int/var/esa/storage/images/esa_multimedia/images/2010/11/inside_the_soyuz_during_a_simulation/9569395-3-eng- GB/Inside_the_Soyuz_during_a_simulation.jpg)

(and that is the 21th century "TMA" version where "M" stands for modernized and "A" for anthropometric :)

<comment><USER3> Some Soyuz design decisions were surely off the mark :) . Like, diameter of the capsule - when they tried to squeeze into a particular rocket (fairing?) diameter while having good enough aerodynamics while solid surface-to-volume ratio.

On the other hand, the whole craft weight just above 7 tons - and that's with almost 9 cubic meters of internal volume, and lots of systems still using analog electronics. And, by the way, without toxic propellants in the capsule. Granted, today one can - and should - do better. We'll see.

</comment></comment><comment><USER20> I wonder if the spacesuit and helmet designs shown in the interior video are representative of the work SpaceX is doing in-house to "de-bulk" standard suits?

</comment><comment><USER21> > Crew Dragon was designed to be an enjoyable ride. With four windows, > passengers can take in views of Earth, the Moon, and the wider Solar System > right from their seats.

Wait, are we still talking about a spacecraft?

</comment><comment><USER22> Who is this video for? Don't get me wrong, I thought it was the coolest thing ever. But do people sending astronauts in space get sold by carbon fiber and slick videos?

<comment><USER17> Well if we are frank about it Astronauts for the most part are quite useless as far as science goes, they don't really do anything in space other than PR, which is quite important.

Other than PR they play technicians to plug all the experiment modules to laboratories in the ISS and are guinea pigs for various experiments which are conducted on the astronauts them selves so they'll do an ultrasound of their eyes, keep a log of their feelings and take blood samples when needed.

<comment><USER23> From Jerry Pournelle' Blog:

"Although I pay dues, I don't interact much with the planetary society. My last experiences with them was Carl Sagan arguing for more robotic exploration and abandoning manned space exploration. Making the universe safe for robots. Larry Niven told Sagan 'Carl, I hope you realize that every time you get a convert , you lose support for space exploration. People don't hold ticker tape parades for robots.'"

[http://www.jerrypournelle.com/chaosmanor/why-icann-is- import...](http://www.jerrypournelle.com/chaosmanor/why-icann-is-important/)</comment></comment></comment>


Wonga to write off debts of £220m for 330,000 customers - <AUTHOR> http://www.theguardian.com/money/2014/oct/02/wonga-writes-off-customer-debt

<comment><AUTHOR> I assume this is because the regulator decided they couldn't make 330k people bankrupt. Its insane that they have been able to run this business for so long with so many "customers" at 5,853% APR. That's 5 thousand !!!</comment>


A criticism of JavaScript's Single Var Pattern, and a simple alternative - <AUTHOR> http://danielhough.co.uk/blog/single-var-pattern-rant/

<comment><USER2> When I started using the Node debugger a while back I encountered the problems he addresses quite often. But I came up with a different solution.

The single var pattern makes it hard to tell when you miss a comma. But rather than write 'var' over and over again, why not use comma first?

        var foo = 0 // local
          , bar = 1 // local
          , wat = 2 // local

It becomes very easy to see when a comma is missed, because the indentation is visually misaligned:

        var foo = 0 // local
          bar = 1 // global
          , wat = 2 // global

As for the debugger, I break my 'single var' blocks into logical separation:

        // modules
        var async = require('async')
          , _ = require('lodash')

        // constants
        var IS_SERVER = !process.browser

There are more ways to address these issues than just var var var var var var var.

<comment><USER3> But what is your reasoning for prefering this? Do you find it more visually pleasing?

I have always used one var per line out of habit (I think probably from C dangers with one var being a pointer and the following not if you put the asterisk by the typename rather than by the varname). However, I find it more visually pleasing too and I think there is something nice about a line of code being "atomic" so you can easily cut it and paste it in somewhere else instead.

</comment></comment><comment><USER4> Given this post I am actually curious as to whether there are certain edge cases in which a single var statement prevents a _semantic_ error that multiple var statements would hide.

This phrase piqued my interest:

> variables being hoisted half-way through a scope are declared before being > necessarily defined

now I know how hoisting works. Every var statement is silently split from its assignment so all the declarations are semantically at the top of a function scope regardless of what you do, but the assignments stay where they are. Which means that the bugs we're trying to prevent probably have to do with building up a value through sequences of assignments using previously defined variables- which could well behave differently depending on which of these patterns is used.

I'm just wondering if there's some set of variable assignments that actually behaves differently depending on which of these two presented patterns are used. So I'll need to do some testing I think.

Aside from that, I always assumed the main advantage of this pattern is as an obvious visual indicator of code smell. If you have enough variables that the single var pattern starts becoming unmanageable, that is a strong indication that the function you are writing probably should be several different functions.

<comment><AUTHOR> > _I 'm just wondering if there's some set of variable assignments that > actually behaves differently depending on which of these two presented > patterns are used. So I'll need to do some testing I think._

You could be onto something, I'd love to hear if you come to any conclusions about that. Off the top of my head I can't actually think of anything since as far as I can tell, the only difference is that one `var` statement is used and in the other it's one for each variable - they are still declared in the same place.

As for the code smell thing, that's a good point. I think after roughly the same amount of time using multiple vars would cause the same indication but it's probably more obvious with single var.

</comment></comment><comment><USER5> i've never liked it, but that's because hitting enter after a comma is ultimately just an aesthetic choice and there is no universe in which I actually mean to do this in a single statement:

var declare = 'all', your = 'variables', using = 'a', single = 'var', statement = 'then', semicolon;

</comment><comment><USER6> Just use JSHint and/or a proper IDE, which highlights global variables among other things.</comment>


Ask HN: American web working abroad - <AUTHOR>

i did some cursory searching on the topic and it was brought up in spots in other threads, but i was looking for input specifically on this topic.
i'm giving some consideration to living in another country while doing some freelance stuff and working on startups based in the US.  and maintaining my US citizenship.
anyone have any thoughts/experience/etc. on this?  any input on the legality and/or visa requirements of doing it?  any countries specifically friendly to this type of work? etc.. <comment><USER2> I have been doing this for the past year and a half (Canadian Citizen, working in Finland). It has been great, but there are some things that you need to watch out for.

\- Ensure the countries have a double taxation treaty in place, so that income you claim abroad does not have to be claimed at home (or rather you have to claim it, but not pay tax on it again) \- Residence permits for self-employed persons can take a long time in some countries. For example, Finland has two national languages, and I decided to apply in the minority language (Swedish) because I was studying it. It took nearly 5 months to get the residence permit, partially because of the extra bureaucracy involved with doing things in the minority language. \- Cost of living is a huge issue. Choose a country where you will benefit from the currency exchange (harder with the US dollar lately). I am earning Canadian Dollars, living in Euros, and it hurts.

I do not think that citizenship should be an issue, though, unless you obtained your citizenship recently. If you are a natural born citizen, living in another country under a residence permit should not affect things.

I hope some of what I said helps.

</comment><comment><USER3> Are you going to be paid in the US? Or the other country?

If the other country, you'll need a visa with work entitlements, and you'll want to fill in a U.S. Form 1040 when you file your taxes. Generally you won't be taxed twice.

On the other hand, if you go somewhere on a tourist visa - say for 3 months - and get paid in the US, it's business as usual.

<comment><AUTHOR> i'm looking at tourist visas and being paid entirely in the US. i'll probably maintain an official residence with my parents if i end up doing this.

<comment><USER3> Nice one. I've done exactly this 3 or 4 times without a problem. But,

a) Don't mention the word 'work' when passing through immigration.

b) Ensure you're carrying a credit card, and can produce evidence of a bankroll large enough to cover your entire stay.

c) Don't carry hardcopy docs e.g. functional specs, and bury email that mentions timelines in webmail or some such.

d) Think of the rest of us when you're hacking from a bungalow on Phi Phi Island.

All this sounds excessively cloak and dagger until you're in an interview room with some muppet pawing at your laptop.

</comment></comment></comment><comment><USER4> It'll depend on your expectations. You can come to Buenos Aires, Argentina. You're money will worth at least three or four times more than in the US. We're specially friendly with foreigners. Best food you'll ever get. Plenty of night life. And last but not least, incredibly gorgeous women. Cons? There always are, but you can always go back to the US.

</comment><comment><USER5> People do this from all over. I have a friend here in Jerusalem who is a translator between Japanese and English. Having made many contacts when in Japan, all the work is now done over the web in an apartment in Jerusalem.

I do web development, but I find that meeting people over the web to do this is not easy. Anybody could be anywhere and trust is a problem. Some people have a talent for self promotion, and some don't. The web is loaded with self promoters and spammers. Standing out on the web is hard. Business tends to be about personal relationships and personal trust.

I observe that the people who make contacts on the web are very talented bloggers. Joel Spolsky and 37signals come to mind, also Raganwald. Oh, and of course P. Graham and ycombinator...

</comment><comment><USER6> I'm not sure this is the best advice, but a number of my good friends do this, and they set up companies in the US (LLC) and do their work abroad while on tourist visas.

</comment><comment><USER7> I'm doing this starting in September. I'm a Canadian and will be moving to Australia with my girlfriend. I'll be doing all my work through my Canadian corporation. Going to be traveling for the first 6 months or so on a tourist visa but then switching to a spousal visa once my girlfriend gets her migrant worker visa.

</comment><comment><USER8> You want to double check the tax code. Otherwise you might get charged twice.

<comment><USER9> You would have to be unlucky for that to happen (maybe depends on country). For me I have done that before and had no issue, only local tax (just like anyone else who "exports" stuff really). On the US side, I didn't think it was an issue in my case.</comment></comment>


Ask HN: Materials science collaboration software? - <AUTHOR>

Do you know of any collaboration software / web service for materials science businesses?<p>- I run the US sales and marketing for a materials science company. - We need some sort of software collaboration tool that helps us track materials science samples. - Yes, we've STFW. - We make 200 - 400 samples per year for customers, almost all technical textiles.  It could be an A4 sheet to 1.6 meters wide x 2 kilometers in length. - Our customers will then test, evaluate and modify the materials, which they will then share with their customers... (turtles all the way down) - I'd be willing to pay for this by the month (if we were SFDC users, it could be a plug-in, but we are not). - I've seen similar attempts at life science products - but nothing that has been close enough to merit an attempt to modify. - We've had custom builds done in the past (RoR, .net, etc.), but this seems like it would be useful to groups beyond ourselves.<p>Any leads are greatly appreciated.  And yes, if someone was looking for an initial customer, we could be that group. <comment><USER2> <http://hubzero.org> is just a suggestion. See the nano science implementation at nanohub.org</comment>


To Beat the Blues, Visits Must Be Real, Not Virtual - <AUTHOR> http://www.wsj.com/articles/to-beat-the-blues-visits-must-be-real-not-virtual-1464899707 <comment><USER2> I keep seeing reports like this, but it is so VERY NOT TRUE for me. I've met so many wonderful True Friends online. Why don't we get equal respect for connecting in cyberspace?</comment>


Graphs: A Better Database Abstraction - <AUTHOR> http://whydoeseverythingsuck.com/2008/03/graphs-better-database-abstraction.html

<comment><USER2> Total nonsense. I'm no relational-junkie, but I know a bad argument when I see one.

Firstly, the author can't decide whether relations are an abstraction or not. At points he seems to be preferring graphs to relations because graphs are abstract and relations aren't ("the anti-abstraction argument rears its head in the RDBMS vs graph database debate"). At other points, he admits that relations are also abstractions, but argues that graphs are more suited to the data we actually use. Seeing as relations are just as abstract as graphs, we can ignore all the stuff about abstractions being a good idea. Yes, we know; that's why we use relations.

Secondly, despite this being a post about abstraction, he doesn't distinguish between a physical implementation and a logical representation. Yes, a SQL database can store graphs inefficiently, but that's a problem of how the relations are physically stored, not a problem with relations themselves. You can store a self-joining relation just like a graph, and optimise it for graph-like queries. That's the beauty of _abstraction!_

Thirdly, he claims that graphs are better when the structure of your system will change frequently. There's no argument for this, it's just a _non sequitur_ he drops in at the end. It's true that most RDBMSs are very static in nature, but that's because they have been designed reap the rewards of static typing. They don't have the be that way, and I can't see that graphs give you any benefit here.

Fourtly, he claims that 'you want an abstraction that reflects how you really think about the data and not some jury-rigged representational model continuously intruding itself into your thought process.' True, but graphs are just as much a jury-rigged representational model as relations. Almost every system needs to store data about users, but users are not graphs (nor are they relations. Don't confuse your data model with reality!)

A database is something we build abstractions on top of. These could be graph abstractions, or object-oriented abstractions (ORMs) or whatever. A database does not dictate the abstractions you use, it simply provides an abstraction for data storage. Such an abstraction should be chosen because it can store all the different kinds of data you need, and provide constraints that prevent the data from becoming incoherent. These are the important considerations, and they aren't even mentioned.</comment>


'You cut, I choose' - <AUTHOR> https://medium.com/keep-learning-keep-growing/on-writing-437a3dadc564

<comment><USER2> Where did you get this title from? Seems to me that it has _nothing_ to do with the article.

What am I missing?</comment>


Service provider story about tracking down TCP RSTs - <AUTHOR> https://mailman.nanog.org/pipermail/nanog/2018-September/096871.html <comment><USER2> I've never heard of routers using the ttl field for hashing, why would that ever be useful?

Also it seems an incorrect use of anycast to terminate the same flow at different machines. At Google, anycast traffic goes through clusters of maglevs that directs individual flows to the same endpoint consistently.

[https://ai.google/research/pubs/pub44824](https://ai.google/research/pubs/pub44824)

Also I'd like to echo that Fastly's NOC is great. Super responsive and smart.

Disclaimer: I work at Google

<comment><USER3> If you're doing multi-tier ECMP with the same hashing algorithm at each tier, using TTL can ensure you don't get polarization issues. Though there's plenty of other ways to avoid polarization, this works out of the box.

I have heard fastly competitors tut-tut their use of anycast as potentially unreliable in the face of issues like this.

<comment><USER4> What is "polarization" here? I am not familiar with this term applied to routing? Oscillating between different available paths?

<comment><USER3> Consider a case where you have a router balancing over four links. It chooses which link based on a hash of some information from the packet.

Now imagine you have four more routers on each of those links, hashing out over four more links. So you have a tree with 16 outputs.

If the second-tier router uses the same hash algorithm as the first one, all the packets it receives will hash to the same link, because it's doing the same calculation as the router before it.

Thus the 2nd tier of four routers will only use 4 of their outputs, instead of all 16.

<comment><USER4> I think you are describing a CLOS(spine and leaf) network data center topology here.

>"Now imagine you have four more routers on each of those links, hashing out over four more links. So you have a tree with 16 outputs."

I'm not really understanding this as a link exists exactly between only two routers do you mean "path" instead?

>"If the second-tier router uses the same hash algorithm as the first one, all the packets it receives will hash to the same link, because it's doing the same calculation as the router before it.

And this is kind of the tax of flow based preservation which is fine compared to the price of TCP reordering no? Efficient hash-based ECMP utilization is going to be a function of the distribution of source IP and port in the 5 tuple used in hashing. You can see this outside of EMCP for example when running LVS with the hashing algo and you have customers that are all behind the same NAT box. But also there's nothing stopping you from using different hashing on your spine tier than you do on your leaf tier. You could assign a 4 tuple on one and a 5 tuple on the other.

At any rate a common CLOS ECMP design with BGP is to put each ToR switch in its own ASN and then load balance across ASNs. So using your example and a 3 tier CLOS network. If Tier 2 had the 16 outputs then the a router should ECMP over the 16 different ToR ASNs to the destination.

<comment><USER2> > And this is kind of the tax of flow based preservation which is fine > compared to the price of TCP reordering no? Efficient hash-based ECMP > utilization is going to be a function of the distribution of source IP and > port in the 5 tuple used in hashing.

mcpherrinm's example is worse than what I think you're suggesting. Because a given second-tier router will _only_ receive packets that hash to a specific set of values, if that router has the same number of downstream links that the first tier router had, it will send __all __packets it receives to the same link, ignoring other links. Which is a terrible trade-off for avoiding OOO packets.

The more reasonable trade-off is giving up on utilizing all routers for a __single __flow, to avoid OOO packets.

<comment><USER4> >"The more reasonable trade-off is giving up on utilizing all routers for a single flow, to avoid OOO packets."

Huh? No you would never want to use "all" routers for a single flow anyway. Each router just needs to make a deterministic selection for each packet. The alternative to a hash based scheme would be per packet load balancing which is practically never used b/c it gives you TCP packet reordering.

>"if that router has the same number of downstream links that the first tier router had, it will send all packets it receives to the same link, ignoring other links. Which is a terrible trade-off for avoiding OOO packets"

No it would not be a terrible trade off. Optimizing for maximum link utilization only matters if you have congestion in your network and even then ECMP is congestion agnostic. In reality your leaf network has less downstream link that it has upstream. A common topology is 4x4x2 where each leaf node has two downstream links to two ToR switches.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> A consistent route for every packet in a flow is considered desirable, but it's not an entitlement or a requirement of the IP protocol. An DDOS prevention tool that insists that TTL be the same for every packet is broken. Here's one that checks for inconsistent TTL, but it has some tolerance for variation.[1] The one mentioned in the original post didn't like a difference of 1 in TTL.

[1] [https://fortiguard.com/encyclopedia/ips/12934/tcp-ttl- evasio...](https://fortiguard.com/encyclopedia/ips/12934/tcp-ttl-evasion)

<comment><USER6> I'm not a networker, but sounds like from a correctness standpoint, a problem on Fastly's end -- they're reusing frontend IPs for distinct sets of machines, and traffic directed to the 'wrong' PoP is dropped hard rather than attempting any kind of internal routing

Of course that kind of routing would create a potential bottleneck for an attacker to exploit ("simply" force traffic to the wrong IPs to the wrong PoP, assuming $attacker had this level of access to the backbone), but that's the problem Fastly are supposedly paid to deal with

Their scheme is fine and dandy with a protocol like DNS where UDP retries are transparent and TCP is a tiny fraction of weird traffic, but for business applications handling credit cards, surely the occasional RST is already too many

Or another way to look at it, basically they're saying their IP addresses are special snowflakes and actually the full address includes the route, and source networks are wrong for assuming things work the way they're supposed to everywhere else on the Internet

<comment><USER7> Not really. Anycast is fairly standard and usable for stateful connections - the issue is again middleboxes fucking with stuff and a weird default of incorporating TTL in the ECMP hashing algo

<comment><USER8> Expecting all flows to have all packets on a flow delivered via the same path is extremely optimistic.

</comment></comment></comment></comment><comment><USER9> We run Arista 7280SR's on our edge. I went looking, and as far as I can tell, the TTL is NOT part of the default ECMP algorithm on this platform (Jericho chipset)? We certainly haven't tuned this setting one way or another. I would love for someone more experienced with Arista kit to weigh in on this, since it seems like it may be platform dependent. We do have a support contract so I can reach out to them directly, too.

These commands are the best I could find browsing the Arista docs/blog/forums.

edit: fixed code formatting

edit2: We're on the EOS 4.20.x version train, fwiw

      #show port-channel load-balance jericho fields | grep TTL
      IP TTL field hashing is OFF

      #show load-balance profile (output snipped for brevity)
      </comment><comment>---- default (global) </comment><comment>----
      IPv4 hash fields:
         Source IPv4 Address is ON
         Protocol is ON
         Time-To-Live is OFF
         Destination IPv4 Address is ON

<comment><USER10> The Arista units are 7504N which are running 4.20 or later, and I believe they use the Arad or Petra chpiset.

</comment></comment><comment><USER11> I wonder how such anycast setups would deal with MPTCP.

<comment><USER8> I don't think MPTCP is going to interact very well with modern high load sites. Even using unicast, it's going to be hard (impossible?) to ensure that all the individual flows make it to the same nic queue, which is what you'd really want for performance. I suspect this is part of the reason why it hasn't caught on very much. (Also, Google doesn't seem to want to invest in a good tcp stack on Android, instead they put an additional tcp layer (http/2) and then built tcp on top of udp (quic) ).

<comment><USER11> Sad. Apple seemed interested, at one point anyway.

But damn, it does work amazingly well site-to-site. I've managed ~50 Mbps throughput using bbcp (four streams) between Tor .onion services via OnionCat. And ~190 Mbps total from one source transferring simultaneously to five target servers. Each peer had six .onion services.

With six OnionCat interfaces per peer, in MPTCP full-mesh mode, there are up to ~36 subflows per TCP connection. So using bbcp with four streams, there are as many as ~150 tcp6 connections via Tor per bbcp transfer. And with five simultaneous transfers, the MPTCP kernel in the source VPS was managing up to ~750 tcp6 connections. That's impressive!

[https://ipfs.io/ipfs/QmUDV2KHrAgs84oUc7z9zQmZ3whx1NB6YDPv8ZR...](https://ipfs.io/ipfs/QmUDV2KHrAgs84oUc7z9zQmZ3whx1NB6YDPv8ZRuf4dutN/)

<comment><USER8> Apple is still pushing it, which is great. I'm just not sure how well it's going to scale -- MPTCP adds an extra layer of indirection, and extra locking in the easy case where it's just one server handling an IP. In the load balancing case, people are going to have to teach their load balancers a lot of new tricks to get the subflows aligned. If using anycast, the client is likely to be using multiple networks, so using the same server address seems likely to get to a different pop; exposing a pop specific extra server ip seems like something people don't want to do, since exposing that may make it easier to do a single pop.

I've been debugging an issue where incidentally I'm hitting 1gbps on a single tcp connection (server to server, with tls), so I'm not sure why MPTCP is required? ;) But I guess if we had it, I would probably hit 2gbps instead of being capped by the one nic.

<comment><USER11> Where it gets useful at consumer level is when your phone can hit WiFi and 4G simultaneously, so you can aggregate. And it's even more useful when both WiFi and 4G are iffy, so you seamlessly use one, the other, or both.

And yes, if both of your servers have to gigabit NICs, you can get 2 Gbps. But only if those uplinks aren't bottlenecked at 1 Gbps at the rack or data center level.

</comment></comment></comment></comment></comment><comment> CKN23-ARIN TL;DR: Incapsula, Imperva, Sucuri, Fastly, and likely others are using anycast incorrectly.

<comment><USER7> Not really...The issue is more using TTL in your ECMP hash algo. It's a weird default to have.

<comment> CKN23-ARIN That's what caused the issue to surface, but the root cause is offering a stateful service over anycast. There is no hard requirement that you ECMP flows consistently. Spraying may be sub-optimal, but it must be accepted.

I do agree that including TTL by default is weird, though.

<comment><USER12> Am I the only one who sees a different issue here? The problem is neither stateful service over anycast nor TTL based hashing.

Being a DDoS service, one can imagine the need to have stateful POP since each edge needs to track the TCP state in order to provide DOS protection. At the same time, it is understandable that the state can't be replicated at scale.

As for including TTL in hashing algorithm, it is aimed to solve link under- utilization so it is also a valid implementation.

The real bug here is Arista CPE mangling the TTL bits for the Client Hello packets. I always hate it when networking gear meddles with the protocol stack. Sure it gives some flexibility but time and time again, it ends up breaking something somewhere in the path since much of internet networking is a pile of assumptions. Tampering with protocol fields unilaterally is going to break someone's assumptions somewhere down the path.

<comment><USER10> To clarify, the Arista routers are the ISP's border routers. It was the residential/business customers' SOHO routers, of various makes and models, that were not decrementing the initial TCP SYN.

<comment><USER12> Thanks for pointing out. Sorry I overlooked that part. Perhaps I got primed by the opening statements which implied that problem happened only after placing new Arista routers and hastily assumed that it was Arista's routers that mangled the bits.

<comment><USER10> You are correct, the problem started only after placing new Arista border routers. The previous border routers were not doing ECMP. The issue was a combination of the use of anycast, diverse Internet transit egress, this model of Arista defaulting to using the packet's TTL in its ECMP hash calculations, and the end-customer router CPE egressing packets that are part of the same TCP connection with variable TTL values. Change any one of those items and the issue would not have shown up.</comment></comment></comment></comment></comment></comment></comment>


Ask HN: Why Google Analytics (GA) Chrome Extension Has Been Deprecated? - <AUTHOR> <comment><USER2> I didn't even know there was a GA Chrome extension. What did it do? Show the stats of your own site instead of having to go to their dashboard?

<comment><AUTHOR> Yes and also I think it showed the number of clicks on page elements like links and buttons on hovering on them</comment></comment>


Zimbra's new Desktop: Look ma, no browser - <AUTHOR> http://blogs.cnet.com/8301-13505_1-9871953-16.html <comment><USER2> saying this is the 'best email client ever' without a comparison chart is lame.. :(</comment>


High-Level Rendering Using Render Graphs - <AUTHOR> http://ourmachinery.com/post/high-level-rendering-using-render-graphs/ <comment><USER2> The trend is clear: Rendering engines are becoming compilers.

At the dawn of real-time rendering everything was both bespoke and fixed- function. You would call a different optimized codepath to draw a floor, a wall, or a ceiling. If the platform was amenable to it you might use self- modifying code to optimize the time/space tradeoff. The datasets were small enough that a simple array was always the default "right" choice until you were running out of memory.

Gradually the demands generalized and became more algorithmic than low-level in nature. DOOM's best-known optimization was in using BSP for visibility.

Now - while there's still a great demand for smarter algorithms - most of the pipeline complexity comes in this kind of generalized dependency analysis stuff to maximize use of resources across a broad, complex, configurable pipeline without hand-tuning everything, which is a familiar compiler problem to have.

<comment><USER3> One of the best talks at Siggraph last year was on Bungie's particle system Destiny 2 (slides are here: [http://advances.realtimerendering.com/s2017/index.html](http://advances.realtimerendering.com/s2017/index.html)). The talk was an elegant breakdown of how they (1) created a CPU interpreter for a domain specific language describing particle parameters, (2) ported it to the GPU (even running an interpreter on the GPU for parts of the production game!), and (3) how they converted it into a compiler for the obvious performance wins.

Apparently running bytecode interpreters on the GPU is not uncommon: [https://dolphin-emu.org/blog/2017/07/30/ubershaders/](https://dolphin- emu.org/blog/2017/07/30/ubershaders/)

</comment></comment><comment><USER4> Long post about rendering.

Not a single pretty image.

What gives?

<comment><USER5> Yeah, I started skimming and at the end got the impression it was a thought piece and the author hadn't even coded anything yet. I also kept wondering why the new terminology instead of "scene graph". There's probably a difference, but I didn't find it compelling enough to read in depth.

<comment><USER6> A scene graph and a "render graph"/Frame graph in Frostbite terminology are not the same. I would recommend checking out:

[http://www.gdcvault.com/play/1024656/Advanced-Graphics- Tech-...](http://www.gdcvault.com/play/1024656/Advanced-Graphics-Tech-Moving- to) and [https://www.gdcvault.com/play/1024612/FrameGraph- Extensible-...](https://www.gdcvault.com/play/1024612/FrameGraph-Extensible- Rendering-Architecture-in)

for a more in depth view.

I would describe it as such: A scene graph specifies _what_ needs to be drawn, while a render graph specifies _how_ it should be drawn and what the dependencies of each step in drawing is. For example, a render graph is used to reduce the number of image layout transitions in a frame by looking at what layout is expected for each operation and figuring out where to put the layout transitions, instead of letting a human place the layout transitions which will inevitably lead to unnecessary transitions when the scene becomes complex enough.

I didn't think this article was bad even if it is maybe less concrete than the slides I linked.

</comment></comment></comment><comment><USER7> Imo a group of Passes should be called a Stage or a Phase, not a module. The terms module is too easy to overload.</comment>


S3 best practices, to catch a predator - <AUTHOR> https://konghq.com/blog/s3-breach-prevention-best-practices-enterprise-cloud-security/ <comment><USER2> I can't see the words catch or predator in the text, so I assume they must have changed the title already (toned it down). Together with a background image taken at the Berlin Holocaust memorial it would've been two pieces of weirdness for an devops article.</comment>


Magic Ink - <AUTHOR> http://worrydream.com/MagicInk/

<comment><AUTHOR> Here's my question, why _aren't_ we designing interfaces like this? It's 2009 now, and I don't see things changing in the next few years.

I've spent the best part of the day mulling over this question (it's evening here now), and the best I can come up with, it that it's _hard_.

With desktop apps, which is where most of my experience lies, there's simply no easy way to do much of what he's suggesting. Putting a few radio buttons and drop-down lists on a form is simple, but to create something like the flight schedule <http://worrydream.com/MagicInk/p/flight_redesign.png> is not.

Why is this? Is it because it really is too hard to do this on an individual basis? Are our expectations too low? Is it lack of exposure to ideas like this? In short, why are we still displaying choices pretty much the same way we have been for the last 30 years?

<comment><USER3> I remember finding this article on Digg in April '07. To me it was gospel - <USER2> contacted the author thinking for sure someone else had shared his vision and wanted to bring these ideas to all kinds of applications. At the time, not really - he had gotten a lot of attention for being innovative, but in terms of deeper interest it was mostly from those academically interested in the ideas. (although perhaps Apple hired him for their deep interest as well).

Why did this fantastic article take so long to make its way to hacker news? In fact, I ask myself why I did not submit it here having read it half a dozen times over the last couple years.

I'm not sure I can answer this question. But to me there is most definitely a delay between the output of innovative, unproven ideas, and the acceptance of even discussing these ideas in an engineering community. Maybe somewhere in this dynamic lies the answer to both our questions.

<comment><USER4> Absolutely. I rarely see such insightful, constructive, and inspirational writing about UI design floating around the web. Relatively little has changed since this written, and it still looks so innovative and even "futuristic." I think just about everyone on HN can take something new away from this.

</comment></comment></comment><comment><USER5> This guy (Bret Victor) also wrote an excellent article a few years back, Alligator Eggs <http://worrydream.com/AlligatorEggs/>

Every now and then, probably about twice a year, I come across something so good I print it out and keep it. This is one of those articles.

(apologies if only cubicle67 gets this joke)

<comment><AUTHOR> Only doing what I'm told :)

</comment></comment><comment><USER6> This is clearly the best Human Computer Interaction article I've ever read. Great stuff. Thanks.

</comment><comment><USER7> I really like the the idea of star-rating "whiskers":

<http://worrydream.com/MagicInk/#p115>

</comment><comment><USER8> (ahh my eyes. the font is so small and squished. when i 'apple-+' the menu disappears off to the right but oh well)

<comment><AUTHOR> There's a PDF link at the very top of the page. Is it more readable for you that way?</comment></comment>


Minimal Linux Live - <AUTHOR> http://minimal.linux-bg.org/ <comment><USER2> The best designed and implemented of these scripts has always been NetBSD's build.sh. Builds the whole OS, including base userspace, compiler etc and ISO images. Configurable. And it cross compiles so you can do the whole thing from OSX or whatever. It builds all the tools you need to do the build, such as (cross) compilers etc.

Basically download source then [1] ./build.sh -U -u -m amd64 release

You can change the options too. Very well designed, if you like this sort of thing. And there is a script to build it all and run the test suite under qemu just to be sure [2].

[1] [https://www.netbsd.org/docs/guide/en/chap- build.html](https://www.netbsd.org/docs/guide/en/chap-build.html) [2] [http://www.gson.org/netbsd/anita/](http://www.gson.org/netbsd/anita/)

<comment><USER3> For a Linux distro, definitely check out the Yocto Project which has similar goals. It is quickly taking over the embedded Linux BSP space.

In addition to configuring and building the entire OS base image, including cross-compiling, managing the base image, including custom third-party software, testing with a qemu image etc., it also coordinates working with a team of developers during development by managing build artifacts, and controls software updates to the new distro after it is deployed by building apt- or rpm- (or opkg-) style packages automatically.

Maybe a bit of a learning curve, but it is very well documented and has a large community and some big companies behind it. Definitely worth it for the flexibility.

\- [https://www.yoctoproject.org/](https://www.yoctoproject.org/) \- [https://www.yoctoproject.org/docs/current/yocto-project- qs/y...](https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto- project-qs.html)

</comment></comment><comment> vezzy-fnord You might also be interested in the Aboriginal Linux project, which is similar in intent, but also devoted to easy cross-compilation: [http://landley.net/aboriginal/about.html](http://landley.net/aboriginal/about.html)

</comment><comment><USER4> You can try it here: [http://copy.sh/v86/?profile=custom&cdrom.url=https://dl.drop...](http://copy.sh/v86/?profile=custom&cdrom.url=https://dl.dropboxusercontent.com/u/61029208/minimal_linux_live_07-Feb-2015_32-bit.iso)

</comment><comment><USER5> This is really cool - have a read of the tutorial it presents what's going on in a concise manner. Makes it all seem quite simple... until it gets to the end. "Nice work" to the author.

</comment><comment><USER6> Out of curiosity, what userspace `libc` do you provide?

<comment><USER7> The only userspace application is busybox. I think it is statically linked against whatever you have installed on the machine doing the build.

<comment><USER6> So one can't install other applications or build upon the resulting OS? Is it just for light shell scripting then?

<comment><USER7> You can so long as they have libc statically linked.

</comment></comment></comment></comment><comment><USER8> Nice. I know of some people at the LinuxBBQ forums who should like this.

</comment><comment><USER9> Awesome, I've been looking for mini ubuntu iso. Ubuntu server is good but still bloated. It should be called Ubuntu Mini or Mini-Linux. Now all we need is for DigitalOcean to add this and we can use it for development :)

<comment><USER10> This is unrelated to Ubuntu.

Ubuntu has a minimal install - it's called the net install, it's a short iso, and it installs much less than a server install.

</comment></comment><comment><USER11> So, a system that automates generating a Linux distro from scratch. Except for the fun, I can't figure out the application. It doesn't seem to match Buildroot or Yocto for embedded systems, but people can assume that; I suggest describing the objectives in the first paragraphs.

<comment><USER12> As an old-time user of Linux, I'm surprised by the dis-interest in the idea of collecting a short, sweet, succinct set of minimal scripts with the intention of demonstrate the building a new Linux instance. Linux is all about building ones own distribution, always has been .. unless you have someone else do it for you.

But this is not a distro. Its more of a porting kit.

It used to be that the only way to use Linux, was to use scripts like this. Well, it point of fact: all distros are constructed of such mechanics. This is a very minimal one. The next step would be to put a 10_compiler.sh step in the pipeline, and then build the kernel again.

This project seems to be a new, fresh look at the game, I suppose. The linux- from-scratch approach is also a good way to break in newly built hardware in my experience, too.

If you've got nothing but these scripts, you can .. continuing the tradition .. continue to put Linux .. just about anywhere.

So, like I said .. a porting kit. Linux All Things.

<comment><USER13> Actually, considering the current state of Linux I wouldn't mind a set of instructions that details the setup of a more _modern_ base Linux, including stuff like systemd and udev.

<comment><USER14> Linux From Scratch maintains both a classic and systemd based guide these days.

[http://www.linuxfromscratch.org/lfs/view/stable/](http://www.linuxfromscratch.org/lfs/view/stable/)

[http://www.linuxfromscratch.org/lfs/view/stable- systemd/](http://www.linuxfromscratch.org/lfs/view/stable-systemd/)

Note also that they have a project similar to the one linked to: [http://www.linuxfromscratch.org/alfs/](http://www.linuxfromscratch.org/alfs/)</comment></comment></comment></comment>


So You Want To Be A Writer? That's Mistake #1 - <AUTHOR> http://www.ryanholiday.net/so-you-want-to-be-a-writer-thats-mistake-1/

<comment><USER2> This is a really great point.

I'm a big advocate of Kathy Sierra's "minimum badass user" strategy. Basically, try to write as little about yourself and write what will be most useful to improve someone else's abilities. I'm not amazing at this (yet), but it's my main goal.

Identifying too closely with being a "writer" or "coder" or whatever can be detrimental to doing more meaningful work. That's because it's all about you. But really, it should be all about your users and how you are making their lives better.

The more you can focus on "What will help _my reader_ be awesome?" instead of "What will _I_ write?", the better your writing will be.

Nobody cares about how awesome I am (and they shouldn't!), but everyone cares about becoming more awesome themselves. Resist the temptation to focus on yourself and shift that focus to them and you'll automatically be better than 99% of writers out there.

If you spend a week learning something remarkable and then show others how to do it in only an hour, it's a huge win for them. By focusing on learning and then sharing what you learned in a succinct way, you are accelerating the progress of others. That, more than anything else, will make you a great writer. The metric should be how much more powerful your readers are after reading your writing.

(Naturally, I'm talking about a specific type of writing here, not fiction or historical writing, etc.)

<comment><USER3> _" I'm a..."_

What matters is that the topic about which a person is writing is something about which they feel passionate - for example the process of writing in the original article...and in your post...and in this post. So, while I agree that anyone who cares about how awesome I am will be sorely disappointed, my goal is to say something interesting and entertaining - not necessarily entertaining in the sense of amusement but in the sense of engaging the reader's mind.

I suppose that the Pythonic Mr. Anchovy has no more likelihood of going from a chartered accountant to writer in one go than he does of becoming a lion tamer. But that seems a wanting-to-be-a-writer-strawman.

I read somewhere that there's no such thing as a person who is passionate about writing who doesn't write, and I am too lazy to google it.

The strong sense of wanting to be a writer is wanting to be a better writer, and that means practicing the craft and throwing manuscripts over the transom and the internet is a great place for doing that, e.g. HN provides an excellent opportunity to obtain feedback about one's writing, and not just from internet trolls, but from "really fucking smart people."®

Of course that's just my opinion.

<comment><USER4> As I look at my office bookshelf--which runs from tech stuff to random stuff bought downtown and not taken home, I question "about which they feel passionate". It is certainly reasonable to say that Hennessy and Patterson have a consuming interest in hardware design, but do they feel passionate about it? Would Wright Morris or Anthony Burgess have used "feel passionate" as a reason for writing those volumes of autobiography?

</comment></comment></comment><comment><USER5> The author sets up a dichotomy between living an interesting life and learning rules of grammar. But writing well is deeper than either. If you don't practice and learn from the masters, then even your most fascinating stories will turn to mush.

"Take any good piece of writing, something that matters to you. Why is it good? Because of what it says. Because what [sic] the writer manages to communicate to you, their reader. It's because of what's within it, not how they wrote it."

Obviously not true! Even our patron saint Paul is praised for his style as much as his insight. His clarity is a product of taste, training, and vigorous editing. And, I'm confident, of a strong wish to write good prose.

There's something to Ryan's point, but he doesn't express it very well. The article could be much better.

Just one example: the first paragraph namedrops Schopenhauer, but the article doesn't make use of the philosopher's thought. Instead, he's only brought in as a sideshow to support the author's point. Does he respect Schopenhauer's philosophy? If so, why not engage with it? If not, why cite him as authoritative? Sloppy!

</comment><comment><USER6> These types of posts that deal with identity always bring me back to Paul Graham's identity post [1] and Bruce Lee's quote on limitation [2].

I feel that by being too focused on the identity, you fall in love with the action, not what the action does or can do. Like Ryan Holiday is saying, they don't write to say something, but for the sake of writing.

With Bruce Lee in regard, he went beyond his formal training in wing chun and studied other forms of fighting and also studied philosophy along with other topics. It seems beneficial to a person to seek out other interests and intertwine them, I feel that that's what creates more beautiful work.

[1] [http://www.paulgraham.com/identity.html](http://www.paulgraham.com/identity.html) [2] [http://zenpencils.com/comic/36-bruce-lee-there-are-no- limits...](http://zenpencils.com/comic/36-bruce-lee-there-are-no-limits/)

</comment><comment><USER7> On a related note, you should probably just read Schopenhauer in general.

His philosophical works are very inaccessible (to those unprepared) but his essays are brilliant and casually consumable.

[http://www.amazon.com/Essays-and-Aphorisms-Classics- ebook/dp...](http://www.amazon.com/Essays-and-Aphorisms-Classics- ebook/dp/B002RI9K9K/)

FYI: He was the philosopher who influenced Nietzsche the most.

<comment><USER8> Yes they are very readable and his thoughts often feel like they were written last week. It's surprisingly timeless.

Schopenhauer was not a big proponent of empty, pointless philosophizing. His stuff is all practical and to the point.

</comment></comment><comment><USER9> I think it's good advice, but I also think it is wrong. There are writers who I read for the sheer joy of the skilled way they construct their prose- Salman Rushdie would come to mind as one.

That doesn't mean he doesn't also have worthwhile things to say. But there is undoubtedly a skill to great writing that is only improved by doing more of it.

<comment><USER10> They aren't writers they are entertainers.

<comment><USER11> Hmmm... so is it necessary for someone's writing not to be enjoyable or entertaining in order for them to be thought a proper writer?

<comment><USER10> No, professional mass market writers are entertainer. Not sure how else to say it.

</comment></comment></comment></comment><comment><USER12> The one point he makes there, which I find to be terribly important, is the bit about reading a lot.

I don't claim to be a great writer or anything, but I've managed to get an article or two[1][2] "out there" and have actually had a few people (including a former English professor) give me some praise for my style. But outside of Creative Writing 101 my first year of college, and H.S. grammar class, I have done little in the way of "training" to be a writer.

Except... I read a lot. I mean, a _lot_. Like, a really, really, lot. I read voraciously, which is a trait I appear to have inherited from my mother. And I can't help but think that if you read a lot, you'll inevitably absorb enough of _something_ to go a long way towards becoming a decent - if not great - writer, if you choose to write.

So yeah, I think "read a lot" and "write a lot" are really the keys to writing well. Sure, this might not get you to James Joyce territory, but for writing marketing material, blogs, technical docs, etc., it can take you a long way.

And as far as that goes, somebody famous (Stephen King, IIRC) said pretty much the same thing in a book on writing. "Read a lot, and write a lot".

I'm with Ryan here... don't label yourself as "a writer" just read and write. If you _really_ don't get basic grammar and punctuation, read Strunk & White, or _Eats, Shoots & Leaves_. That should be enough to enable you to write at a respectable level.

I would add one more thing though... since I started writing more for specific reasons (that is, beyond random ranting on my blog) I do read with more of a conscious eye on the details of what I'm reading, in terms of structure, voice, etc. And I freely admit I will shamelessly crib useful ideas from other writers. Of course, it might not be the best thing for my interest in writing technical content that my favorite writers include Dean Koontz, Stephen King and H.P. Lovecraft.

[1]: [http://www.infoworld.com/d/application-development/why- you-s...](http://www.infoworld.com/d/application-development/why-you-should- care-about-your-local-hackerspace-221628)

[2]: [http://www.infoworld.com/d/application-development/how- provi...](http://www.infoworld.com/d/application-development/how-provision- users-in-cloud-world-227362)

</comment><comment><USER13> If writing is only a means to an end and it's wrong to identify as being a writer, why shouldn't the same analogy apply to programming?

I've taken an excerpt from the article and replaced certain words with analogous words related to programming: _" The problem is identifying as a [programmer]. As though assembling [code] together is somehow its own activity. It isn't. It's a means to an end. And that end is always to [create] something..."_

Advice given to people who want to pursue programming versus pursuing writing seems really different.

1\. Why is that the case, and why are the two not quite analogous?

2\. Is it just the bias of our perspective, as the "techie" people?

<comment><USER14> He points out, part of the reason his advice holds is that getting published isn't hard. And also that readers enjoy anything written, regardless of its writing style, as long as it's a good read. The same isn't true for programming. Getting 'published' requires getting a compiler to agree to run your code, getting peers willing to work with you, and finding a company which thinks you should be hired (or starting your own). And computer users won't accept buggy programs, even though they may accept poor grammar. Also, the industry is perfectly happy to tell programmers exactly what programs to write and pays them well. In effect, being a "writer" isn't that great of a goal because writing (in itself) for readers isn't that hard--it's hard finding something worth saying. Programming is hard and most programmers write for companies who already have an audience.

edit:

Maybe a better analogy to this article is not to programmers, but to startup founders. Don't set out to be a founder, set out to make something people want, and to do that requires a little bit of life experience too.

</comment></comment><comment><USER15> If you write enough and are willing to study, you can learn the proper grammar or diction. That said, it is sad that we don't seem to have authors who write fantastic prose anymore. Rather, everyone writes to the lowest common denominator, because (as the author notes), the prose isn't what matters. I feel this same way about music - I think it's often harder to find successful _skilled musicians_ than it is to find successful musicians who found something interesting or different to play, regardless of their skill.

<comment><USER16> > _it is sad that we don 't seem to have authors who write fantastic prose > anymore_

To spin this around a little: we don't talk about authors in the past whose prose isn't worth going back to. Shakespeare had many contemporaries, but you might be hard pressed to name more than a couple.

Good prose can be challenging, and people don't want to be challenged all the time. I admire Pynchon's writing in Gravity's Rainbow - I don't want every book I read to be like that.

Or to put it another way: there are many novels from the 19th century that were massively popular at the time, but totally forgotten about now. They were novels that were pretty average in terms of prose, but had stories that were relevant to people at the time, and gripped them.

I doubt if in a hundred years people will still be reading the Da Vinci Code - but I can guarantee books like Infinite Jest, The Satanic Verses, Nights at the Circus, and the like will be attracting critical attention.

</comment></comment><comment><USER17> You could go out and experience a bunch of crazy shit and at the end of it all, not know how to put it in words that people will understand. That's what makes writing a craft. You could write passionately and still not get to what you're trying to say because you don't know how to make the words work for you. But I do agree, there's no point in writing something unless people are compelled to read it.

<comment><USER16> > _there 's no point in writing something unless people are compelled to read > it_

I would probably disagree with this, if only in the sense that there are several works I can think of that _at the time of publication_ were ignored, only to be re-appraised at a later date. It can be very hard to determine whether your writing is compelling, and even if your contemporaries decide it isn't there's no reason it may not be relevant in the future.

</comment></comment><comment> FLUX-YOU Pretty good post.

Writing on pure impulse is good for practice and discipline and short-length things, but it won't help you when you need to write a ton of stuff that has flow and needs to be coherent. It is great for a first 'driver' to get you doing something productive, but you need to combine it with additional 'drivers' along the way (planning, coherency, etc.)

For instance, I could not imagine GRRM being successful with ASOIAF if it was written without discipline and planning.

An interesting contrast is that this author praises unique ideas, but discards its execution as less important (or not important), while most programmers are more concerned with the execution of ideas, since the ideas in that realm are very common (usually).

In both cases though, it's ideal to have both a good idea and good execution. In the case of this post, the execution is in the word choice, word play, and other writing elements I don't remember from school because I was too busy writing drunk and editing drunk.

</comment><comment><USER18> It's about what's within it, not how they wrote it. But at the same time what's within it evolves with practice. With novels and poetry imagination is the limit. Practice pushes that forward, probably more so than with the sort of writing Ryan is doing. He makes some great points though.

</comment><comment><USER19> Oddly enough, a lot of that applies to programming as well, though to a lesser degree.

<comment><USER20> I think it would be exactly like programming if piracy was legal.</comment></comment>


Ask HN: How to realistically prepare for the robotization of the U.S.? - <AUTHOR> So their is a huge swath of automation coming down the pike. Automated cars, automated work force, video based education.
Many of these things still require human input although we've set ourselves up so that people don't get paid or paid very little (an example is Google translate which Jaron Lanier likes to use as an example).
I'm curious what insight people here have to mitigate being a victim of all of this. I know customer service jobs and the like will always be available but those are low paying and require a certain personality type. Mainly upbeat and happy...all the time. We seem to be moving toward a lack-of-a-middle class society. I am still convinced there are enclaves that will be well paying that don't require an MIT degree or a customer service personality that borders on senility. So feel free to respond.That is all. <comment><USER2> The real question is "What do we do when we are forced to acknowledge that a free market in labor doesn't work?"

Most of us reading this live in a bubble. We work at things that are, for now, very hard to automate. Employers bid up our wages. We may even tell ourselves that smart people are always in demand. It won't always be this way.

How will your brain be valued when prosthetic brains can make all those dullards you look down on now smarter than the un-assisted you? Will the poets with minds that (still) can't be artificially be boosted start pitying you and giving you free advice that you should have become more creative?

One of the biggest challenges for all us smarties will be to try to imagine ourselves on the outs, and to imagine economic systems very different from the one we have now.

<comment><AUTHOR> "One of the biggest challenges for all us smarties will be to try to imagine ourselves on the outs, and to imagine economic systems very different from the one we have now."

I already know what that's like. If any of the 'smarties' are writing an anthropological fucking study on the cave people of U.S. society just ask. lol

</comment></comment><comment><USER3> I believe even customer service jobs are not immune to technological unemployment. I see no reason why a modernized automat couldn't replace most of the food service industry. And why couldn't an upgraded Siri replace most customer support workers?

The problem is when company owners replace human laborers with computerized laborers. CEOs are the ones who see the profits from the increased efficiency and the employees see nothing. This seems fine in a free market system yet if we follow through to the end game, we find incredibly efficient companies owned by a few people, with no human employees. If nobody is employed except CEOs, who will have money to buy their products? Robots can't buy stuff (yet)!

I believe the only solution is to pay people for robot labor. This may seem counter-intuitive, but when society has no income, there's nobody to buy the goods your robots have so diligently created.

Two solutions I've come up with are either a guaranteed minimum income or robot labor profit sharing.

An example of robot labor profit sharing is forming a union of "robot laborers" in which human employees invest in robots and receive the profits their robots generate. It would essentially be employees outsourcing their work to robots and receiving the profits.

One thing is certain. If we don't make significant progress on this solution, in favor of society as a whole, economic inequality will continue to increase until our economy breaks.

I am deeply interested in this topic and would love to hear from anyone who is working to find a solution to this problem.

<comment><AUTHOR> I was asking based on the assumption that social, cultural or 'institutional' solutions are not going to happen and that individuals are on their own.

<comment><USER3> As an individual? I'd suggest researching the hardest problems for computer AI to solve, then picking a career in one of those areas. Generally any area to do with creativity and the human condition should remain viable for a long time. Luckily, programming and design should remain relevant for quite a while.

<comment><AUTHOR> Creativity huh? Like music? j/k

</comment></comment></comment></comment><comment><USER4> My recommended mitigation strategy would be to stick to things that computers do badly, and save as much money as possible. If someone asked me to pick a (potentially) lucrative career that won't be replaced by robots or computers in the next 50 years, I'd tell them to go to culinary school.

<comment><USER5> Except that it's not at all lucrative.

<comment><USER4> I'm not talking about line cooks. I'm talking about executive and personal chefs. I know several, and they all make high five to low six figures.

</comment></comment></comment><comment><USER6> Full disclosure: I am probably too optimistic re: AI (in 1982 I put an AAAI bumper sticker "Artificial Intelligence: it is For Real" on my car :-)

I think that not only in the USA, but in most developed countries that within 10 years robots will be doing a lot of routine physical jobs like stocking shelves, farming, flipping burgers, etc. Lots of white collar knowledge workers will be partially displaced also.

Preparation: favor jobs like management, very high tech, nursing, etc. that are more difficult to replace.

</comment><comment><USER7> 1\. Provide for your own i.e. grow your own food and customize your own manufacturing. 2\. Develop a strong ethic of value add to your interactions with other people. 3\. Empower,not just encourage, other individuals to be creative rather than consumptive, thus generating freedom and accountability.

</comment><comment><USER8> [http://www.washingtonpost.com/blogs/the- switch/wp/2014/02/18...](http://www.washingtonpost.com/blogs/the- switch/wp/2014/02/18/some-predict-computers-will-produce-a-jobless-future- heres-why-theyre-wrong/)

</comment><comment><USER9> [http://www.economist.com/node/21552897](http://www.economist.com/node/21552897) might be relevant. (Pay-walled.)

</comment><comment><USER10> Learn robotics.</comment>