litchralee

joined 3 years ago
[–] litchralee@sh.itjust.works 2 points 9 hours ago

Corporations even before AI have sued each other, precisely on the premise that "your code looks like ours. We think you stole it" and then have a petty fight in court because their lawyers couldn't hash out a settlement.

Now with so-called AI washing, it's only going to get worse, because LLM generated code doesn't have to be 100% identical to be considered a derivative copy of the original. It all goes back to the central question: did this copy come from this original work?

The corporate IP lawyers will be making bank off of the ambiguity.

[–] litchralee@sh.itjust.works 9 points 14 hours ago* (last edited 14 hours ago) (2 children)

I've had similar trouble understanding this aspect in the past, so I'll share how it now makes sense to me, within the frameworks of existing IP law. IANAL.

Copyright law protects a specific, tangible work from duplication, meaning that if someone directly derives an unauthorized copy from an original work (eg scanning a book), then that's copyright infringement. However, copyright law does not simply look at whether a copy is identical to the original. There must be an analysis of the provenance of the copy: did the copy come from the original?

Two people can separately stand at the Grand Canyon visitor center and use their own cameras to take identical film photos from the same vantage point, such that the developed film is identical in every way. And yet, neither has violated each other's copyright, because neither photo came from the other. Person A can sell their copy to a magazine, while Person B distributes copies for free with their holiday cards. This is all A-OK.

The trouble is when somebody suspects infringement, because they see a copy that looks unusual similar to an original. If they decide to raise a copyright lawsuit, then the defense would like a way to affirmatively show that "no, our copy didn't come from your original". How do they do this?

In software, the approach would be to methods like the clean room approach. This is explicitly a method for legal reverse engineering, precisely to avoid copyright concerns. It works because while copyright protects a tangible work, it does not protect the ideas recorded by that work. So if somebody was given only the idea, and tasked with writing the software that re-implements that idea but without ever seeing the original, then the resulting work cannot possibly have been based on the original work. Rarher, it's just a take on the same idea, which is allowed to be similar, in the same way as the photo of the Grand Canyon. There is no straight line that connects the supposed copy to the original work, apart from the idea itself, which copyright does not cover.

With LLMs, there is zero assurance that any clean room approach was followed. By training directly on original, copyrighted works, there is a cloud of uncertainty about whether the LLM is regurgitating parts of the original (which would be infringement) or if it actually reduced the user's prompt into an idea, and then independently generated code which implemented that idea.

Copyright infringement poisons everything that is derived thereafter, so even the spectre of a doubt causes problems, because if GNU or whoever else builds atop questionable copyrighted software, that foundation collapse suddenly if someone brings a lawsuit to enforce their copyright. And those are pricey to defend, even if it's without merit.

The clean room method, when followed faithfully, is a way to discourage potential litigants from even filing a lawsuit, because it's clearly obvious that they would fail to prove a connection to the original work. Patents are a different story (where ideas are protected).

LLMs basically have the same problem as when an engineer quits and goes to work for a competitor. Will they have (accidentally or not) taken trade secrets with them and implemented those in the competitor's product? A well-advised company would go through great lengths to make sure that engineer isn't working directly on a competing product, to avoid a costly lawsuit. LLMs do no such mitigation.

[–] litchralee@sh.itjust.works 3 points 1 day ago* (last edited 1 day ago)

From memory, I believe it does. But that means the bisection would give the result that the merge commit is responsible for the bug. Which isn't wrong, but most workflows do not just blindly revert a whole merge, but would have to follow-up to surgically find and fix the bug in the merged-in branch.

So that would be yet another invocation of Git bisect. The hazard is believing that bisect is an fully automated bug finder, when it would just stop at the first merge commit if the bug came in from elsewhere.

The other hazard that I didn't mention is a presumption that every commit -- merge or not -- is individually buildable and testable. For good workflows, this is the case. For some... more casual workflows where broken code is pushed and then fixes thereafter, bisect will not be able to hone down to a singular commit.

[–] litchralee@sh.itjust.works 27 points 1 day ago* (last edited 1 day ago)

There are business, technical, and UI/UX reasons for having a client. The business case is that it clearly demarcates the service they're selling, because it must be installed and isn't built-in (eg Firefox VPN). The act of having the user do something means that for a brief moment, they have to concentrate on the product. Consumers have this tendency to value things higher if they were involved in its success, such as when building flat-pack furniture.

The technical side is that while a VPN is indeed just a tube that transports packets securely to the VPN servers, the fact is that there are so many ways for this to go wrong. For example, leaking DNS requests is a way to throw the confidentiality guarantee* of a VPN out the window. As can Happy Eyeballs, where the same HTTP request is sent by both Legacy IP and by IPv6; if both aren't sent through the tunnel, confidentiality is lost.

To deal with this, the client can implement mitigations, such as setting a different DNS nameserver, as well as the (IMO exceedingly inappropriate) measure of disability IPv6 outright. These are not functions which the built-in VPN client in the OS would necessarily do, although some OS network managers genuinely will do a good job. But even more important than applying mitigations is to check for leaks! The client app can run periodic tests to make sure DNS or IP packets are always going down the tunnel, such as by checking destinations that only exist through the tunnel. Failure to pass this test should throw up huge warnings that the user's confidentiality may be imperiled. This is table stakes for a retail VPN service in 2026.

Finally, UI/UX for a VPN requires that the whole thing be easy: users want to browse the web, download ... uh... Linux ISOs, and go about their life with a VPN that Just Works (tm). Most people do not want to copy a Wireguard config into the OS using a terminal. A VPN service should have broad appeal, since the ~~fear mongering~~ advertising suggests it's a product that everyone online should use.

At bottom, we can say that "retail VPNs" really do need a client app. But for technically minded folks, a Wireguard config would be enough, because the endpoints would also be configured to route solely down the tunnel. Or even use an isolated netif, in the case of Linux namespaces, which is IMO quite clever.

[–] litchralee@sh.itjust.works 7 points 1 day ago* (last edited 1 day ago) (2 children)

Another word of caution: bisection will have a rough time navigating around merge commits, because those introduce nonlinear "forks in the road" that also tend to be introducing large, possibly-breaking, non-trivial changes. But if your workflow is already avoiding merge commits except when necessary, then the drawbacks are minimized.

Yet another reason to prefer linear history in Git whenever possible, because bisect will work more predictably.

That said, if you're needing to use automatic bisection very often, this may point to a lack of a CI pipeline to validate commits automatically. After all, if a broken change is flagged before you notice, then you wouldn't need to bisect because the system has identified the faulty commit.

[–] litchralee@sh.itjust.works 6 points 2 days ago* (last edited 2 days ago) (1 children)

Would cert-manager for Kubernetes be approximately what you're looking for? In that particular case, it's a service that runs in a K8s cluster, that can auto-request CSRs and send them to Lets Encrypt using one of the challenge types. It takes care of managing the returned certificates, such as renewing them before expiration and registering the private keys within the K8s key store.

I presume that you're not already using K8s, so maybe that project will help you find the keywords to describe the sort of certificate manager that you want.

[–] litchralee@sh.itjust.works 20 points 2 days ago

If you're already using Debian on desktop, then Debian on a VPS makes sense from a maintenance perspective: you only have to track one set of security updates. When there's suddenly a critical update for some vulnerability, you can update both at once because it's the same upstream repos. Whereas with Ubuntu on your VPS, you'd have to be mindful to make sure to check back when the same vulnerability is patched there.

Do not underestimate the effort to upkeeping a server, and do try to unify your procedures so you're spending less time doing the necessary things, and more time building up your self hosting stack.

[–] litchralee@sh.itjust.works 0 points 2 days ago

I vaguely recall seeing (what I hope was) a joke where the C preprocessor allowed the use of Old English in lieu of the typical keywords. I can't seem to find it right now.

[–] litchralee@sh.itjust.works 1 points 2 days ago

Unirust has you covered: https://github.com/charyan/unirust

(to be clear, that's a joke and please don't code with that, even if it would further Rust adoption)

[–] litchralee@sh.itjust.works 2 points 3 days ago (5 children)

"more posts create more conversations" has a logical end point, where the sheer volume means more time is spent skipping over uninteresting questions than time spent on answering the interesting ones. At that point, people with answers would rather spend their time elsewhere.

Curation is moderation by another name, and it is hard at scale. The solutions that work for communities with a hundred followers will not work for communities like this one with 49,000 (!) subscribers.

[–] litchralee@sh.itjust.works 6 points 4 days ago

I've copied a portion of an older comment I wrote, answering part of the question:

One thing which isn’t immediately apparent, even to Americans themselves, is that the large American political parties are less equivalent to individual political parties elsewhere, and are closer to “uneasy coalitions”, like those found in Europe involving multiple parties trying (and maybe failing) to form a government. That makes it harder to draw broad conclusions like “USA Democrats would be right-of-center” because progressives and “DINOs” (Democrats in name only) within the party would be left-wing or right-wing, respectively. Logically, the same applies to the Republican party, although ranging from right-wing RINOs (Republicans in name only) and “moderate Republicans”, to the far-right factions of the party, like neo-Nazis and MAGA.

That's what I wrote then, and what I'll add today is that because of the enormous variety in different parts of the USA, two members of the same national political party from different parts of the country might sit down for dinner and find they have very little common group. What appeals to them about their party might be highly local.

For example, a registered Democrat in California might be fully onboard with regards to the rule of law, as applied to immigration and unlawful detention, but might be a bit apprehensive about tax reform that would eliminate middle-class subsidies (eg SALT exclusion) because that hits very hard in a HCOL state.

Meanwhile, a registered Democrat-Farmer-Labor (the state's Democratic party) in Minnesota may be fully convinced that environmental protection is important to preserve both the planet and the nation's public lands, but wouldn't necessarily support the wholesale ban of hunting because of the rich cultural value instilled from an early age.

With the exception of vanguard political parties, I'm not aware of any political parties that strictly adhere to and enforce the party platform. That is to say, membership that mandates exsct alignment to the values of the party, and failure to do so requires expulsion or resignation. This is a rarity in American politics, because parties generally want the barrier to entry to be low. The downside is that there's no party discipline whatsoever for members that aren't in government.

[–] litchralee@sh.itjust.works 2 points 4 days ago (1 children)

Is the couch in reference to just parking one's investment into a simple index fund and then laying on the couch passively? I saw the URL first and was concerned it might be about the USA vice president.

Also, out of curiosity, was an LLM used to generate this game?

 

A few months ago, I was gifted a non-operational DEC VT320 serial terminal. This is a 80s/90s text-only CRT monitor, which was only displaying a thin vertical line rather than a proper picture. I've done some electronics repair in the past, but nothing this old or involving a high-voltage tube. But I figure that it would make for an interesting project over the summer, whether or not I can recover it. If nothing else, it is quite a retro talking piece.

Fortunately, DEC -- aka Digital Equipment Corporation-- made a lot of these things, and also published troves of service information, which was the norm back then (#RightToRepair). Among the documents that can be found online included the schematics, which would be of incredible aid. That said, the quality of the scan is pretty poor, and it took quite a bit of cross-referencing of component identifiers with the parts list to confirm what couldn't be read.

Before opening up the monitor, I did some preparatory research, to identify areas which would be worthwhile to investigate, and also to make sure I'm not going to shock myself in the process. My findings showed that because the CRT was able to display something beyond a single dot in the center of the screen, the issue would not be in the high-voltage generation circuitry, but rather the downstream circuits. Specifically, in the horizontal deflector path; this explains why the only image is a vertical line, because horizontal control was lost.

Using the field replacement guide, I got the monitor open and then discharged the anode using a screwdriver attached to the ground strap. There was no spark or sound, which can happen if the bleeder resistor was still intact. A good sign as to what's probably still working in this monitor, but I take no unnecessary risks around potentially high voltage.

The innards were reasonably laid out, basically existing as components that adorn the CRT display itself. The PSU, main board, and "arc protection" board were all easy to identify, although the latter was more like a connector than a board. I quickly ruled out the PSU by checking its output voltages, so the issue must be on the main board.

logic board of VT320 from above, unobstructed by the picture tube

It took a while to extract the board, since I didn't want to break any of the 40-year old plastic clips. But once out, I began matching the board to the diagrams and examining for any obvious damage. No obviously blown caps, no evidence of thermal events, no components rolling around on the bottom.

At this point, I stopped to do some very thorough circuit analysis of the circuit diagrams, to absolutely understand what I was going to do. This actually took two tries, since each attempt revealed faults in my understanding, and I had to go back to the thinking chair. This part took a few days, until I finally internalized the circuit's behavior. As it turns out, this wasn't necessary, and I'll probably include it as a later comment, just for posterity.

When I returned to the board, I made a plan to solder some trace wires, to verify my expectations when powered on. And indeed, after reinstalling the board, my oscilloscope confirmed that the H sync signal was intact and the power transistor was functioning as expected.

oscilloscope traces, one showing a square wave pulse for 35 ms with amplitude of 4 volts, and another trace showing a single distorted sine pulse lasting 10 ms with peak amplitude of 200 volts

Narrowing the search, I took the board back out and started tracing the lines on the PCB surface -- it was fortunately only a two-sided board -- and then compared my observations to the schematics. This revealed a difference, where the Horizontal Linearity inductor (H-LIN) was not showing connectivity, despite visibly being attached to the trace.

Closer examination revealed that of the inductor's three legs -- two for electrical connections, one extra for support -- one had developed a hairline fault. This physical damage broke continuity, likely from the shock of impacting something. I made a repair by constructing a wooden splint for physical support, and then soldered over the leg for electrical connectivity.

a tall inductor supported by wood splints, marked as H-LIN

For good measure, I completed the exercise of verifying all other components, which showed that all other resistors, capacitors, and connectors were intact and likely working. And with that, I reassembled and powered on the monitor to see.

monitor displaying: VT320 OK, Firmware and Set-Up Screens Copyright  C 1997, Digital Equipment Corporation

And it works! In total, I probably spent a week on-and-off working on this. I will say that this is a strange machine to have, since I've been able to hook it up to a modern Linux machine and use it as a serial TTY. I even wrote most of the text of this post in vim.

a VT320 terminal with vim open

 

The convention in the USA for old urban centers and new suburban sprawl is to construct a street or road with a crown that drains rainwater to gutters along both sides of the road, then have storm drains to convey the water from the gutter to some nearby creek or tributary. But why?

Wouldn't it be easier to construct the road in a roughly canal shape, so that rainwater drains towards a single V-shaped gutter at the road's center? This would cut the number of storm drains by roughly half, prevent leaves from falling directly into a drain and clogging it, make it possible to clear a drain by driving a streetsweeper over it, and also prevent a clog from flooding adjacent properties, since the road itself can temporarily impound more water until municipal authorities can clear the blockage (whereas side gutters would invariably flood the sidewalk and carry sharp debris that would damage tires entering a driveway).

Furthermore, a center drain can be built once and then retained as-is each time a suburban arterial needs expanding -- "just one more lane, bro" -- whereas side gutters are regularly demolished and rebuilt to accommodate additional lanes. By routing water away from the edges of the road, sidewalks avoid freeze/thaw cycles, and the road surfacing can be continuous from the curb: no more bike lanes in the gutter. As a convenient benefit, the "drop" off at a curb-cut from a driveway to street level would cease to exist.

And where required to improve water quality due to runoff pollution, a center drain can be excavated and rebuilt as a linear stormwater retention pond, where moderate stormwater can filter into the local soil slowly, with a predefined overflow level that will drain to the existing stormdrain pipes. This is already done for both surface parking lots as well as Interstate highways, so it's not an unproven design.

Narrow alleyways in older cities do use a central drain, so I can't see why the idea stops making sense for larger streets and roads. The only drawbacks I can envision are aesthetic -- a neighbor's excessive lawn irrigation would draw a wet line across half the street -- and that the center channel would also carry leaves and wayward soccer balls into the middle.

But even still, that doesn't seem worse than the status quo: gutters attract all sorts of detritus, but it's usually hidden beneath the wheels of parked cars until something punctures a tire. And at least in water-starved California, irrigation runoff deserves to be noticed and called out so that it gets fixed. There may even be some small road safety benefit from having a V-shape channel in the center, since it would unmistakably divide opposite sides of the street.

For larger arterial roads that have trees in the center, this seems like free irrigation and water pollution control. It even works when the center traffic lanes are converted for running a tram or light rail train.

What am I missing here?

 

cross-posted from: https://sh.itjust.works/post/61250326

A crafted MeshCore node name could compromise any Home Assistant instance running meshcore-card as soon as someone viewed a dashboard with that card.

The same XSS (cross-site scripting) pattern appears to be present in MeshCore-Home-Assistant-Panel-v2 and its HACS variant

To be abundantly clear, and the post goes into detail why, this is not a bug in MeshCore but rather in how web dashboards are not properly sanitizing untrusted input. In this case, the untrusted input is via a field that any malicious MeshCore node could send.

Well worth a read and a follow on their Mastodon.

 

A crafted MeshCore node name could compromise any Home Assistant instance running meshcore-card as soon as someone viewed a dashboard with that card.

The same XSS (cross-site scripting) pattern appears to be present in MeshCore-Home-Assistant-Panel-v2 and its HACS variant

To be abundantly clear, and the post goes into detail why, this is not a bug in MeshCore but rather in how web dashboards are not properly sanitizing untrusted input. In this case, the untrusted input is via a field that any malicious MeshCore node could send.

Well worth a read and a follow on their Mastodon.

 

A reasonable overview of the MeshCore architecture and tunable parameters.

Probably the only part I don't agree with is the idea that the companion/repeater dichotomy is an inherent part of the MeshCore architecture. I don't believe it is, although it's certainly part of the practical implementation. That is to say, if someone wants to use MeshCore purely as a private point-to-point link, then they can jettison the motions of companions and repeaters entirely. As a person to person mesh network, though, companions and repeaters are essential. The distinction I'm trying to draw is that MeshCore can be a lot more than text messages sent amongst friends.

While reading, the explainer for the three-tier t delay seemed especially analogous to me to how circuit breakers are arranged: a nearby power strip might have a fast-tripping 15 amp thermomagnetic breaker, the upstream main panel might be using a 20 amp curve B (moderate trip rate) thermomagneric breaker, and the utility might be using a magnetic 400 amp breaker. By their nature, thermomagneric breakers will handle localized faults that are 3-5x the rating, while the utility's magnetic breaker will trip precisely at 400.1 amps, to protect line-side equipment. Whereas if the utility breaker tripped first, it would unnecessarily black out a whole neighborhood.

Also observe that MeshCore's "flood-then-direct" behavior is identical to that of Ethernet (ie unknown unicast, then unicast), except that Ethernet frames do not get appended with the network path as they progress, which is akin to the postal service where letters arrive at their destination but with no indication of the routing. Accordingly, the MeshCore sender necessarily reserves space to store the mesh route, choosing a tradeoff between node-count (up to 64) or granularity (up to 3 bytes per repeater). This seems complex, but just like with the tax code, complexity is necessary to handle every reasonable scenario.

I will also reiterate the ongoing bug in MeshCore's encryption, which is the use of AES-ECB in the year 2026. Although it's AES-256, ECB has been a known encryption vulnerability for decades and should not have been used in the MeshCore spec. Meshtastic appears to have avoided this particular foible.

Note: the author's blog mentions in the About page that some AI is used to assist in his writing.

 

Background: I spent 40 minutes typing up a reply to a different post, but decided that it ran on for too long. I'll include it at the bottom, but I'm curious to know how much cash is still used in this country.

Certainly, a like-for-like Giro (Europe) system doesn't exist in the USA, with ACH, checks, and Zelle almost filling the void -- albeit incompletely -- which I suspect is responsible for the remaining cash utilization. But is that right? Is cash only used for when there isn't another option? Or is it a matter of consumer preference?

I can understand tipping in cash, or paying for a Craigslist purchase in cash. But maybe I'm missing another dimension? Do some folks pay rent in cash? Or taxes? I'm genuinely curious, but please make sure not to dox your finances in the comments.


My original comment

It's annoying when they get suspicious of a 25k USD withdrawal for instance (even if you managed to prove the purpose of such a withdrawal, it remains at the banks discretion whether they'll approve the transaction).

Let's break this down into multiple points:

  1. Suspiciousness of a 25k USD cash withdrawal
  2. Suspiciousness of a $25k USD electronic or check withdrawal
  3. Necessity to "prove the purpose" of any withdrawal
  4. Bank discretion and considerations regarding withdrawals
  5. Necessity of approval by the bank

I don't believe any of these five points are actually issues. As background, cash withdrawals within the USA are still very commonplace, as the country is fairly rather cash-centric when it comes to businesses, due in part to the lack of a system like Giro (Europe) that has both low, fixed transfer costs and can be sent or received by third-parties. The Federal Reserve's ACH system requires established relationships between accounts, whereas Giro does not. Debit card systems aren't a replacement for Giro either. Zelle (USA) is closer, but still isn't quite as full-fledged. Hence, businesses often deal in cash, pay employees in cash, and consumers pay other individuals in cash (eg buying an automobile).

To that end, for point 1, $25k as a cash withdrawal is not a daily occurrence but it does happen. I can't really think of ever paying for a private party used car by check, and such a cash-heavy transaction is often performed at the buyer's bank, so the seller is assured that the cash is good. In this setting, requesting to withdraw $25k cash is ordinary and mundane, if done very rarely. I doubt even prolific car buyers have this problem, but would be open to hearing evidence otherwise.

For point 2, electronic and check withdrawals have even less suspicion than cash, because they always leave traceable evidence. Money laundering concerns are reduced because the entire money trail can be reestablished later, whereas as cash can easily disappear or be "forgotten". To that end, the suspicion isn't about the cash amount but the source and destination. Even a $1 million check is not suspicious, if it's coming from a law firm's client account to a client's personal bank account. That is, again, a thing that happens fairly regularly. More down to earth, people can and do pay housing deposits by check, and property taxes are often drawn electronically. When one or both accounts to a transaction is prominent and established, there is a low probability of money laundering.

Point 3 is often though to be an issue, due to confusion about regulations for bank clerks on when to file a Suspicious Activity Report (SAR). Bank tellers are required to follow Federal Reserve regulations that aim to prevent abuse of the American financial system for money laundering. An SAR must be filled in whenever the teller: a) thinks money may be laundered, or b) the transaction is above the bank's or regulation's fixed amounts. The latter is often pegged at $10k, so this is where people think that it's disallowed to withdraw over $10k. This is not correct.

An SAR is something the teller fills in, and to do that, they might ask the customer some questions about the transaction. For the grand majority of people, the purpose is quite simple: cash purchase of a car, housing down payment, loan for a friend. Would the teller know if the customer is lying? Nope, not at all. But the SAR forms part of a trail of records, so that money laundering investigators can trace funds in the future. But note that the clerk can fill in an SAR for any type of transaction, including checks, and don't strictly need the customer's truthful answers (or any answers) anyway. An obligation to fill in an SAR does not prevent the transaction from going through. It's a speed bump, not a stop sign.

As for the actual stop signs, that's what point 4 covers. A bank obviously cannot allow a withdrawal if it would exceed the customer's balance, or if they don't physically have enough cash, or if the withdrawal is not authorized (ie not named on the account, or PIN not known), full stop. But other situations may arise where the withdrawal must be delayed, either for the bank's own convenience or because the account agreement specifically requires certain holdings times.

I quickly perused a random account agreement for Wells Fargo and the Available of Funds section describes that new accounts (less than 30 days old) will have elongated hold times for withdrawal against newly-deposited funds. This is applied in a first-in-first-out fashion, so only fully-draining the account would incur the longer hold time. In other cases, the bank may take more time but is required to inform you of that, and provide a definite date for when the withdrawal will clear. This verbiage does not distinguish cash vs non-cash, so they're within their rights to delay a check, as long as they obey their own agreement. If this is not tolerable, find a different bank.

Finally, this also gives us some insight into the default behavior for banks subject to Federal Reserve regulations, which is point 5. A bank may not deny a withdrawal of unencumbered, unheld funds (cash or otherwise), except when the bank has actual knowledge that the withdrawal definitely is for laundering. It is, after all, not their money: it belongs to the customer and they are just the regulated custodian of it. A bank can certainly advise a customer not to fall for a pig-butcherint scam, but they cannot block the customer from obtaining their own money back out. They can, as described earlier, apply a temporary, finite-time hold on the funds, but that's it.

To my knowledge, there is no Fed-regulated, FDIC/NCUA bank or credit union that requires pre-authorized approval to access a customer's own funds. I am open to hearing evidence to the contrary, but I don't believe such a thing exists. How would they even stay in business? To be clear from point 4, a bank can certainly ask for a few day's notice to prepare $50k in new $2 bills. But that's easy enough: just call the bank and verbally request the withdrawal, then collect it in-person days later.

Who is disadvantaged by this? Mostly money launderers and con artists trying to abscond with their scam proceeds. But I'd be remiss if I didn't also mention rich people that prefer to suddenly go on vacation and pay for everything in cash. But the system is designed to be no obstruction to those that plan ahead, or are dealing in such small amounts that it's not a big issue. Normal everyday people all share the costs of money laundering, so it's not fair to disadvantage them just so rich people and scammers aren't inconvenienced by their inability to plan ahead. They don't even have to plan ahead: just keep a few racks in the safe.

It is to me, frankly, a non-issue to withdraw money for me or anyone in the working or middle class, because the very issue of being "flagged by US banks" just rarely even a speed bump. And the rich folks have private banks that will gladly give them inordinate amounts of cash to spend.

What exactly is the problem here, specifically?

 

What can be done

The most glaring problem with MeshCore is that the maintainers do not openly communicate vulnerabilities. Users are left without knowledge of any problems, unable to judge whether to trust MeshCore with their private communication.

 

Here is the thing about open source, Andy: it isn't yours to fence. You don't get to ride a community's goodwill into a USPTO filing and a paywall. You don't get to turn "we built this together" into "I own this, pay me." That isn't a pivot. That's a rug pull dressed up as a business model.

And here is the thing about the "license check" you shipped: it is a 32-bit djb2 hash of the device's Android ID, XORed with the four ASCII bytes MCPP, hex-encoded. That's it. Thirty-two bits. Less entropy than a decent ZIP password. A first-year CS student could break it. You used Claude to generate the code. We used Claude to read the code. It took 19 minutes. The receipts are one click away.

 

CLAUDE CODE JUST RICKROLLED ME. I'm working on a project where part of it will involve videos, and in building out the project it created a dummy page, with made up content (relevant to me!) with two video links pretending to be something else and BOTH WERE RICKROLLs.

Note: I'm using a broad definition of "programmer" to include HTML generation, and a broad definition of "humor" that includes Rickrolling. Together, I think this is appropriate for c/programmerhumor. Mods, please remove if not correct.

 

The money quote:

VTA buses and light rail carried 30,000 people to and from Levi's Stadium, according to the agency. That was 5,000 more than they anticipated and "far surpassing" ridership records set when Taylor Swift played there in 2023.

 

As background from the Wikipedia page, the Anaheim Transit Network (ATN) was established as a city-sponsored non-profit in 1998 to operate bus lines around the Disneyland resort in California, with private funding from the various hotels in the area to run this public bus system. These hotels are obliged to operate or pay for shuttles to Disneyland as part of their development agreements with the city, presumably to avoid untold amounts of automobile traffic.

As the linked press release says, ATN will shutter its operations on 31 March 2026. The area will still be served by Orange County Transportation Authority (OCTA), the county-wide bus service, but looking at the bus lines near Disneyland, coverage seems non-optimal as a replacement to ATN's service.

Other reporting indicates that the City of Anaheim was unwilling to invest further into ATN (despite earlier indications), nor were the hotel operators.

What I find utterly inexplicable is that these stakeholders -- especially the city -- are not recognizing this fact: data from Q3 2025 shows that ATN fixed-buses moved 96,300 average daily riders. From the same document, the USA's heavy rail systems did not exceed that rate, except in the San Francisco, Washington DC, Atlanta, Chicago, Boston, and NY/NJ areas. Basically, ATN was moving metro rail levels of people on buses.

I shudder to imagine how bad this will be for Anaheim once the closure occurs, where workers, visitors, and all other former riders will need to figure out how to move around Anaheim. Ride share automobiles hardly have enough capacity to absorb even a fraction of the prior riders, let alone more automobiles, even if they all carpooled. And seeing as many visitors to Disneyland use the buses to stay at farther hotels to reduce costs, this is a negative attraction. The difficulty of car-seats on ride share made the buses particularly attractive to transport younger children safely.

Each individual hotel operator made an economic choice to not properly fund ATN, but together they will all lose out. Likewise, I don't see how the City of Anaheim is going to make up the transportation capacity around the Disneyland area. Disneyland itself isn't party to the agreement that funds ATN, but they do contract with ATN to shuttle visitors from a far-flung parking lot. But they too will be impacted if staff and guests can't afford to get to the park.

Everyone is going to be worse off, and no one is stepping up to the plate to keep the buses rolling, when it's clearly the obvious thing to do.

 

I won't spoil the walkthrough of the appalling source code. But it does end like this:

If you’re using X_wallet, you need to move your assets Right. Fucking. Now. to a wallet that isn’t a steaming pile of dogshit.

As always, there's an XKCD to succinctly describe the situation: https://xkcd.com/221

view more: next ›