For anyone willing to take the time and provide BBC with your personal contact and address information, you can file a "complaint" at: https://www.bbc.co.uk/contact/complaints
GPT-4o is the only model that seems to work well in the text-image joint space to this degree, even Gemini Flash 2.0 with native image support is not nearly as good so it will probably be a while for a good open source alternative to pop up (a while in the context of AI development).
I used GPT-4o for some image editing (adding or removing things) to an image of a person and they distort the look of the people after each edit but (Gemini Flash + image out) did much better.
The main problem is there is little control. For example I asked to add a helicopter to an image in a ski resort but then it seems cumbersome for me to have to write a full paragraph to describe where exactly I want this helicopter to be rather than if I could just do it by dragging things with a mouse.
The point is you are not going to be allowed to even install windows without an account to make use of the great privilege of using a walled garden app store.
And no one on this forum really needs app store when homebrew exists
But advertisers exist and will continue to exist, and have no incentive to follow this. I don't think either are at fault necessarily; I think it was a weak attempt all around.
The only thing that will get companies to comply are a/ laws (and so far all laws have done is annoy end users) b/ browsers doing more to block tracking (which is almost impossible; this will forever be a game of cat-and-mouse).
Does this change include any UX improvements? The article only mentions updated visuals and theming. From the discussions I've read, it's the UX of GIMP that holds it back.
It's just Photoshop addicts needing the UI to be identical to Photoshop because when they use GIMP their muscle memory is broken.
To be fair, though, all industry professionals are forced to be Photoshop addicts. But Photoshop's UI is objectively awful; it's the 10,000 hours you spent in it that makes it seem sane. You could have learned Thai in 10,000 hours, too.
The real weaknesses in GIMP have been in its lack of some necessary functionality, especially some that is necessary for print. The great thing about being GPL is that when the stuff is eventually added, you own it forever.
Photoshop's UX is poor, but everyone is used to it. GIMP's UX is even worse, and nobody is used to it. And based on those screenshots in the article, it has, if anything, got even weirder and less intuitive.
I'd probably try and power through if there was even close to feature parity, but it's only just now catching up with where Photoshop was in 1994.
I'd say so. Non-destructive editing means you don't have to Ctrl-Z over and over again when you want to change a filter, which is a better user experience. Same with built-in text outline features, which makes that process much easier than in GIMP 2.10. Multi-selection instead of the chain tools is another nice UX improvement.
Not to say that there isn't more work to be done, but I think there's a lot of good work done by volunteers already.
Most of the comments here echo what the article is criticising. I can see countless threads of back-and-forth defending single-entry bookkeeping.
Sure, single-entry bookkeeping might be easier and more normalized, but sometimes it is a good idea to just stick with the systems and abstractions that have been developed over centuries.
Just use double-entry bookkeeping unless you definitely need something else. Sure, it might be icky for the programmer inside you, but I think you'll be thankful if you ever need to get actual accountants involved to sort out a mismatch.
On a related note: does anybody know of any good resources for programmers in payments and adjacent fields? Something like an "Accounting for Programmers"?
I read an article from Modern Treasury that advocated for mutable pending transactions to vary entry amounts by replacing entries¹, which is just about the worst idea I ever heard in the design of a DE system, and their reasoning boiled down to: if you're running a settlement system but are too lazy to implement a clearinghouse layer separately, no worries, just violate the entire DE covenant instead. So I'd take anything they write with a pinch of salt.
Out of curiosity, how would a clearinghouse layer plug into this in practice? Thinking aloud, would you have an event stream of, say, EntryCreatedEvent, and the clearinghouse would provide streams of of EntryClearedEvent and EntryRejectedEvent - would you join those streams together to derive EffectiveEntry, EffectiveTransaction, PendingEntry, PendingTransaction based on whether all clearing is done on both sides?
I would strongly advise against additional event types because the double-entry model is already an append-only journal. At most, I’d encapsulate the creation of a transaction as a structural formality for whatever event stream/bus is in use. The clearance events produced by the clearinghouse need to be more purposeful and work at a domain level for the logic to have any chance of coherent implementation. So it’s a PaymentsCleared event, note the plural because in many systems this is a batch. This is probably followed by events for the creation of records for the aggregate settlement transfers and their subsequent approvals/lodgement/lifecycle with financial institutions/treasury systems.
The most interesting projections from such an event stream are usually just Balance and PendingBalance. I wouldn’t type entries based on status, it’s just a flag (or more likely a timestamp and reason code), and transaction is not distinguished at all, its status is nominally cleared simply when all the linked entries are cleared.
I consider that first link, Accounting for Computer Scientists, as the canonical guide for computer scientists as to wtf double entry accounting is and why it's the right way to do it.
> On a related note: does anybody know of any good resources for programmers in payments and adjacent fields? Something like an "Accounting for Programmers"?
Get a grip on the accounting basics first. I built my own bookkeeping system with double entries and realized the design and the programming was the easy part.
These and other related machines are super popular among people interested in handheld gaming. I agree that the AI label is just for hype, but GPD does make good machines.
> And if you step past something but then later realize it was important, time to start over.
How can you do this using print debugging? For every print statement I add, I can add a breakpoint. Even more importantly, I can see the stack frame and know which functions led to the current one. I can inspect any and all variables in scope, and even change their values if I want to pretend that the code before was fine and proceed further.
What I mean here is, with print debugging, the setup is usually you have a run or test case that you start, spits out a bunch of text from the prints, and is complete in a second or two. With an interactive debugger, you often end up spending a while stepping around and through things and watching how data flows or changes. Then it can be a pain if you realize something was important after you stepped past it.
Granted, there's nothing really stopping you from using an interactive debugger with frequent short executions, but using print debugging seems to encourage it and interactive debuggers kind of discourage it.
Photos and numbers seem to be stolen straight from it.