I think you should consider putting this information in your site. I always read "we don't support Firefox" as "we are lazy", but that's not always the case.
That's true, but you forgot a key piece in this puzzle. The AI can only produce things that already exist. It can combine new things, this is why you can it for a picture of Jesus planting a flag on the Moon. But it only works because Jesus is a concrete concept that already exists in our world. If you ask for a picture of jacquesm planting a flag on the Moon the result will be nonsensical.
Nano Banana 2 has an image search tool that looks up pictures of things and uses them in the context (and arguably, an agent could eventually figure out who jacquesm is and hunt for a photo).
However, I tried "a picture of jacquesm planting a flag on the Moon" for a laugh, and I have to hand it to Google as the person was in a spacesuit, as they should be, and totally unidentifiable! :-D
Has anyone ever tried to have a SMTP server to receive e-mails and have an integration with third-party services to send e-mails (aws ses, sendgrid, ...) ?
In my experience receiving e-mails is easy, you just need to deal with some spam. But reliable e-mail delivery can be tricky, especially if you don't send a lot of e-mails regularly.
> they make per-instance decisions with per-instance state
But this is a feature, not a bug. You seems to be assuming that people use circuit-breaks only on external requests, in this situation your approach seems reasonable.
If you have cbs between every service call your model doesn't seem a good idea. Where I work every network call is behind a cb (external services, downstream services, database, redis, s3, ...) and it's pretty common to see failures isolated in a single k8s node. In this situation we want to have independent cbs, they can open independently.
Your take on observability/operation seems interesting but it is pretty close to feature flags. And that is exactly how we handle these scenarios, we have a couple of feature flags we can enable to switch traffic around during outages. Switching to fallback is easy most of the time, but switching back to normal operation is harder to do.
You're right, for intra-cluster calls where failures are scoped between the node itself and the infra around it, per-instance breakers are what you want. I wouldn't suggest centralizing those, and I might be wrong, but in most of these scenarios there is no fallback anyways (maybe except Redis?)
Openfuse is aimed at the other case: shared external dependencies where 15 services all call the same dependency and each one is independently discovering the same outage at different times. Different failure modes, different coordination needs, and you have no way to manually intervene or even just see what's open. Think of your house: every appliance has its own protection system, but that doesn't exempt you from having the distribution board.
You can also put it between your service/monolith and your own other services, e.g. if a recommendations engine, or a loyalty system in an E-Commerce or POS softwares go down, all hotpath flows from all other services will just bypass their calls to it. So with "external" I mean another service, whether it's yours or from a vendor.
On the feature flag point: that's interesting because you're essentially describing the pain of building circuit breaker behavior on top of feature flag infrastructure. The "switching back" problem you mention is exactly what half-open state solves: controlled probe requests that test recovery automatically and restore traffic gradually, without someone manually flipping a flag and hoping.
That's the gap between "we can turn things off" and "the system recovers on its own." But yeah, we can all call Openfuse just feature flags for resilience, as I said: it's a fusebox for your microservices.
Curious how you handle the recovery side, is it a feature flag provider itself? or have you built something around it and store in your own database?
> where 15 services all call the same dependency and each one is independently discovering the same outage at different times
I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter. This solution will save a few hundred requests, but I don't think this really matters. If this is a pain point its easier to adjust the circuit-breaker settings (reduce the error rate, increase the window, ...) than introduce a whole new level of complexity.
> Curious how you handle the recovery side
We have a feature flag provider built in-house. But it doesn't support this use-case, so what we done is to create flag where we put the % value we want to bring back and handle the logic inside the service. Example: if you want to bring back 6,25% (1/16) of our users this means we should switch back every user that has an account-id ending in 'a'. For 12.5% (2/16) we want users with account-id ending either in 'a' or 'b'. This is a pretty hacky solution, but it solves our problem when we need to transition from our fallback to our main flow.
> I don't really see what problem this solves. If you have proper timeouts and circuit breakers in your service this shouldn't really matter.
Each service discovering by their own is not really the main problem to be solved with my proposal, the thing is that by doing it locally, we lack observability and there is no way to act on them.
> what we done is to create flag where we put the % value we want to bring back
Oh I see, well that is indeed a good problem to solve. Openfuse does not do that gradual recovery but it would be possible to add.
Do you think that by having that feature and having the Openfuse solution self-hosted, it would be something you would give a try? Not trying to sell you anything, just gathering feedback so I can learn from the discussion.
By the way, if you don't mind, how often do you have to run that type of recovery?
> The real question is what existing language is perfect for LLMs?
I think verbosity in the language is even more important for LLMs than it is for humans. Because we can see some line like 'if x > y1.1 then ...' and relate it to the 10% of overbooking that our company uses as a business metric. But for the LLM would be way easier if it was 'if x > base overbook_limit then ...'.
For me, it doesn't make too much sense to focus on the token limit as a hard constraint. I know that for current SOTA LLMs we still have pretty small context windows, and for that reason it seems reasonable try to find a solution that optimizes the amount of information we can put into our contexts.
Besides that we have the problem of 'context priming'. We rarely create abstract software, what we generally create is a piece of software what interacts with the real world. Sometimes directly through a set of APIs and sometimes through a human that reads data from one system and uses it as input in another one. So, by using real world terminology we improve the odds for the LLM to do the right thing when we ask for a new feature.
And lastly there is the advantage of having a source code that can be audited when we need.
> As philosopher Peter Hershock observes, we don’t merely use technologies; we participate in them. With tools, we retain agency—we can choose when and how to use them. With technologies, the choice is subtler: they remake the conditions of choice itself. A pen extends communication without redefining it; social media transformed what we mean by privacy, friendship, even truth.
That doesn't feel right. I thought that several groups were against the popularization of writing through the times. Wasn't Socrates against writing because it would degrade your memory? Wasn't the church against the printing press because it allowed people to read in silence?
I'm not that well read on Hershock but I don't think this is a very good application of his tool-vs-tech framework. His view is that tools are localized and specific to a purpose, where technologies are social & institutional. So writing down a shopping list for yourself, the pen is a tool; using it to write a letter to a friend, the pen is one part of the letter-writing technology along with the infrastructure to deliver the letter, the cultural expectation that this is a thing you can even do, widespread literacy, etc.
Again I think this is a pretty narrow theory that Hershock gets some good mileage out of for what he's looking at but isn't a great fit for understanding this issue. The extremely naive "tools are technologies we have already accepted the changes from" has about as much explanatory power here. But also again I'm not a philosopher or a big Hershock proponent so maybe I've misread him.
That is perfectly on topic and you are identifying correctly flaw in the argument
Technology is neutral it’s always been neutral it will be neutral I quote Bertrand Russell on this almost every day:
“As long as war exists all new technology will be utilized for war”
You can abstract this away from “war” into anything that’s undesirable in society.
What people are dealing with now is the newest transformational technology that they can watch how utilizing it inside the current structural and economic regime of the world accelerates the already embedded destructive nature of structure and economic system we built.
I’m simply waiting for people to finally realize that, instead of blaming it on “AI” just like they’ve always blamed it on social media, TV, radio, electricity etc…
it’s like literally the oldest trope with respect to technology and humanity some people will always blame the technology when in fact it’s not…it’s the society that’s a problem
Society needs to look inward at how it victimizes itself through structural corrosion, not look for some outside person who is victimizing them
> Technology is neutral it’s always been neutral it will be neutral
I agree with a lot of what you say here but not this. People choose what to make easy and what to make more difficult with technology all the time. This does not make something neutral. Obviously something as simple as a hammer is more neutral but this doesn't extend to software systems.
> The change was first spotted by users on Reddit and confirmed in an updated Netflix support page (via Android Authority), which now states that the streaming service no longer supports casting from mobile devices to most TVs and TV-streaming devices. Users are instead directed to use the remote that came with their TV hardware and use its native Netflix app.
My guess is that adblock became too easy on smartphones, so by forcing people use the app on the TV it makes harder for people to bypass the ads.
That's pure speculation, as I don't have any subscription from netflix. But I've used this method with the HBO app and it works 90% of the time, so I'm assuming netflix has the same issue.
> My guess is that adblock became too easy on smartphones
Not within native apps. Your only option is essentially dns/hosts based on both platforms however this can also be done on the router. On Android there is ReVanced I guess. But these are almost as technical as a pihole. What is the percent of people who know of DNS based adblock but not pihole?
Edit: And DNS adblocking can be done on android tv.
Sure, but I've never had a 'standard router' with support dns blocking. I know you can do this with something like pfsense, but that's not that common.
You also have the option to put a piehole in your network. It is pretty easy if you have some technical knowledge but I would say that it is generally out of reach for the general population(non-tech folks).
But on android you just open the settings, search for 'private vpn' and paste an url. This is way easier to do for someone with no technical background. Even chatgpt should be able to correctly guide you through these steps.
Sounds probable to me... This is a great example of why I am by default anti-app unless there's a demonstrable benefit to the user (e.g. Offline mode or something). If the web version of Netflix goes away then I will never access it again. I will also never buy a "smart" TV. I leave the ball in Netflix's court.
> developers have gone away from Dedicated servers (which are actually cheaper, go figure)
It depends on how you calculate your cost. If you only include the physical infrastructure having a dedicated server is cheaper. But by having some dedicated server you loose a lot of flexibility. Needs more resources? Just scale up your ec2, and with a dedicated server there is a lot more work involved.
Do you want a 'production-ready' database? With AWS you can just click a few buttons and have a RDS ready to use. To roll out your own PG installation you need someone with a lot of knowledge(how to configure replication? backups? updates? ...).
So if you include salaries in the calculation the result changes a lot. And even if you already have some experts in your payroll by putting them to work in deploying a PG instance you won't be able to use them to build other things that may generate more value to you business than the premium you pay to AWS.
> You have to carefully review and audit every line that comes out of an LLM. You have to spend a lot of time forcing LLM's to prove that the code it wrote is correct. You should be nit-picking everything.
I'm not sure this statement is true most of the time. This kind of reasoning reminds me of the discussion around 'code correctness'. In my opinion there are very few instances where correctness is really important. Most of the time you just need something that works well enough.
Imagine you have a continuous numeric scale that goes from 'never works' to '100% formal proofs' to indicate the correctness of every piece of software. Pushing your code to the '100% formal proofs' side takes a lot of resources, that could be deployed on other places.
At least for us, every bug that makes it into a release that gets installed on a client computer costs us 100x - 1000x as much as a bug that gets caught earlier.
Sometimes getting the new capability around that bug to market faster is worth the tradeoff, because the revenue or market position from the capability with that bug is way more important to the business than the 1000x cost of the fix after distribution.
As long as you have some mechanism to catch the issues before it hits customers. Too many software companies are OK shoveling crap on customers because it's easy to fix it in the field. Yes, it's easy to fix in the field, after you've inconvenienced and wasted the time of thousands of customers.
I think you should consider putting this information in your site. I always read "we don't support Firefox" as "we are lazy", but that's not always the case.
reply