HN user

jakemoshenko

233 karma
Posts1
Comments76
View on HN

Not the OP, but AMS can be useful for loading and unloading filament, as well as automatically continuing a print job when you run out of one spool of the same filament. It's not just for multi-color prints, although that's obviously the primary use case.

Can you though? The protocol is not very well documented and it seems to iterate rather rapidly with the server version that it aims to be compatible with.

Multiple frame generation (required for 5070=4090) increases latency between user input and updated pixels

Not necessarily. Look at the reprojection trick that lots of VR uses to double framerates with the express purpose of decreasing latency between user movements and updated perspective. Caveat: this only works for movements and wouldn't work for actions.

Tap to pay with spend controls sounds ideal for things like after school snacks/activities and transit. It could also be an easy to way to manage things like allowance digitally?

AuthZed (W21) | SRE, Customer Success Engineer, Technical Writer | Remote (US, EU) | Full-time

AuthZed is changing the way top tier companies add rich permissions experiences to their applications. Modeled after Google's Zanzibar, AuthZed offers a low-latency, high-scale permissions system, that scales to millions of QPS with milliseconds of latency.

Apply using https://www.ycombinator.com/companies/authzed/jobs

If the roles above aren't for you, we're adding new roles regularly so keep your eye on our work at a startup page!

Pros: It will automatically orient to either a frontal or rear collision and has tons of contact area with the body. If it's made of even a slightly stretchy material it would also spread the force out over some period of time.

Or you just mean they do some kind of low-res rendering mode to populate most of the framebuffer outside a smaller zone where they do full quality rendering?

This exactly. They don't reduce the resolution too much, but it's visible to an outside observer watching on a monitor.

I fear that fovea-tracking will remain scifi dreams in my lifetime, so the reality is we need to render full resolution throughout the field of view to be prepared for where the eye gaze might go in the next frame.

This is not at all true. All of the AVP, the Quest Pro, and the PSVR2 do eye tracking based foveated rending. They lower the clarity of the things you're not looking at. And reviewers say it works perfectly, like magic. They are unable to "catch" the screen adjusting for what they're looking at.

Detroit, as the capital of the auto industry, has far more parking than just about any other city I've ever been to. There are huge, multi-story garages right on the main thoroughfare downtown.

https://bigthink.com/strange-maps/parking-lots-eat-american-...

Detroit was, or is, Motor City. Its center can pull off another automotive-related nickname: Parking Central. Fully one-third of downtown Detroit is dedicated to letting cars do what they’re not designed for: standing still.

I've had a question that I haven't seen anyone else ask that you might be able to shed some light on: is there an internal battery to facilitate switching power sources without an instant loss of continuity?

Why do we need an accelerator when we know how fast the wheels are turning directly? The first derivative of wheel speed is almost always car acceleration. Is this to handle some edge cases like not turning the brake lights on when we're actually sliding on ice with the wheels locked? Seems unnecessary.

Tesla is 65 on the Fortune 500, and Twitter was ~600 before the acquisition. SpaceX is also huge, but it's hard to say just how huge without it being public. The amount of commitment and work to become CEO at a company that's even 600 on the Fortune 1000 is insane. A quick google says there are 213 million companies in the world, I think having at least two in the top 1000 counts, no?

While that's certainly one way to synthesize directional audio, the far more common way is to actually have the audio come from the direction it's supposed to and let your ear do its normal thing to sort it out. Imagine you had an entire room wallpapered in individually addressable tiny speakers, you could actually project sound from any angle. The added benefit being that it would work for more than one person in the room. we've gone from 2.1 audio -> 5.1 -> 7.2 -> atmos 11.2. Why wouldn't we want to go to 50000.2 audio as the next extension?

Authzed (YC W21) | Senior Site-Reliability Engineer (SRE) | NYC, Remote USA | Full-Time | https://authzed.com/

20 milliseconds at the 99.5 percentile and five-nines (99.999) of uptime. Those are our goals for our globally-distributed permissions system as a service. If you’re interested in helping us achieve these goals, we would like to talk. We’re currently using best-in-class open source solutions on the public cloud for delivering this vision: Kubernetes, CockroachDB, PostgreSQL, Prometheus, Pulumi, Cuelang, Let’s Encrypt, etc.

As part of our small team, you will help to build our application platform, delivery pipelines, data architecture, and the application itself. You should be passionate about both software development and infrastructure. In this role you will be required to code. You will also participate in our on-call rotation which is responsible for the health of our highly-available globally-distributed service.

About the Company

At Authzed, we’re solving application permissions. We’re building a highly available, highly reliable, multi-tenant permissions system as a service which is deployed globally. Modeled after Google’s Zanzibar, our core open-source component SpiceDB is revolutionizing the way developers build powerful, flexible permissions into any application. With our founding team formerly of Red Hat and CoreOS, open-source is deeply ingrained in the fabric of our company.

https://www.workatastartup.com/jobs/47704

We have it on our backlog[0] to add documentation on how to run it with Kubernetes, at least.

Very sorry about the "work in progress" moniker on our v1 APIs. We developed the v1 APIs based on our real-world experience running the Authzed.com service for ourselves and others, and we just finished their implementation and porting everything over. We will remove that warning ASAP!

One thing to note though, is that we thought about calling our v1 APIs v5 or something, because we didn't want to give the impression that they will never change. We intend to continue to improve the APIs, sometimes in backward incompatible ways, but will just keep the existing APIs around for a very long™ period of time, similar to how Stripe handles their API versioning.[1]

[0] https://github.com/authzed/spicedb/issues/147

[1] https://stripe.com/docs/api/versioning

This is a pretty good analysis of the situation I think. The only thing that I would like to point out is that only a description of the API is available via the Zanzibar paper. We, and other clean-room implementations, have had to fill in the gaps around what the APIs actually look like. We've even made some of our own improvements such as resource lookup by subject[0] and a filter-based delete that mirrors the read API[1].

[0] https://authzed.com/blog/acl-filtering-in-authzed/

[1] https://buf.build/authzed/api/docs/main/authzed.api.v1#authz...

There are a variety of synchronization methods, and the choice of which is very application specific.

The simplest choice to get started with is to add it directly to your application logic. The main pro of this solution is that you can directly handle the semantics of when and how to add/remove permissions. For example, it's sometimes safe and idempotent to write permissions for data that may fail to commit, because permissions for the data will never be queried in the future. You can also directly control the management of ZedTokens and effectively eliminate the new enemy problem[0]. As far as I know, this is how Zanzibar is used within Google.

Solutions which tail a primary source of truth, such as the database logs, kafka topic, event queue, etc. may perform better in some applications where eventual consistency on permissions is ok. With these systems you are adding some delay in between writing the data and the permissions, which can open you up to new enemy or require UX compensation like adding data on the client side and hoping the permissions replicate before they are ever queried for real.

We will work to write a guide that talks about some of these architectures and their pros and cons.

[0] https://authzed.com/blog/new-enemies/

Yes you can use it directly as a service with your own authentication. There is no Authzed account required.

The docs are built around the idea of using Authzed.com, the hosted SpiceDB solution for protecting your first app. We will try to put together a guide around self-hosting SpiceDB.

For usage from CloudFlare workers and other non-http/2 friendly environments, we're considering adding a gateway which can speak regular http natively. Bolt-on solutions like grpc-web or more invasive solutions like adding twirp support will be considered. Do you have a preference?

Disclaimer: We're a startup so things are obviously subject to change!

Right now, the business model is around running a single SpiceDB service globally so that you as a user don't have to figure out how to deploy and manage the service at scale.

This service is especially tricky to run because of the need for low latency, high availability, and a single globally replicated service. For an individual company to run HA clusters all over the world would be cost prohibitive, but when all Authzed.com customers share the cost it becomes more reasonable.

With our roots at CoreOS and in the OpenShift org of Red Hat, we've got a solid amount of experience building distributed infrastructure in Go. We toyed around with the idea of using Rust, as the reliable software building darling du jour, but ultimately we felt like with this team, at this time, we would create a better product in Go.