xorgar831

Laf, Joylent's site is more Cirque du Soleil than food company.

It's tongue and cheek deterrent, it's effectively ex-communcaiton from their social circles which is where they get their attaboy/girl encouragement that this is acceptable behaviour. They don't see themselves as part of the hoi polloi, and bending the rules to their advantage is called "smart".

I'd like to see the execs barred from country clubs, and a 2yr ban on playing golf.

rather a regular http proxy that every browser supports

And exactly as expected, they have a MSFT stack so they're wedged and think changing the spec is the right way to solve it. Sigh.

> With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment.

They key phrase is "rely upon", meaning they went down a route of using a clever hack rather than formally designing a system to meet their goals.

I wonder why SOCKs proxies, which every browser supports, wouldn't work for them.

Right, but you're just offloading lots of the work to staff then. So you prob can do it cheaper, but is is really going to be good? Or just a pile of hackery one guy put together?

I don't think non-viable to viable is exactly what's going on however, at least in most cases. I think the costs are not being fully understood, the impact to the mindshare of the team, the quality of service and redundancy, the additional headcounts and quirky management code that someone's going to be toiling away on when a cloud provider can handle it at a much lower cost.

Yes, you still have to open tickets, and yes, they still have problems that suck up a lot of time, however they spend the brunt of the time burning folks out fixing those issues, not you. If you talk to folks working with physical systems, that consumes their mindshare to the point that they're not focusing on their core product anymore.

You just end up wasting your time maintain relationships with hardware vendors, troubleshooting low level issue, upgrading firmware. It wastes a lot of people's time in the company, not just the team, and you're building one off tooling to work with some vendor's half broken management API. No thanks. :)

The problem with onsite data centers is that it's rare for the total cost to be tracked effectively, they often don't include salaries for example.

Additionally to say that building something outside of the cloud ensures you're cloud agnostic is too simplistic. There are many more shops that would like to move to the cloud to reduce their costs, but can't due to on-site lock-in. They then run into much more expensive problems around expanding datacenters, network or power limitations, or staffing to maintain physical machines which have real world MTBFs you have to do something about when they fail.

I think the issue isn't as much lock-in as much as apps being designed poorly, reliant on a specific feature that's not necessary, but then means their app will only work in one cloud as a result. However in the cases where there is no way around that feature, then you're getting a huge benefit of an instant solution so you can focus on your product rather than infrastructure. And if that cloud does provide a single killer feature you need, then just run that feature there.

Load testing is really hard, it would be interesting to see more research in this area, such as tooling and design patterns that flag bottlenecks that could be outages at larger scales.

It's pretty middle of the road, there are plenty of devs that pull in twice that. It's due to stock however, so it also depends on how well your company is doing.

Typically $150-180k is salary, and then benefits on top of that, so if you're at one of the bigger companies that offer RSU's your total comp is closer to $200k. But $170k is fine, and unless you're in a great tech area already, you'll likely make more connections.

Rent for most software folks is $1600-2500, the UW district is cheaper since it's a notch down from other areas. Ballard or Capitol Hill would be better, that or Ravina or Freemont. All great places for 30-something yuppies.

Depends on where you're coming from to say whether you'll like the weather, but it's not cold in Seattle, it has a lot of overcast and drizzly days though. Folks that like the weather here appreciate the mildness, not too hot and not cold. Outdoor stuff galore, lots of mountain related stuff, craft everything foodie scene, nerd gaming galore.

That's what the consumer would want too

That's not exactly true, cities can and do still have limits on the number of cars, case in point Seattle:

hhttp://blogs.seattletimes.com/today/2014/03/seattle-city-cou...

It would be interesting to know what MSFT's cost to run apps per users is. That would be a better measurement that captures total cost, rather than just the PUE.

It might not be that sudden of a change, you may still need someone watching the truck remotely, so one truck driver could be responsible for multiple trucks. So you could have larger fleets with the same workforce too.

Yahoo won't let you enable two-factor auth with a Google Voice phone number. Oh well, time to delete my account.

Here's the magic link: https://edit.yahoo.com/config/delete_user

That's interesting they didn't just collaborate on alembic.io, despite being sister companies.

... they are still redeeming things to do, but yeah, ideally you'd skip the scamming part. The Rockefellers made their money flatout on scams, but their name is fairly redeemed at this point.

It's a "me first" attitude, once folks get what they want, then they'll consider others. Pretty normal unfortunately.

I thought that was the punchline to all the cures. :)

That's interesting they just bought apigee which does about the same thing?

Some level of packet loss is not a sign of a problem, this is a common confusion which has lead to the buffer bloat issues, and many poor quality behaviours by apps within datacenters.

It's such a point of confusion that cloud providers don't want to even share the network error rates with customers since they feel they will misinterpret them.

You have to consider that there are other streams on the same network paths, so simply sending faster doesn't actually mean faster transfers.

It's almost identical to exiting a building during a fire, everyone can rush or exit orderly. Where the bottleneck is the door, and if everyone tries to get through at once, no one will.

Also what's interesting about not going off of packet loss, is that blips in the network are less likely to cause TCP connections to become synchronized and all backoff and re-probe at the same time.

"Magic code" is the modern "spaghetti code", where you still can't figure out what's going on unless you're deeply knowledgable about 10 layered frameworks that have invisible global state and the entire app magically appears from an annotation.

I'd love to know too, are there any frameworks that are at least more straightforward than React and Angular? One where you're not passing anonymous functions into functions with all sorts of confusing syntaxes, where you can just express what you want to do without having balance three types of punctuation that require the shift key to type.

A SQL db + Tableau are vastly more powerful and mature than those tools, they just can't do "big data", that's all.

I think the point is if you really have big data then it makes sense, but many shops add huge cost and complexity to projects where simpler tools would be more than adequate.

That makes sense. Yep.

Exactly my point, figure out the correct time and optimize for that, introducing what's effectively a neurosis seems kinda of neurotic way to work :)