nagaiaida
nagaiaida on Hacker News
did chromium become another type of fluorine while we all weren't looking or is this just a fun fact wholly unrelated to the bit about PFAS upthread?
running this the other direction it seems a touch odd to suggest my own instance's 6969 character limit is capable of conferring some amount of authority, but hey i'll take it
unless i misunderstand the implication as to their behavior on touchscreenful computers, this would seem to poorly address the concern upthread of explicitly expecting the touchscreen hardware, and thus the concomitant software annoyances, to become effectively unavoidable
railway guns go all the way back to the us civil war, but i suppose we can still quibble on locomotive there.
sure, i'm happy to recant my rather tepid defense of chainguard in the case that what was said upthread was a blatant fabrication. i'm even open to being convinced that it was.
as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.
what exactly is the point of maintaining coordinated disclosure even if one believes in it wholeheartedly in the case where the thing in question is under active exploitation already and there is no longer any hope of quietly solving the issue before active exploitation begins?
are we to somehow count the hypothetical future exploitees that may yet be helped by avoiding disclosure 1–1 against the actual literal current exploitees harmed by further postponing the fixes landing?
what possible reading of "I made the call to get these out early when exploits hit in the wild" contorts into "these exploits hit in the wild after i made the call to get these out early" with flipped causality?
this is basically how raku fixed perl regex
was this discussion not about apostrophes? but yes, different sets of pronouns work differently. more to the point, those different ways are not confusingly akin to contractions.
does your terminal on your laptop smoothly resize to match the same terminal session constrained by the screen dimensions of the phone you just opened it on so that you can monitor something from either? can you easily switch to a different terminal tab by name based on the output of something you just ran? can you have each ssh login pop open a new gui terminal tab you can later switch to interacting with locally?
"its" is precisely parallel to "hers" though?
having a base there at all would seem to embody an inherent concern as to the self-determination of such islands insofar as one wants to keep determining the fate of the base
changing what cursor actions prompt it to stop hiding
presumably somewhat more like nebula
maybe then we'll pin hashes instead of filenames, and oops now anybody can fork my/domain and hand out a link that looks official with whatever contents they wish
when people left their laptops unlocked, we used to wrap their sudo so that the output would be pre- and postfixed with ascii dolphins
phones let you type … effortlessly
would you care to share your interpretation of the function of the word "just" upthread? because that would appear to be the operative part doing the reducing that you've conveniently left out here.
potentially overly-aggressive spam filtering? the first comment by that account happens to start off with "The new $39.99 USD Anker Nano 45W(A121D) charger" verbatim.
mainly i just mean dataset configuration and arrangement within the filesystem in general as it pertains to whatever you're actually doing. if you can reliably send writes with different storage characteristics (deduplicability, compressibility, etc.) to different datasets configured accordingly, you don't have to deal with the drawbacks of trying to dedupe service logs or installed packages (which will just slowly inflate the dedupe tables for no real benefit) or compress media/encrypted files (admittedly you can usually just bail out early compressing so this side doesn't matter much but imagine the next really good compression algorithm can't fail fast for some reason). so as long as you only enable dedupe where it will actually help you because you designated a dataset for some highly duplicated purpose (and a bunch of transient writes won't harm you by growing the tables needlessly), there's really no reason not to go for it unless tight write latency constraints are also in play.
for instance, i have a pool with plenty of datasets that have dedupe off and only a crucial few with it enabled: the ones that are nfs-mounted media storage volumes for fediverse instance containers that would otherwise all duplicate all media they see in common, which is most media posted to any of them and a good bit of the remote media received by any of them. the size of the dedupe tables in memory is purely a function of the number of blocks written to those few datasets and i expect to either sunset this laptop from 2012 or migrate the pool to a fresh one long before i would be worried about the memory cost of deduplication swelling a few orders of magnitude to where i'd have to care.
> ZFS needs around 1-5GB of ram per TB of storage
...per unique TB written to datasets with deduplication enabled, of course, not the pool as a whole (even though that ram cost is indeed at the pool level).
there are plenty of useful things to be done with zfs dedupe at practically no cost if you design for it ahead of time. unfortunately for some reason people parachute into every thread where zfs comes up to say you can never ever turn it on, so people are taught not to even try.
if you don't trust something to survive an atomic filesystem snapshot, why would you trust it to survive sudden power loss?
well the good news is you can indeed already just have unified cpu/gpu memory on linux with an igpu on good old replaceable ram. i've done it on 8th gen intel stuff i picked up dirt cheap used. for the most part, running on the gpu wasn't faster (nor appreciably slower) than the cpu for the things i was doing, just more power efficient. overall bandwidth is relatively limited regardless which would be the bigger difference comparing against the m chips. and of course, good luck if you're hoping stuff like opencl support hasn't long ago been ripped out of whatever software you might perfectly reasonably expect to run this way today
you can just hash the metadata masking out the hash as all zeroes or anything similar to get around that, like header checksums that ostensibly include themselves
(to be clear, i have been on mastodon/fedi for coming up on a decade now and have no qualms about the way leaving or sunsetting an instance works. part of the magic imo is that old posts from long-dead instances regularly go around again)
how exactly do you propose someone looking to delete all of their old posts from a dead instance might obtain the exhaustive list of instances that have historically received their posts via a long indirect cascade of boosts to send these formal or informal deletion requests? an allowlist-federated instance obviously makes that far more tractable, and otherwise I could potentially see annoying paths to doing it anyway if i had been the admin and had every log ever sitting somewhere to trawl through, but in the case of a normal user whose instance is already gone and who doesn't have an ongoing relationship with the prior admin, this is hardly a realistic way to address that concern.
i've always thought one of git's strengths is offering robust aliasing and subcommand flexibility. why not spend three seconds making git have split too?
e in interactive mode lets you directly edit the patch line by line, so it depends how you count popping open an editor
somewhat relatedly, shell pipelining is very amenable to being massaged into (non stack-based) concatenative programming
dang, and here some us were doing it for free like suckers