litchralee

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

What are these "built in listeners" that you speak of, and which OS's can I find this on?

Also TCP will work before UDP. For whatever reason firewalls and such do weird things with UDP traffic.

This doesn't really explain why troubleshooting is more difficult, but rather that firewalls often cause trouble for UDP. My question was "why would diagnosing a UDP problem be harder than anything else?", not "why is UDP more problematic?". I'm fully aware that some firewalls are configured with absurd parameters, like blocking ICMP, QUIC, or even TLS in some bizarre situations. But my tools for debugging network troubles have always been the same: tcpdump for passive tracing, nc to coerce an active response, and icmp/icmp6 ping for basic connectivity and MTU verification.

Whether it's UDP or anything other protocol, those tools have proven sufficient for me. Do you use something else?

[–] litchralee@sh.itjust.works 31 points 4 days ago* (last edited 4 days ago)

I'll add some color to this post.

The original FTP is, frankly, a monster of a protocol. Very useful, but an anomalous protocol that even without NAT breaking the end-to-end principle, it is unlikely to have survived modern corporate firewall rulesets in any case. The fact that FTP was even ported for TCP is its own historical quirk.

BTW, that is the term which this post is missing: the end-to-end principle is the design philosophy that the network itself should not have to perform work on payloads transmitted, except to carry it towards the destination. This also implies that no fields or bits should be modified in transit, once it leaves the sender; encap/decap restores the fields so that the receiver is none the wiser.

NAT breaks end-to-end in two respects: corruption of the original sender, and corruption of L4 port numbers. Note that Legacy IP also violated end-to-end, when packets are fragmented due to MTU issues. With IPv6, fragmentation by the network is disallowed outright, and the technical case for NAT is non-existent.

There's something to be said about adopters of NAT, that they were facing a Hobson's choice: use NAT so that they could connect early dial-up users to the emerging Internet, or reinvent the 20 year experiment of the Internet so that it could scale properly. In 1995, IPv6 did not exist so they made the only real choice available.

In the year 2026 though, that argument doesn't hold water: it is a choice to continue to ignore the dual-stack and IPv6-only internet. There's a quote that all sufficiently complex technical problems are in-fact political, and this is that: the modern case for Legacy IP and NAT is rooted in inertia, resource scarcity (eg hyperscale cloud companies buying up IP subnets), and recalcitrance by professionals that abdicate their responsibility to their clients to pursue the available technology.

There is no colorable technical rationale for why IPv6 best practices cannot be adopted today for most organizations, when all network hardware, all major consumer and enterprise OS's, and all mobile phones support v6. Note that I said "best practices", because a minority of orgs such as certain American ISPs have undertaken truly bonkers decisions that are putting us on track for the very same sins as Legacy IP.

The fact that some ISPs assign nothing but a single /128 via DHCP6 is absurd: this malpractice perpetuates the same problem as NAT44, except that there's no good excuse for it. Even the most delusional of ISPs will never run out of /128 addresses in their assigned /32. Per best practice, even handing out /48's to customers is not a problem either, because that's 65536 customers and if that's really a problem, just ask the RIR for another /32, which they can do as RIR dues-paying members. There is no practical limit, except that some people just cannot math properly to see that there's no practical limit. When a technical solution to a technical problem fails because of innumeracy by those tasked with implementing it, then that's so much worse than any 1990s workaround.

I've harped a lot about IPv6 because its strength today is that it's technically competent, future-proofed, and most importantly, practitioners that saw the first travesty of NAT will not allow a redux to play out with IPv6. The technical reasons to deploy NAT66 are non-existent: it is always a workaround for political issues.

I can (just barely) accept NPTv6 as a like subnet-for-subnet mapping that does not harm L4, but that's still glossing over a political issue. IPv6 gave network engineers real choices in numbers and administering their networks, and while some will squander it, I will be encouraging people to not let that happen.

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

Why would UDP be any more difficult than TCP (or anything else) for troubleshooting? If nothing else, it should be easier because there are no stateful connections and every packet is "fire and forget". Now, as a tunneling technology, WG might be more difficult than a simple client/server socket-driven application, but that just means some routing tables need to be inspected and you have to understand IP subnets. In any case, you'd still want to obtain packet traces from both ends of the WG tunnel.

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

The thing is, if you don't wish to port-forward on Legacy IP nor open firewall ports for IPv6, then the only other option is to reach out to some sort of relay server. But whether your own VPS fulfils that role or you use Tailscale's DERP/TURN relays, the same class of latency and bandwidth issues will still erupt. So you'd still have to debug them, although you presumably would have better visibility into diagnosing issues with your VPS relay.

Generally speaking, if Tailscale isn't working for you, then all other solutions will increase in complexity, not decrease.

Answering the ultimate question, I operate and secure my SSH server, with port 22 open only for IPv6 inbound. There's no NAT, so I don't have to deal with debugging odd port mangling. The SSH server only allows key auth, and all password attempts are logged and blocked, because there can't be any legitimate traffic like that. On this SSH server would be my mounts for backups.

[–] litchralee@sh.itjust.works 4 points 1 week ago* (last edited 1 week ago) (1 children)

The case "eBay Domestic Holdings, Inc. v. Craig Newmark, et al." in Delaware's Court of Chancery does not support the assertion at all. What the two corporate officers did wrong was to dilute a minority stakeholder's shares for an impermissible reason under Delaware law. One permissible reason to justify such dilution would be if the change was "reasonable to promote shareholder value" (page 49). The two officers could not prove that their actions were reasonable, nor could they prove any other permissible reason, so they lost the case.

At bottom, the major question in that case was whether the corporate officers can conspire with the majority stakeholders to harm a minority stakeholder. It was about two corporate officers that were acting out of self preservation (page 59):

Jim and Craig simply disliked the possibility that he Grim Reaper someday will catch up with them and that a company like eBay might, in the future, purchase a controlling interest in craigslist.

The minor question (whether shareholder value would be promoted) could have been answered in the affirmative and those two would still have lost the case, because Delaware law also doesn't allow harming a stakeholder, violating their fiduciary duty to eBay in this case (page 61):

If Jim and Craig were the only stockholders affected by their decisions, then there would be no one to object. eBay, however, holds a significant stake in craigslist, and Jim and Craig’s actions affect others besides themselves.

The court only looked at the minor question to appeal-proof the ruling, because the two corporate officers had tried to match their argument to an earlier DE Supreme Court ruling.

For the purposes of my point in this discussion, the distinction doesn't matter.

I disagree. Drawing the correct conclusion from the wrong cause is pure sophistry (ie "arbitrary, inauthentic, or deceptive styles of reasoning" -Wikipedia). It is intellectually dishonest to state a conclusion but then decline to support your basis, dismiss your own basis as irrelevant, and then circularly assert that the conclusion stands on its own.

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

I can agree that corporations are immoral, but no one has ever offered a citation for "legally required to maximize profit". Many corporations have failed in spectacular fashion and yet where are the lawsuits or criminal prosecutions for leaders that fail this supposed obligation?

What does exist is the fiduciary duty to be frank with shareholders, and many corporate officers have been sued for lying by omission. I believe that a corporate officer can choose to prioritize something else besides profit/value, so long as they inform the shareholders. In turn, the shareholders can fire the officer and replace them.

It's no surprise that most officers won't stick out their neck for non-financial causes, but let's be honest if it's simply self preservation rather than some oft-cited but wrong assertion of the law.

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

IIRC, the USA Social Security Administration's website operates somewhat like this, because they seem to still do batch processing (a la mainframes) during the evening hours. As a result, they prevent people from logging in so that they don't get interstitial data about their public pension.

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

Torvalds was careful to frame this as a correction of language rather than a rejection of the technology itself.

You "paraphrased" into oblivion the very thing Mr. Torvalds was trying to be careful about, contorting it into click bait rather than the nuance that he and the article are trying to get across.

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

Agreed. This post's current title does not appear in the link, and the link does not contain a quote that can be remotely matched to this post's title.

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

The CS job market is very location specific, so I don't have much advice in that regard.

I've got quite a bit of experience with Linux and I manage a home server, but that probably doesn't differentiate me much.

That said, I have been on my company's rotating interview panel for about a decade now, and while my company's line of work involves a lot of Linux development, I can say that most of our college hires do not possess very much Linux background at all. Sure, they might have used Linux machines for school projects, but rarely do any of them assert to be "experienced" with Linux.

By that, I mean deeper knowledge than just using Bash. If a candidate can tell me why they prefer csh over Bash, or any syntax difference between POSIX sh compared to Bash, that is definitely a distinguishing quality. It speaks of an operator who has enough usage under their belt that they're annoyed by the typical distro's defaults, and more importantly, assessed the available tools, and picked the right tool that works for them.

I cannot understate how valuable it is to us to find a candidate that understands their tooling, especially right out of college. Considering that we assume most new hires have to be brought up to speed over the first few months, a candidate that saves us that effort is at least one rank above their peers.

Deeper functional knowledge comes in other forms as well. It's one thing to know how a C program's main() function is invoked by an OS, but anything which shows a fuller understanding of, say, system architecture and how a timer interrupt leads to a context switch in an assembly ISR, to a returned service call to load an ELF, to a CPU privilege ring change, to crt0, to main(), that is another level entirely.

I've interviewed candidates that had side projects involving retro game disassembly. So maybe they couldn't give me the above level of detail for x86, they could describe the same for MIPS. And that's good enough, because most architectures do roughly the same thing, with a few different semantics and names.

Circling back to managing a server, if you had to deal with PAM, NAT and port forwarding, tunnels and VPNs, compiling from source, or abything like that which is non-trivial, do not sell yourself short. All that stuff is resume material, because if you can relay to an interviewer that you've dealt with real network or machine security tasks, it is distinguishing.

The best part is that you have all of college to learn the CS curriculum, but it's also time that you have to pursue any particular focus that excites you. I've written earlier about how embedded engineers don't really get caught in the hype cycle, so jobs don't suddenly appear then disappear a few years later. If you wanted to do that route, getting started with any microcontroller (eg Arduino, STM32) would help, with a goal to understand all the "magic" that the IDE and compiler are doing. Maybe instead you like das blinkenlights and find yourself drawn to hardware design. It wouldn't be too late to consider a switch to the Computer Engineer (CE) major, so you have a small taste of the EE life.

CS as a field is so large that there are many routes between "I want to work with computers" to a declared major and to a career thereafter. Fortunately, time is on your side; this would be a very different conversation if you were a 4th year college student.

[–] litchralee@sh.itjust.works 1 points 3 weeks ago

Humans that successfully visit would be honored as a Discman.

[–] litchralee@sh.itjust.works 10 points 3 weeks ago* (last edited 3 weeks ago) (3 children)

IIRC, the IAU's definition of planet -- infamously applied so that Pluto fell off the list of Solar System planets -- requires that a candidate planet be large enough that its own gravity is strong enough to force it into a rough sphere, whatever it might be made of.

So a disc-shaped planet could not ever meet this criteria, because if it were made of something strong enough to remain a disk, then it's too small to be a planet. And if it did exceed the critical size for gravity to make a sphere, then it wouldn't be disc shaped anymore.

But setting that definitional quibble aside, we will focus on sizes and materials that allow a disk shape object to exist and be large enough for humans (or Mario) to visit. So no Wensleydale cheese. If we say that this object is mostly uniform in its mass distribution, then it would have to be the case that for any disc shape (including cylindrical), different points along the surface will be farther or closer to the center of gravity. Thus, inhabitants would experience gravity differently depending on where they are.

Note that we haven't even considered whether the disc is rotating. If it is, then there's a chance that the centrifugal acceleration at some points will completely negate the gravitational acceleration. At such points, one could hop up and off the surface, linger for a bit, and then get pulled back down once the disc has rotated to a position where there's a net force upon you again. Or if the centrifugal acceleration is too strong, it might repel visitors on the surface altogether.

Alternatively, there would be a danger of playing on a trampoline that accidentally crosses into a net-zero gravity region. Here, a double bounce could send someone very high up, only to then plummet back down to their death when re-entering a downward gravity zone.

I have almost no citations for the above, but I thank you for posing an interesting question.

 

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.

 

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.

 

When I moved into my home many years ago, there was this lock-box mounted to the water main on the side of the house. I figured it was one of those used by real-estate agents to store the house key for viewings, but months passed and it still remained there. No one from my buyer's agent's office had a clue what this was, and the seller of the house had already moved out-of-state.

Recently, I had some plumbing work done, and that also included replacing the main water valve for the house, allowing this lock box to come free from the plumbing. Now inspecting it up close, and looking up the model online, I realized that it has an alphabet wheel and uses a three-letter combination.

As it happens, Thanksgiving weekend was upon me, and since I was bored, I figured I'd try all the possible combinations. Just 17,576 possible combinations, how bad could it be?

The most immediate problem was that due to being out in the elements, the dial did not turn easily. It would move, but was rather rough. And since the knob is only ~1 cm diameter, this is an incredibly un-ergonomic endeavor. I had to stop after the first 100 tries, due to the finger exhaustion.

Knowing this would be untenable for the long-run, I decided to build my way out of this problem. Since a combo lock involves making rotations that almost go all the way around, I drew inspiration from rotary telephone dials, where one's finger starts with the intended number and then swivels the dial around.

But whereas a rotary telephone dial only needs 10 positions, I needed to fit 26 positions, one for each letter. I decided on each hole being 17 mm to comfortably fit any of my fingers, but that also dictated the overall diameter of the wheel. But that's good, since a larger diameter wheel means more leverage to overcome the rough lock movement. It also happens to be that this wheel has a diameter of 180 mm, which is just enough to fit in the 200 mm bed of my 3d printer.

Using FreeCAD, I designed this wheel so that it fits around the splines of the lockbox dial, which held remarkably well. I had thought I would need Blu Tack or something to keep it together.

CAD design for lockbox dial wheel

Using this wheel, I'm able to "dial" combinations much quicker using one hand, while holding the lockbox with my other hand to press the lever down to test the combination. This should be good.

(note: some parts of this story were altered to not give away identifying details)

1
submitted 2 years ago* (last edited 2 years ago) by litchralee@sh.itjust.works to c/newpipe@lemmy.ml
 

(fairly recent NewPipe user; ver 0.27.6)

Is there a way to hide particular live streams from showing up on the "What's New" tab? I found the option in Settings->Content->Fetch Channel Tabs which will prevent all live streams from showing in the tab. But I'm looking for an option to selective hide only certain live streams from the tab.

Some of my YouTube channels have 24/7 live streams (eg Arising Empire), which will always show at the top of the page. But I don't want to hide all live streams from all channels, since I do want to see if new live streams appear, usually ones that aren't 24/7.

Ideally, there'd be an option to long-press on a live stream in the tab, one which says "Hide From Feed", which would then prevent that particular stream ID from appearing in the feed for subsequent fetches.

From an implementation perspective, I imagine there would be some UI complexity in how to un-hide a stream, and to list out all hidden streams. If this isn't possible yet, I can try to draft a feature proposal later.

 

I'm trying to remind myself of a sort-of back-to-back chaise longue or sofa, probably from a scene on American TV or film -- possibly of the mid-century or modern style -- where I think two characters are having an informal business meeting. But the chaise longue itself is a single piece of furniture with two sides, such that each characters can stretch their legs while still being able to face each other for the meeting, with a short wall separating them.

That is to say, they are laying anti-parallel along the chaise longue, if that makes any sense. The picture here is the closest thing I could find on Google Images.

So my questions are: 1) what might this piece of furniture be called? A sofa, chaise longue, settee, something else? And 2) does anyone know of comparable pieces of furniture from TV or film? Additional photos might help me narrow my search, as I'm somewhat interested in trying to buy such a thing. Thanks!

EDIT 1: it looks like "tete a tete chair" is the best keyword so far for this piece of furniture

EDIT 2: the term "conversation chair" also yields a number of results, including a particular Second Empire style known as the "indiscreet", having room for three people!

view more: next ›