My boss came up to me and said a coworker using LLM tools has shipped more customer solutions in a week than basically what I've done in 3 months.
The bosses are out to force people like you to use AI. And have been for months.
Maybe not your boss yet, but it swept through my office dramatically. Maybe two or three months from limited tests to now today FORCED usage of AI (people going around the office asking constantly if there's any AI that can help today).
----------
This has a few toxic effects.
1. You are not allowed to complain about code quality issues anymore. Any complaints are met with okay, we will get the AI to fix it.
No discussion, no elaboration. No one in the office is even interested anymore. AI solves everything.
2. You are basically in a position where you are forced to use AI, whether you want it or not.
3. I expect code quality at my office to drop dramatically as fewer and fewer office mates give a shit
Reduced Ordered BDDs are likely not as succinct as an arbitrary BDD.
The famous Hidden Weight Bit problem can be more succinctly expressed in arbitrary BDDs (changing the order and revisiting nodes), but are provably EXPSPACE in ROBDDs.
-------
We study ROBDDs because they uniquely reduce to a canonical form. All functions have exactly one (!!!!) ROBDD.
BDDs in general however are really arbitrary, as arbitrary as any codebase can basically get. That makes BDDs in general to difficult to study or do math upon.
Results based on the studies of arbitrary BDDs do NOT apply to the simpler, easier to understand world of ROBDDs. And vice versa.
I can now elaborate on my comment above a bit more...
Ingo Wegener's "Branching Programs and Binary Decision Diagrams" copyright year 2000, is considered the introductory work on all BDD related matters. On the front cover are two BDDs: BOTH of these implement the hidden weighted bit function (HWB-4) introduced in the first chapter, and is basically the main example used throughout the whole book.
Please locate a copy of the front cover ASAP, before continuing with my post.
-----------
Now that you've found the book cover, look at it carefully and understand the HWB-4 function. (Just traverse it by hand, dotted lines represent "x1 == 0", while solid lines represent "x1 == 1").
Both BDDs fail to be ROBDDs: the left diagram explores the variables in this order: x1, x2, x3, x4, and then (depending on path), x1/x2/x3. That is, the variables x1/x2/x3 are explored _TWICE_ (breaking the rule for ROBDDs).
The example on the right also fails to be a ROBDD. The variable orderings are seemingly random: one branch covers x4, x1, x2, x3. The other branch is x4, x3, x1, x2. This fails the "ordered" property as the different branches cover different orderings.
BOTH are BDDs however. Both clearly implement the HWB-4 function efficiently (less than EXP-space. Indeed, its a very small graph for the front cover of a book). If these were actually ROBDDs, they'd be ridiculously large and unable to fit.
-------
ROBDDs are again, studied due to the unique property (and proof), that for any given function, there can only be one ROBDD ever generated (!!!!). For the verification problem of circuits, this is extremely useful. Different circuits might implement the same function, despite one circuit being smaller or using less power (or other useful properties).
To "prove" that the circuits output the same function, you simply create an ROBDD. Because functions ALWAYS result with the same ROBDD, you can ALWAYS use this process to prove circuit equivalence.
ROBDDs aren't succinct. No: their usefulness is the opposite. Exactly one ROBDD to ever find for any binary function that has ever existed or will ever exist.
Remember how 16GBs used to be an enterprise level database mainframe?
Well, GPUs also have stupid amounts of compute on them. I have to imagine that there is some kind of database format that's useful with GPU compute attached.
Since the data is already in VRAM, the GPU can sort, join, or otherwise manipulate data as needed.
GPU-accelerated databases have a long history. I founded HeavyAI (previously MapD/OmniSci) in 2013, but there are or have been many other startups in this space, such as Voltron Data, Kinetica, Sqream, etc. And now you have major players like IBM, Starburst, and Microsoft (which just announced Fabric SQL on GPU today) working on their own GPU-accelerated systems. GPUs have a huge advantage in terms of compute, memory, and interconnect bandwidth over CPU, as long as you can keep them fed with data.
I believe within 2-3 years databases and data warehouses on GPU will be common. The widespread use of agents to query data will be a part of this, as there will be a need to run far more queries at lower latency than needed for the ETL and BI workloads of the past.
And smart NICs are moving significant amounts of compute directly onto the network interface, though I haven't seen anyone combining a GPU and a 100GbE NIC into a single part yet.
Where does a few more steps of evolution take us? A wide path between a few heavy devices, and then the CPU off to the side just orchestrating the data flow?
You are able to use GPU Direct Storage to communicate between the GPU and PCIE storage devices. It's nice, but it's not typically as performant as one would like, in comparison to the onboard memory.
Not related - many robber barons went bankrupt in the severe economic crashes of the time, such as the Panics of 1873 and 1893. The Gilded Age continued despite bubbles popping.
I don't believe that a benevolent God would create bones in the ground to trick millions of scientists into falsely believing in the existence of dinosaurs.
Like seriously, every creationist who goes with this argument really compromises on the benevolence leg of our understanding of God. Like God is some kind of trickster being who leads atheists astray on purpose or something.
You might enjoy reading the concept of the demiurge [1]: A lesser creating-but-not-creator deity than the ultimate benevolent god, usually portrayed as something of a deceptive character. Great rabbit hole to go down.
I know it's pretty dubious if anything could be considered a true infohazard, but Gnosticism is up there in the running. I was warned, and it is indeed a hard mindset to shake regardless of low priors.
This is rsync we are talking about. A bug in rsync basically means lost data and/or unreliable backups.
I think it's normal to be pissed at lost data. Maybe it's not socially acceptable to spit in the face of a volunteer but it's 100% human to feel annoyed by an obvious drop in code quality.
There must be some degree of communication from customers to developers. Even if it is a free volunteer service.
Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary.
This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated.
Problems aren't solved by shutting up and ignoring things. And based on the discussion in this topic, it's clear there's a lot of people who are worried about rsync code quality here.
Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too strong, block people. Rsync has been maintained for a very long time. Bugs happen, even regression bugs happen. People don't get to dictate how should the volunteer do development.
If I were the rsync maintainer after this I'd unpublish it everywhere I had control over, delete the repo and turn off my computer to go walk in the park. The linked thread is insane.
Again, this is not work and they are not customers.
This is somebody spending their free time on code they enjoy and then putting the result online.
The reason businesses are careful about which customers they fire is because they want to keep having customers. Open source maintainers have no reason to deal with that shit.
And it seems like regressions that lead to rsync losing data is just as serious.
Again: we are talking about rsync here. This new methodology being used this year seems to be associated with a regression (ie: Data loss since this is rsync after all....) that likely wouldn't have happened any other year.
Or at least: the regressions at play are consisting of thousands of lines of changes that was only navigated by Claude later down in the discussion.
We are reaching the point of AI developed code that requires AI itself to analyze. One step at a time. It's right for the open source customers who are used to understanding changes and smaller patches than this.
Before you call yourself a customer of an FOSS project, perhaps show us the receipt that a monetary transaction had actually taken place between you and the developer.
Otherwise, you're just a beggar. And beggars don't get to choose.
Customers pay money for goods and services. They thus get a bunch of social, ethical, and legal positions in terms of their relationship with the seller.
Rsync is an open source project that its maintainers put onto the Internet. People who use it are not customers, and they do not have the right to expectations around how the maintainers will change the software or change how they develop it.
You've never had a customer in your professional setting who didn't pay money for goods and/or services? Yet it was very important for your boss (and therefore you, as a programmer) to service their every whim?
Customers are customers. Whether they're paying or not. Not all customers are worth servicing (even with infinite money offered, "firing a customer" is important to keep the community in check).
But this isn't a situation where the RSYNC maintainer should fire the customer. There's a LOT of backlash to this release. Even if this one particular customer is a bit of an ass, there's plenty of good users in that 90+ comment chain (hundreds now?) where this regression has clearly struck a nerve.
This is not a professional setting. This is an open source project that somebody published to the internet. Using it does not make you a customer, and it doesn’t matter if it “struck a nerve” with users.
Well in my professional setting, I deal with non-paying customers all the time. They're still customers and I'm still expected to listen to them.
It was better when a dedicated PM was shielding me from this crap but here we are. Deciding who and who not to listen to is just part of project management.
If committing thousands of lines of unreviewed AI generated code is "doing their best", I'd argue that them not contributing anymore would be a net benefit for the project.
The first comment, which is a screenshot from Mastodon, is perfectly acceptable. There is a clear regression between newer versions of rsync.
Then egos got bruised and things leave the realm of reason soon after. But coming with a request saying "Version X worked while version Y doesn't", with maybe some degree of annoyance, is fine.
This doesn’t seem related to my comment. Did you mean to reply to me upthread?
Saying ~“maybe it’s not ok to do <thing> but <reasons they might do thing>” is nothing like your example and does imply it’s acceptable to the speaker to sometimes do that thing.
But we’re past that now because the person I was discussing this with has gone ahead and clarified that telling an open source maintainer to please stop fucking up isn’t an angry comment.
Can YouTube stop shoving terrible robot-English AI dubs down my throat?
I once looked up a German language test. It was auto-AI dubbed into English. Ugggghhhhh..... There are also a lot of anime where the AI dub essentially removes the music and sound effects and leaves only a dreary AI voiceover. It's kinda crazy that Google is pushing this feature out....
It doesn't remember my preference. Or rather, it seems to remember me picking a specific language, and then loads the dub in that language next time I click a video. It doesn't remember "don't duh videos".
Not if you Airplay to your TV. I get random foreign languages when I watch English speaking YouTubers. No way to enable subtitles or change the language. It's a known bug according to the internet.
The problem is that it doesn't even respect this choice. My native language is not English and most of the videos in this languages will be auto transcript to English. Even the last time I changed both the language and country and YouTube still managed to auto transcript to English.
The solution is a simple toggle to turn it off, not pushing it to our throat.
That just tells it which languages to serve if the video has multiple tracks, including Ai-generated ones. "Keep original language" should be the default, or at least an opt-in.
And what about the atrocious title auto-translations? I'm in France, my browser is set to accept EN-us and FR-fr as languages, and my Youtube is in EN. And yet it keeps auto-translating the titles of some French videos. And the translation is so awful, it mistranslates many things and translates literally some obvious puns, that I can't believe they're using Gemini for this. They must have repurposed a 5-year old version of Google Translate. It is not consistent either, the titles are translated in the home page, but not in the channel's page.
Even worse, sometimes it dubs ads, where there's no way to switch the audio track and no way to see if it's being dubbed. This also makes it look like the dubbed audio is the original audio from the ad, which makes the advertiser look terrible.
It's an option that individual channels can disable. Granted, it's opt-out, but YouTube emailed creators several times about it well before:
> Effective today, you can turn off automatic dubbing for your entire channel in your Channel settings > Upload defaults > Advanced settings > Automatic dubbing.
> Once auto-dubbing is enabled for your channel, while uploading a new video, you will also have the option to turn off automatic dubbing for that video.
So if you're seeing auto dubbing on a video by a creator who clearly pays attention to YouTube's algorithm and should be aware of the feature, then they deliberately opted to leave the option on, probably thinking that it can't hurt.
reply