rincebrain

I assume they typoed reflinking, a way of doing CoW-based copying of file contents.

I think in common usage, people expect an "emulator" to be a more sandboxed translation layer than Wine, for example, provides.

e.g. it's probably a security vuln if loading a Game Boy ROM reads arbitrary paths on your local filesystem determined by the ROM's code, not so much with Wine.

Someone made a cute demonstration that I think usefully encapsulates this a while ago. [1]

[1] - https://gpfault.net/posts/drunk-exe.html

The WRT54G community tried this for a while.

Red Hat most memorably has tried it with "technically you are legally permitted to distribute these things we are giving you under contract but we will terminate your contract if you do."

Some nicer boards have redundant copies of the BIOS so if you fuck up the update, it boots the old one.

Various enterprise boards with BMCs can flash the BIOS from the BMC even if the BIOS is fucked.

You might even be able to do that with Intel AMT, but I've never had occasion to try.

My understanding is that you can usually flash the BIOS from the BMC even if the BIOS is fucked, though it's a paid feature upgrade (though I think someone might have cracked the algorithm on older boards).

At least, it has been the case on several boards of mine, including an X10SDV which bricked itself, as far as I can tell, just from bad luck somehow.

I don't think that's necessarily true.

You can be cashflow positive and still benefit from having a larger pool of cash to throw around, particularly in any situation involving hardware manufacturing.

If you tell your investors "our limiting factor is how fast we can spend to deliver on additional requirements for these new customers", then it can both be true that you're not going to miss payroll for 5 years no matter what happens tomorrow and more cash would be beneficial.

Many people who have ever had to deal with the long tail of insanities in physical hosting, like "the ceiling burst and dumped water on a rack", "the RAID controller's capacitors exploded and now you need to figure out what still works", or "for some reason three of the servers won't talk to this switch but talk to anything else using the same cables, and the switch ports work for other devices", would happily pay a premium to only deal with SaaS logistics.

(Those were all firsthand examples; I'm not saying everyone needs cloud providers, but there are reasons beyond "really good salespeople" that people opt for offloading those logistics.)

I would imagine that it's plug and play until you start adding nonsense like customizable scripting on buttons or more than a certain button count as is standard on specialized gamer mice, but sure, fair enough.

"This is a platform you can build on", software and hardware specs included, is still a much nicer thing to iterate on than "it's commodity parts to slap together" for someone without familiarity with the processes involved at scale, and going from "this is an opaque piece of hardware that responds on guaranteed timing" to "this responds on guaranteed timing but also has more complex features" is still a substantial jump, since "building software that meets realtime timing requirements" is not a thing in a lot of people's wheelhouse.

I think the point is less to add features and more to lower the barrier to entry for people making mice, since, as you said, in large part keyboards and mice are appliances to the degree that it should rapidly converge to a stable set of features.

Plus, on a human level, I wouldn't be surprised if the teams working on mouse development were annoyed they couldn't show their past work in the same way...

Because at scale, that doesn't work, I think, even money no object, because it's a task that requires a lot of domain knowledge, but also is monotonous and offers little in the way of satisfaction or looking good on your resume, so the candidates you're trying to hire aren't very junior, and also are not going to like the work.

I have to imagine the answer was either "dedicated MSCC servers and EEE" depending on your level of cynicism or "it was just a tech demo that escaped".

The government is in a bad position to be that kind of paternal - any sort of large machine is the worst possible judge of the difference between "shit happened" and "I am systemically making incorrect life choices".

I agree that what you need here is someone(s) with leverage and respect in your life to interfere with systemic bad behaviors if they exist, but that takes community, government merely gets leverage, and churches are often not a welcoming place to many people's eyes, rightly or wrongly, around the US.

As I get older, I'm increasingly of the opinion that the best you can do is unconditional support from the government (because it's the only kind you can rely on no humans in the chain acting in bad faith to condition), and well funded local support structures for people to subsist while fucking up their lives and also help them get out of that spiral if they want to.

Not because I believe in some fundamental good in man or something, but because I think that's the only way you can design this that isn't subject to people's bad faith manipulation, and I've personally seen too many cases go wildly differently for "objective" criteria where the main difference seemed to be whether the person reading it went into it assuming you were lying or not.

"The court said these are X" and "it is a fact that these are X" are distinct claims, and a lot of journalistic manners is pretending you never state as fact things that could be disputed.

Of course, since there are lots of ways to describe things in bad faith without ever breaking that rule, it can ring hollow once you lose trust...

I had a lot of use for this for a few years, there was a window where I had my first laptop's hard drive die a horrible death, but I could not afford a replacement.

Enter Knoppix and persisting any state I cared about on a thumb drive.

Of course, since RAM was so limited on devices, just installing packages and leaving the modifications taking up valuable RAM was inconvenient to do, so I went down a rabbit hole of customizing the image builds with various nonsense.

Useful dozens of other times before Ubuntu popularized live images just being a thing you supplied as table stakes, but that window of going down a customization rabbit hole and running a diskless laptop is what I remember.

My only contention is the word "quickly".

Employers past a certain scale are not really using degrees as anything other than a low pass filter, and the people judging how qualified hires were in practice are not the ones deciding the minimum requirements, so there's no avenue for feedback on that point.

I'm not convinced this is the correct move, if only because anything short of draconian control is going to be lossy, and draconian control has catastrophic failure modes for people who are naive to the things you're trying to help them not be overwhelmed by (see: abstinence-only sex ed).

There's no one-size-fits-all pitch, but my starting point would probably be time limits per day on a smart device, killing all notifications on it, and telling them that these things are because it has bad consequences if they don't have limits, so if you catch them getting around the limits, the privileges of such things will be temporarily or permanently removed.

I don't love it, but unless someone comes up with a wonder drug to dampen addictive effects of things in humans and we're all somehow convinced this is a great idea to give to everyone, all you can do is avoid the parts that are a race to the bottom of gamified attention and focus, until they're old enough that they hopefully have an informed opinion and are the ones making the choice to drink the poison chalice or not.

Last I looked at their releases of code, they had branched from ZFS before it became OpenZFS, and had a lot of proprietary extensions beyond just the reshaping (from memory, they implemented encryption differently, as one example, and I think they had one or two checksums that I assume were because something they shipped had hardware support for it?) so I wouldn't hold out hope that their goal is to rebase on OpenZFS unless they announce something to that effect.

AMD, historically, has taken a "we don't test enterprise features on consumer SKUs, but we don't fuse them off if you really want to qualify it or let them try it" approach to e.g. ECC on consumer chips with Zen.

So it's quite possible they were doing the same with TSME, and either made a rude marketing decision that the people using it on consumer chips would probably pay for PRO chips if they were prevented from doing so, or kept getting people attempting to RMA the chips for a feature they never said worked on them not working, or there's some systemic flaw in the consumer chip's implementation that they didn't feel like trying to qualify fixing versus just killing the not-guaranteed support.

Hard to guess without more data than just them going silent about it.

Apparently the recollection of the fix was that they deferred actually freeing memory for a while if they detected it was SimCity running. [1]

[1] - https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

They did, apparently, at one point pay someone to build that glue, and then threw it out and wouldn't let the author release it so he's been reimplementing it out of...spite? Burning desire? Unclear. [1]

I can't imagine the logic involved in "this is implemented, let's toss it in the dumpster" for that.

[1] - https://vosen.github.io/ZLUDA/blog/zludas-third-life/

Sure, I'm not suggesting that they're a good idea to use blindly at this point - I think most people are building on filesystem-based setups so most of the polish is going there.

But that was the original logic.

I also would be curious to see benchmarks for them on FBSD and Linux, because FBSD and Linux (the platforms at large) diverged in how they handle "disks", with FBSD opting for only character devices (unbuffered) and Linux only block devices (buffered).

Various ways.

Drives sometimes are worse at their internal error detection than you might hope, and might return incorrect bytes.

You might have faulty hardware flipping bits between when you computed a checksum/parity/etc over your data and when you wrote it out, either in memory, or over the wire.

You might have a software bug or an interaction with a hardware erratum that causes the CPU to misbehave and mangle your bits in certain cases, maybe around switching from running code in a VM to not and back.

You might have had, say, the Samsung HD204UI hard drive, which loses data after it tells the OS that it's written because of a bug around its write cache, so you get no error back, but you go to read the data back later and it's actually whatever was there before you tried overwriting it.

SSDs, NVMe and otherwise, _can_ fail in ways that aren't just vanishing from the bus, it's just much less common than with mechanical drives, IME. I have sometimes seen SSDs return incorrect bytes inconsistently or consistently, or start spitting up read/write errors rather than entirely vanishing from the bus.

Each of the above examples is a real thing I saw happen. None of them is particularly likely, plenty of people never have dumb shit like any of that come up. But it's not never.

The reason to use zvols is twofold, AFAIR:

- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance

- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage

Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...

But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.

I think the problem isn't that competition needs to be an order of magnitude better, it's that if places have exclusivity agreements, it doesn't matter how much better you are.

The comment in [1] also outlines a bunch of reasons it's extremely difficult to break into.

[1] - https://news.ycombinator.com/item?id=48452308

In this particular case, I think the point is less 1 or 2 but more point 3

(3) the contrapositive, where you continued the flight, it really was someone stupid enough to name the broadcast name of a bomb "BOMB", it goes off, and now you have to explain to the press "we thought nobody would be stupid enough to really name it 'BOMB'"

So you assume it's a low risk event, and tell everyone onboard to turn off their devices to remove the chance it's just someone making a bad joke or a coincidence, and then you end up with the outcome of trying to avoid having to say that in a press conference where everyone is already primed to think you didn't do enough.

Americans think they're "free and democratic" in the same way that aristocrats think they're better than everyone - it's been inculcated in them since birth, by every aspect of the culture and their upbringing, and as an axiomatic belief, it's not something they challenge.

There's nuance, of course, with people who are worse off in America seeing some cracks in it, but that's how you get the idiom about "Americans vote like temporarily inconvenienced millionaires" - they are so convinced the game isn't rigged against them that they vote assuming they will win at the casino one day.

My intuition is that what makes them well suited is that the transformations on the input desired are well-defined and frequent tasks - e.g. any other software that migrated from, say, SDL1 to SDL2, or had to move from gcc 3 to 4, or Sun cc to gcc, had to have these transformations in their source history.

IOW, "there is probably very little stopping you except time from having written Coccinelle patches to mechanically do most of these transformations".

Because most tasks aren't "refresh this code from 10-20 years ago"?

If you needed an old piece of code at $WORK, you probably already paid the tax of refreshing it or replacing it.

This sort of task is similar in nature to something like "I have a 25yo unmaintained Linux driver, let's refresh it for modern Linux" - a great demonstration of the efficacy of these tools if you have the right-shaped task, but not a task that comes up repeatedly in most people's days.

There exist a great many people in the world who think that the only important thing is having a good enough idea, and everything else is almost valueless by comparison. You've probably met them, people who say things like "I just need someone to code it, can you sign this NDA, what do you mean you want to be paid, it's just coding?"

They exist in other formats too - blogs in the vein of "for exposure" cover the same premise, mostly.

Vibe coding has allowed them all to try and show everyone how right they were.

How have you found syncthing's scaling?

I've been trying to use it for a massive tree of ~250k files across ~500k folders, which only needs to live on one device at a time and sync to a backup in case it dies, and even if I tell it send-only/receive-only explicitly, it regularly seems to go cross-eyed at some change made in the folder structure and give up and rescan and hash everything, and if anything in the tree changes while that's happening, it gives up and just marks it a conflict to be manually resolved...or silently hangs until I restart it.