litchralee

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

Is this correct though, in terms of a confidentiality or non-repudiation guarantee? For a ledger system -- blockchain or not -- every unit can be traced back through the history, to one or more sources. Yes, multiple transactions can serve to obfuscate the sources, but the real source is within that subset of all possible sources. So unless obfuscation takes place by involving all possible addresses, there's still going to be some amount of knowledge revealed about the relationship of some source and some destination address.

But I think non-repudiation could be more damaging in a cryptocurrency context. Imagine a corrupt politician that takes a cash bribe. Unless the briber recorded the serial numbers, the politician can plausible repudiate any connection with the briber, because the cash could have come from anywhere else.

Whereas with cryptocurrency, if the briber's wallet address is ever revealed (eg. by hack, by change of heart, by blackmail, or by cryptographic collapse), then there's a line which can connect the briber to the politician. They cannot deny that it's possible to have received the bribe, which is a scandal unto itself. Probably not good enough to convict of a crime, but enough to do political damage.

Ultimately, I'm of the opinion that a ledger system still isn't as strong on confidentiality as cash, because cash records nothing at all, so there's nothing to accidentally reveal. To be clear, bribery is a stand-in for any sort of payment that would cause adverse effects if revealed. Other examples include secret child support, for a secret pregnancy, for a secret abortion, or anything else that people don't want to reveal to the world. The whole point of privacy, I maintain, is to have a choice on what other people get to know.

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

By what criteria do you say that? You might be right, but without any qualification for how one might be better than another, it's as useful as saying "purple is better than yellow".

But ultimately, you're looking for a moderation paradigm and don't owe me or anyone else a criteria or explanation for what you ultimately choose. It merely means that the question as posed is unanswerable, no different than "why is green the best color?".

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

"best" is relative, and while moderation can achieve a great deal of success on a smaller scale, it's proven to be extremely tricky at large scale. Mike Masnick of TechDirt (and on the BlueSky board of directors) has documented this rather well, using some very notable case studies.

For example, moderation is both necessary and complex (Twitter post buyout): https://www.techdirt.com/2022/11/02/hey-elon-let-me-help-you-speed-run-the-content-moderation-learning-curve/

Decentralized moderation like Mastodon is good (by blocking Gab from the get-go) but requires active coordination from federated operators: https://www.techdirt.com/2019/07/16/gab-mastodon-challenges-content-moderation-more-distributed-social-network/

At a slightly larger scale, volunteer moderators can be overburdened and lead to adverse infrastructure shutdowns (Parler getting bumped for violating AWS policies): https://www.techdirt.com/2021/01/13/parlers-laughably-bad-antitrust-lawsuit-against-amazon/

My point with these examples is that a moderation system solely based on volunteer effort can be: 1) overwhelmed, 2) manipulated, or 3) antithetical to the purposes of the community and/or platform. There is no magic moderation system that will be 100% effective for your environment at all times.

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

in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.

This is the use-case I hadn't considered. And it makes sense now that I think of it. Though I personally haven't come across it, since I don't typically work on multiple, cascaded features at a time. Most of my work as been with waterfall models, so I can understand that other approaches may indeed have cascading features in parallel.

Thanks!

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

TIL git history.

That said, I'm trying to figure out what the target workflow is, specifically for the "autorebases all your branches to match" functionality. Assuming we are not talking about rewriting published history -- and nobody should ever really be doing that anyway, when multiple commiters are using the same branch -- I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other. The trouble I'm having is the number of commits per feature.

If the number of commits per feature is 1, then that means each branch just has one commit that its dependent branch doesn't have. What is the point of the branch then? Just have a single WIP branch and keep building a linear commit history. If you need to give someone one of the features, then give them the commit which inplemtns that feature and nothing afterwards.

If the number of commits per feature is >1, then this is certainly more difficult to work with, and the appeal of git history starts to shine when dealing with WIP commirs. But why is the dev in this situation, where they're building multiple dependent features but they're none are fully complete yet? Because if they were complete, then I presume the dev should squash the commits so the number of commits per completes feature is 1.

My current thought is that having >1 commits to implement a single feature is a transient condition, and good practice is to get to 1 commit per feature. Is there something I'm missing?

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

This blog post is a wandering train of thought on the topic of what tools are and why it matters to be even slightly more mature in how we think about them.

That's the second sentence, and it's fairly clear that the author means to start the discussion of the titular topic, not to conclusively explore every ail of AI. Of which there are many, yet enumerated.

Some people call this "food for thought"; I would agree.

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

I saw this counterpoint on Mastodon and I think it sums up things rather well: https://hachyderm.io/@chris_e_simpson/116925250364867462

Child labour is such an excellent comparison to use against the "if it is effective why not use it" argument.

[–] litchralee@sh.itjust.works 0 points 1 week ago

I'm relying a lot on the background of Sweden from this video: https://www.youtube.com/watch?v=7CsSs0eQKKA

In essence, the USA does not have the same pressures that led Sweden to their current strategy. For that reason alone, duplicating the same strategy in the USA would be a failure to meet the country's actual threats, use up more cultural and military capital, while also throwing away some of the USA's natural strengths (eg stable geopolitics in North America, service exports economy, vastly distributed population).

As a reminder, only until fairly recently, the USA military branches met most of their recruitment goals through voluntary enlistment, an approach that succeeded against the backdrop of 1975, when the country was deeply against the draft. What fuels the enlistment pipeline is, rather unfortunately, the poorer class, because military service is a route to a better life. In some ways, the voluntary enlistment benefits are a perverse form of state support.

So the need for a draft is, IMO, wholly inappropriate if voluntary enlistment is still viable. The next question would be whether the USA would find itself overwhelmed by crisis or disaster that it would need the civilian population to help defend the national interest.

And still, I don't see as being plausibly, because it really shouldn't ever get to this point: the USA still has (we think) credible nuclear deterrence and power projection. This can, and does, make up for the lack of civil cohesion and, quite frankly, civil apathy for anything beyond putting food on the table. That is to say, a threat would have to seriously infringe on the average American's daily life before they will do something about it.

If this were seriously part of the national defense, then we'd have already lost the game.

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

There are a few things that need to be clarified, because they're all fairly distinct even though they might seem to be doing similar things:

  • Copyright: protects the reproducibility of some work. Objective: a time-limited monopoly for the owner to control copies

  • Trademark: protects the authenticity of a vendor. Objective: elimination of marketplace confusion; vendors are judged on their merits

  • Patent: promotes disclosure of innovations and protects the use or application of an invention. Objective: a time-limited monopoly for the owner to control uses, but must disclose the secrets for how to build it

  • Defamation: (USA specific) protects against provably false statements published about someone. Objective: elimination of lies from the marketplace of ideas, but does not affect opinions or public mores

  • Right of publicity: protects personal marketability and opportunities. Objective: elimination of labor marketplace confusion; person will be judged on their merits

There are two things which can cut against almost all of these: fair use and parody. Fair use arises commonly in copyright but the logic is the same: in order to discuss something, the thing must be identified. The marketplace of ideas cannot exist if nobody was allowed to screengrab a TERF's wizard movie or mention why they don't like a certain cola company. The key is to be minimize the incursion to what is absolutely needed. For example, someone organizing a boycott can indeed use a brand's logo to refer to that brand.

As for parody, it goes a bit further and will (for comedy or sarcastic intention) assert that the statement is true or the work is authentic. This too is allowed, because -- at least in the USA -- poking fun at things is a valid (and human) way of discussing things that would otherwise be difficult to say. How it relates to defamation, trademarks, and right of publicity is that a reasonable viewer of the parody must be able to determine that yes, it's a joke and it's not actually making that particular point but rather a different one. This is akin to someone nodding their head to say yes but verbally saying "no": there are enough mixed signals that nobody would take the assertions seriously.

So would someone's face be "locked out of the arts"? No, not by copyright. But under right of publicity, they could have a claim if the depiction could potentially be confusing. Fortunately, this generally can be cleared up by explicitly identifying who the depicted face belongs to. And also to never try to sell or distribute artwork that rides on that person's coat-tails.

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

I would say that the crucial pillars of embedded work are: mastery of C, computer architecture, and data transfer. I say this because most embedded challenges can be framed in (and often are written in) the C language. The same problem-solving approach for C is very similar to solving problems in a microcontroller. I put specific focus on pointer arithmetic and alignment, because although higher level languages take care of these things automatically, it has to be handled eventually at the lower levels, usually by the embedded engineer.

For everything that isn't C, the next set of challenges are in integration: rarely does a microcontroller run on its own. It might coexist with a host computer, have its own serial interfaces or other peripherals, access memories or sensors through complex buses, and some even have a quantity of DDR (with all its required supports). I don't think it's absolutely necessary to enter the field knowing the ins-and-outs of ARM's AXI bus or how PCI/PCIe transactions propagate through a tree. But knowing the inspirations for commonplace things like Virtual Memory, IOMMU, DMAs, and memory bus width, those are foundational.

Finally, there's always data transfer. Some data here needs to go over there. This can include actual networking protocols (eg TCP/IP, WiFi, ZigBee) but can also be point to point (I2C, RS232). This is probably the part where people entering the field have to be generalists: there are just so many different ways to transfer data that it's basically impossible to study them all in advance. Instead, some things are common to all transfers: a specification of the start and end of the payload, why headers or sync patterns are used, error correction, medium arbitration, reliability guarantees (if any), and API considerations (eg conformity to BSD sockets).

To be abundantly clear, embedded is very hardware oriented. In my time, I've seen a lot of Electrical Engineers and even Mechanical Engineers successfully make the leap over to embedded software, because they already have the ability to efficiently absorb knowledge from data sheets and specification documents, and will work within the absolute limits given. If there is the aptitude to dive very deep into the details, to find truth where everyone else sees "magic", then embedded will not be too difficult.

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

I'm an embedded software engineer, and IMO embedded software has the benefit and curse of being not-very-sexy, in comparison to web developers or database engineers or backend engineers. That is to say, it's really easy for front-end engineers to describe their work, because it'll be something that people have seen (eg a website, or a service like Netflix). And even for backend engineers, they can analogize to fields that are well-known, such as administration or utilities (ie everything goes to poo if the sewers fail).

But embedded engineering is a tough one to explain, and that also means prospective employers might not even know that they need an embedded engineer for their Whizz Bang 3000. It's not at all intuitive to most folks that there's a separate set of skills necessary to program a screen-less, keyboard-less, network-less tiny CPU that might not even run an OS.

On the flip side, it means that the job is fairly specialized and thus valuable. Most software engineers could probably figure out how to program a microcontroller using C, but the most talented embedded engineers can achieve the same in the smallest memory footprint, thus saving hardware costs. To shave off $1 off the cost of a product that will sell hundreds of thousands, that's something that companies will pay for.

Embedded is diametrically opposite of application development: basically everything is under constraints (eg RAM, CPU time, I/O, interfaces) and we just have to deal with it. At its core, the occupation seeks to do the most number of things with the fewest resources. Not everyone has to skills to optimize this hard, to strip down software to only its abject requirements.

I can't speak as to what any particular job markets looks like right now for embedded engineers. But given that the need for embedded software does not ramp up during hype cycles, I think it tends to be a fairly stable occupation. The trick is that it's not a huge market everywhere, so moving for work might be necessary.

TL;DR: embedded software is a small but stable occupation, IMO.

 

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.

 

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)

 

(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 ›