> Conclusion: Always set billing caps and alerts on cloud API keys.
Sadly, way easier said than done in the case of GCP. Been a proper reason for me to avoid GCP deployments with LLM use-cases for smaller projects.
I remember looking into this a while back assuming it would be a sane feature to expect. But for some reason it's surprisingly non-trivial with GCP to set budgets. Especially if the only thing you want is a Gemini API key with finite spending.
IIRC you could either set (rate) limits on quotas, but quotas are extremely granular (like, per region per model) meaning you need to both set tons of values and understand which quotas to relax. Or alternatively do some bubblegum-and-ducktape like solution where you build an event-driven pipeline to react to cost increases in your own project.
I understand that exact budgets are hard to enforce in real-time, especially for their more complex infra offerings.
However, (1) even if it's not exactly real-time, but instead enforced every hour that's already going to go a long way, and (2) PAYG LLM usage is billed rather linearly by the amount of tokens you use, so if there would be an easy way to set a dollar-amount and have that expressed as budgets that would already get you part of the way there.
Anyway, the current state of GCP budgeting it makes me avoid it for production usage until I'm ready to commit spending significant effort to harden it. For all small projects, the free tier tokens are a safe bet, but their extremely low rate-limits make them rarely a good fit.
> To be clear, I don't mean that the premium is warranted, but just that it may not be much of a privilege for many tourists.
Then we agree on that :)
For sure, it's not a big dent in ones budget for most travelers coming from other continents. The eSIM rates are indeed not that different from local rates. Looking at it transactionally, the premium is easily worth the convenience it yields.
Most of what I dislike about it is that being nearly forced to take the eSIM makes me feel more like an outsider.
Previous time I visited I did manage to get my local SIM, even though it took a couple of hours to find a store which was capable - and willingness - to issue one. This time, the regulation change caused my SIM card to get stuck in bureaucratic limbo because of new and poorly implemented additional KYC checks.
I appreciated the chore of getting a local SIM card, because it exposes you to integrate somewhat. It leads to interesting encounters outside of the normal tourist bubble, not just the people but also a bit in how their day-to-day business works. As such, I would like to be able to recommend others to try to get the SIM for themselves too.
Besides this 'stay in your privileged tourist bubble'-feeling, it also feels wrong that the premium between local data rates and the eSIM rates are that high. Even though the value-add seems minimal for anything other than skipping KYC completely and being able to pay with international credit card.
That difference goes somewhere and - I worry - that by fuelling that niche it only incentivizes the eSIM providers to lobby for borderline impossible KYC checks on local SIMs, which they can bypass for anyone able to afford that premium.
Airalo made getting a SIM in India so much easier. The KYC checks they introduced are poorly understood by local vendors making it really painful to get a local SIM.
Also, being able to pre-purchase the SIM card means you can immediately browse when arriving. When we arrived, the WiFi in Chennai airport couldn't deliver the OTP to our foreign phone numbers, so without the pre-purchased eSIMs we wouldn't have been able to get internet.
I don't like it that they charge such a premium, it makes having data as a tourist somewhat of a privilege. Also, local SIMs typically offer beside data also a local phone number, which can be really helpful.
Whether it's a viable business is to be seen though.
I've been a happy user of Prisma for a while, and so far we've not been running into severe limitations nor need for their additional services. Who knows what the future will bring though.
He wrote it out of a need and it actually works for his use-case:
> I created GitSlick mostly for sending messages to myself from one machine to another, mostly for use on e.g. customer machines where I can't use our own company Slack, and may be limited in what other tools I can install.
Ran into the same issue when naming our startup ClaimR, searching for the name on Google would indeed give a suggestion "Did you mean 'claim'" and completely tank our SEO.
Although ~9 months after launching the site it stopped giving this hint. Not completely sure what changed it, although in the meantime we added the domain to the Google Search Console and incorporated.
Nice, thanks for sharing the demos. Was sharing it at work and its hard to convince people to install something to try it out.
I was wondering about the commercial side, because I noticed that the code responsible for turning it into a "hosted" notebook was kept outside of the main repo, which seems common in SaaS approached.
Anyhow, using it for teaching is definitely a good purpose! In fact, it's the use case which sparked my interest. At work we give trainings and the training materials [1] are already in Markdown, so making them interactive by merely annotating them seems easy enough.
I'm happy to see these DevOps courses take off, two years ago when I was finishing my bachelors in CS DevOps wasn't even part of the curriculum. Being able to implement algorithms and architect code. Now these courses are everywhere and well up to date with the industries best practices.
Chris this is so cool! Earlier this year I was thinking about doing the same thing, mostly for making interactive CLI tutorials - similar to the Git tutorial you have in the examples. Then I tried with Jupyther notebooks, but it feels quite limited, and they are not as easy to work with as Markdown files.
I followed the installation instructions and it works super well! [The Gifs in the README already look promising, but it still lacks the empowered feeling you have when interacting with it.] There seem to be some rough edges, e.g. I bricked my session when enabling Docker probably because Docker wasn't available, but overall it all works super well.
Some small things w.r.t. presenting the project/idea:
- I nearly clicked away because there was no quick demo, merely pictures. In part because I scrolled over the install instructions - which could be fixed by a table of contents, but also because cloning and installing is quite a barrier when you still haven't seen much from the product.
- The website of ottomatica have some buttons which don't seem to do anything.
Anyhow, out of curiosity, what are your plans with it? I noticed it was an academic endeavor, are you planning on commercializing it and/or building a company around it?
For me the takeaway of this talk is that in our race of making UI design more and more consistent our websites and apps lost personality. This has gained us a lot (improved accessibility, cheaper, more performant), but during our path to optimize all UIs become so homogeneous that they lose personality.
It's a trade-off, however sometimes it might be better to be bold enough to explore and innovate to try to find something better than to stick with what is known to be working and copy whatever everyone else is doing.
Hmm, I see your concern. I'm pretty big on privacy myself, so I feel I should be able to answer this in a satisfying way.
Most importantly, this always requires the user's concent. On Android you still need the same location permissions as for normal GPS location positioning. Hence, as a user you're always free to reject location permissions same as before.
I have to admit, this tech can also be used for evil purposes. For now, not all phones support collecting raw measurements - either hardware or software support is lacking, but in the future if some entity could force you to have your location verified, then having you cannot lie about it anymore.
Problem: Currently, users (or attackers) can easily manipulate the location provided to an app on a phone.
Solution: Use raw measurements from positioning sattellites to check if the location reported by a user actually lines up with the measurements of their phone.
Why is it hard?
- Lack of documentation, standardization and support on collecting raw measurements on phones.
- Processing raw measurements is tricky
- Finding anomalies in this raw data is even harder
Some of it is working - yay! - and there's also a public API, such that others can use it too: https://claimr.tools
Reminds me a bit of https://juju.is/. Haven't looked at it much, but it seems super powerfull and tries to solve at least some of the issues you mentioned.
> Conclusion: Always set billing caps and alerts on cloud API keys.
Sadly, way easier said than done in the case of GCP. Been a proper reason for me to avoid GCP deployments with LLM use-cases for smaller projects.
I remember looking into this a while back assuming it would be a sane feature to expect. But for some reason it's surprisingly non-trivial with GCP to set budgets. Especially if the only thing you want is a Gemini API key with finite spending.
IIRC you could either set (rate) limits on quotas, but quotas are extremely granular (like, per region per model) meaning you need to both set tons of values and understand which quotas to relax. Or alternatively do some bubblegum-and-ducktape like solution where you build an event-driven pipeline to react to cost increases in your own project.
I understand that exact budgets are hard to enforce in real-time, especially for their more complex infra offerings.
However, (1) even if it's not exactly real-time, but instead enforced every hour that's already going to go a long way, and (2) PAYG LLM usage is billed rather linearly by the amount of tokens you use, so if there would be an easy way to set a dollar-amount and have that expressed as budgets that would already get you part of the way there.
Anyway, the current state of GCP budgeting it makes me avoid it for production usage until I'm ready to commit spending significant effort to harden it. For all small projects, the free tier tokens are a safe bet, but their extremely low rate-limits make them rarely a good fit.