cameroncooper

I did not. Didn't want to call anyone specifically here. Should have gone to you but didn't really pursue the question any further.

IMO there isn't a distinction between Launch/Show, or at least one that's well understood. When we were going through our launch we asked what the difference was and didn't get a clear answer.

We have two approaches to securing this kind of data. Once you specify what fields you want secured we can simply mask it out, or we can hash the data in a way that allows you to search for it if you know the value you are looking for.

Thanks! Our standard model for on-premise is an annual license and depends on some factors such as request volume and features.

The standard model for on-premise is an annually licensed managed service. We deploy, manage and monitor the platform on the customer's resources (usually AWS account).

Great questions on credential management and transformations. These are not in the offering today, but they are on our near-term roadmap and we are very excited about their potential. As you've alluded to, there's a lot we can do there.

Yes it is. Bearer relies on client side instrumentation. Today that is limited to just Node.js and Ruby applications. While we also support client side instrumentation, the proxy is an important element in our offering because it is language agnostic and enables a new class features that can only be implemented in the proxy (e.g. caching).

Thanks for sharing your experience. We love GLA as well.

Great questions.

- For sensitive fields that you do not want retained or searchable, we can mask them out.

- We don't currently have integrations to push our logs to another service, but this is a good use case for us and it's on our near term roadmap.

- We use Elasticsearch in the product, but we also use CloudWatch extensively for our own operations.

- Right now we only support proxying HTTP requests, but are open to supporting other protocols.

Thanks for sharing your experience, we have heard similar things from other companies. We do have plans to create common interfaces for different services like SMS/email as you have suggested. This will allow us to seamlessly fail-over between providers to maintain uptime and performance without any action on the client part.

We wanted to architect a system that made it easy to deploy proxy nodes to multiple regions and clouds. We also wanted it to be easy to add functionality specific to our feature set. While we might have been able to achieve our goals by modifying an existing proxy, it made more sense to us to build our own. I have built proxies in previous companies and this was something I was very comfortable doing.

This is something you can easily configure with our automatic retry function. We have an option to return a pre-configured response to the caller, and put the request in a queue to be retried until successful. This allows you to have a sustained outage while making sure all calls are eventually delivered.

We are not built on top of Envoy and have built our own proxy.

Many of the service mesh solutions require you to deploy and manage them as an on-premise installation. Our primary offering is a hosted solution, but also offer a managed service for on-premise installations.

As you've correctly pointed out the service mesh solutions can allow routing of external traffic, but by focusing on the external calls there are features that make sense for us to build that wouldn't make sense in something like Istio/Gloo/AppMesh. For example, we can build an enhanced experience around third-party APIs to better understand the calls, errors, quotas, etc that are specific to that provider.

Glad it's been able to help! Please let us know if there's anything else we can do.

You're right that there are a number of proxy solutions out there, but most are focused on exposing an API for external consumption (i.e. API producers). We think that by focusing on outbound API calls we can go deep on features that make less sense in those products. The same is true for the analytics solutions (i.e. Newrelic). For example it wouldn't make sense for them to add automatic retry or request caching, but its still a common pain point with integrations and makes a lot of sense for us to build. Finally, some of the tools (i.e. Runscope) are meant for development debugging and don't solve the production pain point.

Nuclear Fusion has a really interesting history. There's a good book called A Piece of the Sun I highly recommend to anyone interested in the subject. I was surprised on just how much money has been spent by so many countries on research, how different designs have evolved and just how much politics has influenced its development.

Very cool! This emulator even correctly mimics some of the hardware in the Apple 1 TV interface that strips out invalid characters. Many emulators miss this and simply replace them with a blank space. https://apple1org.wordpress.com/2012/02/19/a-common-apple-1-...

Great project! I went down a similar path some years ago and ran into the same limitation with lack of any existing software. Very cool that you've got a chance of digging up COS!

Here you go internet friend

https://www.wired.com/2005/02/microsoft-5/

With NLB targetting EC2 you can only specify one port per target group. To achieve multiple ports going to a single instance (or autoscaling group) you need to have one listener and target group per port.

I tend to agree. As much as I love 1984, I tend to agree with some of the points Huxley made in his letter to Orwell in 1949.

"Whether in actual fact the policy of the boot-on-the-face can go on indefinitely seems doubtful. My own belief is that the ruling oligarchy will find less arduous and wasteful ways of governing and of satisfying its lust for power, and these ways will resemble those which I described in Brave New World."

The letter is very interesting and worth a read.

https://cognitive-liberty.online/orwell-versus-huxley/

Surprised that nobody has mentioned the true hero of this story - git bisect - awesome tool, and perfect for pinpointing these sorts of regressions.

No

"Error establishing a database connection"

When I set up my Deep Learning rig I intended to run Linux, but ended up installing OS X and have had a great experience. Really no other way I could get a Mac with these kinds of specs:

Titan X, 32GB Ram, 6-core i7-5820, hot-swap SATA bays, water-cooled CPU/GPU.

Would definitely build another in the future, especially given the status of Mac Pros.