"There's an all day meeting we need you in for. It's not relevant to you, and we expect you to work on other things while you are in, but we feel like its beneficial for you to be here."

Option 4. Remote work. That would solve for packed offices, packed parking lots, overpriced real estate, long commutes, and more.

Option 5. Screw it, we're The Google -- we are going to build our own mini-Domed Cities.

Option 6. Create software that writes itself

This is from one of my college professors, nice to see it make it on HN, and it looks like there's a bit more material since I used it in class. I found it helpful in explaining basic concepts (more-so than the bland textbook that I had to pay for).

I believe window.requestAnimationFrame is preferred over setInterval, and doesn't get limited as such.

https://developer.mozilla.org/en-US/docs/Web/API/window.requ...

Actually requestAnimationFrame is limited more (possibly even entirely paused) as it assumes that if the tab isn't visible, no animation needs to be requested

I couldn't tell that the dots were colored differently at all.

"We require that you deploy our public key to your root account’s authorized_keys file so that we can provision users on your behalf."

That feels like a big requirement. What is the gain of using your UI/service over using puppet in-house and creating your own UI?

Well, we talked to server admins (mostly at companies that run servers on behalf of web design or web services clients) and heard that they didn't want us to impose the requirement of adding another package to their deploy scripts. They'd have to keep the version up to date, make sure it's installed on their machines, etc. That's feedback was really the only reason why chose to impose this requirement for the beta.

I'd love to hear more about your use case and if you'd feel more comfortable having a daemon run on your servers (so that our service wouldn't have root login ability).

> That's feedback was really the only reason why chose to impose this requirement for the beta.

I'm not sure how accurate this quotation is, but Henry Ford may have said:

"If I had asked people what they wanted, they would have said faster horses."

As a consultant I feel it is my duty to advice people when they are asking me to implement something that is not in their best interests.

If someone has told you that "installing packages is difficult, just login as root", I think it is your duty to educate them as to why that is a bad idea.

Anyone familiar with security best practices would never even consider allowing an untrusted third-party to log in to their servers as root, which drastically reduces the size of your potential market.

Currently, your target market is: people who find it difficult to use configuration management tools, and who aren't aware of good security practices.

Just about anything would be better than 100% root access and "employed measures to make sure that we never have unattended access to your servers", and there's no reason you can't offer two solutions.

You'll have to develop a cryptographic scheme makes sure that when your management service is compromised, it does not affect the servers the management server controls. We've done that work.

Say we have a daemon though - the daemon would require root access in order to create user accounts. If the management service is compromised, the user accounts can be created. That's why we've made it infeasible to access SSH keys even if the management server is compromised.

Funny, I see "Leaving Twitter (nathanmarz.com)". That's pretty descriptive.

I had no idea who Nathan Marz was. When I saw the title, I assumed "Leaving Twitter" was implying discontinuing usage of Twitter from an outsider's perspective, not an employee parting ways with the company. The original title is completely unambiguous.

AFAIK all of the mods are YC insiders, so they'd know Marz by name.

If it is as you imply, that's a pretty serious Theory of Mind failure on their part.

Agreed, and more importantly, thank you for introducing me to the term "theory of mind." It seems a nice way to succinctly refer to the notion of understanding the perspective and level of familiarity of others.

I think it would be beneficial for Chrome (Android as well) to allow for an app to have a dynamic set of permissions.

Instead of requiring all web access just so an app can perform an action on any page (when you decide for it to) - what if a specific user action could grant temporary/permanent access to a domain? E.g. Clicking an icon if the app is in the toolbar, or selecting a certain action from a menu.

Chrome has a way to prompt for temporary permissions - but this brings up an alert box, and that is never ideal, it would be nice if the user interaction could be taken for permission.

edit: apparently its in beta (https://news.ycombinator.com/item?id=5383011)

Other features I wish Android's security model has are 'soft permissions', and 'pseudo permissions'.

Soft permissions would be where an app can function without permission, but has feature(s) that require it. For example, if I install a game, I should be able to play it without giving it internet access. However, if they want to have a online high-score system they must require that I give them internet access in order to install the app;

Pseudo permissions would be where the app thinks it has permission to use something, but it is really receiving bogus data. For example, say an app 'requires' access to my phones GPS system (when such access is not critical to the function of the app), it would appear to the app that it has access, but the data it receives would not corralate to the actually data.

I think I recall seeing a project to implement both of these features in Android, but I do not recall what it is called.

Rosetta Code is a great resource (http://rosettacode.org/wiki/Rosetta_Code). Examples from many languages are provided per a given topic (e.g. http://rosettacode.org/wiki/Sieve_of_Eratosthenes)

Yeah, that was some time ago, and I've had comments since then so its a little odd.

Thanks for the help.

You're back!