litchralee

I was going to write about how an existing tax agency (the California FTB) is already aggressive at tracking down high-earning residents that leave the state -- whether in-fact or on-paper -- in order to collect precisely what the state is owed per the tax code. That is, the FTB already engages and challenges the precise amounts that these former residents write on their final California tax returns, with some more spectacular results being some incredibly detailed timelines for when someone finally stops being a resident in California, as defined in state law.

But then I noticed that because of California's proposed wealth tax (aka Billionaire Tax) on the November 2026 ballot, the SF Chronicle has already started a series of articles to answer the specific what-and-hows of the wealth tax. This is the first article, pertaining to enforcement, and it agrees that the FTB would be capable of pursuing any high-wealth individuals that the proposal would tax. https://www.sfchronicle.com/california/article/ca-billionaire-tax-mechanism-21330110.php

This proposed tax in California is written as a one-time tax, so the question of whether high-wealthy people could flee the state is nearly irrelevant, because either they're subject to the tax or they're beyond the reach of the US courts (eg Venus). Almost. The remaining questions are legal in nature, and don't really change how the tax would be pursued. Whether FTB simply hires a dedicated team or outsources to private investigators, the task is still straightforward: follow the money.

Unlike civil lawsuit plaintiffs, who have more limited means of chasing down a defendant's assets in order to get paid on a judgement, the California tax authorities enjoy the benefit of the subpoena power, that can be used to compel companies and banks to tell the tax authorities about where and how wealth is being held. It is, after all, a core power of a US state to administer a tax, especially when the tax is authorized directly from the sovereign power (ie the citizenry). Any other result would conflict with the very purpose of a republic: to unyieldingly serve the people.

(short on time, so here's an overview to answer part of the question)

All password managers that are worth their salt (cryptography pun intended) have to anchor their trust to something, be it the OS's secret-storing APIs or a piece of hardware like a TPM (typically built into your machine's motherboard), an HSM (eg Yubikey) device, or an external source of authentication outright (eg a smart card, akin to what the USA Military does). Without any sort of trust anchor, a password manager is little else than a random program that happens to invoke a few cryptographic algorithms. It would be almost trivial for a malicious actor to use a bog-standard debugger like GDB to read the program's memory and steal the secrets, either after it has been conveniently decrypted by the program or by spying on the program while it performs the cryptographic algorithms.

Since a password manager runs within an OS, meaning that you already have to trust that your OS isn't an NSA backdoor, it makes sense to rely on the OS for storage of secrets. What the password manager does is provide the frontend for adding/updating secrets from the OS's store, while also making sure to authenticate the user prior to allowing access to the store of secrets. Once again, this is where hardware modules can come into play, but it can also be done using a main password. That is, you need to unlock the password manager before the secrets it contains are available for use.

Rather conveniently, the OS can also provide this authentication functionality: if you have already successfully logged into the computer, then that's a form of authentication. The most basic-but-reasonably-secure password manager would use two APIs to offload the difficulty tasks to the OS: the authentication API and the secrets API. That's the absolute bare minimum.

What Firefox's password manager provides, by default, is exactly that. But you can choose to upgrade to a Firefox-specific main password, so that if you forget to lock the computer, someone can't just open Firefox and use your secrets. This is one step above the minimum for a reasonably secure password manager, but it comes with the inconvenience of having to unlock the password manager every time you want to use a secret.

By and large, all password managers make these types of tradeoffs between convenience and additional layers of protection against certain threats. If your machine is inside the vault of Fort Knox and is actively guarded by people with machine guns and a keycard bullet proof door, then Firefox password manager is plenty acceptable.

Whereas a shared home computer in a situation where the disclosure of the secrets would cause a grave problem -- eg if an irate person finds that their spouse has a login for the local family court's online website, which might suggest a forthcoming divorce proceeding -- this might make sense to add additional layers. Indeed, some password managers can provide a decoy set of secrets, as a way of forming plausible deniability. If your situation needs plausible deniability, then Firefox's built-in password manager might not fit the bill.

I want to stress that using any password manager at all is already a massive improvement in security posture, and that any additional features and frills are merely refinements. Some folks are in high-risk situations where they cannot accept the possibility of off-device secrets synchronization, which would rule out Firefox password manager. But if you don't have such requirements, and if you can trust your OS, then you can also trust Firefox to store and manage secrets.

I have a rule which is that when anyone asserts that something is "more secure" or "more performant", they need to come with specific evidence for those claims. IMO, those two phrases are often used to "handwave" away any criticism for the asserted position, as a form of thought-termination. I would suggest that you always ask "more secure from what threat?" in response to such empty assertions. If they answer you with a specific scenario, then you can assess for yourself if that even applies to you. If they cannot answer with specificity, then Hitchen's Razor should apply.

without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others

From the perspective of a user, why would they care about development speed? A user, by sheer definition of wanting to use the software, can only use software that is already developed. If it's not actually developed yet... they can't use it. So either they see the software at the end of the development cycle, or they never see it at all. Development speed simply isn't relevant to a user at that point. (exception: video games, but I'm not aware of any desktop game developed using a web framework)

As for platform consistency, again, why would the user care? Unless each user is actually running the same software on multiple platforms (ie a Windows user at work, Arch at home, and BSD at their side-gig), this is a hard sell to get users to care. A single-platform user might never see what the same software looks like on any other platform. Even mobile apps necessarily differ in ways that matter, so consistency is already gone there.

What I'm getting at is that the concerns of developers will not always be equally concerning to users. For users to care would be to concern themselves with things outside of their control; why would they do that?

Was this question also posted a few weeks ago?

In any case, what exactly are the requirements here? You mentioned encrypted journaling app, but also gave an example of burning a handwritten sheet. Do you need to recover the text after it is written, or can it simply be discarded into the void once it's been fully written out?

If encryption is to protect the document while it's still a draft, then obviously that won't work for handwritten pages.

At least for Lemmy -- I have no idea about kbin or other ActivityPub software -- there isn't a user-accessible way to back up one's account on an instance, nor to preserve any communities that you're a mod for. So yeah, if the instance goes down unexpectedly like due to data loss or an FBI raid, the communities and users that were on that instance will disappear.

It's true that other servers will have a cache of some of the existing community posts and the users on the departed server. But it's exactly that: a cache, which will eventually be evicted.

A similar situation occurs when a Lemmy instance changes domain name: all prior posts to the community (and the community itself) were homed to the old domain. So a new domain cannot have the same identity as the old; it will simply be a separate entity, even if all posts were somehow preserved and reposted on the new instance.

Is this Lemmy-specific? No, Mastodon and I think all other ActivityPub software, plus BlueSky have this property, because they anchor identities to DNS names. From that, the posts to a community are anchored to the instance, and the instance is anchored to DNS.

So if the domain is lost, then it's game over. But if the domain is still there but the disk got wiped, then it would be a matter of recovery from a backup. You do have a 3-2-1 backup strategy, right?

I will note that Mastodon has a user-initiated export feature, which functions as a backup, something that Lemmy doesn't have. A Mastodon user can export their data and then move their identity to a new instance. Lemmy can't do that today, but it should be possible. Though in both cases, only the saved account is preserved. To restore a Lemmy community would require a disk-level backup image.

(this is all conjecture based on my limited knowledge of Lemmy. A better answer would come from an instance admin or one of the Lemmy devs)

128 MB (1024 Mb) of RAM, 32 MB (256 Mb) of Flash

FYI, RAM and flash sold to consumers is always in Bytes (big B); it's only RAM manufacturers (and EEPROMs) that use the bit (small b) designation for storage volume, I think. If you're using both to avoid any confusion, I would suggest the following instead: 128 MByte. No one will ever get that confused with megabits, and it's the same style used for data transfer, which does still use bits: Mbit/sec.

I wish you the best of luck in your search.

some people

they say that it's definitely a thing

To borrow a phrase from the largest encyclopedia project in the world, citation needed.

This is not to say that you, OP, need to provide the evidence of a problem. But rather, whoever you're hearing this from needs to proffer up more than just weasel words.

There is only so much time before each of us shuffles off our mortal coil, so why spend it contemplating nebulous "issues" when the real issues are readily visible: a pattern of physical violence against LGBTQ+ communities. It's not exactly difficult to do a web search for "lgbtq violence".

And to be abundantly clear, proof of "a pattern" has to show a pervasive, widespread, or organized/systemic series of events. LGBTQ+ violence easily meets this criteria, sadly. Whereas violence against white people because they're white or violence against straight people because they're straight is none of these things.

Demand better evidence from your vendor of talking points. Perhaps switch suppliers if you're not satisfied.

I think it depends on which Amish community, since they all adopt different degrees of self-sufficiency. See https://nebula.tv/videos/hai-how-amish-people-get-around-not-using-electricity/ (or on YT).

When looking through the history of Windows, some of the major milestones included the very concept of a windowed user interface in 3.1, refining the concept into a complete desktop-oriented (as in, a physical table top, with files and folders and a recycling bin) experience in Windows 95, huge backend improvements in the kernel (eg networking) by merging in the NT kernel (last used intact in Windows 2000) and giving us Windows XP.

Note well that XP was the first juncture between a consumer-oriented OS (a la Win 95/98) and a business-oriented OS (a la NT Server or Windows 2000). The missing link here is Windows ME, which was the next consumer OS after 98 but it flopped so hard when it became apparent that this artificial consumer/business division wasn't going to scale. Specifically, the Windows 9x kernel had too many DOS-isms whereas the NT kernel had no such issues. Hence, Microsoft undertook the massive effort to bring the two kernels together for XP.

In that sense, XP coupled a newer kernel with a polished UI. In essence, the company bet all its chips on XP. And fortunately for them, it paid off. But this came with a cost: XP has to carry the lineage of both the DOS/95/98/ME and NT/2000 into the 21st Century. This means the same OS has to support things like Active Directory (a feature only used by corporate customers) and Fax for Windows (used by anyone that wanted to use their dial-up modem for faxing, but also on fax servers, which are somehow still relevant today), while also supporting DirectX for the consumer gaming segment, plus multi-user support for "home computer" customers that still share a single machine for a household, despite a market trend towards personalized computing, and everything else under the sun.

And that's before we get to some of the backwards-compatibility support they still have to upkeep, like 32-bit support on the x86 family of CPUs, and BIOS (in spite of UEFI being a decade old). Notably, Windows on ARM has never kept such backwards compatibility, with ARM32 being completely deprecated and only ARM64 being supported by Windows 10 and beyond (hence, Windows on Raspberry Pi).

And then, of course, the Microsoft own-goals and mistakes: somewhere around 8.1, they decided to meet the tablet/touchscreen market by having Windows be touch-oriented. But as was blitheringly obvious then and now, the desktop concept cannot possibly be similar when the controls (keyboard/mouse versus touchscreen) are swapped out. Thus, this compromised the desktop experience in pursuit of a relatively niche target market. Meanwhile, Apple essentially forked their Mac OS to support mobile, tablet, and smartwatches as iOS, and aren't exactly itching to merge iOS back into the desktop OS.

A better execution might have been to port Windows for ARM (which is what most/all phones and tablets use today) earlier than they did, use that as the basis of a tablet-experience OS (like how Windows Media Center was just an application atop Windows XP), and then later introduce compatibility with desktop apps (like how Apple can now do full-speed x86 emulation using special ARM extensions baked into their custom silicon). That said, the latter was only technically achievable in the 2020s, but seeing as Microsoft was the market leader well into the 2010s, they would have been in the same position as Apple is in today.

So to summarize my long-winded comment, Windows carries a lot of weight. It is the result of successfully merging two very-real market segments into one product (business users and consumer users), then MSFT dropped the ball by chasing the Next Big Thing and adding more diametrically-opposed objectives to an over-burdened OS, with nary a plan for how to eventually relieve it. Had they instead did a separate OS for tablet and mobile (rip Windows Phone), they could have merged that one into the XP-based kernel and got the refined best-of-both-worlds.

Instead, they now have the worst of both. The Windows 11 desktop experience sucks, with bad icons, near-invisible text boxes, confusion where there wasn't any, and all while pushing consumers towards web browser-based apps. And to make it sting harder, because they've been feeding this mess to their corporate customers, those customers now demand that everything be kept the same ("better the enemy that you know") which prevents Microsoft from making XP-level wholesale improvements.

They're stuck, they know it, and they can't really fix it unless great leadership shows up to take command of the ship. But similar to Amazon (which makes most of its revenue through AWS, not selling/shipping products), Microsoft makes the majority of its revenue in two segments: Azure cloud and Office 365. It's hard to revamp Windows when it's now playing third-fiddle.

(I'm sure I've got some of the historical details wrong, but it's Saturday morning so full send)

The absolute first thing is to establish the jurisdiction of this scenario. The answer will be vastly different if the jurisdiction is California/USA than if the jurisdiction were South Susan. No shade against South Sudan, but we are talking about criminal and civil law, so the details might be very different.

But supposing this is a jurisdiction that follows in the Anglo-American common law (such as California, and I'll proceed using California as the setting), then we can make some generally-true statement, some of which confirm what you're already written:

1. Criminal law exists to punish bad acts committed against society at-large
2. Criminal law can only punish the persons or entities which have committed an act or omission that is proscribed in law, and only those persons or entities within the territory
3. Dead people or dissolved corporations are beyond the reach of criminal law
4. The notion that the next-of-kin will "inherit" the criminal liability was abolished long ago; see US Constitution "Bill of Attainder" prohibition, and equivalent in other jurisdiction like the UK or Australia
5. Anyone that is still alive and collaborated to aid or supply the dead assailant can be pursued using criminal law or civil lawsuits, or both
6. In parallel to the criminal law system, civil lawsuits can be filed against the remaining property of the dead assailant. This is known as the "estate" of that person, and the lawsuit would be captioned as "XYZ v the Estate of [dead assailant]"
7. A civil lawsuit can only win as much property as the respondent (ie person being sued) has, or any insurance policy they had which might apply, or any debt which was owed to the respondent at the time of their death.
8. Mass murder commonly result in civil lawsuits that do not obtain anywhere near the full amount to compensate for the victims' families' loss.
9. As a result, the target of civil lawsuits can be expanded to include adjacent parties, such as the manufacturer of the weapon or materials used, under a claim of product liability or something similar. This is not a guaranteed result, but they often have deeper pockets and good insurance policies.
10. Civil lawsuits can only bring a monetary compensation. The law cannot revive the dead, cannot erase or amend history, and cannot salve the void left when victims are removed from this world unjustly.

With all that said, the entire line of inquiry into the dead assailant's will, or to their parent's will, or anything like that, is entirely inapplicable. Children or parents do not inherit the sins of others, at least where criminal liability and civil lawsuits are concerned. Unless, of course, the parents participated somehow or willfully neglected a duty to report (very few of these exist in California, unless the victims were undoubtedly known to be children; see mandatory reporting laws). Thus, these other people cannot be sued nor criminally punished, usually.

The other commenter correctly said that what we call the "justice system" is more accurately called "harm reduction". That's not wrong, but I would post that the crimimal law system is about harm reduction (nb: I do not endorse the carcereal state of imprisoning huge segments of the population, disproportionately by race), whereas civil lawsuits are about equity and compensation.

Both systems exist in tandem to prevent people from achieving a bloodier form of justice in the streets, like in days of yore: pistols at dawn, dueling in general, lynching, "bigger army" diplomacy, shakedowns, midnight slaughters of whole families, and other such unpleasantries. It's definitely not perfect, and it needs reforms in many parts, but the structure serves a purpose and so far, it's what we have and the best that we have.

I think this would easily qualify for !brandnewsentence@lemmy.world

I've even seen people vibe code ethernet drivers for freeBSD.

Please make sure to read what considerations that developer had before undertaking that effort using an LLM: https://github.com/Aquantia/aqtion-freebsd/issues/32#issuecomment-3997341698

Specifically, they (the human) were kept in the loop for the entire process, which included referencing the working Linux driver to do a clean-room reimplementation. This already means they have some experience with software engineering to spot any issues in the specifications that the LLM might generate.

Also, Aquantia (before the merger) already had a published FreeBSD driver but it hasn't been updated. So this port wouldn't have to start from zero, but would be a matter of addition support for new NICs that have been released since, but Aquatia hadn't updated the driver.

This is very much not an example of an Ethernet NIC driver being "vibe coded" from scratch, but a seasoned engineer porting Linux support over to FreeBSD, a kernel that already has a lot of support for easily adding new drivers in a fairly safe manner, and then undertaking a test plan to make sure the changes wouldn't be abject slop. That's someone using their tools with reasonable care. In the industry, this is called engineering.

Admiration for what people can do with the right tools must always be put into the right context. Even with the finest tools, it's likely that neither you nor I could build a cathedral.