oautholaf

I ought to have distaste for them? No.

Sure I'd reform the program, but I am glad that they can come here and so are they. I would be upset if they couldn't anymore and so would they.

Sorry to say, I don't think reforming the program with applicants in mind is on the table in this administration.

And I haven't met any of them who would prefer it gone entirely...

I can't speak to any abuse of these programs, but as a US citizen I value my co-workers on H1-Bs and want them to stay.

I'd like to believe you, but 'the most likely' outcome has not consistently happened recently.

Regardless of lobbying, the incoming administration ran a campaign that was built on anti-immigrant sentiment. Their base wants that. They have to throw their base something. No one in Silicon Valley voted for them or fundraised for them.

This could totally happen, and it bothers me as a citizen because a lot of my co workers are on H1-Bs.

Pre-acquisition YouTube was probably skating on thin ice here. Rumor has that eBay's origin was less pure than selling Pez dispensers.

Having worked at many startups, I can say that it is very common for startups to have an 'original sin'.

That's very sad. He was a hero of mine in the NeXTStep era. I always figured I'd run across him sooner or later but time ran out...

As someone who was there, let me say that the decision to use Java was definitely not made before the Google acquisition. The codebase that came with the acquisition was C++/JavaScript and was completely rewritten.

Uhh, as someone who was there when Android began: There was no Go in 2005. And anyway, Go started with explicit about initial goal of being a server-side language, with choices (eg, only static linking) appropriate for that goal.

I am not a lawyer, but it's possible the non-compete is enforceable in California in this case.

When an employee gets something "in kind" for the non-compete agreement, which arguably this is, then it may be upheld. For example, if a company pays you non-salary money in exchange for a non-compete agreement, then it may be upheld. Consider the case of former HP CEO Mark Hurd when he went to Oracle.

What's not enforceable in CA are non-competes in, for example, normal employment contracts that apply to everyone.

Edit: To be clear, Mark Hurd was allowed to work at Oracle, but he had to give the money back he got for signing the agreement.

> Within the context of the U.S.'s current economic/legal system, I think it's more in accordance with common usage to think of the existence of private property and contract law as being the basic substrate on which everything else happens

This may have been common usage through the 1920s, and it may be common usage for people who wish the New Deal never happened. But even then it would be a stretch. This country's legal history is a lot more nuanced than that. What you articulate is probably best described as a minority vision today.

I think your lense of "free market" needs to be supplemented with a little game theory here. If you're an employer, what's your disincentive for tucking in a little non-compete in your contract? None at all[1], especially since many of your prospective employees won't read it or potentially (if you're a low-wage employee) understand it's implications. Then what's the disincentive for an entire industry to do this? None at all. And suddenly, there is no free market for job seekers anymore.

There's a reason why in the US, overwhelmingly contracts are read against the one who drafts them for example. There's an inherent power imbalance here. That's where laws and courts come into balance things out.

[1] To point, it's not uncommon for California-based tech companies to insert non-compete clauses into their contracts, even though they cannot possibly be enforced unless there is some special compensation.

That's funny, as someone who has used both github and gerrit for several years each, I completely disagree. I found the gerrit flow worked well.

At the gerrit-based shop, we kept very good discipline of regular, small checkins. And yes, you can pipeline your checkins too.

I found the gerrit flow also much easier to explain to new engineers. The github PR flow is much more full of sharp edges.

> The author invokes the old myth that "digital audio must be sampled, therefore it's lower quality"

Actually, the author made a different argument: That the removal of the higher frequencies in PTSN PCM combined with the low frequency of modern cellphone background noise made for something much harder to understand. As someone quite familiar with the subject, I think this is a very nuanced and compelling argument.

> Saying that the digital protocol is "permanent" is basically a lie;

The author also did a spectacular job dealing with this in an understandable way too, talking about how it's baked into so much of the infrastructure.

Inside an organization, separate repos and versions can simply be unnecessary overhead. As long as you can have an edict from above that 'thou shall not break the build or its tests for you or your dependants; the punishment is immediate rollback', empower some people to enforce this, and have plenty of automated tests, distinct repos and versions are silly, unnecessary and massively inessential overhead.

But if you don't have that balkanization is a reasonable option.

For me, dwarf's state machine debug encoding was a direct inspiration for my work on the Android Dalvik dex debug data, which I made sure to recognize in its documentation:

https://source.android.com/devices/tech/dalvik/dex-format.ht...

Encoding the dex debug data this way meant we could keep all the debug symbols on our early devices with limited storage, which helped a lot during 1.0 development.

I always thought people in our industry should loudly shout out their references more. I'm glad I did.

A lot of the examples and counter-examples in the threads here are great, but Microsoft in the Windows era is a great counter-example here: from operating system to Office dominance. How did they crush Lotus and WordPerfect again?

And for how long was Siri just a set of regular expression rules?

Does that make your application more responsive to the user?

Not only can JSON be slow, SQLite has been shown be very problematic as well: http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f...

The filesystem is a fantastic way to persist data for 80-90% of mobile applications.

Which was more prescient, this or "Content is Not King"? http://firstmonday.org/article/view/833/742

In many ways, it seems like Microsoft's late-90's obsession with content didn't really pan out. Sure, MSNBC is still around but sidewalk.com long since evaporated. It doesn't seem like MSFT really became a profitable media company.

But look at how many multi-billion dollar "unicorns" are messaging companies.

I wish the experimenter had explored random distributions other than uniform. I suspect uniform distribution may be non-ideal here and other distributions may produce better results.

There's really a strong reason to do this for things like user session tokens, where using crypto and avoiding database updates could easily remove a substantial portion of your database traffic.

But for things that are less common, like password resets and email validation, consider the downsides:

a) using the database gives you a built in (depending on schema) audit log of these events, where a signed token does not b) If the key is stolen in the scheme described, the person in possession of the key can hack into all your accounts. If you use database state, someone needs to have access to the database. c) (also mentioned above) You will almost certainly be able to have a smaller token if it refers to database state, which has it's own advantages: copy and paste errors, etc

There's certainly advantages to crypto tokens/cookies, and they're the right call in some circumstances, but there's downsides to consider as well.

As someone who was present at Google working at OAuth at the time OAuth 2.0 was negotiated: the way to interpret refresh tokens is in the context of a large organization like Google or Facebook, not a small website. A refresh token, which is powerful, would only be presented to a single endpoint which could had different logging and security considerations.

But yes, a lot of damage can be done in an access token timeout.