https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock...

Comments URL: https://news.ycombinator.com/item?id=44864482

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44646089

Points: 1

# Comments: 1

I've often noticed that these boundaries are not considered when carving out microservices.

Subsequently, workarounds are put in place that tend to be complicated as they attempt to implement two phase commits.

https://www.nasdaq.com/press-release/nasdaq-completes-migrat...

  It helps standardize:
    - deployments of containers
    - health checks
    - cron jobs
    - load balancing

Is it same/similar across teams within and outside your organization.

If not, what would it cost to build consensus and shared understanding?

How would you build this consensus outside your organization?

For small organizations, one should do whatever makes them productive.

However, as soon as you need to standardize across teams and projects, you can either build your own standards and tooling or use something like K8S.

  Once you have K8S, the extensibility feature kicks in to address issues such as:
   - Encrypted comms between pods
   - Rotating short lived certificates

However, if not K8S then, what alternative should we consider to build consensus and a shared understanding?

From a moat perspective, I wonder if the TAM of this business in the context of the three cloud providers is substantial.

Their stock price is back down to reasonable levels.

Perhaps they'll remain a niche player in the market?

    #!/bin/sh

    set -e

    if [ -n "$VERBOSE" ]; then
      set -x
    fi

    if [ "$1" = "--show" ] && [ $2 = "twitter" ]; then
      echo "https://twitter.com/teaxyz_"
    elif [ -n "$1" ]; then
      # Hi, I know you’re excited but genuinely, pls wait for release
      # I added this so I can do CI :/
      case $(uname) in
        Darwin) suffix=macOS-aarch64;;
        Linux)  suffix=linux-x86-64;;
        *)
          echo "unsupported OS or architecture" >&2
          exit 1;;
      esac

      if [ "$1" = "brew" ]; then
        d="$HOME"/.tea/bin
        mkdir -p "$d"
        curl https://tea.xyz/dist/tea-$suffix -o "$d"/tea
        echo "$d" >> $GITHUB_PATH
      else
        mkdir opt
        curl https://tea.xyz/dist/tea-$suffix -o ./opt/tea
        chmod u+x ./opt/tea
        shift
        ./opt/tea "$@"
      fi
    else
      echo
      echo "418 I’m a teapot"
      echo
      echo "thanks for your interest in tea."
      echo "alas, we’re not quite ready to serve you yet."
      echo
      echo "while you wait why not follow us on Twitter:"
      echo
      echo '    open $(sh <(curl tea.xyz) --show twitter)'
      echo
    fi

Comments URL: https://news.ycombinator.com/item?id=29474108

Points: 147

# Comments: 2

From https://incoggo.com/faq/

  If you’re a very security-minded individual (or you use your computer for very sensitive tasks), before using Incoggo you may want to be aware that the application does the following:

  Upon installation, Incoggo adds a file to your system’s sudoers.d folder that whitelists specific commands from requiring a sudo password to perform. (This allows Incoggo to manage your system proxy settings, kill certain processes on shutdown / restart, and perform tasks related to Incoggo’s auto-updating feature without requiring that a sudo password be prompted each time.)

  Incoggo loads external Javascript files when you visit specific domains (i.e. those we filter paywalls / clear cookies on / clear storage on / etc.).

  Incoggo overwrites a few system defaults (re: open page / process limits) at runtime for performance reasons.

  Upon installation, Incoggo also installs a trusted root certificate in your system keystore. This is required for Incoggo’s advanced filtering functionality to work (unlike the issues above – which we intend to clean up shortly – this one is a hard requirement for the app to work).

The conflating part here is that using the callback as a mechanism to imply subscription.

This works for your situation.

However, if you need to start making multiple backend calls, then, you will likely need to separate the authentication part from the subscription part.

Generally, OAuth implies that the requirement is to get authenticated by a provider and making multiple subsequent calls to some backend. Additionally, the backend will verify the authenticity of the short-lived token before allowing the operation to proceed.

The title of the article says OAuth, and hence assumed that you wanted an authenticated client to be able to make the call to the backend for subscribing.

  ... one might think implementing OAuth sign up is relatively trivial; after all, you just need to write a fetch request that redirects the user to the OAuth page, then another request that sends their email to the newsletter service of choice to sign them up. Well, the issue is that in order to do the second step of that process, one needs to hit an API endpoint that requires authentication (an API key). That is essentially a password and not something you want to expose on the front end and give everyone access to.

This article Auth0 does a good job of explaining PKCE: https://auth0.com/docs/authorization/flows/authorization-cod...

I recommend https://www.peplink.com/products/ap-one-ax/

Minikube sets up a Linux VM using MacOS Hypervisor.

It even has a convenience command to configure docker-cli/docker-client.

  $ minikube docker-env
    export DOCKER_TLS_VERIFY="1"
    export DOCKER_HOST="tcp://192.168.65.11:2376"
    export DOCKER_CERT_PATH="/Users/wibble/.minikube/certs"
    export MINIKUBE_ACTIVE_DOCKERD="minikube"

  $ minikube start --embed-certs