If we're talking about putting static assets (like basic websites) on their CDN, or moving your backend to Workers, (etc...) you are by definition moving _away_ from single point-of-failure.
> Maybe that's the core of this message. Face your fears. Put your service on the internet. Maybe it goes down, but at least not by yet another Cloudflare outage.
Well I'd rather have my website going down (along with half the internet) be the concern of a billion dollar corporation with thousands of engineers - than mine.
We once had a cloudflare outage. My CEO asked "mitigate it" I hit him back with, okay, but that'll take me weeks/months potentially, since we're tiny, do you really want to take away that many resources just to mitigate a once every few years half the internet is down issue?
He got it really quickly.
I did mitigate certain issues that were just too common not to, but when it comes to this sort of thing, you gotta ask "is it worth it"
Edit: If you're so small, cloudflare isn't needed, then you don't care if you go down if half the internet does. If you're so big that you need cloudflare, you don't wanna build that sort of feature set. The perfect problem.
I think that really depends on feature usage. You can use Argo/Cloudflare tunnels to route to private backends that are normally unroutable. In such a setup, it might be quite difficult to remove Cloudflare since then you have no edge network and no ability to reach your servers without another proxy/tunnel product.
If you're using other features like page rules you may need to stand up additional infrastructure to handle things like URI rewrites.
If you're using CDN, your backend might not be powerful enough to serve static assets without Cloudflare.
If your using all of the above, you're work to temporarily disable becomes fairly complicated.
It depends. The site is up, but now you're pumping 10x/100x the traffic. What are you scaling up?
Suddenly you're not blocking bots or malicious traffic. How many spam submissions or fake sales or other kinds of abuse are you dealing with? Is the rest of your organization ready to handle that?
I self-host my blog on a server in my home. Instead of opening a port to my home network, I'm using Cloudflare Tunnel to expose the blog to the internet.
That's not really anonymity or privacy in all likelihood, though. Your residential IP is already anonymous. Knowing it tells me nothing other than your general region. The benefit there is that you don't need to have a static IP.
And besides, Cloudflare Tunnel is distinct from (though it integrates with) the cdn product.
> you are by definition moving _away_ from single point-of-failure
Depends on the frame of reference of “single point-of-failure”.
In the context of technical SPOFs, sure. It’s a distributed system across multiple geographies and failure domains to mitigate disaster in the event any one of those failure domains, well, fails.
It doesn’t fix that technology is operated by humans who form part of the sociotechnical system and build their own feedback loops (whose failures may not be, in fact are likely not going to be, independent events).
SPOFs also need to contemplate the resilience and independence of the operators of the system from the managing organisation. There is one company that bears accountability for operating CF infra. The pressures, headwinds, policies and culture of that organisation can still influence a failure in their supposedly fully distributed and immune system.
For most people hosting behind Cloudflare probably makes sense. But you need to understand what you’re giving up in doing so, or what you’re sacrificing in that process. For others, this will lead to a decision _not_ to use them and that’s also okay.
Definitely has similarities. I think we do not realize how most top websites and services rarely go down anymore, and we use them 100 times more than we did 20 years ago. Building your own networking, compute, storage, CDN, or database solutions to avoid dependencies on AWS or Cloudflare would almost certainly lead to more service downtime than relying on highly sophisticated third parties.
But now, when one of these services breaks, everything on the internet goes down. And it is a lot easier to explain to your director of engineering that the whole internet is down than to say that your custom home-rolled storage system fell over, or whatever esoteric infrastructure failure you may run into doing it yourself.
> That's a bit like the 'nobody was fired for choosing Oracle' argument, but it does make sense.
The reaction to AWS US-East-1 going down demonstrates this. As so many others were in the same boat, companies got a pass on their infrastructure failing. Everyone was understanding.
I just paused cloudflare on a site of mine. On a normal day, it would be pretty easy to unpause it if it gets hit by a DDOS. Now cloudflare is down and the site is up again. Small sites do not benefit much from the performance effects of cloudflare either. Site won't be in their cache.
I guess by using cloudflare you are pooling your connection with other services that are afraid of being ddosed and actively targetted, whether by politics or by sheer volume. Unless you have volume or political motivations, it might be better not to pool, (or to pool for other purposes)
Another idea I had with this concept is to make an LLM-proof captcha. Maybe humans can detect the characters in the 'motion' itself, which could be unique to us?
- The captcha would be generated like this on a headless browser, and recorded as a video, which is then served to the user.
- We can make the background also move in random directions, to prevent just detecting which pixels are changing and drawing an outline.
- I tried also having the text itself move (bounce like the DVD logo). Somehow makes it even more readable.
I definitely know nothing about how LLMs interpret video, or optics, so please let me know if this is dumb.
An awesome addition to this would be to illustrate the effect of investor liquidation preferences during an exit. A graph of sale price vs your take would be really helpful for this since it’s nonlinear.
UI suggestion: allow click-drag on percentage boxes. I was tweaking percentages between 4 founders in order to come up with certain amounts post-round and it was a bit trial and error. On mobile it would have been tons easier if I could just nudge the values up and down rather than having to type them all in again.
As somebody else suggested just a share link would be a good way to allow sharing. Alternatively, for either a share link or as just a way to keep the state in the URL, I'd recommend B64 encoding the data as opposed to just directly escaping it. URLs have a maximum length (forgot off the top of my head, may be 1024 or something), so storing large stringified objects usually results in issues as opposed to just encoding it. It also makes for a more logical URL structure of fundingsimulator.com/{b64}. This is if you wanted to keep the URL as the single source of truth on the state, otherwise you could keep state internally which can be initialized by optional URL state (structured as stated before), and then just encode it and put it in a URL which is copied to clipboard when a share button is clicked.
Or hire better accountants. No, I’m not talking about the creative kind, but the kind that tell you “hey, your cash reserves are projected to be too low” kind.
If your accountants are telling you when it’s too late; you are losing. Hard.
Cashflow management,
but that is mostly up to you. They can’t stop you living beyond your means just tell you what those means are. Another example (in countries that have it) is GST/VAT that you collect and pay the government later assuming you didn’t spend it!
thanks for the suggestion!
we had the same thing happen as well. although it's not very standard I think in the case of safes. a dirty way now would be to do "Resere/give options" before the safe.
The sad thing is that it definitely could be. If you install Bitwarden (an Electron based password manager) from the Arch user repos, Electron is a separate dependency shared with other Electron applications. This means Bitwarden itself can be downloaded in just 5.4 MB (compressed, of course).
Tauri is not that different, though its dependency is the system browser rather than the Electron framework itself. I think Tauri's approach is better, but a lot of Electron applications could be only a few megabytes in size if dependency management wasn't done so badly in modern software distribution.
Unsurprisingly, the Linux AppImage is 87MB in size because it comes with a runtime. There's a smaller (17MB) .deb file, but I don't see any references to a package repository, so I guess on Debian based systems it'll just make you download the .deb every time to install it manually.
You can make interactive web sites with a minimal amount of JS (et al).
For example the mentioned Go has a HTML templating package in the std library.
You could use something like htmx (the creator is a regular on here) which is a very small, very convenient library that gets you 80% of the way for your typical web application.
For the rest, you can always just stick with plain old DOM manipulation or write web components if you want something that's more re-usable and general. No build step or transpilation shenanigans required here.
Sure, but you don't have to do it the way most JS projects do it.
I've made a career writing Django apps. In most cases, the JS I write is limited to vanilla JS with no JS dependencies (the minification is done by a Python library which might depend on JS, but it's abstracted away enough that I don't have to know). There needs to be a serious amount of justification to even install Node/NPM as part of a project.
The vast majority of work is done on the backend, with JS only being used for UX. I used to pull in React+ReactDOM on some projects, but Web components are paving the way for that to no longer be necessary.
As I mentioned elsewhere, it's possible to pull all of pip into a Python project and have all the same problems, but the culture around Python isn't quite as myopic as the JS community, so I've generally been able to keep dependencies more sparse when working on Python teams.
> Maybe that's the core of this message. Face your fears. Put your service on the internet. Maybe it goes down, but at least not by yet another Cloudflare outage.
Well I'd rather have my website going down (along with half the internet) be the concern of a billion dollar corporation with thousands of engineers - than mine.