It’s useful to keep the 16 million IoT devices you have running on WiFi segregated a bit.

Thanks for the correction on the the broadcast address, btw. The details are important.

At home, I have 172.16/12 scoped out for my cluster subnet and just use the second and third octet to denote service function. It’s excessive scoping, but it’s an internal scope for a private network and broadcasts are generally contained to the cluster network. It would be trivial to split that into a 172.16/16 if I ever had the desire. (Speaking bluntly, it really doesn’t matter much in this case. I’ll need to split it out to keep Longhorn traffic segregated later, but it’s not an issue now.)

The rest of the network is reasonably scoped out across 192.168 ranges and chopped up across a few VLANs.

My addressing scheme is split into “public” and “stay the fuck out”, with most 172 addresses being the latter. At home this is great. In a large network, scoping out such a large 172 subnet could be detrimental. (“It depends” on the detrimental bit and requires proper planning and understanding about why subnets were even built into IPv4 from the get-go.)

Edit: Most addressing is static on my cluster network, with DHCP only handing out addresses based on MAC address. The 172 subnet has very restricted dynamic IP ranges.

Regardless of what is what, it’s a scheme I recognize and that is the more important bit.

255 is reserved for broadcast.

Edit: Yes, 255 is technically not ‘reserved’ by itself. I was only thinking about the addresses scoped to /24 for a simple answer. A broadcast address is reserved, though.

When in doubt: https://www.calculator.net/ip-subnet-calculator.html

Feature detection in images is extremely light weight so it seems that it would be fairly trivial to detect someones wang before the stream is encrypted in the first place. There is likely already a ton of processing done on raw camera data before it’s encrypted and sent off-device anyway.

Also, it depends on the problem you are trying to solve and if the good deal lets you buy plenty of spare drives.

I have a 3 server cluster running 9 k8s nodes with persistent storage in Longhorn. While it thrashes the drives a bit more and I lose performance, I opted to use hardware RAID so a drive rebuild would be much easier. (I think with Ceph, it’s a step or two more to kick a drive out of the storage pool before you can swap the drive safely. The fact that I can’t remember much about Ceph already and it’s only been a month or two since I setup a Ceph testing cluster should alone explain my decision.)

Basically, I get volume replication backed by easy to manage and affordable drive replacements. I even get mirrored boot drives too. The setup is fault tolerant to a degree and it gives me enough time to shuffle things around if a server starts to die completely.

All the drives are used and have already had a full life, but yey, the risk is ok because the parts are cheap. I’ll probably buy another refurbished server of the same type just for the spare parts, drives and memory. I could even just use the extra server as a cold standby. Whatevers.

The cluster isn’t critical, to be perfectly honest. It really just holds a massive tool suite of containers that I need at random times and now I at least have solid templates and ansible confogs for all of those containers anyway. Even the data isn’t super critical.

Parts are cheap and my setup allows for disposable drives in a setup where risk tolerance is sky-high.

My NAS is RAID 10 with brand-new drives and read/write cycles are conserved. I care about that data and will probably mirror that storage that to an additional pair of mirrored m.2’s to absorb most of the read a cycles while adding an additional redundancy layer. (The hdds would primarily only see write cycles and probably just function as an incremental backup location for specific folders off of the m.2’s.)

Those are the cliff notes, and only I attempted to explain how I thought about risk in my setup. Volume over quality for my cluster: I think about fast recovery and how I can parch around a problem during a catastrophic failure. Long term: Multiple layers of redundancy for important data with less concern about price but I have less capacity and speed.

Having spent years around lots of equipment, I view a flashy red light on an HDD as a suggestion to do something about it in a couple of days if the server is just a worker node. (I have been desensitized to most hardware faults, TBH.)

It’s got what plants crave.

There isn’t a shred of good will left at Google and their ban hammers operate on algorithmic randomness.

If anything, files should be jammed into as many short-form videos as possible to hopefully trigger a run-away implosion of that that entire ecosystem.

I certainly wouldn’t say it was incompetent and there is a good set of data points. Given the nature of what the study is attempting to correlate, not explaining what limitations were taken into account is a a significant limitation, IMHO. It is called out that there are limitations, but that it is essentially just a short footnote. (The full paper does a better job of calling out other studies and some contradictions.)

This referenced study found the opposite and had a no (or weaker correlation) to cancer associated with SSBs: Khairan P, et al. Sugary drink consumption and the subsequent risk of gastric cancer: Khairan P, et al. Sugary drink consumption and the subsequent risk of gastric cancer: The Japan Public Health Center-based Prospective Study. Eur J Clin Nutr 2023;77:218-25.

Without doing a comparative analysis of the studies, which would be interesting, I have open questions about what the key differences were. My first guess (without calling either study “wrong”) is that maybe risk factors were calculated differently?

On the darker side, there is motivation for keying-in on a specific correlation and that cannot be ignored either. (Past grants, groups requesting the study, etc.) The original paper also sets itself up to be a marketing call-out for artificially sweetened beverages, unfortunately. (I am not saying that is the intent, but the wording aligns exactly with what vitamin water-type company would want to see. It made for a good Lemmy post title, at a minimum.)

At the end of the day, they stated what they were looking for and presented what seems to be a clean analysis of that data. The limitations that were presented have the potential to be significant, however.

So my chance of developing gastric cancer doubles to 1.8% chance over my lifetime if I drink sugar-beverages every day… (This math wasn’t sponsored by a cancer testing company.)

After you actually get the the study, there wasn’t any mention of other associated lifestyle behaviors that may contribute to the risk of gastric cancers. What sticks out to me is that people drinking one or more sugar-packed beverages per day likely have additional diet or lifestyle concerns.

It’s not that I think the number crunching for the study was wrong or that the sample sizes were too small, it’s just that it was extremely focused on making a correlation for the sake of making a correlation.

Flags have always been poorly standardized outside of system apps and tools. Generally, -u should equal --update (and depending on how the app was written, may warn for --up: “Did you mean --update?”) Single tick flags are generally combinable: -ua or -ls. I have seen long single tick flags somewhere, but can’t remember where. (Your -update example.) Various python libraries than handle flags have helped a ton with getting people to use the same patterns, so that is nice.

You just summed up my first experience with systemd many years ago.

systemctl != sysctl. Both somehow got wedged into the same index in my brain and took years for me to correct. On top of that, <service> <action> was reversed to <action> <service>. (Or was it the other way around?)

I was convinced from my first experience with systemd that the person who wrote it was the purest form of evil. (It’s leveled out a bit over the years, so it’s tolerable to use these days. Still not a fan though.)

Trash app. If you actually want to see all of your data and have it recorded accurately, just switch to the Garmin ecosystem. Garmin isn’t without their own set of issues and problems, for sure. However, if you actually want data and not AI slop summaries, stay a far away from Google Health.

Simply put, it’s designed for people who think that wearing a fitness tracker will improve their health and want a chat bot that will make them feel better about that.

I did. All the important things have time to gracefully shutdown now. (Except my for my rack of 4 DL360’s, which need something a little more robust than a Walmart UPS. They aren’t critical and only exist to handle weird one-off projects anyway.)

This happens, too. A burst of local brownouts killed an OPNsense firewall of mine once. (The hardware was fine. The data got wrecked.) The firewall would boot, or almost finish booting, and then another brownout would hit. After the third or fourth cycle, the poor thing was toast.

I should thank the power company for free resilience testing.

May 19, 2026 3:00 PM _Meta Employees Are Scrambling to Use Up Benefits Ahead of Ahead of Meta’s latest round of mass layoffs tomorrow, some employees are deserting offices, abandoning their work, and loading up on perks they might soon lose, several people at the company tell WIRED.

Two employees describe a widespread rush to use up an annual $2,000 flexible benefit, which can cover a variety of expenses including health and wellness activities. A separate triennial credit of $200 toward the purchase of audio gear has led to a scramble to purchase Apple AirPods and other headphones. Another source says Meta offices have been largely empty this week, as people prioritize polishing their résumés and gather offsite to commiserate with friends for what may be their final time as colleagues. Employees are variously “paralyzed,” “coasting,” and “panicked,” sources say.

Meta plans to lay off about 10 percent of its nearly 80,000 employees on Wednesday, with notices going out to affected workers’ personal and corporate email addresses at 4 am Singapore, London, or San Francisco time depending on their location, according to a company-wide memo sent on Monday. The cuts are coming at a time when the social media giant behind Instagram, WhatsApp, and Facebook is enjoying record-high profits.

But CEO Mark Zuckerberg insists that the company must free up cash to invest in AI data centers, and that Meta can perform just as well with fewer employees because of AI technologies that augment human labor.

Are you a current or former Meta employee who wants to talk about what’s happening? We’d like to hear from you. Using a nonwork phone or computer, contact the reporter securely on Signal at peard33.24 and ChaoticGoode.12. Meta didn’t immediately respond to a request for comment for this story. The company has undergone three previous large rounds of layoffs since 2022, including as part of Meta’s one-time “year of efficiency” drive in 2023. But even though the latest round is smaller than a couple of those, it is drawing widespread scrutiny because it comes at a time of societal anxiety about AI’s impact on jobs.

Inside Meta, the imminent cuts are among several concerns that have sunk morale to unprecedented depths, according to 16 current and former employees who recently spoke to WIRED. Employees also have been frustrated by being “drafted” onto a new AI team without any choice and the rollout of surveillance software that tracks US workers’ laptop use to train AI models.

Meta also plans to internally restructure as it conducts sweeping layoffs, transferring 7,000 remaining staff to “AI initiatives” and converting more managers into individual contributors. That would bring the total number of those affected—either laid off or placed in a new role—to 20 percent of the current workforce, Reuters reported on Monday. WIRED independently confirmed this reporting. Some parts of the company have been told they won’t be affected at all.

But in recent days, employees who are bracing for changes have shared checklists internally about benefits to take advantage of, and are saving documents such as performance reviews and pay stubs, according to one worker. Some teams are meeting up at bars and restaurants near Meta offices in New York and Menlo Park on Tuesday and Wednesday to eat and drink away their sorrows, several employees said. Management has encouraged employees not to come into offices on Wednesday.

Update, May 19, 11:40 PM EDT: WIRED corrected the time zones when layoff notices will be emailed. _

What exact is the goal here? You kinda just rolled right into install instructions without context…

Most of this is just marketing crap from Anthropic.

Finding vulnerabilities in code and generating complex, multistep exploits with publicly available models is possible now. This biggest hurdles now is setting correct context and actually knowing what to look for. Any “guardrails” for this behavior are easily bypassed by framing the detection and exploit generation as a valid dev style question in the most difficult of situations.

They likely just trained a model without guardrails in this case.

What they are doing here is over-hyping a problem and framing it like they are the only ones with a solution. LLM security issues are more in-focus now that companies have dumped a ton of resources into building AI systems they don’t really understand.

Companies these days do what is right for their shareholders and if Claude makes money, or appears to make money, then the shareholders are happy.

000, 666 and 900-999 are invalid area numbers and any digit group of all zeros is also invalid. Thanks for playing!

I am making a slightly different point and have a bias to this perspective: https://www.legis.iowa.gov/docs/publications/SD/19230.pdf

I am saying that an SSN can be part of a larger validation scheme, not the only key to the castle. Specifically for government sites, SSNs can be linked to IRS data to verify places of last residence. A person generally needs to verify multiple items that are referenced by the SSN before basic authentication can be established and set by the user. (This is part of the full Authentication, Authorization and Access Control triad.)

An SSN is just a broad level identifier. If you look at many laws around the release of SSNs, the redaction is usually in place to prevent the linking of different documents and other data points.

If I released my SSN in this chat, I could be fully doxxed in a matter of seconds. It’s mainly because there are many legal systems in place that use an SSN as a primary key, of sorts. (It’s a bit more than that, as SSNs can be duplicated in some circumstances.)

So to say, at a high level, an SSN is considered private is absolutely correct. However, it’s so easily referenced and obtainable it really isn’t fully private either.

If I was to generate a full list of every possible SSN in the US (which I have done, multiple times), that list is effectively useless to anyone who obtains a copy of it. So, by itself, an SSN is effectively public.

SSNs are generally considered public information but how the SSN is linked to other information is usually the more difficult bit to find and it’s generally pay-walled. (Any jackass with a business license and a credit card can usually buy background check information for ‘hiring’.)

But no, it shouldn’t be solely used for authentication. That is just dumb. However, it can be used as part of a larger verification and validation scheme while building authentication/authorization profiles. In most systems that I have seen that use full or partial SSNs, it is always linked to several other identifiers that need to match.