A 15 frame min anf max GOP size would do the trick, then you'd get two 15 frame GOPs. Each GOP can be concatenated with another GOP with the same properties (resolution, format, etc) as if they were independent streams. So there is actually a way to do this. This is how video splitting and joining without re encoding works, at GOP boundary.
In my case, bandwidth really mattered, so I wanted all one GOP.
Ended up making a bunch of patches o libx264 to do it, but the compute cost of all the encoding on CPU is crazy high. On the decode side (which runs on consumer devices), we just make the user decode the prefix many times.
You're right, but the way to achieve this is to allow the error to propagate at the file level, then catch it one function above and continue to the next one.
However, LLM generated code will often, at least in my experience, avoid raising any errors at all, in any case. This is undesirable, because some errors should result in a complete failure - for example, errors which are not transient or environment related but a bug. And in any case, a LLM will prefer turning these single file errors into warnings, though the way I see it, they are errors. They just don't need to abort the process, but errors nonetheless.
> And in any case, a LLM will prefer turning these single file errors into warnings, though the way I see it, they are errors.
Well, in general they are something that the caller should have opportunity to deal with.
In some cases, aborting back to the caller at the first problem is the best course of action. In some other cases, going forward and taking note of the problems is best.
In some systems, you might event want to tell the caller about failures (and successes) as they occur, instead of waiting until the end.
It's all very similar to the different options people have available when their boss sends them on an errand and something goes wrong. A good underling uses their best judgement to pick the right way to cope with problems; but computer programs don't have that, so we need to be explicit.
I believe it's because if you are easily replaceable, then screwing up means you're not worth the trouble. If you aren't easily replaceable (whether it's because you have demonstrated you're a good employee or you're working a high-demand role), you are worth the trouble and you'll get more chances. There are other reasons too, such as jurisdictions where suing after being laid off is more common, which makes more chances, PIP and severance packages more likely.
>I believe it's because if you are easily replaceable, then screwing up means you're not worth the trouble.
These ideas work great when you have a large/growing labor population, we're seeing it start to fall apart in a tight/shrinking labor population. "nobody wants to work" is the drum beat of the employers that used to burn employes.
Well, then they're not easily replaceable. Which implies those workers have other options. And thus employers that treat workers worse than other employers will see workers leave and/or find it harder or more expensive to hire. So it all works out.
Well, maybe fast-food restaurants were a low-interest-rate phenomenon or whatever the equivalent term is (a high-labour-supply phenomenon?). If that kind of business can't afford good enough working conditions to get a decent supply of labour while selling its products at a decent price, then yeah, the whole industry will burn. But if there's a demand for it then sooner or later someone will start offering it. I think that probably looks like a decoupling between middle-class-oriented (e.g. Costco or Chipotle) and working-class-oriented.
During COVID a new kind of food business sprung up called a virtual restaurant (or a ghost kitchen), where instead of having to rent a restaurant space and hire wait staff, they just had a kitchen and delivery drivers. Lower expenses, fewer staff.
Eventually, those delivery drivers will be replaced by delivery drones.
I promise I’m not that whiggish when it comes to automation, but there was a time when a good portion of human labour was washing clothing, and now that’s become much less of a thing for much of the world.
Perhaps food service and in-person retail will start to go that way too. It’s my hope we can navigate that and still make a place where it won’t be so bad.
Sometimes we do our own laundry, sometimes we pump our own gas, and sometimes we prepare our own meals. Not having a servant to do those things for us doesn’t make us destitute; it makes us human.
Why don't I cut my own hair? Because I'm shit at it.
If you went to a barber, and you sat down for a haircut, and they handed you a pair of clippers, would you go back? Fuck no!
The problem with having customers do their own checkout isn't that the fat and lazy customers have to get off their fat asses. No. It's that customers are unbelievably shit at that.
Have you noticed that, despite there being, like 10x as many self checkout lanes than before, the lines are longer than ever? Go ahead and do the math on that. Not only are people doing more work, they're paying more for it too, and it's a much worse service. Lose, lose, lose. Unless you're the corporate overlords.
You may find yourself in that situation if you have a device that only supports SIMs, and you can't use any of the cheap travel esim providers with it. For travel, you would replace your local SIM with the 9eSIM, and be able to switch providers depending on destination. The difference can be huge in some countries, where a local provider's travel plan can be 30 to 50 USD, while a equivalent on an ESIM provider is just $4.
I live in such a country and have parents with older phones who can't use esims, so the value is obvious to me. :)
In which countries are eSIMs cheaper? I have never encountered this in Africa or in Asia. I was just in Vietnam, a local SIM was probably 50% cheaper than anything I could find on esimdb.
Currently I'm in Georgia, unlimited internet for a week is 9 GEL, or around 3ish USD per week. The cheapest on esdimdb is 19 USD for unlimited internet for a week.
What we usually do when we travel is buy the cheapest eSIM, usually on some introductory offer to get like 1GB for 1 USD (so we can order taxis, maps etc), then go to a local provider and get a local SIM.
One place where an eSIM was a good choice was China. I don't quite understand how it works, but it seems if you use an eSIM in China you get around the great firewall without needing a VPN.
I wish eSIMs were cheaper, so I wouldn't have to deal with the headache of doing that. When going to local providers, sometimes they offer an eSIM option, but there is usually no price difference.
> I don't quite understand how it works, but it seems if you use an eSIM in China you get around the great firewall without needing a VPN.
That's just the default for most mobile data services, eSIM or physical SIM. Your home network provides Internet connectivity. "Local breakout" (where you get an IP of the visited network) has never really taken off for various reasons, one being that people actually like being able to access everything they also can at home.
I also strongly suspect that this is why iPhones in China don't have any eSIM capability.
I don't know if eSIMs are more expensive or less than a local SIM, but they are much more convenient for me when I travel. I can have working internet as soon as I step off the plane, which is great for finding transportation and not having to deal with kiosks that won't speak any language I know and might be closed. I don't have to hand over my passport to get a SIM, and in China they get around the firewall. The cost of an eSIM vs the cost of travel is too small to notice but the convenience is always noticed.
Currently traveling, and the savings are real. Although in this case it’s the opposite: travel eSIMs rates are about $80 for data for 30 days, whereas a cheap local prepaid SIM card is $8-16 (but with no eSIM option)
The service is called Holafly, it was advertised on the plane, and my travel mate bought it without hesitating (because of the convenience of an eSIM, even though they didn’t get a local number)
That's basically guaranteed to be overpriced. Anything prominently advertised means you're going to be paying for the advertising budget.
Also, it's "unlimited data", which probably makes it more expensive than it needs to be due to adverse selection. For instance it charges $50 for 15 days in europe, but on esimdb[1] you can easily find esims for just over $1/gb. It might still be worth it if you're using absurd amounts of data, but citing it as an example of esims being very expensive doesn't really make sense.
I don't know about europe but 40 to 80usd for 15GB for 30 days in Mexico is completely crazy when you can get a physical telcel sim card with 25GB and unlimited data for whatsapp and all major social medias, which means you can easily go for the smaller 10GB (15usd) or 7GB (10usd) choice if the most you will transfer is on social medias and whatsapp.
I found my google maps app for navigation and image translation via google lens/translator app ate up a ton of my data. I had to turn off off a setting or two to reduce the maps data.
In my experience, getting an eSIM is usually cheaper than the airport SIM card plans, but often there are cheaper plans available when you get to the city. In any case, having both options is nice!
I think it depends on how you define “developing countries”!
I’m currently in Thailand and I got 6 GB for about $2 total (50 baht for the SIM with 3 GB for 3 days, another 20 baht top up for another 3 GB / 3 days). I did use eSIM for about a month before that though (I just wanted a local number to order some stuff from Lazada).
Another example (also from Southeast Asia, FWIW): Malaysian SIMs are also cheaper, though topping them up is painful so I’d personally stick with an eSIM there.
I expected to use an eSIM when I went abroad for a month last year. It turned out the providers offering "travel eSIM" are 2 to 4 times more expensive compared to buying a prepaid physical sim at the counter valid for 30 days.
Quick note that "the counter" may not exist or be hard/time consuming to track down and then there may be language barriers and also identity proof requirements that you can't meet. So service that's available and working as soon as your boots hit the ground do have some value.
I don't recall what it was called in the menu, but it was definitely possible to assume a struct on a particular address. Muscle memory tells me the button is U, even though actual memory fails me.
The alternative is making it possible for developers to only think about code, not permissions, or at least specify the permissions in terms of what you want to do, not what permissions you need. Think iOS, you write "I need fine grained location access" into the manifest, you don't configure the permission system to allow you to call the API.
Another poster touched on another important point: it's important for this to be changeable independent of the code. The reason for this is actually kind of subtle. Obviously, you don't wanna have to need to rebuild in order to regenerate permissions. But the real reason, imo, is that it should be easy to parse for a human, easy to locate for a human, and also easy to parse and adjust for a machine, that might determine a permission is no longer necessary, or who is trying to build a dependency graph in order to determine who to wake up during an incident. That means it should go into configuration that is versioned and deployed alongside the code, but not in the code.
If you make this hard to understand and change, people will just copy it, and the you're back to square one. It's gotta be the easiest thing to do the right thing, because at scale, people are gonna do the easiest thing.
I feel like I'm kinda going on at length about this, so instead I'm gonna leave you with a link to a blog I wrote about the same concepts, if you wanna read more. It's about Kubernetes network policies, but really the same concepts apply to all kinds of access.
How you're describing iOS is similar to how nitric works. Developers indicate in code "I'm reading from this bucket", it's a request not an order, they're not actually configuring the permissions system. That request is collected into a graph of other requests (for resources, permissions, etc.) and passed via an API to a provider to fulfill.
If you want to change what "read" means you're free to do that in the provider without changing a single line of application code. But you also get the benefit on the Ops side of not needing to read the application code to try and figure out what permissions it needs to work, that part it generated so you can't miss anything.
If you want to output Terraform or config files or something else like you do today, to enable audits and keep it alongside the code, you can do that easily.
In newer versions of Android, apps which are not opened by the user have their permissions automatically and periodically revoked. So they no longer have the permissions, and when reopened, the user needs to grant the permissions again interactively. Presumably to solve this.
Thats great but their is a boat load of permissions that Android allow that never require user acceptance and are never revoked. Total disablement when not used would be much better.
Damn I guess we shouldn't do any small step to improve society somewhat unless we can overhaul systems entirely all at once!
Personally, I'd prefer to see us fight for successively smaller and smaller blast radii than simply hoping and praying the blasts disappeared entirely.
Small steps get us things like pop ups on every webpage or TSA. You'll just slowly create a bureaucratic dystopia. We need giant sweeping reform of privacy laws in the US and a restoration of the 4th amendment.
Not in the context of the government buying the data, they'll just buy it from google instead of shadowgovt.databroker.com. It's a red herring, a feel good feature that just limit's googles competition and doesn't really change the information collected on us.
Unless you're somehow claiming that your browsing history was used to train an AI for identifying tanks or terror connections, in which case for the former that makes no sense and for the latter the data is so emulsified that it can't really be considered your data any more than you could lay claim to a cat recognizer that was trained on a billion cat photos, some of which happen to be from your blog.
(And that's even assuming one accepts the premise that Google's cache of browsing data was used to train the AI that the Israeli government is using. In reality, that information is deeply firewalled and doesn't see the light of day for other applications).
You're arguing in bad faith, making this about browser history, this is about data collection of the sensor array that is your smart phone device, two very different things. It's hilarious to claim that what google is doing by disabling app access matters at all when google created the problem and profits from it in a really shady way all the while pretending to be doing you a service by protecting you from those 'shady' apps (and 3rd party app stores like say.. f-droid). And then using that data to _literally_ kill people. I'm not saying those apps aren't shady, I'm saying google pretending to protect you is shady.
Sorry; I just don't follow. Google isn't "protecting" me from F-droid; I have it on my Android right now. Nor is Google using cellphone telemetry to kill people. Nor is Google (AFAIK; if there's evidence to the contrary I'd be interested to see it) providing cellphone data to nations that are targeting them for death (Google doesn't even own a cell tower deployment). Nor is geotargeting people based on cellphone data a system limited to Google's architecture; that's a feature of cellphones, because they're little radios we carry in our pockets that continuously broadcast to a mesh network in an attempt to allow connection to it.
I don't think I'm arguing in bad faith, but I am trying to argue with someone who seems to be operating from a source of facts I don't have access to. You seem to be upset that Google makes cellphones? What am I missing here?
>Sorry; I just don't follow. Google isn't "protecting" me from F-droid
Yes, they give you a warning to scare off normal users and you have to enable installing from 3rd party sources. My point isn't that they're "protecting" you at all, my point is it's security theater.
>Nor is Google (AFAIK; if there's evidence to the contrary I'd be interested to see it) providing cellphone data to nations that are targeting them for death
Various subsystems on android are controlled by Google and they enable Google to collect and consolidate all of the telemetry/usage data etc (effectively google is root on your phone).
This information is used to select targets and kill people:
"Since 2002, and routinely since 2009, the U.S. government has carried out deliberate and premeditated killings of suspected terrorists overseas. In some cases, including that of Anwar Al-Aulaqi, the targets were placed on “kill lists” maintained by the CIA and the Pentagon. According to news accounts, the targeted killing program has expanded to include “signature strikes” in which the government does not know the identity of individuals, but targets them based on “patterns” of behavior that have never been made public. The New York Times has reported that the government counts all military-age males in a strike zone as combatants unless there is explicit intelligence posthumously proving them innocent."
You're not bringing much evidence to the table to single out Google for your frustration. Targeted tracking of individuals with cellphones is enabled by every cellphone, by virtue of the fact that it's a radio and signal strength and connection is logged and forwarded by the towers themselves; there's nothing special Google is doing to modify that process. So I don't know why we should focus on Google and not, say, T-Mobile or AT&T or TracFone or the entire cellular infrastructure.
You seem to be alleging that Google is brokering third-party access to data stored on the phone or generated by the phone (beyond the telemetry that's natural to every cellphone), but there's no evidence to support that hypothesis. Have I misunderstood what you're alleging?
Google's value in tracking is in providing services to users with the tracked data and (in the ads arm) linking advertisements to potential interested users (which is a system they broker internally).
They don't hand data to third-parties; third-parties hand data to Google, and Google might kick out answers to questions, but it does not kick out answers to questions like "Hey, is this person a terrorist?" There's no program for that. Hell, Google doesn't even kick out answers to questions like "Would Bob like to buy my shoes," the entire ad network is architected to minimize the ways an advertiser could glean the identity of a specific user who saw their ad.
The Network Mapper can export to Grafana Tempo (contributed by the community!), but doesn't have to. You can get its output as text, JSON, PNG or SVG using a CLI or an API (directly from the deployment in your cluster), and use it to auto-generate network policies.
Built while avoiding eBPF and reliance on a particular CNI with the intention to run on older nodes, with low privileges, a low performance footprint, and most importantly - zero config.
