HN user

pliu

241 karma

https://twitter.com/pwyliu

[ my public key: https://keybase.io/pwyliu; my proof: https://keybase.io/pwyliu/sigs/_COjb32nYGeprGg6N0wkb7NUI450EkJJTKGdRG57JBc ]

Posts4
Comments60
View on HN
HashiCorp Boundary 6 years ago

It would be interesting if the networking model for the end targets could also be inverted, so that an agent (or something) on the end target could make an outbound connection to establish a reverse tunnel to the proxy that user connections could then be sent over.

The use case I'm thinking of is for IoT or robotics, where you have devices you want to manage being deployed into remote networks that you don't have much control over. It's really helpful in this situation if devices make outbound connections only, so that network operators don't have to configure their firewalls to port forward or set up a VPN.

Edit: clearer language

That's really great introspection. I have the same tendency which has led to creating some really deeply unpleasant situations for myself. I hadn't thought about it quite in the same way until I read your comment, thank you for sharing this. I think I've just had a light blink on in my head.

In cases like the example mentioned, this is clearly a malicious entity. I don't agree that "get a subpoena" is the right response, some judgement should be applied to cases where someone is clearly using your service to do harm.

The thing that stuck out to me about the presser was the quote from the VP of Cloud and Enterprise Group, and that someone high up on Azure team is joining the Linux Foundation board of directors. This indicates to me that it's really a desire to compete effectively with AWS and Google Cloud that drives this co-operation, rather than a desire to expand Linux. Nothing wrong with this of course. Azure is a major cloud platform, personally I think it's better for everyone if Linux runs well there.

I actually was thinking about that too, but automated analysis of video at that scale seems prohibitively expensive unless you are Google or Netflix or something. Serving tons of video through a CDN is one thing, but the compute requirements needed to analyze it all are another.

Not that I have thought too terribly deeply about this, but I have a suspicion that this feature is actually powered by additional metadata sent along with the video by the content provider. It seems logical that if you were to control a vast archive of rapidly growing, extremely similar looking content, you would want to tag just about everything you could about it so you could build product.

I predict there will shortly be some dark future for all of us where we'll be able to don our Facebook nightmare helmets, say a single word, and have a super focused stream of filth blasted directly into our brains like that one scene from Demolition Man. That's where this is all going, right? Gotta be.

It's been quite a few years since I was last an Exchange administrator, but I seem to recall that you could secure a distribution list such that only authorized members could send mail to it. Perhaps (hopefully) only a relatively small group at NHS are allowed to mail all 1.2M mailboxes, and within that group there are 120 very silly people.

Signal and Giphy 10 years ago

I don't have an iPhone, but with the Android client at least, you can disable image auto downloading in the settings page. If you hate fun and are dead inside.

If you read the PDF, it seems the FPGAs can be used in a number of ways:

1) As a local co-processor, they have been deployed to accelerate selected Bing search ranking operations. This is described a little bit in the white paper, but I think the most interesting parts are going to be proprietary.

2) As a network accelerator, because they are inline with the server network interface. In the white paper using the FPGA for crypto acceleration is described. This is cool. The CPU overhead of encrypting 40Gbps is significant and managing keys for this many hosts is probably non trivial. Moving encryption to another layer would simplify things significantly I think, let app developers not think about it and let datacenter peeps manage keys independently of whatever is going on in the host.

3) As a large scale distributed processing grid. Because the FPGAs have their own network interfaces, they can be used independent of the host. Regular host network traffic gets passed through unaffected while the FPGA is simultaneously running distributed compute tasks from the grid. The white paper described training a DNN, but also describes their Hardware As A Service delivery model, meaning developers I guess have access to the grid and can deploy whatever they want. I would guess there is a lot of machine learning and map reduce type tasks going here, but who knows. The whitepaper also tantalizingly contains the phrase "cross-datacenter" which implies a globally distributed network of these things. Rad.

So that's a long way to say that I think there are very many use cases for this kind of thing. Coupling the FPGAs with regular compute nodes is operationally beneficial I think - they can be co-processors or they can be part of the grid. Microsoft is doing some pretty cool shit.

Edit: This whole thing is called Project Catapult. There are some other good papers here https://www.microsoft.com/en-us/research/project/project-cat...

Double Solitude 10 years ago

I've just started "The Best Day the Worst Day: Life with Jane Kenyon" after discovering the authors work here. I had to take a break after the first chapter, it is intensely sad. I don't have the right vocabulary to describe his writing. This man truly loved his wife.

https://www.amazon.ca/dp/B003JTHWIC

QUIC is a UDP based network protocol. It is an alternative to HTTP2 or HTTP, which are TCP based protocols. If you visit google.com with a recent version of chrome, you're using QUIC. Open chrome://net-internals/#quic in another tab and click a connection UID to see the conversation.

Be Kind 10 years ago

In my experience this strategy has not worked out very well. When we tried to deploy risky changes during low traffic times, we would end up creating time bombs, scale issues being masked until a high traffic time rolled around.

This also creates like a kind "brain latency" for developers I think. I'm coming at this from the operations side of things, so maybe my observations are a little biased here. I have observed that if people deploy changes and it breaks something immediately, it's a very clear correlation and they can fix the bug generally pretty quick. If they deploy and then it breaks 72 hours later, any number of things could be the culprit, especially in a fast moving environment (times 1 billion percent if it's a microservices architecture without a strong devops culture, which most of 'em are). Debugging then takes much much longer. This is made worse if the person who deployed the change is not quickly available when their thing breaks, and it makes being on call for someone else's unproven feature very stressful.

So instead I think it's better to make sure deployment and build systems are rock solid, and deploys are as accessible and as idempotent as possible. Chatops type systems are good here. Then you can roll out big changes during peak traffic and be confident that you can quickly revert if it goes bad, and that the changes were reliable under load if it goes good. I also think it's critically important that big changes are behind rollout flags, such that you can dial up or dial down traffic at will. This is also useful when introducing new cache systems or something like CDN if you need to warm up slowly.

This is a better approach I think than trying to use the time of day to modulate user traffic. I would rather developers can control traffic to their feature themselves and have the person deploying the change with their hands on the wheel until they are confident they can take them off. That way people can do stuff independently, and everyone can trust everyone to deploy and yet still feel safe.

500px | Toronto, Canada | Full time | Onsite

500px is a photo community and marketplace for discovering, sharing, buying, and selling inspiring photography powered by creative people around the world. We are well funded, backed by great investors and the company is growing super fast. Join us and help us build the very best place to show and sell photos.

Our architecture is a Ruby on Rails monolith surrounded by a constellation of Go based microservices. There are a wide variety of technologies and distributed systems in use, and you will always be welcome and encouraged to learn something new and to touch any part of the stack. We are passionate about what we ship, we care deeply about our craft and our users, and absolutely everything at 500px is made with love.

We are hiring many roles and disciplines, but we are especially looking for:

* Devops and site reliability engineers

* Backend and frontend engineers

* Data engineers

* Tooling engineers

Check us out and let's build something cool: https://about.500px.com/jobs/

Your comment made me curious, so I went looking and found a price sheet. I see two SKU's, one at $32K and one at $39K, I think probably this is just for the chassis. The storage modules list at $22K, $46K and $92K for the 1.2TB, 2.9TB and 5.7TB models, respectively.

I don't think too many people really end up paying list, but I have to imagine the markups are very healthy.

This thing looks rad af. I work exclusively with IAAS stuff now, but in a past life I used to spend a lot of time with enterprise hardware like this. I bet those modules feel real good when you snap em in.

http://www-01.ibm.com/common/ssi/rep_ca/3/897/ENUS115-003/EN...

500px | Toronto, Canada | Full time | Onsite

500px is a photo community and marketplace for discovering, sharing, buying, and selling inspiring photography powered by creative people around the world. We are well funded, backed by great investors and the company is growing super fast. Join us and help us build the very best place to show and sell photos.

Our architecture is a Ruby on Rails monolith surrounded by a constellation of Go based microservices. There are a wide variety of technologies and distributed systems in use, and you will always be welcome and encouraged to learn something new and to touch any part of the stack. We are passionate about what we ship, we care deeply about our craft and our users, and absolutely everything at 500px is made with love.

We are hiring many roles and disciplines, but we are especially looking for:

- Devops and site reliability engineers

- Backend and frontend engineers

- Data engineers

- Tooling engineers

Check us out and let's build something cool: https://about.500px.com/jobs/

I sometimes have a similar issue with Travis CI, if I can't use one of their built in integrations or something. A simple workaround is to just upload an artifact to S3 after a successful build. Then on another system scan the bucket with a cron or listen for an S3 event notification for further processing. You can put a lifecycle policy on the bucket so it cleans up after a while too.

It's sort of annoying to have to add on another system to the pipeline, but I think it's generally reasonable. Managing artifacts shouldn't really be part of the CI system anyway, I feel it's better to handle that stuff separately.

This is neat, but I feel a bit conflicted about it. Authenticate to phone, phone authenticates to website.

Certainly less laborious than entering a password, then authenticating to your phone so you can copy a token code. But I feel like my login would then become simultaneously more and less secure.

More secure from remote attackers who would have to spend a lot of effort to get at my phone, but like waaaayyyy more vulnerable to local attackers who could super easily get at my phone. Breaking the screenlock on my phone is surely easier than breaking a complex password.

I'm definitely an edge case in that I have a very high level of security for my personal stuff, but I've always modelled my security strategy on the fact that anyone can easily wack me on head and jack all my shit. You could put password auth on your phone, but from a UX perspective this is awful. I'd rather just have no phone.

So, conflicted. This feature sounds great, but feels less good than "normal" MFA. Maybe I'm being crazy and it's all just fine. I accept than my credit card number will somehow become compromised in the future, maybe we all just have to accept a little identity theft in our lives too.

I don't necessarily agree with this statement, but I suppose it depends on the vendor huh.

For what it's worth, I am currently running off the official packages at moderate scale (~30 machines all together) and have not yet had an issue with it, though it's certainly possible that one will arise and I will thereafter curse Elasticsearch forever.

In this particular case though, security updates are critical, so what other choice is there unless you want to package your own?

The situation is now like this:

* In Debian Jessie, you can still install the Debian Elasticsearch package, but it will not receive security updates any longer.

* In future releases of Debian, this package will not be available in the main repo, but will still be available in the unstable or jessie-backports repos.

* Elasticsearch (the company) maintains its own Apt repositories where they will provide updated versions according to their support policies. If you add this repository to your Debian based systems you can install the (supported) Elasticsearch package with "apt-get install elasticsearch".

It is my opinion that you should not deploy the Debian ES package in a production setting. Use the vendor repo and save yourself a headache.

The tone of this article is very upsetting. It begins with "I like to think I’m pretty alright at computers", but frankly I don't really agree that this is the case. Good at programming, maybe, but clearly not very good at ops.

Rather than accept that there are skills and experience they don't have, the author instead chooses to blame the entire world for their ignorance. The frustration on display is understandable and real and I totally get it, but the attitude is less forgivable.

Faced with a problem, instead stopping for a hot second to read some documentation, the author instead concludes that Docker is garbage, does some insane shit and then claims that the software industry has failed them. What incredible arrogance.

This article says way more about the character of this person than it does about the state of web app deployment.