litchralee

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

Let's also not forget inheritance tax, which directly addresses the problem of hoarding wealth and perpetuating inequities across generations. If supposedly "self-made" people "earned" their billions, then their heirs should have no problems earning their own as well.

[–] litchralee@sh.itjust.works 36 points 1 day ago (3 children)

In California, property tax is adjusted annually regardless of which way it goes. But if it goes up, it is capped at 2% per year, due to Prop 13. If the assessed value drops, then the reduction in property tax is not limited.

As public policy, this has been devastating for local funding, being the primary means for funding local school districts in this state. When the education prospects of children are subjected to the whims of the wider economy and/or how hot (or not) the local property market is, this is a recipe for inequity: well-off areas are willing to tax themselves extra (beyond the Prop 13 2% cap) and get good schools for it. But poor areas cannot afford even the existing tax, because property tax is regressive and consumes a larger proportion of poorer household budgets. Meanwhile, the state abdicates its role in funding education, because they believe the locals would vote for more taxes for education, even though it's plainly obviously a Zip code lottery.

But I digress.

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

I believe you have the current meta understood, yes.

I know that most people actually get places by having stuff to show off e.g projects, clubs and GOOD GRADES

From what I've seen with how my company handles intern applicants, there are at least two different tracks: the first track is indeed people that have GPAs and coursework that is immediately impressive to any recruiter working on commissions. But the second track is where applicants make an impression to our engineers staffing the company's booth when on-site for career fairs.

My take is that engineers have a better gauge for aptitude and generally fitting-in with the company culture, miles above what an external recruiter or a company HR person could ever assess. This makes for higher quality interns, whom could later be offered a full position. And fortunately at my company, the process for assessing applicants from either track still ends up before an interview panel of technical people.

My advice then is that in tandem with a mass approach to resume distribution, also seek out in-person career fair opportunities. These opportunities won't exist after you've left uni, and it's a good way to both understand a prospective employer and also make a good, in-person impression. And if you do this, do brush up on exactly what those prospective companies work in, and put your most appealing strengths forward first. Even just asking them questions but using correct industry vocab is a differentiator.

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

Happy cake day btw!

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

Many years ago on my way home, just one block down the street, the pole-mounted transformer was aflame and the fire department had already arrived and were setting up their equipment to deal with it. After detouring around the scene, my neighbors told me they believed it was struck by lightning on that stormy night, although the loud boom and the loss of power to the neighborhood could also have been the transformer or its fuse exploding.

Seeing as the fire department was already attending, and not having any additional concerns about the transformer itself, I went inside my dark home to find a flashlight -- this was before smartphones were a thing -- and then checked to make sure there wasn't any obvious electrical damage in every room. Finally, since flashes of lightning has been seen earlier that evening, as a precaution, I decided to flip off the main breaker and called it a night.

In the morning, waking up to no electricity, I at least had daylight and went to turn on the breaker. And indeed my home powered up, as if nothing had happened. I then went on with the rest of my day, driving past the scene where both the fire department and electrical utility must have toiled in the rain to clean up and restore service.

That was years ago and I've not experienced such an event again. But apart from making sure that your electric appliances aren't damaged, there isn't much else to do once the fire department and utility are alerted. Instead, I would advise general emergency preparedness, and avoiding common sources of mishaps, such as lighting candles and open-flames during a blackout.

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

Better to use an old architecture whose patents have expired, and implement it on a new, smaller process.

I'm not aware of any examples of an old architecture that was largely reused while ported to a new process, without requiring extensive redesigning of the analog components. Old processor architectures are a product of their day, making assumptions and decisions about the silicon paths that would be wholly invalidated if brought as-is to more-modern processes. It is nowhere near as simple as a copy/paste job of SystemVerilog or RTL.

To invest even one hour of design time to update, say, the 1970s Intel 4004 design (10 micrometer process) into the 2000s (130 nm) would be more expensive than just using RISC-V for free, which has already been fabricated using 22 nm, among other processes.

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

I can't say I've looked too much at RISC-V (yet), but someone once painted the following picture for me: if AMD and Intel are duking it out for supercomputers, while ARM works its way up to servers and down to microcontrollers, who serves the absolute smallest use-cases? As in, what if my whizz-bang product genuinely only needs a 300 Hz -- not MHz, not kHz -- processor to do some truly banal calculations? How can I possibly convince a silicon fab to build such a niche and tiny chip at scale?

In this context, scale would be however many could fit a single 300 mm wafer, and takes into account the fixed cost of the wafer itself, and then the price premium for smaller manufacturing process that would fit more chips onto the same wafer. At such low clock frequencies, the chip could be made using ancient lithography machines for dirt cheap.

But ARM would almost certainly not entertain the request to do consulting work for such an incredibly low-end chip, where the ARMv8 and v9 architectures would be vastly overpowered.

For these sorts of economically infeasible ideas, RISC-V brings to the table the possibility that some small-batch ASIC consulting firm would work with their customers to churn out some mindboggling processor designs. Because when the architecture is free (as in beer and as in speech), it releases the designers from constraints that today's designs must have.

[–] litchralee@sh.itjust.works 10 points 3 days ago

but it's got warm water

A person of high standards! A fine luxury indeed!

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

They see me ~~rollin'~~ turnin', they hatin'

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

some ominous comments stating that it is practically unmaintained (which is not true)

Objectively, I can see that the last commit to the default branch was in March 2026, and that the 10th newest commit was back in September 2025. Of these 10, 3 are new features and 6 are fixes and 1 is documentation. I also see in the issue tracker that no project developer replied to the two newest reports, which were reported 2 weeks and 2 months ago.

As a subjective opinion, the explanation that Conduit is essentially rock-solid and this doesn't need much upkeep or commits, that is just not credible. The Git history shows fixes and new features, but at a rate that averages just one commit per month. And some of those commits are literally one-line changes.

But let's suppose that the maintainers are uninterested in small UI or quality-of-life features, and only make changes when it crosses their threshold for what is "important" enough. That's a choice, sure, but let's see if that holds water. Here is the project's response to an issue opened in January, with the response being in February that confirms a logic bug and schedules it for the next release.

That was three months ago. No updates. No mentioned branches or PRs or merges. All while this bug remains in place. And that's understandable for FOSS project developers, for whom the project is not their day job.

But in any circumstances, the totality of the evidence does not inspire confidence, let alone a determination that Conduit is "rock solid". And that's even before looking at the code.

TL;DR: the premise of the question is wrong. Conduit is not maintained.

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

I guess you'll just have to lift the entire cable machine /s

 

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.

 

To make it easier for the haulers, I sort my flattened cardboard boxes by size, and then insert the smaller ones within the larger ones, rotated 90 degrees. That way, they can grab larger bundles at once.

To me, this is less effort than the Japanese approach of using twine to tie bundles of cardboard together.

 

Every so often, I think about how much electric power my house consumes at all hours, even when it's the dead of night and nothing is really being used. So this morning, I went out and flipped each breaker off, one by one slowly, while watching the instantaneous kilowatt reading on the electric meter and taking observations.

This took about 20 minutes for all circuits, and then I honed in on the suspicious circuits, the ones which don't have a known appliance like a fridge which should always be running. Years ago, when I moved into this house, I drew out a map which describes which outlets and appliances belong to which circuit.

The two suspicious circuits were the living room and bedroom circuits, and armed with a Kill-o-watt, I ended up finding that my very old Bose Companion 5 desktop speakers will draw 23 Watts doing absolutely zilch. And my 2018-era Roku TCL so-called "smart" TV draws 20 Watts when it's "off".

I've been meaning to replace the Bose speakers -- due to a separate issue where the mute button only works half the time, and horrific Linux support -- and a friend recently offered to sell me some reference speakers that I can pair with a Class D amplifier, one which has a physical on/off switch.

For the TV, I'm not exactly sure what to replace it with, since I was going to wait until it died and replace it with a commercial-spec display, one that has no remnants of "smart TV" anything. I don't allow my TV to even have a network connection or WiFi, so it really shouldn't be doing anything. So I guess in the meantime, I'll just pull the plug when I'm not watching; at least it's easy to reach.

EDIT: the TV is now showing inconsistent results. It will occasionally drop down to a more-reasonable 0.1 Watt. But it might also remain at the aforementioned 20 Watts. Not entirely sure what it's doing, whether just sitting there or staying on for a while after turning "off" the TV.

 

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

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)

view more: next ›