To be fair, GitPod claims they will support devcontainer.json: https://github.com/gitpod-io/gitpod/issues/7721
1,288 karma · joined August 16, 2015
Capital One offers virtual cards through Eno (https://www.capitalone.com/digital/eno/virtual-card-numbers/) that are merchant locked. They make it somewhat cumbersome to use, but I've really enjoyed using them.
It doesn't block wall street knowing about what you're buying, but at least it's likely got one (or more) fewer middlemen looking at all your transactions.
Some other info we've published: https://www.crusoeenergy.com/digital-flare-mitigation
> I worked on a project that produced carbon offsets about ten years ago. The carbon offsets were generated by burning leaking methane from mines in China. UN officials tracked the process, and they required clean digital data and physical inspections of the project site. In that case, the carbon offsets that were produced were highly reliable. I believe many other projects have similar quality standards.
Crusoe Cloud (https://crusoecloud.com) does the same thing; powering GPUs off otherwise flared methane (and behind the meter renewables), to get carbon-reducing GPUs. A year of A100 usage offsets the equivalent emissions of taking a car off the road.
Disclosure: I run product at Crusoe Cloud
Very curious if/when they'll add speach to text/clearance. The syntax is fairly standard, so should be easy to parse, I'm just curious how tolerant folks would be of some % failure.
Totally. The instructions were "taxi Bravo hold short of Kilo" and "cross 31L at Kilo"; read back was correct but instead of turning right at Kilo and crossing 31L, the pilot turned left, then right, and crossed 4L at Juliet.
While taxiing, you're supposed to have the taxiway map up (https://flightaware.com/resources/airport/JFK/APD/AIRPORT+DI...), and something like ForeFlight (which many pilots, GA and commercial, use) will alert you when you're approaching a runway as well as once you enter it. Not sure what the instruments in a 20+ year old 777 will have to help with this (likely the taxiway map, unsure if they'll alert on runway entrance).
On communication: most modern flight computers do support getting your IFR clearance from the FAA (see CPDLC: https://en.wikipedia.org/wiki/Controller%E2%80%93pilot_data_... and Tower Data Link System: https://www.faa.gov/air_traffic/flight_info/aeronav/acf/medi...). This doesn't include taxi clearance.
Looks like ForeFlight and MITRE are working on bridging the gap (take the audio taxi clearance and overlay it on the map): https://www.mitre.org/news-insights/impact-story/runway-safe...
EDIT: here's a video of the feature in action: https://www.youtube.com/watch?v=9p5-7jVg8fE; looks like it's only on the most expensive plan though :/
- Fluidstack: https://fluidstack.io
- Vast: https://vast.ai
- QBlocks: https://qblocks.cloud
- RunPod: https://runpod.io
- Sonm: https://sonm.com (blockchain)
- Golem: https://golem.network (blockchain)
- Rentaflop: https://rentaflop.com (rendering specific, blockchain)
- RNDR: https://rendertoken.com (rendering specific, blockchain)
If you want HPC specific cloud providers:
- Crusoe Cloud: https://crusoecloud.com
- Coreweave: https://coreweave.com
- Lambda Labs: https://lambdalabs.com
- Paperspace: https://paperspace.com
As others have pointed out, the decentralized clouds can't offer high performance interconnects (e.g. InfiniBand) that a lot of folks are using for LLM training. There are definitely initiatives underway to reduce dependence on these interconnects and build performant distributed training (again, some threads below mention this), but I think it's mostly academic at this point.
Disclosure: I run product at Crusoe Cloud, which aims to provide ML training at half the cost of a hyperscaler, while also being carbon reducing (https://crusoecloud.com/climate-impact/).
To a developer, think of them as glorified linters (most of them are, including Kubescape, I believe). Someone on your team chooses which included things should be flagged (e.g. "require resource limits to be set on pods", see the list here: https://github.com/kubescape/regolibrary), and then the tool yells at you when you try to do something it doesn't like. It's then up to you to figure out how to comply with the tool's decisions. Some people really like them, some people really hate them.
To an engineering manager or SRE team, I think they're great at preventing common errors that would otherwise be enforced through code reviews or other processes; they're basically the remediation after an outage where a pod OOMed ("if we set sane resource limits and enforce them, this won't happen" --> enforce resource limits policy).
To your company's legal and compliance team, they usually fulfill a checkbox requirement along the way to $COMPLIANCE_FRAMEWORK. By the time your company is at sufficient scale, you'll have a number of these, and automation is the only way to keep everyone sane (developers and auditors alike).
In general, I think they're well intentioned, and can be useful, but aren't a panacea--they aren't going to catch anything you're not already looking for, they're just going to make it easier to remedy/enforce the problems you already know about.
Disclosure: Former Security Products PM at GitHub
IMO the key to doing it right is ensuring that your hosted solution actually provides value: either because its difficult to operate at scale, there are certain regulatory/compliance requirements that need to be met, because certain features are restricted to a hosted product or under an enterprise license, etc.
I've seen a decent number of people create a hosted version of their product, slap SAML/SSO behind an "enterprise" plan, and wonder why nobody their successful OSS product doesn't translate to meaningful hosted revenue.
The vast majority of cases were "simple cheating" (e.g. sharing answers during a test, collaborating when collaboration was specifically forbidden). Of these, a large percent were foreign exchange students, who explained the behavior as either a difference in the nature of education (individualist in the US vs collectivist in their home country) or a claimed misunderstanding of the instructions due to language barriers (despite reasonable TOEFL scores required to be admitted).
From talking with faculty who had served on the committee for longer than me, while those were occasionally the issue, more often than not students cheated for one of two reasons: 1) external pressure for them to get a good grade (e.g. parents paid tuition proportionally to GPA, or punished for poor grades), or 2) desire for credential over knowledge or apathy towards the education itself.
Crusoe Cloud is hiring engineers to build a high performance, carbon negative cloud platform. We're a series C company with a growing engineering team (currently ~20) looking for folks to align the future of computing with the future of the climate.
Our stack: GCP, K8s (and related ecosystem), go, Typescript and React frontend.
Job descriptions: https://www.crusoeenergy.com/careers
Feel free to email me at: mike at crusoecloud dot com if you're interested!
I totally agree that Google's tooling is _legendary_ when you understand it all, but I also agree that having to learn 15-20 different config languages to get a service running in production was pretty damn painful when we only had three months to do it. There's also been a good amount of work in the world outside of google to get tooling to a similar place (and in many cases, without 20 years of baggage).
I think I mentioned this on another thread, but the "weakening" you mention is "strengthening integrations with other parts of the platform." I think the general thought here is that an App Engine or a Firebase is a local maximum, and in exchange for trading off deeper integration, there is a platform wide global maximum that is achievable.
Pre-acquisition Heroku, GitHub, Firebase, etc. all were able to achieve local maxima, which led to acquisition, and subsequent attempts to globally optimize.
Dev tools is a brutal business: if you're lucky, 80% of your customers cost you money, 15% break even, and 5% are where 80-90% of your revenue comes from. A better DX typically only gets you more customers in the bottom 95% bracket, because it's easier to onboard people who can get from 0 to 1 than from 10 to 100 (or 100 to 1000). Deeper integrations into the features on the far side of the curve tend to get prioritized and look a lot like what folks here are discussing as negatives.
> I've never gotten the impression that at google DX was lionized. Examples of doing this well culturally are pre-Salesforce Heroku, Github, vscode, and Stripe.
It's not, for the reasons others have pointed out about people being smart enough to figure out the solution regardless of the DX, etc.
> Easy things should be easy, and complicated things should be possible.
Was he being serious when he said that? I'd hardly call regex a technology where easy things are easy and complicated things are possible (there are plenty of impossible things in regex implementations e.g. backtracking in RE2).
No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory).
> * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess.
It's a general criticism of any "access your database/storage bucket/etc. directly from the client" product--everyone has to build _some_ authZ mechanism that lives in between the client and the server, whether it's Firebase Rules, Postgres Row Level ACLs, Lambda Authorizers, etc. Otherwise you're writing your own authZ code on your own server, which has it's own set of issues.
> * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers.
I don't think https://firebase.google.com/docs/rules is the best documentation ever, but I'm not sure "scant" is the word I'd use to describe it. What are the main areas you think are missing?
If folks want to build proprietary APIs, and people choose to use them because they are faster/better/cheaper/more suited to a particular use case, I'm not sure why that's a bad thing.
Engineering is tradeoffs, proprietary API surface is one of many things people consider.
Was this cold start latency specifically or request latency in general? Do you know what region you were deployed in?
"There are two ways to make money, bundling and unbundling." - Jim Barksdale
The quote is mostly provided in jest, but at the same time there are many customers who want something totally bundled that solves 90% of their problems in 20 minutes but literally can't solve the last 10%, and there are other customers that want generic building blocks that can solve 100% of their problems, even if it takes years to do.
I think it makes sense that Google offers customers both.
> But even Firebase isn't strong enough to resist the gravitational pull of the GCP behemoth.
Part of the reason we got acquired is because of the above: we knew that we had a number of limitations (e.g. infra scalability) that could be solved, and we knew that GCP had DX problems offering a bundled mobile offering (App Engine wasn't "mobile" focused).
And that acquisition really paid dividends: we were able to build a _ton_ of "bundled" services for Firebase by 2016, and continue deeper integrations with GCP (Storage, Functions, Firestore, Auth, etc.). There are definitely UX differences (some of them intentional, due to different audiences), some not (e.g. it seems like not having an integrated log viewer is a DX miss, though my assumption is that staffing on the Firebase side is down so the decision was made to just send folks to the GCP console :/).
Firebase launched an alpha in April 2012 and got acquired in 2014, so I'm not sure how you've stopped following it for a decade because it's only existed for about that.
> 1) It used to download the whole state (write history) upon startup. Did they ever update it to send a snapshot, or a partial view of the data with lazy-loading for additional nodes?
Yes, that feature shipped in 2014.
> 2) Did they ever provide a simple push notification service? That was pretty much the only thing missing to be able to run Firebase without another server.
Firebase integrated with Google Cloud Messaging in 2016. Cloud Functions (which was also 2016-17) allowed operation without a server.
> 3) Were node aliases/shortcuts ever implemented, so a node could be a reference to another node? That would have greatly reduced the need for a SQL JOIN alternative.
No, the guidance was to duplicated data across paths (when Cloud Functions existed, folks used them).