NASA caught Photoshopping an image of Saturn's moons. What were they hiding? - <AUTHOR> http://gizmodo.com/5659999/nasa-caught-photoshopping-an-image-of-saturns-moons-what-were-they-trying-to-hide

<comment><USER2> They aren't hiding anything, they were combining three monocolor photographs into a color composite, but had to account for the time difference and the motion of the two planets. They posted the raw photos, there's nothing in them.

People need to quit jumping after shadows. The more people cry wolf, the less likely people are to believe it if a real conspiracy falls into their laps.

</comment><comment><USER3> removing lens glare. nothing to see here.

it's probably the work of the guy that updates the website.</comment>


Back door found in Allwinner Linux kernels - <AUTHOR> http://www.theregister.co.uk/2016/05/09/allwinners_allloser_custom_kernel_has_a_nasty_root_backdoor/ <comment><USER3> Especially after seeing that "root _my_ device" string in the code, I think there's much to be said for this in relation to today's world of locked-down devices which resist control from even their owners. Given that their SoCs are meant for such devices, maybe it's AllWinner (or someone at the company)'s way of rebellion against that. If so, I'm glad that there are still people out there who do not believe in the user-oppressing culture of "security" that seems to have become the norm and are actually trying to do something about it. Maybe it really was just a debugging oversight, but either way, I'm not outraged by it --- contrary to what the media seems to say. This is a _local privilege escalation_ for software intended to run on a device that you --- and only you --- are supposed to own anyway.

Relatedly, here is a post 6 years ago by someone putting in a root backdoor in a device he designed --- and explaining how to use it: [http://www.bunniestudios.com/blog/?p=1140](http://www.bunniestudios.com/blog/?p=1140) If that was today, someone would discover it, scream "backdoor! security vulnerability!", and it would be all over the news like this one. And that makes me very sad.

<comment><USER4> The post you linked is very different - it appears to require user interaction, which is a perfectly ok way to allow root access.

This allows _any app_ to gain root. _Without user interaction._ That is insane.

<comment><USER5> In any case, a huge amount of Android devices out there run outdated versions of the kernel, drivers or Android itself with privilege escalation vulnerabilities.

The only thing that is insane here is that we all deem this as "normal".

<comment><USER6> So the update treadmill is normal? That's a very weird thing to assume is normal.

        "Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else—if you run very fast for a long time, as we've been doing."

        "A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!" [1]

<comment><USER7> Are you confusing "normal" with "desirable"?

The update treadmill is normal, in the classic sense of the word.

<comment><USER6> I don't consider it normal _behavior_. It's obsessive in its very nature. But I understand that systems cracking and malware writing are pernicious, antisocial behavior, and should be addressed with heads on pikes outside the city wall.

<comment><USER5> You say it's antisocial behaviour like they do that just for the sake of it, when there is money to be made. Like sending spam, etc. You want a botnet? Then compromise stuff, and then use the botnet for your benefit. It's not antisocial in any way.

<comment><USER6> Like making money is a justification. So now we're up to _their_ head and their _entire family 's head_ on a pike.

Taking over something and operating it without permission is highly congruent with naval piracy. So perhaps hung from the yardarm is better. At any rate, something gruesome, public and nasty needs to happen to them.

Yes, I think the basic ... drive to do this is just latent in people, and they initially did it just for the heck of it. There was no money in it to start with.

How this could be considered anything other than deeply antisocial is beyond me.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Well... they were mostly know for GPL violations and less-than-propper support for everything they claimed (try reading the SoC spec for the A20. If you can find it. Other examples include GPS support, proprietary drivers without support, not releasing sources, etc.).

But apparently they stepped up their game. Even for debugging this is an odd one.

<comment><USER9> They tell you the names of many registers. What more do you want?

(I really miss the old days when you got a document that explained _everything_ about your processor. I have an ARM port of an experimental OS waiting for a new board with a complete data sheet. It's been a year so far.)

<comment><USER3> _try reading the SoC spec for the A20. If you can find it._

Googling "AllWinner A20 datasheet" brings in good results.

"Broadcom BCM2836 datasheet" doesn't. All you get is part of the GPIO registers, and absolutely NO electrical specifications. (Part of me really wants someone working there to "take one for the community" and leak the full datasheet. Ironically, that's how the AllWinner docs were originally released.)

</comment></comment></comment><comment><USER10> > Although it doesn't appear to have made it into the mainstream kernel source

Now, who wants to blame upstream kernel maintainers for not merging in all the dirt around and requiring high quality of code submissions?

<comment><USER11> _raises hand_ Me! I actually run the upstream kernel on an Allwinner device and was looking into why certain audio features weren't enabled. Turns out that someone had written a patch and it'd got stuck in kernel-patch-submission hell, including mutually conflicting requirements from the ALSA and ARM SoC maintainers. This seems to be basically the norm from what I've seen - <USER2> bikeshedding, vague and changing requirements, and other delays that make it almost impossible to get support for modern SoCs merged before they're long obsolete.

I think upstream support for the chips affected by this got stuck in long arguments about the most elegant way to support their clocking and reset infrastructure, which needs to be solved before actual peripheral drivers can be developed. The H3 seems to be approaching the point where it has enough upstream support for a handful of limited uses, over a year after the mainlining effort started. The A83T is still held up on getting the support code necessary to actually boot Linux merged.

<comment><USER4> If only drivers were cleanly separated from the kernel like they would be on any sane OS...

<comment><USER11> That was a nice idea back in the days when hardware was made up of discrete, standalone single-purpose peripherals. Unfortunately there's no such thing as "cleanly seperated" anything in modern SoCs - everything's interdependent. For example, the main USB controllers on Allwinner chips are basically standard EHCI, same as on any PC, except they also rely on the centralized Allwinner clock-generation and reset block and the Linux EHCI driver has to co-operate with the driver for it. There's a whole bunch of shared infrastructure within Linux to make this possible which has to be updated from time to time due to new requirements.

I think modern Intel chips are similar, except that they run closed-source management firmware to help them look more like a collection of separate devices to Windows - but they aren't and Skylake can't enter lower CPU power states unless the SATA link is in power-saving mode and a whole bunch of other peripherals co-operate because they share hardware. ARM SoCs just don't have the magic firmware that lets the drivers hide this from the OS.

</comment></comment></comment></comment><comment><USER12> What are the permissions on /proc/sunxi_debug/sunxi_debug?

Anyone know?

This could be locked down so that, say, only processes which are members of a certain group can open a file descriptor to this proc entry.

This is a lot of unnecessary effort to implement something that can be obtained with a simple /bin/rootmydevice executable that is chmod u+s. (Though it is somewhat more streamlined: no intervening process execution is required).

Which, in turn, is a lot of effort to reinvent sudo.

(But of course, those are arguably front doors; you can easily scan the filesystem image for items that have u+s perms.)

I would do this kind of hole differently: why not just hack the kernel so that any process can do setuid(0). Or, slightly hide it: say, setuid(-42) gives you root privs.

<comment><USER13> It is created with 0666 as the mode. [https://github.com/allwinner- zh/linux-3.4-sunxi/blob/A83T/ar...](https://github.com/allwinner- zh/linux-3.4-sunxi/blob/A83T/arch/arm/mach-sunxi/sunxi-debug.c#L69)

</comment></comment><comment><USER14> And everything hidden in this undocumented monster-commit:

[https://github.com/allwinner- zh/linux-3.4-sunxi/commit/7cc9a...](https://github.com/allwinner- zh/linux-3.4-sunxi/commit/7cc9a8fff679fcd31bca7d18c8b3b960796d032f)

He should have added:

3\. add a backdoor;

<comment><USER14> I like how the repository's history was discretely rewritten since then.

Commit 7cc9a8fff679fcd31bca7d18c8b3b960796d032f was replaced by bcc3e09783ca31039183d5084d8480bd76d531f5, without the sunxi-debug.c file.

Compare [https://github.com/allwinner- zh/linux-3.4-sunxi/commit/7cc9a...](https://github.com/allwinner- zh/linux-3.4-sunxi/commit/7cc9a8fff679fcd31bca7d18c8b3b960796d032f) (original) with [https://github.com/allwinner- zh/linux-3.4-sunxi/commit/bcc3e...](https://github.com/allwinner- zh/linux-3.4-sunxi/commit/bcc3e09783ca31039183d5084d8480bd76d531f5) (modified)

[https://github.com/allwinner- zh/linux-3.4-sunxi/blob/7cc9a8f...](https://github.com/allwinner- zh/linux-3.4-sunxi/blob/7cc9a8fff679fcd31bca7d18c8b3b960796d032f/arch/arm/mach- sunxi/sunxi-debug.c)

[https://github.com/allwinner- zh/linux-3.4-sunxi/blob/bcc3e09...](https://github.com/allwinner- zh/linux-3.4-sunxi/blob/bcc3e09783ca31039183d5084d8480bd76d531f5/arch/arm/mach- sunxi/sunxi-debug.c) → 404

<comment><USER15> Fortunately there are un-modified forks. Created one more just for evidence: [https://github.com/koja/linux-3.4-sunxi](https://github.com/koja/linux-3.4-sunxi)

</comment></comment></comment><comment><USER16> There's even a bug in this back door (assuming The Register accurately copy and pasted). They're setting the effective UID to 0 twice instead of setting saved GID to 0. Not that it makes much difference but it does show a further example of their incompetence.

</comment><comment><USER17> Funny to see how it spreads [https://github.com/search?q=rootmydevice&type=Issues&utf8=%E...](https://github.com/search?q=rootmydevice&type=Issues&utf8=%E2%9C%93)

<comment><USER18> This is a search on the github issues, and not on the source code.

<comment><USER17> You can click on "code" to see the source code copies. I found these issues more interesting as it seems the different repo admins have wildly different approaches to responding.

</comment></comment></comment><comment><USER19> I like to compile and install my own OS images on the hardware I purchase. Of course the smartphone industry does not make that easy, if at all possible.

Hence I am forced to choose other form factors.

It would be nice to flash my own choice of BIOS. As far as I can tell this is still not too common. That is a project to which I am willing to devote large amounts of time should the information needed ever become public.

It seems the newer the hardware the more complicated and difficult this becomes. By my estimation, there is certain value in older hardware because it is not as complicated and can be easier to control.

Here is an idea that stays with me year after year: another open source OS project that chooses a _single item_ of hardware and supports _only that item_.

Silly fantasy: Perhaps a deal is struck with one or more factories that can produce it. Perhaps the terms could be public. Maybe user-developers become faithful and loyal buyers of the hardware, because they like the control. Perhaps they directly pay the costs of production through donations. I have no idea what would happen. That's the point of trying it.

Building this sort of symbiotic relationship between open source user- developers and a single hardware manufacturer based on a single item, one could reason it is in the best interest of the manufacturer to open the specs to the developers, if not the public.

I leave it to you to list all the many reasons this is not worth doing. Then sit back and enjoy the status quo.

But for those of you who are avid users of an open source OS, I ask you to consider:

Do you ever get tired of watching the project trying to keep pace with new hardware? How do you feel about when the manufacturers will not disclose the specs? Are you OK with binary blobs in your "open" system? How about not knowing whether your OS of choice is going to work with your new hardware? What if there was one item of hardware that you could be absolutely sure was always going to work with your preferred open source OS, and to its maximum capacity?

OK, you may now return to chasing the new (locked-down) hardware. Thank you for your time.

<comment><USER20> Stallman has a post about his Thinkpad X60, one of the very few laptops where you can install a totally open BIOS.

The Librem laptop was another attempt at this, but it failed pretty badly. They couldn't get around a lot of the "binary blob" issues with modern hardware. They're attempt may in fact show that truly open firmware on modern x86_64/amd64 machines may be impossible.

There's Novena, but I believe that's ARM based (which is possibly the best bet for truly open hardware today)

<comment><USER21> What is awful about that one is that they even skip microcode updates.

</comment></comment></comment><comment><USER22> Just tested it on Orange Pi, it's too easy. Does that means that all Allwiner based tablets and phones are vulnerable?

<comment><USER18> It was a debug feature that was left enabled in the kernel source for H3 and newer cpus.

They should have done #ifdef DEBUG in the kernel source...

</comment></comment><comment><USER23> This is excellent news for those that value individual freedom and the right to modify the devices you paid for.

<comment><USER24> It's a bit more than individual freedom.

The permissions are set to world writable, so you're giving every app the right to modify your system.

I'm still not sure why Allwinner resorted to this silliness instead of using su like a sane developer. If anyone could loop me in that would be appreciated.

</comment></comment><comment><USER25> Please turn JavaScript on and reload the page.

DDoS protection by CloudFlare

...um, no!

<comment><USER26> I don't see why Cloudflare would require JS to be on

<comment><USER27> It's what they use to try and detect if your browser is a real browser, not a fake one. Which is very hard to determine without Javascript.

<comment><USER26> It looks like an important goal

Maybe they can do it better and not turn people without JS away (at least while accesses are at a regular level)

</comment></comment></comment></comment><comment><USER16> Anyone know how long the Allwinner kernel source had been available for before this was discovered? They were previously known for GPL violations.

<comment><USER24> The source was shared in June 2015. It could have been later though, Allwinner tends to rewrite their Git history.

Thomas Kaiser appears to have been the first person to discover it on April 29th, 2016. [http://irclog.whitequark.org/linux- sunxi/2016-04-29#16314390](http://irclog.whitequark.org/linux- sunxi/2016-04-29#16314390) (Thanks to HD Moore for linking me.)

From what I can tell, it went unnoticed for slightly under a year.

</comment></comment><comment><USER28> [http://irclog.whitequark.org/linux- sunxi/2016-04-29#16314390](http://irclog.whitequark.org/linux- sunxi/2016-04-29#16314390)

(search for rootmydevice)

</comment><comment><USER29> The best backdoor is the backdoor that is labeled _debug_.

</comment><comment><USER30> This is China.

</comment><comment><USER31> Chinese espionage at work... I wonder how many foreign agencies can access my phone: USA, UK, China, Russia, ...

<comment><USER32> Hanlon's razor applies here, but guising backdoors as programming/deployment errors gives plausible deniability.

<comment><USER33> Guise? They distributed source and the patch is not at all obfuscated. Eight consecutive lines like "cred->uid = 0;" and then printk("now you are root\n"), so it's really easy to spot in a diff.

Don't see why they did it, but they did in in the plainest and most visible way I can imagine.

<comment><USER17> It's not THAT easy to spot in a diff because a lot of these kernel source code repository dumps are basically 1 single commit with the entire source code; any existing kernel.org git history is lost. So you'll have to figure out which mainline revision they started working from, and manually diff with that (which will probably turn into a huge mega-patch).

<comment><USER33> That's orthogonal.

What you're saying is that the diffs are hard to work with in general. What I'm saying is that in a diff (be it large or small, a single commit or many), the code they wrote is the most visible and understandable way to do what they did.

<comment><USER17> What better way to disguise a backdoor than an apparently deliberate "debug" utility? I mean, if they have to distribute source code sooner or later (which they do since Linux is GPL), this _looks_ much more innocent than any super obfuscated "hidden" source code that would be discovered eventually anyway.

Not saying this was the actual intention here, but it'd be a plausible way to go about it. It certainly appears the backdoor is running on lots of devices in the wild before it got noticed (even when it's this obvious in the diff(!)), so "mission accomplished"? :)</comment></comment></comment></comment></comment></comment>


Why President of Brazil's Comments Matter - <AUTHOR> https://latinamericareports.com/what-bolsonaro-says-matters/2906/ <comment><USER2> What's the solution to so many world governments now being led by totalitarian intellectual degenerates, especially since it increasingly negatively affects the whole of humanity? Are we waiting for a vague, benevolent singularity to conquer us stupids? Or are we humans becoming the yeast cells in the brew of our own demise? I seriously posit this for intelligent answers as I'm stumped.</comment>


Q. Why is it so hard to swat a housefly? A. It sees us coming in slow motion - <AUTHOR> http://www.independent.co.uk/news/science/q-why-is-it-so-hard-to-swat-a-housefly-a-it-sees-us-coming-in-slow-motion-8818124.html

<comment><USER2> Weird, i just "clap my hands" above the fly... Success rate is about 95% so far (problems on vertical surfaces :))

<comment><USER3> The hardware is fast, but the software has a simple exploit.

</comment></comment><comment><USER4> So doubling the refresh rate would make TV for Dogs interesting?</comment>


Fictional Arpanet dialog - <AUTHOR> http://www.arpanetdialogues.net/vol-iv/

<comment><USER2> It had me for a while, and is still entertaining enough to keep reading, but just to be clear: this is fictional.

Oblique disclaimer: <http://www.arpanetdialogues.net/disclaimer/>

Interview with one author: [http://www.newscientist.com/blogs/culturelab/2011/04/so- reag...](http://www.newscientist.com/blogs/culturelab/2011/04/so-reagan-signs- into-this-chatroom.html)

Previous HN thread: <http://news.ycombinator.com/item?id=2402649>

</comment><comment><USER3> The fact that this is inauthentic should be reflected in the title.

<comment><USER4> Looks like the poster changed the title after it hit the front page. I just read the whole thing thinking it was real.

<comment><AUTHOR> Actually I posted it while reading it thinking the same thing, came back to find it changed out from under me. Kinda sad, it's off the front page now but it's a really neat piece of fiction, would've liked to have updated it with something other than the locked title it has now.

<comment><USER4> Such a letdown to find out it was fiction. The site was really misleading. I was wondering why all the characters seemed to be so stereotypical of the person at some points though

</comment></comment></comment></comment><comment><USER5> Oh, so that was _fiction_. You should have looked a little closer before posting this under its previous title.

I know there's an 'upvote' arrow. But sometimes I wish there was a 'shank in OP's goddamn kidney' glyph.</comment>


How my role as CTO has changed as we've grown from 1 to 100 engineers - <AUTHOR> https://engineering.gusto.com/how-my-role-as-cto-has-changed-as-weve-grown-to-100-engineers/ <comment><USER2> I was an engineer #1 hired by a "CTO" and we grew to 50 engineers. His story/growth didn't really change much, however. He was a coding machine, a true "10x engineer", and programmed day and night. He even started up a second company while working on the first. He built both codebases from scratch, and even re-wrote the first company's core codebase at one point.

He did attend exec meetings and make all major technical decisions, but I never really felt he had to grow into anything.

When we got big enough to start worrying about compliance, security, and HR tools, we did it together and moved on to the next thing.

<comment><USER3> Pretty sad that it sounds as if security was an afterthought in your design.

<comment><USER4> There are a whole host of compliance and security issues that you don't have to (and shouldn't) worry about when you're small. Employee background checks, documented disaster recovery plan, 3rd party pen testing, etc. Those are things you worry about once you have built something. It's different than just application security which itself can always be improved over time even if it wasn't an afterthought.

<comment><USER5> SarBox, GAMP, GAAP, cGMP, PCI-DSS... The devil hath many names.

</comment></comment></comment></comment><comment><USER6> "At this point, I believe technical co-founders have a binary choice: Stay on the technical track and hire a professional manager (usually given the VP of Engineering title), or give up coding and focus on the management aspects yourself. It really isn't possible to do both."

For me this is the key quote.

I have a friend who went the other way from the author of this article. He started as one of two company founders working out of an apartment doing all the technical work while the other founder focused on business stuff.

When the company grew to a point where he had to decide between staying technical and people management, he hired a VP of Engineering, stuck to coding, and still codes 6-8 hours a day.

The company is now at about 200 people, is _profitable_ , raised a series A after figuring out the business model, and blowing past the goals set by the investors. His stake in the company is worth many tens of millions today.

Just an existence proof that 'sticking to coding', _can_ be a viable strategy, if an unusual one.

He is not interested in blogging/social media etc, or else I'd have persuaded him to write up his experience.

I have to agree with dang. _Most_ people running successful startups don't have (or take) the time to write about it.

Which is too bad (imo). We could use more writeups from the successful subset.

<comment><USER7> I'm another of those technical founders who choosed to stick with the code. Even though we are still very small, it has been a subject of conversation since the beginning between my co-founder and me, and after 2 years of trying to convince me to assume managerial tasks, she finally came to term with that idea.

It helps that a late-founder joined us and is already assuming the VP of Engineering tasks. This was done even before our seed round, at only 2 developers. The sooner the divide is made, the sooner you can fully concentrate on building the product.

I never really liked the "CTO" title, as I don't think of myself as a "Chief" or "Officer. I'd rather be called Lead Developer.

</comment></comment><comment><AUTHOR> Hi all!

I'm the author of this post. Happy to answer any questions here about how my role as CTO of Gusto has changed over time!

</comment><comment><USER8> Did you have to get up to speed on al the details of fraud, risk, and FinTech? If so how, what resources did you use to figure it out? If not, did you hire expertise, bring it in-house, and only have to implement bits of it into Gusto?

Second question: how did you determine to shift development from SF to Denver? What criteria went into selecting Denver over other areas? How did you figure out what to move their and keep in SF?

Third question: how are you doing? I remember in S08 when you were working on PicWing. We're still working on Poll Ev!

<comment><AUTHOR> Hey Brad!

I'd say it was a combination of hiring in-house experts (we did that to learn about payroll taxes), and lots of reaching out to people and not being afraid to pepper them with questions (for example, in the case of learning about the ACH system: [https://engineering.gusto.com/how-ach-works-a-developer- pers...](https://engineering.gusto.com/how-ach-works-a-developer-perspective- part-1/))

As for Denver, a ton of factors went into choosing it. Ultimately though, we just loved the people, talent, and culture in Denver so we went with that!

I'm doing great! It's so great to hear from you again.

</comment></comment><comment><USER9> I have a few questions!

1) Did others in the org recognize you couldn't spend as much time on code, and they appreciated your time elsewhere? I can imagine there being some growing pains as you slowly gave your responsibilities to someone else, and in the meantime things not getting finished as quickly/productively. (Not to mention the fact that an average engineer wouldn't like spending 12-14 hours per day coding)

2) What is your favorite advice from the books you've read? What made the biggest impact on your actions?

</comment><comment><USER10> I use Gusto and like it for it's simplicity. It makes a complicated part of running a company much smoother.

That said, I'm very curious what exactly all those engineers are doing every day. What's the most meaty part? Payroll? Dealing with govt? Keeping the servers up?

I think unexpected scaling pains are one of the most interesting and unsolved issues with being a CTO and would love to hear more about that at Gusto.

<comment><AUTHOR> I can certainly share some of the meatier areas that engineers at Gusto work on.

\- Calculating payroll and filing quarterly and annual forms are very complicated tasks that (a) is different in every state and (b) changes frequently as federal, state, and local tax laws change. Doing payroll in 50 states is similar to doing payroll in 50 different countries

\- Benefits is similar to Payroll in the sense that it's also very different in each state. The business logic is complex and a significant amount of engineering work goes into simplifying it for us customers

\- Because we move billions of dollars per month through the banking system, we have a lot of the same technical challenges as a Stripe, Square, Paypal, Venmo, etc. We have a dedicated FinTech, Payments, and Risk teams for this.

\- Security is super important to us, since we have a lot of PII/PHI and financial informaiton

\- Gusto is about 600 employees today and we invest in lots of internal tools for non-engineering functions, an enterprise data warehouse, and security.

\- We are also looking into what the future of payroll looks like. A personal goal of mine is to rid the world of the concept of a "payday". Why shouldn't employees get paid whenever they want for the work that they did? [https://techcrunch.com/2018/06/21/gusto-flexible- pay/](https://techcrunch.com/2018/06/21/gusto-flexible-pay/)

\- Technical debt: When you grow as fast as Gusto does, you inevitably accrue technical debt and it's important that we carve our engineering resources to keep that low.

There's a lot more in there, but hopefully it gives you a sense of how 100 engineers can add up pretty quickly!

<comment><USER11> We use gusto across multiple jurisdictions where tax laws change every year and our bookkeeper our employees put them through funny circumstances. I've been impressed by how many problems they've made invisible (just notify us) or we sent over and they handled. Cannot say the same about other folks we use here (ex: zenefits caused multiple lapses in coverage).

</comment></comment></comment><comment><USER12> When you were larger, you state:

"At this point, I believe technical co-founders have a binary choice: Stay on the technical track and hire a professional manager (usually given the VP of Engineering title), or give up coding and focus on the management aspects yourself. It really isn't possible to do both."

Since you chose the management track, what did you do/who did you hire (in what levels) to take care of engineering at the level you were previously doing? Or were you effectively functioning as a standard IC so any developer could take your role?

<comment><AUTHOR> It was important to us to be deliberate about hiring senior ICs since I was more on the management track. We already had some in the company so that helped as well.

</comment></comment><comment><USER13> We went from 1 engineer (me) to 4 last year. So I'm in the 2-10 stage. I coded prototype and first X customers, which has become literally 20X in the past year. I still code most of the time, and the primary problem I am encountering is being willing to transition technically difficult aspects of the product. This _has_ to happen, as I am finding myself becoming a huge bottleneck.

<comment><USER14> The old cliche to work your way out of a job really resonated with me when I made this transition. It is natural to want to take on a task for yourself and to think you're doing your team a favor by shielding them from details you have a mastery on. But, once you get into the mindset of enabling everyone by focusing on training and knowledge sharing, you find that people are far more capable than perhaps you give them credit for and in fact do them a disservice by not giving them more reign. Worst case, you get a bit of sanity back from being less of a bottleneck. It may not seem like it, but most of the time the people applying tight time pressures are ourselves (customers also have more patience than we give them credit for), and it is generally worth it to invest in teaching someone to fish, as it were.

<comment><AUTHOR> +1.This is a great summary of my experience

<comment><USER14> Fun fact we took over the lease at 425 right after y'all. That picture on the blog with the couches does not do justice to how packed the office was when we did our site tours!

</comment></comment></comment></comment><comment><USER15> > To accomplish this, I decided to fly to New York to hole up in a hotel room > for three days to read a few highly-recommended management books.

> I decided to focus on growing Gusto's engineering team, and not our code. > The technical books on my desk starting getting replaced with books like > Mindset, High Output Management, and The Score Takes Care of Itself — still > three of my favorites today.

If the three books listed in the latter excerpt were not those three books you read in the hotel, can you please tell us what books they were?

</comment><comment><USER16> How did you maintain compliance and security before you could have someone full time on it? How did you deal with audits? Did you hire an engineer full- time dedicated to this, outsource it, or do it yourself? (I ask because I do this now but at 8 people it's starting to take up too much of my time as CTO)

How does it work at your size now?

<comment><USER17> I think either of your options would work. If you have in-house skills (yourself and/or another engineer), exploit them. If you have a trusted third party who can help, spend some time and money on them. If neither of those work and you feel you need to hire someone, do that (although I'd go with the other two options first). Also, as you undertake these audits, keep a solid record of documentation (questions and answers) as most due dil exercises will be made up of many of the same questions. Stock answers go a long way.

</comment></comment><comment><USER18> What do people think about the career trajectory as an individual contributor in an early stage startup? I'm the kind of person who not only enjoys coding, but hates dealing with management, hiring, meetings, etc. I always fear that I will be pushed to take on a management role. At the same time though, I really enjoy working with a group to build something from scratch. In your opinion, do you think it's better that I don't join an early stage startup?

<comment><USER19> No! I was the only engineer at a startup for 18 months (!) and we're now up to 7. Some of the other 6 will never be expected to take on management roles.

One of the great things about being an IC at an early company is there is so much to do. You get to put your fingerprints on a lot of things across the company because there won't be enough people to spread out all those tasks. As the company grows, those foundations become opportunities for you to grow from sole contributor to technical lead on each one; so much so that the hardest part will be choosing what to give up control of, not to what to keep contributing.

If you find yourself in this situation, I strongly recommend being involved in the search for your VPE. It could be really frustrating to build the technical foundations for a company only to be so frustrated by a poor manager being hired above you without your input that you might even quit. Wouldn't be good for your equity, either :).

PS this implies that if you don't want to grow into mgmt, you'll need to grow into being a good lead developer. Early startups have no room for people unwilling to grow.

</comment></comment><comment><USER20> I am a CTO, going from 2 engineers to a total engineering org of approximately 20.

Much of my time is non-coding, but I don't believe you have to totally give it up. I try to leave a day per week free of meetings to code / review code. I keep some projects that, while useful for the company, can be worked on irregularly and slowly, and are not super essential to be accomplished quickly (which is why they aren't prioritized for the engineering teams).

<comment><USER21> Giving up coding is what you do for your team, so they don't have to deal with the half finished B grade work you did inbetween doing the serious shit they can't do

<comment><USER20> Wow! What an extraordinarily unhelpful and bad attitude you have

<comment><USER22> While crude, I believe he is right.

I have seen it too many times with project managers and now my CTO. Trying to still code and fix that terrible bug with already too little time. Ends up slowing down everyone because he never can get anything finished, or breaking things on a Thursday at 6:49pm because of the half baked solution he thought was good enough, but exploded in production, which he then has to spend 1 more hour fixing and 6 more hours cleaning up the aftermath. Spend your time reviewing and mentoring and try replacing yourself with someone who has time.

You now have important shit to do.

<comment><USER20> I have determined that I can still code sometimes and not ruin engineering. Nothing is black and white

<comment><USER22> That is good. You know your situation best

</comment></comment></comment></comment></comment></comment><comment><USER23> This surprised me at first:

> having difficult conversations with individuals is never fun

But apparently "difficult conversations" is a Valley euphemism for "firing people" and doesn't mean "discussing difficult engineering problems".

<comment><USER24> How is this specifically a Valley euphemism?

<comment><USER25> For most working persons globally, getting fired isn't something that involves a "difficult conversation". Working stiffs do not get that degree of attention to their feelings. Suggesting that this phenomenon is common to (or even characteristic of) the high-income and acutely socially-aware circles of Silicon Valley should not be construed to exclude its observation elsewhere, but SV is one of the few places where the behavior is common, and hopefully the only place that feels the need for a polite euphemism.

</comment></comment></comment><comment><USER26> \- How much do you miss coding? Do you ever do it?

\- How would you and the company be different if you stayed on the technical track? Was it a legitmate option?

\- You mentioned you had to give up one or the other, what made you decide go management over technical?

<comment><AUTHOR> Definitely miss coding! I still do a little during our hackathons but otherwise don't have that much time to commit to any projects. I would just slow down the team.

<comment><USER27> Thought of contributing to open source to keep your hand in; while not creating bottlenecks, dependencies and project stress in your own company?

</comment></comment></comment><comment><USER28> This guy flew from San Francisco to New York to read books in a hotel? Like... what?

<comment><USER29> I understand where he's coming from. Sometimes to create a big personal change you need to disrupt your routine in a big way. For me, a change in environment really helps me think or focus differently.

New York may have been special in some way that could help that change.

I think the anecdote underscores how tough it can be to make that shift from doing something you love and are good at into new responsibilities you're not as strong in yet.

</comment></comment><comment><USER30> Yikes, that open office picture looks like my nightmares.

<comment><USER31> The justification I hear for ignoring the data against open offices is: "Every other unicorn has an office like this and they get work done so why can't we"?

<comment><USER32> In a place like SF where office space is as expensive as it is, I wouldn't be shocked if the savings in rent from this kind of floor plan outweigh any productivity losses and I'd bet that is a primary reason why there are so many open offices.

Edit: That said, that one definitely doesn't look like the most efficient use of space.

<comment><USER33> > _In a place like SF where office space is as expensive as it is_

You could always _move_. I for one would love more non-SF companies; it'd open up more options and opportunities to get off the sinking ship that is SF.

<comment><USER32> I would also love to see that, for a number of reasons.

</comment></comment></comment></comment></comment><comment><USER34> Fantastic article! I'm in a similar position as you, and will have to face the same decision you did, so this was refreshing and edifying to read. Thank you for taking the time to write it.

One thing that stuck out to me was your mention of focusing on "diversity and inclusion". Why did that become a necessary thing for you to focus on? It seems political, and entirely unrelated to the actual work of building a good engineering team. Isn't it enough to ensure that anyone and everyone has the same opportunity to get hired? At my company, my goal has been to ensure that all candidates get judged without focusing on attributes like gender or ethnicity; to make sure that the doors are open to everyone, no matter who they are. I then try to trust that the people who want to work in this field, and this company, are capable on their own to come to us.

Has that been your experience, or has there been good reason to put extra effort into finding/favoring candidates with certain characteristics?

</comment><comment><USER35> Given that you were essentially learning management while in the role, did you ever end up hiring people with prior management experience to report to you? What was the mentoring like for these folks - were there cases where your reports actually had more experience than you?

<comment><AUTHOR> That certainly did happen. In fact, I would say its quite necessary for growing startups to continually hire people with more management experience than anyone else in the company. There isn't a sense of ego associated with that. Many of them are really just excited to be on this mission together.

</comment></comment><comment><USER36> it's refreshing to see someone who actually successfully scaled a company write an article about "here's how we did it", instead of bunch of failed entrepreneurs who write medium posts about why they think their startups failed to either feel better about themselves or to capitalize on their failure with the attention they get from the blog post (answer: they don't know why they feailed, and that's why they failed. The only way they know what they think they have learned through failure was actually something meaningful is to apply the "lesson" in their future endeavors and see if it works out. Until then, all your interpretations are nothing more than your opinion)

I would love to see more of these posts on Hacker News instead of failed startup post-mortems. Thanks for sharing!

<comment><USER37> That would be great, but there's a structural limit: people running successful startups don't have time to write about it, while people who have wound down their companies do. When a company is going strong and HN sees a post like this, it's usually because they're hiring :)

<comment><USER38> >>people running successful startups don't have time to write about it

This is both offensive and incorrect. Offensive because it implies that if someone manages to find the time to write about how they are running their company they probably aren't successful. Incorrect because the startup world is in fact full of leaders who do manage to find the time to write about how they run their companies (kalzameus comes to mind).

<comment><USER39> Patrick works at Stripe.

Before that, he consulted and ran a bingo card creator.

I love the dude and his advice has been invaluable to me--but it has been invaluable because he is _not_ a guy who has run startups, he's a guy who's had to make a buck.

<comment><USER40> Plus it seems his output (on his blog and here on HN) has decreased quite a bit since he moved to Stripe, so this validates what happens when you get busy.

<comment><USER41> Although a big part of his job is writing about similar topics, so you could also say he's still doing the same thing, only posting to a different end point and getting paid. That too is success.

</comment></comment></comment></comment></comment></comment><comment><USER42> Thanks for sharing this. I don't have any specific questions but being at the tail end of 2-10 myself, it's good to have reference points for when other people do certain things, like draw down to ~50% code or 0% code, how much time to spend on recruiting, etc.

I will say that I've been feeling a different type of code guilt. I feel guilty _when_ I code, because I view supporting, coaching, and mentoring my team to be my 10x activity. If I'm coding, there could be 8 other people getting blocked or needing help, and I'm off trying to build 4 hours of context to solve problems.

</comment><comment><USER43> Do you ever feel "bad" about cutting corners early on to push a product but now others are working on the the same codebase? I have this feeling constantly.

</comment><comment><USER17> If you're now focusing on the people and management, whose responsibility is technical strategy and execution?

<comment><USER44> Hopefully you've hired solid technical VPs/leads/senior developers who don't need C-level babysitting

</comment></comment><comment><USER45> Alt title could be: how I went from CTO/Co-Founder to the CTO and VP of Engineering.

</comment><comment><USER46> Which mistakes did you make when you were transitioning from an engineer to a manager? Were there any incidents with your employees that you wish now you had handled differently?

Thank you for taking questions.

</comment><comment><USER47> Interesting read, thanks for that. Besides human management, how have your tech skills evolved? What directions have you taken/discovered/fell into, what have you learned?

</comment><comment><USER48> Did you pick up any management education along the way? I spent time getting a masters in public administration and management when I made the move myself, and found it invaluable.

<comment><AUTHOR> It's great to hear that you found the Masters invaluable! I personally didn't do any formal education myself beyond reading, finding mentors, workshops, some coaching, and experience along the way.

</comment></comment><comment><USER49> Very helpful write up. Do you feel 'guilt' for being solely managerial? How do you manage code and design quality? What criteria do you use to hire now vs early days?

</comment><comment><USER50> Sup Eddie. Besides books, did you go and ask people about how to be a great CTO? Who did you pick to ask, and how did you find those people?

<comment><AUTHOR> Hey Wil!

Yeah, I found a few mentors who I would feel comfortable asking questions and getting advice. I met some though investor introductions, and others through friends of friends.

<comment><USER50> Did you find their advice helpful? Could you tell ahead of time who was going to be more helpful than others?

</comment></comment></comment><comment><USER51> Great post! What were some of the toughest decisions that you had to make in your capacity as CTO, as the company became larger?

</comment><comment><USER52> to offer a counterpoint to the lovefest going on here, TFA is almost completely uninteresting. the role changed exactly as one would expect and predict.

the only interesting part is reading about the humble beginnings, the dedication and belief.

what would actually be useful to read about is failings, where OP failed in transition to manager and how he overcame those failings. I mean there's a paragraph in there but it's so boring -- "I read these 3 books". ok there's a little more meat than that but it's too nonspecific to be interesting.

come on people, let's not just throw love out there for no reason. it has to be earned. this article doesn't earn it.

OP should read _the hard thing about hard things_. there are many anti-lessons there, don't treat it as gospel. but read it as a guide as how to write something that actually delivers a lesson.

i await your downvotes ... :P

<comment><USER53> The common failure point, which the author mentions, is that people management is not like coding. And trying to do both at once is a losing proposition. I always stress to new managers that managing is different than coding in its execution but similar in its perception. What that means is that when you code a system and it works well, it operates smoothly and when things happen (like you lose a disk drive, or a server crashes, etc) it continues to operate and perhaps degrade gracefully. This is also true of well run organizations. Most people recognize when the organization is running smoothly, and appreciate it when the organization responds quickly and without disruption ton changes in the environment. To me, I see that as the essence of good people management.

Sometimes when you have a piece of code that in spite of rewriting it a couple of times the system still bottlenecks or whatever, you restructure. Same with groups, except instead of code being moved around you move people around. Being able to see people as a team with unique capabilities and putting them in roles that are successful has been compared to programming.

The next step in the growth of a CTO (or perhaps the one after the next step for the author) is when the company gets big enough to start making choices about which problems they are going to focus on. Are they the payroll company that you can run from your phone, or the one that integrates with Salesforce? Or the one that blends remote workers from the largest number of areas into a single payroll. That is when you have to start thinking as both a business person and a technical person so that you can help steer the priorities to solve the customer problem as it arrives and before it is solved in dozens of ways by your other competitors.

</comment></comment><comment><USER21> At what point do you start calling people direct reports? I find this turn of phrase really jarring

<comment><USER54> Reporting hierarchy is there for a good reason. If you report to multiple people, you're the one that's going to have a bad time when they're not aligned with each other, each trying to give you a different list of priorities.

<comment><USER21> Why don't they know what's important and what's not?

<comment><USER55> In a larger organization, "knowing what's important and what's not" at all times can be practically a full time job in and of itself. A lot of engineering teams like to protect individual developers from meetings and conference calls so they can focus on development, but that necessarily means developers will be missing context.

</comment></comment></comment></comment><comment><USER56> great article, loved it

</comment><comment><USER57> This comment is hard to word without sounding like I'm grinding an axe with the author or the blog post or something. I'm not. It's a good post.

Anyway, I was disappointed but unsurprised to find that Ctrl-F "leadership" yielded 0 results. Anyone can read management books, and I am sure they're super valuable for learning techniques to maximize the value the company gets out of its employees.

However based on my experience over the last many years, it's not enough to be a skilled manager. "Necessary but insufficient."

Leadership is a different skillset. I am sure Mr. Kim has learned a lot about leadership, he just didn't split out the two in the blog post. Undoing the semantic smushing of management + leadership so they can be focused on independently is important, IMO.</comment>


DeepFovea: Neural Reconstruction for Foveated Rendering and Video Compression - <AUTHOR> https://research.fb.com/publications/deepfovea-neural-reconstruction-for-foveated-rendering-and-video-compression-using-learned-statistics-of-natural-videos/ <comment><USER2> Here's an anecdote. My friend's apartment got burglarized many years ago and when we looked at the security footage we clearly saw the thieves taking everything, their faces were impossible to recognize though, due to low resolution. Ever since that happened I kept thinking of a video codec that would store the whole video in low-res but recognize faces and encode those parts in ultra high-res. I hope research like this can lead to better security.

OTOH, government surveillance...

<comment><USER3> OpenCV has a module called "super resolution"[0] whose goal is to reconstruct high-quality images from multiple low quality images.

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

<comment><USER4> Don't they do something like that to boost the resolution of space telescopes? Also I seem to remember reading something about processing a stream of images from an earthbound telescope to cancel out atmospheric distortion.

<comment><USER5> Space telescopes don't do super-resolution of the type used for video, but they do something a little similar. They use a technique called aperture synthesis which combines signals from a collection of instruments so that they have the same angular resolution as a much larger virtual instrument.

</comment></comment></comment></comment><comment><USER6> The dynamic gaze example really convinced me that eye tracking will be necessary for immersive VR. If you can achieve a 1+ order of magnitude improvement in rendering performance with no noticeable loss in quality... it would be very difficult to leave that on the table.

<comment><USER7> You can also use a lower frame rate for the foveal input.

What peripheral vision losses in spatial resolution, it wins back in time.

<comment><USER8> Not necessarily. The "lower framerate" in our fovea is not represented as a stuttering sequence of frames, but a blurry and smooth flow. Simply using a lower framerate would still be noticeable.

Unless you could engineer a display technology that could do this.

</comment></comment></comment><comment><USER9> Dropping of certain pixels is a very peculiar way of reducing input quality. Why was that method chosen?

For 3D rendering I guess that's a kind of DLSS, but the paper focuses on video compression.

For video streams that doesn't seem to make sense. Video codecs are not pixel- based, but block/frequency based, so you can't save any bandwidth by dropping pixels. Raw pixels don't compress well, especially less correlated samples like that, so I wouldn't be surprised if sending just the reduced input for this algorithm was more costly than sending a full video stream. And existing video codecs can already very effectively vary quality within the frame by varying block sizes and quantization.

<comment><USER10> "Compression" is probably just poorly chosen wording. This has more to do with reducing the number of required samples in applications like eye-tracking VR, where you can choose to render a dense image for the part that the user is looking at, while reducing detail in peripheral vision. Current implementations use some fractional resolution(s) for the periphery and blend pixels using more traditional methods, which results in blurryness and/or aliasing artifacts.

</comment></comment><comment><USER11> Those are some pretty incredible results. For any single frame I found it hard to find a significant quality loss between the DeepFovea frame and the reference (obviously while looking at the Foveal target and trying to compare peripheral quality), but in motion there was a lot of interframe noise / aliasing / jitter.

While I'm sure they'll improve on those issues I'm currently wondering what kind of visual peripheral trade offs I'd make; if I had a demo in front of me I'd bet that I'd prefer running at higher foveal settings / fidelity with peripheral artifacts to running at lower overall settings / fidelity to avoid them.

</comment><comment><USER12> Had this idea at least 10 years ago. Have many ideas, that said...

Fovea-oriented compression can be useful for optimized bandwidth usage in video conferencing, too.

One could even implement auto-reframe of video feed when several participants are in the same room without need for a mechanical camera moving. Or something like liquid rescale to still get a glimpse of the rest of the full frame.

Perhaps those ideas were since patented and even developed?

</comment><comment><USER13> Can the eye tracking see saccades? Can it keep up if you rapidly refocus?

</comment><comment><USER14> haven't read paper yet, but this is a silly demo. "turn 10% of pixels black" is not a good baseline, should use nearest-neighbor interp (or something) to fill holes in the "sparse" video for fair comparison. also, you can clearly see in hd video that it's temporally unstable ("shimmering"), which is the same problem nvidia has with dlss since forever; need to build temporal smoothing in or users will hate it.

</comment><comment><USER15> Can this be used to replace Photoshop's Content-aware fill as well? Or does it require some sparse sampling of the whole area that needs to be reconstructed?

</comment><comment><USER16> i was thinking of doing something similar for image segmentation.</comment>


The Internet Needs The Ignorant - <AUTHOR> http://www.superfluosopher.com/digital-world/the-internet-needs-idiots

<comment><USER2> No, it doesn't.

The main argument here is this: the internet needs ad revenue from the ignorant masses to continue existing in its current form. While most people think ignorance is a bad thing, we're presented with this problem that if we got rid of ignorance, we'd also get rid of the internet, therefore we should shake our heads sadly and accept ignorant people as either a good thing or at least a necessary evil.

How about we keep trying to reduce the number of ignorant people, and if it's true that the internet can't exist without them, we fix the root problem of why that is? Does anyone really think the only solution to such a problem is "we need more ignorant people"?

</comment><comment><USER3> Wow, the tone of this article is way off. Potentially decent point about online revenue obscured by a massive superiority complex.

<comment><AUTHOR> A lack of writing talent rather than the intention; I simply couldn't think of a better word than ignorance to describe the phenomenon.

I was watching one of my elderly relatives struggle with Google search (hitting link-bait-y ads) when I started thinking about it. It answered the question "who on earth is clicking on al the ads?!".

My bad if I gave the wrong impression. I am more than fond of my Nan in all other senses. But she _is_ ignorant when it comes to online activity.

</comment></comment><comment><USER4> I clicked on a Google Search ad and bought something less than 2 hours ago. Am I part of the Ignorant?

<comment><AUTHOR> As I tried [failed...] to explain through the examples, the point refers more to spammy and content-poor ads than highly relevant and targeted ads.

So probably not so much retail ads targeting specific intent-clear search terms (e.g. SEARCH: "buy _book-title_ online), rather Facebook-type "Top 3 routes to a flat stomach discovered by this 94 year old woman".

Do they do as well? I don't know. But I see them all the time and the post was my stream-of-consciousness as I try to not mind that fact.</comment></comment>


YC Facelift: Pebble - <AUTHOR> http://kyrobeshay.com/post/21217064143/yc-facelift-pebble

<comment><USER2> A couple things about this one that didn't click with me:

1) You mention "iPhone" at the top. Sorry, I've already clicked "Back"--I'm an Android user. Except Pebble is the first thing I've ever funded via Kickstarter, and I'm ridiculously excited about it, so I'm clearly in their target market.

2) I don't get the "Beam your music, Scotty." part--it's not the biggest draw for me (and I'm not a Star Wars/Trek person, despite being a huge geek!) My biggest interest in Pebble? It's a watch that lets ME do what I want with it-- I can display the time in weird fonts, or make it say:

seven

thirty

THREE

...or any of those other cool things. In other words, it's the design and flexibility that interest me more than the features.

Pebble lets me be crafty...with my WATCH. That is freakin' awesome. It is SO awesome that I will be wearing a watch for the first time in years. And that's exciting. I feel like this page misses that genuine excitement that got me to buy a Pebble and tell all my friends about it.

<comment><USER3> Fair criticisms. However, you're speaking, presumably, from the perspective of a developer – someone who'll be writing apps for and fiddling with their Pebble. I designed this from the perspective of a consumer who intends to purchase the product because of its looks and the apps available for it already. The iDevices are not advertised in a way that directly appeals to tinkerers and developers, but rather to everyday people who want a cool device that does cool things. Of course, I'm assuming who Pebble's target market is, and I could very well be wrong.

<comment><USER2> Probably not, actually--although that's a fair guess based on both the content of my post and the fact that it resides on Hacker News. I'm swamped with my own business currently. I'm more of the "consumer interested in the looks and apps" category.

</comment></comment></comment><comment><USER4> Just wanted to give my 2 cents:

What you are doing is really dangerous. "In an effort to refine my design skills, I've decided each week or so to redesign the landing page of a YC company I dig and whose website I don't feel so similarly about."

Doing a facelift on just the landing page, or rearranging elements around a page is _not_ design. It's a subset of design. What's worse, is that these redesigns you offer gives zero context, no interaction, no brief, no reasoning. It's purely visual reformatting. Every placement of content, layout has a reason – you need to provide those in order for us, the reader, to understand your thought process and why you did the things you did.

I'd suggest taking it a step further to give more 'meat' to your posts. Use services like Invisionapp to create clickable hotspots to allow users to explore the redesigned site. Offer your thoughts as you go through the process.

A simple image with a few words on the product and why it's awesome doesn't really tell us anything about your process.

(Design is about solving problems – you also need to identify what is wrong with the original design, then offer your solution and explain why they are better)

<comment><USER5> This is a popular sentiment among designers, but it is equally dangerous. The flash, sizzle, and aesthetics are a HUGE part of design. People make judgements in fractions of seconds, well before they have a chance to experience interactions or any of the deeper level design issues.

I've seen three of these redo's on HackerNews and each time the redesign is aesthetically much nicer. Sure there are some things that could be better if he understood the market or product context at a deeper level, but each service looked more professional/desirable.

I manage a team of designers and these would be great deliverables if the goal was to help establish a style guide for a brand. After this round, I would have a PM and a marketer work with the designer to optimize flow/content, but this is exactly what I'd expect from a visual designer.

<comment><USER6> This whole thread is getting really dangerous

</comment></comment></comment><comment><USER7> No offense but this looks like a generic template with content filled in. A clean and simple design like this needs to demonstrate excellent typography and spacing, neither of which I see here.

If you wanted to let the product speak for itself, I would have drawn inspiration from Flipboard or Path. Both of these sites heavily rely a clean design coupled with custom typography and a well integrated video.

</comment><comment><USER8> Coming at this fresh, I have absolutely no idea what a facelift is in this context, and you don't give any. Have you redesigned their web site? The product? What's the relevance of biosensing?

Confusing.

<comment><USER9> The author has been redesigning the landing pages of different YC companies.

</comment></comment><comment><USER10> I really like the clean design and simple color palette, the one thing I would address is the Typography. You've clearly chosen a non-standard typeset, however I think it's extremely understated in this design.

There are some really good points about not highlighting both iOS & Android as supported platforms (Android has a much larger user base). One of the really cool things about the Pebble, is that you can grab apps for it or build your own and this is really lost in the design you have.

I love that you are taking on these types of projects/exercises! Don't get caught up in all the negative bias, you'll never please everyone... Would love to see an update to this design, to see how you execute with this type of feedback. Keep it Up!

</comment><comment><USER11> Gee, it sure would have been nice to see that the watch communicates with all these marvelous devices via bluetooth.

I mean really. Why are we left to assume that it's a bluetooth watch? Why can't they just come out and say it? Are they shy or something? Do they themselves secretly believe that by stating that it is a bluetooth device that they some how lower the watch?

Why do they insult their ostensibly budding (zomg! rockstar ninja!11one) "hacker" community with stupid diagrams like this?

<http://www.getinpulse.com/images/how-it-works.jpg>

<comment><USER11> Seriously, the first place I could find where they explicitly state that the watch communicates via bluetooth was here:

<https://play.google.com/store/apps/details?id=com.getinpulse>

<comment><USER12> Check out the kickstarter page for the product: [http://www.kickstarter.com/projects/597507018/pebble-e- paper...](http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch- for-iphone-and-android) . It's very clear about Bluetooth being the method of communication.

</comment></comment></comment><comment><USER5> It would be cool if you included the "Before" in the blog post as well. Nice work on the design, especially for a medical student!

</comment><comment><USER13> I think pebble is the next big thing and might even get rid of its dependence on the mobile phone in future. Just imagine Siri helping you get through your day with out taking the phone out of the pocket!

</comment><comment><USER14> I don't think there is anything wrong with what you are doing, but I hope people understand that there are many, many talented designers out there working for companies with horrendous websites. It's very easy to make a PSD mockup of a single landing page working in a vacuum. However, see how that pretty PSD looks after making its way past meddling founders, overworked devs that don't give a damn about aesthetics, and technology constraints. Building beautiful websites in a business environment is _hard_.

</comment><comment><USER15> How did you decide what to include on the page? One thing that I noticed was that you removed the news mentions from this facelift, but the one you did last week has news mentions.

</comment><comment><USER16> Unlike most of the other facelifts, I'd say that the inPulse web site is definitely in need of a refresh. So this was interesting to see.

</comment><comment><USER17> I think this idea is cool (YC Facelift) but without explaining _why_ you did what you did your designs are just "oooo pretty". Nobody will learn from your work if you can't explain _why_ you did what you did, and if you _can't_ explain why then the criticisms here are probably valid. Design is more than just pretty.

</comment><comment><USER18> kyro, I would actually like to see you do a design that doesn't fall into the "web 2.0" trend. Your designs overall are nice, and flows well, but falls in the realm of "template" in my eyes.

Really push the boundary of the design to stand out from the rest.

Also don't take this as all web 2.0 sites are similar, or you can't pull inspiration from them. Just something refreshing to break the mold of mundane would be nice.

</comment><comment><USER19> I like your design better, much cleaner. I was not a fan of the exec redesign you did however this one is a big Improvement. Good job.

</comment><comment><USER20> You should start accepting requests, I know so many startups that could use a big redesign.</comment>


Google, Just Cut The BS And Give The Gordon Gekko Speech Already - <AUTHOR> http://techcrunch.com/2010/08/13/google-net-neutrality/ <comment><USER2> Can someone explain to me how they think less than full net-neutrality benefits Google? I didn't understand that argument in this article, or any of the previous ones.

<comment><USER3> Closing the door to the country club works if you're already inside when the door closes. Google's agreement with Verizon positions them inside. Startups and companies offering services we haven't even dreamt of yet are on the outside.

<comment><USER2> >Google's agreement with Verizon positions them inside.

No part of this agreement creates any business relationship between Verizon and Google. I'm still not understanding.

<comment><USER3> Doesn't the agreement position existing web services like HTML over HTTP in an advantageous position over services yet to be named? And doesn't Google's current revenue stream depend on this?

Since Google dominates current services, it doesn't need to monopolize them, just ensure that anything new coming along has some hurdles to clear.

<comment><USER4> Wrong layer as I understand it. Seems more like it's trying to allow the providers to set transport prioritization, not application layer.

<comment><USER5> It's not only on the app layer: """ One is a provision that would let broadband providers offer "additional, differentiated services," that would be not be subject to the same rules as the open internet. These would possibly include "health care monitoring, the smart grid, advanced educational services, or new entertainment and gaming options." """

<comment><USER6> Isn't that necessary though? If your surgeon is operating on you remotely, don't you want those packets prioritized over my LOL Cats download? It seems there are services that are impossible to provide without quality of service guarantees.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It was about time someone said something to this effect. Net neutrality aside, Google is a public company. They have shareholders. From what it sounds like, Larry and Sergey are more or less full blown academics and therefore idealistic. Problem is, they aren't the parents of a Stanford project anymore but instead a multi-billion, multi-national corporation with thousands of shareholders, employees and customers.

Could they have approached net-neutrality with a "cut off your nose to spite your face" approach? Absolutely. Could they have won out in the face of adversity? Maybe. Would it have been good business? Most assuredly not.

Google in acting in self-preservation; nothing more, nothing less. They aren't martyrs. I can understand if you are upset about them not admitting this fact, but anything else is naive.

<comment><USER8> _From what it sounds like, Larry and Sergey are more or less full blown academics and therefore idealistic. Problem is, they aren't the parents of a Stanford project anymore but instead a multi-billion, multi-national corporation_

Patronizing comments about "academics" and "idealism" ought typically to be delivered _before_ the target's company has attained megasuccess. Larry and Sergey's competency to lead a multibillion-dollar corporation has been proven for many years. More to the point, so has their ability to do it in a less evil way, a way that raised the bar for everyone. The issue is not whether it's possible for Google to be Google; we have an existence proof for that. The issue is whether Google is breaking its own values, and if so what the consequences will be.

 _Would it have been good business? Most assuredly not._

This wretched argument, so sure of its own hard-nosed realistic businessism, is just what people were saying 10 years ago to prove that Google should sell banner ads. Oh sure, that home page was cute. But look at all the money they were leaving on the table! Well let's just remember how things turned out: by sticking to their guns, rejecting that thinking, and putting users first, Google made _orders of magnitude_ more money than they would have had they followed that path. (How do we know this? Because countless counterexamples ended up in the dotcom garbage bin.) Oh yeah, and they changed the world and the industry forever.

So what was really good for business?

<comment><USER7> I definitely believe the agreement is necessary for Google to have regular access to its current channels looking forward (both across the net and especially with Android through Verizon). Yes, it is good for business.

There may be a huge outrage over it, but I tend to doubt it.

Furthermore, the anecdote "Sergey Brin did not want to cave to any of the Chinese demands to operate inside of mainland China, but Eric Schmidt talked him into it", if true, is pretty good evidence that the founders are more idealistic. I don't think that is patronizing.

<comment><USER9> I think reputation matters a lot. If you rubbish your customers and only look at your bottom line, they will slowly start leaving.

<comment><USER10> I think this is spot on. The problem here isnt that Google did what it did, it's that they shouted about it for the other side for so long, and then switched teams. The same thing with China. If you're going to take a hard stance on something, then do it and people will respect it for you. But Google is turning into all talk and no walk, and walking straight into the next Microsoft.

If they had just said from the beginning that they were out for their own interest (just like everyone else), and not tried to play the good guy even when it would hurt them, then nobody would be surprised by this.

<comment><USER7> True, the old switcheroo is definitely bad business. A little more transparency would have negated this whole thing.

</comment></comment></comment></comment></comment></comment><comment><USER8> I found this the most interesting part of the article:

 _In private conversations with Googlers and ex-Googlers over the past couple of days, the vast majority of them seem to be disturbed by what Google is doing here as well._

If that's accurate, it's significant: it means this isn't all a big misunderstanding, and hints at how much damage Google could potentially do to itself here.

I still think they're smart enough not to let that happen, though it does look like they've painted themselves into a corner. I wonder if they realized how tremendous an asset their standing up for net neutrality was.

</comment><comment><USER11> Since cellphones are merely a convenient connection to a backbone network, would it make sense to develop and promote a wifi system with automated handoff between access points that can bypass cell protocols altogether? Being in the clutches of Verizon and ATT doesn't sound like a good strategy.

</comment><comment><USER12> What makes people think Google is capable of delivering a well-versed argument in a charismatic manner?</comment>


The Art Of Applying Rule Of Five Plus Or Minus Two For An Effective Wireframe - <AUTHOR> http://www.onextrapixel.com/2009/07/20/the-art-of-applying-rule-of-five-plus-or-minus-two-for-an-effective-wireframe/ <comment><USER2> _For global navigation, for example, try to use a minimum of 3 and a maximum of up to 7 top-level links, excluding the logo for the home page._

Umm...they have nine.</comment>


The Musk Ox and Me - <AUTHOR> https://www.newyorker.com/magazine/2020/08/17/the-musk-ox-and-me <comment><USER2> Typo in the headline missing the 'e' in The</comment>


Kubernetes is going to support rkt - <AUTHOR> http://www.wired.com/2015/05/google-backs-alternative-docker-cloud-computing-s-next-big-idea/ <comment><USER2> I've been using CoreOS & Docker for about 3 months now in production (stable channel on AWS). At the moment I have a "cluster" of 2 machines on AWS and 1 simple CI server on DigitalOcean, also on CoreOS & Docker. It wasn't easy for me to get used to "the docker way" of doing things, but I think I'm quite fluent in using Docker & building containers now. Setting up everything is very easy & productive, they have a great documentation (example: [https://coreos.com/docs/running-coreos/cloud- providers/ec2/](https://coreos.com/docs/running-coreos/cloud-providers/ec2/)). If you're interested, you can setup a test VMs using Vagrant, this takes like 5 minutes: [https://coreos.com/docs/running- coreos/platforms/vagrant/](https://coreos.com/docs/running- coreos/platforms/vagrant/)

However, I don't really feel comfortable with Docker security and I will probably switch to rkt - more focus on security and better approach to containers imo. CoreOS is incredibly good product, these people see the future. Full disclosure: I'm very happy user of CoreOS products.

<comment><USER3> Just anecdotally, I've had the shittiest experience in recent memory with CoreOS. Their choice of BTRFS bites me pretty much daily whenever logs start writing stack traces for errors. A similar problem happened when Deis chose CephFS for their registry container.

While I'm a huge fan of Docker I will maintain that CoreOS is not ready for production in most capacities and recommend against using it in its current form.

<comment><USER2> Can you elaborate on "whenever logs start writing stack traces for errors."? What caused the problem? And what exactly was the problem with Deis & CephFS? I was considering using those some time ago.

<comment><USER3> Sure. Whenever the log messages start to get pretty decent in size, like, when the log messages start including tracebacks due to errors, and you have lots of errors happening back to back, like lets say high traffic is causing some deadlock exception at the DB layer or something(this was our actual problem), this high write causes BTRFS to lock up. Usually this happens because of some kind of kernel level error, our ops guy is familiar with the exact details of the exception BTRFS throws. Suffice it to say, when that happens, it's not immediately obvious the instance is unavailable. If you have plenty of errors happening in a short time span, this behavior will start to roll across your cluster and depending if all of the hosts are running the offending container, your entire fleet of hosts will lock up. This sucks bad. The only real solution is to bounce the host machines -- though they seem to come back just fine.

CephFS had a similar-ish problem, where if you happened to ever own less than 3 nodes (almost always because of the above), it would have a real problem self-healing and start to get confused and re-elect bad nodes to quorum leadership, possibly clobbering all your registry data. We contributed a patch back to Deis to use S3 as a registry persistence layer because, well, having a volatile registry sucked. We were about to develop a control layer for quorum services to live on separate of the application services we were developing, and using a proxy in the quorum layer to communicate stuff like etcd. I would highly recommend this approach if you end up with any services that require a quorum.

<comment><USER2> Thanks for the reply.

I would prefer to avoid many disk operations in the first place. Not sure, if it's applies to your problem, but have you thought about using something like Sentry ([https://getsentry.com/](https://getsentry.com/) || [https://github.com/getsentry/sentry](https://github.com/getsentry/sentry))? Maybe there is some other tool that could help you here, I'm often impressed by the Open Source community and the vast number of different packages for (almost ;)) every technological problem.

</comment></comment></comment></comment></comment><comment><USER4> The title is slightly misleading but not entirely. Docker was, at first, a container technology. However, after it received its funding it has tried to convince the community and investors that it can be more and started to provide container orchestration tools, i.e Swarm, Machine and so on. Docker has received most of its momentum and attention because of the work they did around the container format. Docker build, run, stop, encapsulates most users experience of Docker.

Docker wants to be known as a platform providing container management tools and it needs to do this quickly because Mesosphere and Kubernetes provide this type of functionality at a more mature level, albeit using somewhat different philosophies. The container format part of Docker is ultimately replaceable.

Google (Ventures) backing Tectonic is significant because Tectonic will provide a commercial enterprise-ready distribution of Kubernetes supporting Rocket. Rocket doesn't need to reach feature-parity with Docker to be a notable replacement because Docker already does too much. All Rocket needs to do is provide the much needed enterprise features that Docker is lacking and integrate well with Mesosphere or Kubernetes. If this happens before Swarm and Machine mature, we could be wondering 6 months down the road what the hype around Docker was all about.

If Tectonic succeeds in the enterprise marketplace then Google will have stealthily marginalised Docker using community efforts through rkt and kubernetes and not had to fight them directly.

</comment><comment><USER5> Does the article read like a smoke screen, designed to push a specific agenda? Given that Kubernetes supports Docker too?

I love Rocket and Docker, but I don't love misleading sensationalism in tech reporting. Maybe my mistake is thinking of wired as tech reporting?

<comment><USER5> hmmm, my mistake. I should have read this more carefully.

"Google also offers cloud computing services a la Amazon, and it was the first big-name cloud company to embrace Docker. Since then, Amazon, Microsoft, and others have followed, responding to Docker's enormous popularity among Silicon Valley developers. But now, Google is backing Rocket as well, rolling the technology into its Kubernetes cloud computing software. Google calls this "an important milestone for the Kubernetes project."

My reco is update the title.

</comment></comment><comment><USER6> > The irony is that Docker is based on software that underpins Google's vast > online empire.

Doesn't Rocket also use cgroups?

<comment><USER7> Actually, it does not have to, it is a more general spec. Technically Docker doesnt need to either.

<comment><USER8> I believe there's even at least one production deployment of Docker on a different stack of underlying container technology, the one Joyent runs on top of SmartOS (which uses Solaris/Illumos zones as the container tech).

</comment></comment></comment><comment><USER9> Isn't this obvious with the backing of CoreOS by Google Ventures?

<comment><USER10> Investments by Google Ventures are unconstrained by and untied from the rest of Google's corporate strategy.

<comment><USER11> That's a bit surprising, given that Google's percieved backing often is enough to make or break projects in this space.

</comment></comment></comment><comment><USER12> Misleading article. The news is that Kubernetes is going to support coreos's rkt. It already supports Docker.

<comment><USER13> Thank you. Pretty shoddy on Wired's part.

We've updated the title. We can update it again if there's a better one.

<comment><USER14> I think the title should be "Kubernetes is going to support X" where X is either rkt or appc. CoreOS is a company, developing an open container spec (appc). rkt is CoreOS's implementation of that spec, but other implementations are possible. Currently X=CoreOS, which is most likely to imply CoreOS's operating system, and that isn't what the article is about.

(An analogy: appc=JVM, rkt=OpenJDK, CoreOS=Sun)

<comment><USER13> Ok, sure. Is it accurate now?

<comment><USER14> I believe so - thanks!

</comment></comment></comment></comment></comment><comment><USER15> Headline: Google backs alternative to AngularJS, the web's Last Next Big Thing. Google reveals the entire AngularJS project is a ruse designed to ruin countless weekends of aspiring web dev's! No backward compatibility, no human- readable documentation and no implementation of their own technology in their own core product line! In fact, Google states, AngularJS is their first experiment with using their "considerable weight" to trick engineers into learning a technology which is completely useless and unsupported in the long run.

<comment><USER15> Before I get down-voted to oblivion, apologies for snark but I think I'm making a valid point. A lot of engineer's decided to throw in with AngularJS because of Google's "considerable weight" but as we're seeing now, we're all getting burned. It's a fine technology but the pain points have been severe. My point being just because Google backs a technology doesn't mean it's going to be useful, and should instead be based on its merits.

<comment><USER16> Disclosure: I work at Google.

I think your point is fair: all technology should be reviewed strictly on its merits. We certainly don't have a magic formula that gets it right 100% of the time. I can however say we are quite committed to this area and this project in particular.

Here are the things I think about most days:

In the case of Kubernetes, we are doing is a little different to anything we have done before. We have a commercial offering (Google Container Engine) based on this project that we ultimately hope the world to consider as a great way to run containers for money (yes, we hope to create a business around this). The nice thing is we are a service provider so we just need to convince someone to use our compute services for us to benefit from an open source project we sponsor. We aren't really hiding our intentions here; we do containers well inside Google and have some whizz-bang container hosting infrastructure and services. The problem is that people are not likely to use it unless there is a 100% open, fully compatible alternative available for off-Google use. By way of background I was the product lead for Google Compute Engine (our infrastructure-as-a-service product) for several years. The product is going really well now, but I learned the hard way that big customers like choices and no-one likes to be locked in. This isn't just us being Googley (though I have a personal predilection to openness); this is a simple fact of the marketplace today. We could not convince someone to bet on a disruptive technology if an open and credible alternative does not exist.

The second thing is that we see tremendous power in the open source community that we want to tap into, both for our cloud product line, and for our own internal use (it is no secret we use a lot of OSS internally). Kubernetes has achieved an almost ridiculous velocity (check out our PR acceptance rates) because the community is supporting it. It is a better product because we benefit not only from having a bunch of Google engineers working on it, but because we also get engineers from Red Hat, CoreOS and others who bring different perspective and capabilities. We aren't enterprise guys for example, but the Red Hat folks are -- the combined team is way better than the sum of the parts. Our service (Google Container Engine) is stronger for it, and in the limit we expect to use Kubernetes to run a lot of our internal services too.

Cheers, \-- craig

<comment><USER15> Thanks, right on. It's a huge organization - I think small potatoes like my dev shoppe need to be wary of just doubling down 'because Google.' Angular was hopefully an outlier! Looking forward to seeing how Kubernetes evolves.

</comment></comment></comment></comment><comment><USER17> How ironic. Docker is one of the biggest and most successful Go deployments there is.

<comment><USER18> Google supports Docker, too; Google supporting multiple approaches to the same problem isn't new (heck, its not even that uncommon to have multiple solutions to the same problem _originating_ at Google.)

</comment></comment><comment><USER19> Shame they are so behind on development, I am in the process of learning Docker. Loving it so far..

</comment><comment><USER20> So if the article is true . Does it make sense or is it dumb to think that Docker would not be acquired by Google ? Since it is not backing up</comment>