It seems that btrfs is being phased out of fedora. It looks like Fedora will be moving to stratis storage over the next year or two. Btrfs is nice but it's raid5/6 support still seems shaky and there's odd corner cases that apply to all btrfs setups (getting stuck when free space is low is mostly resolved but can still occur).
I no longer have the direct relationships with storage folks at Red Hat that I once did and that stuff may all be over on the IBM side anyway. Stratis (which I wasn't familiar with) does seem to be designed with the intention of bringing a lot of pooling etc. on top of a conventional file system but haven't really looked at or talked to anyone in the storage groups recently. Conventional LVM was pretty old and really designed for a different time.
I'm not super-plugged into Fedora these days. Red Hat has long been pretty comfortable with a more conventional file system (think it's still XFS out of SGI by default) plus volume management for RHEL. ZFS was a non-starter for licensing reasons and Oracle; btrfs just wasn't there. I suspect things could have played out differently had Oracle relicensed ZFS once upon a time but that ship has likely sailed in a variety of ways.
XFS is a default filesystem in a production system? Really?
XFS was dead to me 20 years ago. The only time I ever actually verifiably lost data to a system crash was on XFS. I had actual zero length files with XFS after a crash. Lost actual data. But the file system was in totally happy consistent metadata state. Never ever would I ever consider that filesystem ever again.
The ominous "reisserfs" everyone complained about? Never lost a single byte of data to it even when I pulled the plug in the middle of a write operation to test it. No issues with ext4, no experience with btrfs.
I vaguely know some of the backstory of moving off ext4 (as default). As I understood it at the time, it was less focused on some of the larger systems Red Hat was interested in.
If a founder is going to VCs or the markets in general for funding, there's no way to really do this. I don't see how the vast majority of founders can realistically expect others to fund their companies and still let the founder have the final say on all company matters.
If founders are willing to self-finance or finance based on cash-flow/collateral, that's a different story. But if you're selling majority stakes of your company's equity to others in order to finance your operations and growth, the equity owners should get a majority vote in how your company runs.
> I don't see how the vast majority of founders can realistically expect others to fund their companies and still let the founder have the final say on all company matters.
By not selling the controlling majority stake in their company, or retain super-voting rights. Anything to not give anyone the possibility to take their company from them.
And FB is a lesson to a lot of companies and the public not to allow the same dual class stock structure. Zuckerberg can cash out a lot of his equity and still be the controlling force behind FB even though other people "own" a majority stake of the stocks and equity.
Iran had a pretty strict P5 agreement under Obama that would have prevented Iran getting nukes for sanctions relief and other benefits. For some reason, a president decided to toss it for no apparent benefit.
Trump literally said a day or two ago that if Iran had nukes, he'd treat them a lot nicer and would cozy up to them like with China, Russia, and North Korea. Given that what government wouldn't serious consider obtaining nukes if only as a matter of survival?
The following wiki article has a section on it. Cluster munitions allow you to saturate areas and prevent infantry from advancing. The issue is that some of the submunitions malfunction and sit around on the ground and injury civilians (particularly children since they look like toys at times) https://en.wikipedia.org/wiki/Dual-purpose_improved_conventi...
Could be due to better control of blood sugar. E.g. lower blood sugar increases inflammation, decrease immune response and provides bacteria a readily available source of food.
More to the point for Guam and similar locations, canned and non-perishable food can are probably around and more can be airlifted in to get people through it. It was pretty much the standard back in the day.
The diet in Guam is already heavily dependent on shelf stable foods. I know this from personal experience but theres a surprising (to me) amount of research on it as well (c.v., https://www.guampedia.com/health-consequences-of-modern-diet...). However, it is worth noting that food on a military installation =/= food nearby, for many obvious and non obsvious reasons.
The dedup functionality in something like zfs or btrfs isn't all that great. It tends to be extremely memory hungry and to slow things down significantly. E.g. ZFS needs around 1-5GB of ram per TB of storage and writes need to be compared to a hash table to dedup properly.
Using hints or knowledge at the app level is a much better experience if the app can tell the FS that two files are identical. The FS doesn't have to worry about hashing blocks within the file, correcting alignments, etc.
Yes, but package managers are not that great either. Better keep them as simple as possible. And you don't have to do deduplication in an online fashion; you can do it overnight, if you want, as just a simple example.
Do you specific issues with uv that makes you distrust the implementation? Otherwise that reasoning is pretty weird - it's possible to write good software, even when the existing options aren't good. Why would we ask them to limit themselves to what might make sense for worse code?
You're missing the point. No normal user program can ever do what a filesystem can do: deduplicate in a way that is hidden for the user of the filesystem. Unless you want to change everything into a black box managed by the package manager, making everything confusing for users and also maintainers.
Why would the deduplication need to be hidden from the user? Why would everything need to become a blackbox?
Hardlinks have long been a well-documented feature of many file systems. I don't see how their use in a context users largely do not meddle with is too confusing or complicated.
Because why would you make everything more complicated if the file system can handle it just fine, plus you can automatically deduplicate other files that have nothing to do with package management?
Because (going by scheme271's numbers) I might not want to waste lots of expensive RAM on something or mess around with offline deduplication, when a less resource-intensive alternative is entirely sufficient for whatever my use case is.
Maybe it's because I've been recently playing around with deduplicating subtrees in a different domain, but I don't see what makes this feature too complex to be worth the cost. Sure, symlinks and hardlinks require some additional care compared to plain files, but it's easy enough to add tests for those cases.
Well uv runs on many systems and most don't have filesystem level dedupe configured, unfortunately.
Anyways it can be both? It could let the filesystem handle it if it detected the FS has file or block dedupe and fallback to hardlinks otherwise. It doesn't but that could be done if it showed it was worth it.
...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.
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.
The pause is for immigrant visas so most visas like H1 or H2 or O visas aren't affect this time. But it's definitely part of the US admin's overall theme of ratcheting up visa restrictions and making any immigration or travel to the US extremely difficult.
Not _this_ time but they were targeted previously: banning up to 75 countries from issuing visas, adding a $100k fee to the application, forcing visa renewals to go through consular processing instead of change of status, etc.
The end goal is to do end migration as a whole (especially from “certain places”) and expel all “undesirables”. To get there, they will test the waters, get the right precedents and judicial orders in place, and move the Overton window enough so the public sees these actions as “business as usual”.
Illegal immigration does not create queues or waitlists for legal immigration.
But I'll be honest: between the uncited numbers, the clear-eyed, neutral potted history, the italics, and the all-caps "LEGAL," I'm starting to think it would be foolish not to take your argument seriously.
This "they did bad stuff so we have to do worse stuff" idea strips the people doing the second bad thing of their agency. That's false; they have agency, and can choose to do better.
Immigration laws are like any other licensing or permitting regime. Controlling "who" and "how many" is the whole point. Making legal immigration easier doesn't solve the problem, it defeats the purpose.
The laws should produce friction but the right friction in the right places. There are too many arbitrary and difficult processes in the US immigration system that keep great people out of the US.
In other words, completely inaccessible to many people who would like a better life and are willing to work but lack opportunities in their native country.
Just because it was achievable for you doesn't mean it is achievable for everyone.
So? No one is entitled to immigrate to the US. It is very much supposed to not be achievable for literally everyone but only for those where it will be a net positive for the country.
And it's perfectly normal that the country where the most people want to immigrate to will also have higher barriers.
> And it's perfectly normal that the country where the most people want to immigrate to will also have higher barriers.
In my country, I've not heard a lot of people expressing the wish to visit, let alone immigrate to the US for quite some time now.
And as a reminder of what country we're all talking about here, that'd be the one with the highest number of school shootings in the world, and the least political action and drive to do anything material about it, because, you know, emotional neanderthals gotta have their guns.
What sheltered well off ideologues say in their bubbles is irrelevant when it comes to determining what country people from around the world want to immigrate to. Historically, the US has been THE country where people want to be and I have yet to see any evidence that that has changed. If people would no longer want to come to the US then these changes to the immigration policies would also not affect anyone.
There was another similar flood on the same river about a year or two ago. The problem was the the glacial flooding started in Tibet and affected people just over the border (one of the videos is from the border crossing). There's no international data sharing for this sort of thing between China and Nepal and Nepal can't deploy sensors in Tibet to give sufficient warning.
reply