NTFS is a beast of a filesystem and has been nothing but solid for 25+ years. The performance grievances ignore the warranties that NTFS offers vs many antiquated POSIX filesystems.
- mandatory byte-range locks enforced by the kernel
- explicit sharing modes
- guarantees around write ordering and durability
- safe delete-on-close
- first-class cache coherency contracts for networked access
POSIX aims for portability while NTFS/Win32 aims for explicit contracts and enforced behavior. For apps assuming POSIX semantics (e.g. git) NTFS feels rigid and weird. Coming the other way from NTFS, POSIX looks "optimistic" if not downright sloppy.
Of course ZFS et al. are more theoretically more robust than EXT4 but are still limited by the lowest common denominator POSIX API. Maybe you can detect that you're dealing with a ZFS backed volume and use extra ioctls to improve things but its still a messy business.
These are pretty much all about mandatory locking. Which giveth and taketh away in my experience. I’ve had substantially fewer weird file handling bugs in my Linux code than my Windows code. POSIX is very loosey-goosey in general, but Linux’s VFS system + ext4 has a much stronger model than the general POSIX guarantees.
`FILE_FLAG_DELETE_ON_CLOSE`’s equivalent on Posix is just rm. Windows doesn’t let you open new handles to `FILE_FLAG_DELETE_ON_CLOSE`ed files anyway, so it’s effectively the same. The inode will get deleted when the last file description is removed.
NFS is a disaster though, I’ll give you that one. Though mandatory locks on SMB shares hanging is also very aggravating in its own right.
Also to point out that outside UNIX, surviving mainframe and micros, the filesystems are closer to NTFS than UNIX world, in regards to what is enforced.
There is also the note that some of them are more database like, than classical filesystems.
Ah, and modern Windows also has Resilient File System (ReFS), which is used on Dev Drives.
It's not just about memory. I'd like to have a stable Rust ABI to make safe plugin systems. Large binaries could also be broken down into dynamic libraries and make rebuilds much faster at the cost of leaving some optimizations on the table. This could be done today with a semi stable versionned ABI. New app builds would be able to load older libraries.
The main problem with dynamic libraries is when they're shared at the system level. That we can do away with. But they're still very useful at the app level.
> I'd like to have a stable Rust ABI to make safe plugin systems
A stable ABI would allow making more robust Rust-Rust plugin systems, but I wouldn't consider that "safe"; dynamic linking is just fundamentally unsafe.
> Large binaries could also be broken down into dynamic libraries and make rebuilds much faster at the cost of leaving some optimizations on the table.
This can already be done within a single project by using the dylib crate type.
You could check that mangled symbols match, and have static tables with hashes of structs/enums to make sure layouts match. That should cover low level ABI (though you would still have to trust the compiler that generated the mangling and tables).
A significantly more thorny issue is to make sure any types with generics match, e.g. if I declare a struct with some generic and some concrete functions, and this struct also has private fields/methods, those private details (that are currently irrelevant for semver) would affect the ABI stability. And the tables mentioned in the previous paragraph might not be enough to ensure compatibility: a behaviour change could break how the data is interpreted.
So at minimum this would redefine what is a semver compatible change to be much more restricted, and it would be harder to have automated checks (like cargo-semverchecks performs). As a rust developer I would not want this.
Perfect frames is what Mac and Windows provide and what Linux should also aim for. Border tearing is a display bug, correctness should come first, Wayland's approach is right. X was designed for CPU and IO constraints that no longer apply. _Graceful_ degradation of slow UI should lower the frame rate, not compromise rendering of individual frames.
Well, exactly. Windows does try to provide perfect frames. If the display glitches, it's considered as bug rather than the momentarily acceptable degradation that OP was praising X for.
First, read up on Venezuela's oil. I don't think that's the case. At the very least it's very expensive oil, hard to use and very bad for engines, refineries and for the environment and also oil is over (meaning oil will go into terminal decline probably before 2028 and that will be the end of the oil companies)
Second, when the US did have Venezuela's oil things were going a lot better in Venezuela for the whole population. So would that really be such a bad thing?
Third, Chavez made things so bad in Venezuela it's tough to imagine this making it worse. Oh and then he died and Maduro came ... and made things worse.
> and also oil is over (meaning oil will go into terminal decline probably before 2028 and that will be the end of the oil companies)
Back in the 90s, my dad told me a quote from someone big in oil:
"Oil is too valuable to burn"
(Shah of Iran? Trouble with searching for quotes on the internet, they get misattributed a lot).
Oil as a fuel will, hopefully, be over soon. 2028 is… I think that's too soon, though it would be good if it was. But oil is useful for a lot more than just fuel, and engineered bacteria synthesising more is probably more like a 2030s thing than a 2028 thing.
You don't understand. 2028 is the time peak oil will definitely be behind us, and therefore the oil business will only deteriorate from that point forward. It will quickly mean the end of all oil producers except the very cheapest.
If you're going to go with conspiracy theories, China is desperate for oil and was openly allying with Venezuela, and so was, ironically, petrostate Russia, although that's ending (for now). I bet Putin is looking for contingency plans though. Even though Venezuela is not exactly the easiest to reach for either of them, but beggars can't be choosers. Preventing any progress here might have been worth a lot to both the US and the EU. And, yes, I know how it sounds, but this will be pretty helpful with the Ukraine war. Yes, really.
Of course leftist tankies will be mad the billionaire fake-communist "revolution" that started with Chavez and should have ended 20 years ago is now very likely over. Of course, most Venezuelans (75% according to the opposition) would describe that revolution as a nightmare.
Of course I doubt 75% of Venezuelans wanted the US to resolve it.
I seriously doubt either China or Russia could manage to extract significant quantities of Venezuelan oil at a profit even if the US lifted all sanctions and completely forgot about Venezuela.
The costs of getting production set up at are so high compared to the relatively bleak outlook for the oil market, it's likely that Venezuelan oil isn't a hugely attractive proposition for anyone.
China is desperate, and also the enemy of essentially every source of oil ... "except" Venezuela (disregarding the fact that of course Maduro can't be trusted, and thus isn't really an ally of China. More accurately they're both desperate and might be able to help one another).
Russia is also desperate. And is extracting oil in Venezuela easier than doing it while under Ukrainian bombardment? Good question but we can summarize: extracting oil inside Russia is failing, thanks to Putin's 3-day special military operation ... and they've already had to import fuel twice in the past 6 months, despite how utterly ridiculous that is: the country that out-produced Saudia Arabia when it comes to oil needed to import fuel.
China is moving away from oil at such a pace that any massive development of first the extraction technologies for Venezuela and then the actual infrastructure would probably take too long to be particularly useful.
Venezuela is also simply too far from China to be a reliable source of oil.
Yes because the only reason Chinese government officials would talk with Venezuela is because China wants to spin up large-scale oil production there? Literally no other reason they could possibly be talking, right?
And ... of course the answer here appears to be that I was right. About China, about the US, about most of what I said.
With a MAJOR exception: I expected Trump to think about things for 5 seconds before ordering people killed and kidnapped and ... If he did a good thing, it's pretty clear now that it's accidental.
As long as PCs wont ship with Linux preinstalled, the number of Steam installs will correlate heavily with sales of new PCs. Most new PC users wont even know that switching the OS is an option, let alone what advantages could this give them.
I would guess the Steam switch to Linux is mostly driven by the adoption of the Steam Deck.
JSON is used as config files and static resources all the time. These type of files really need comments. Preventing comments in JSON is punishing the wide majority to prevent a small minority from doing something stupid. But stupid gonna stupid, it's just condescending from Mister JSON to think he can do anything about it.
The problem is that packaged Java CLI utilities will also take 20MB+. The minimum size is still much too big for that class of programs. Also, AoT compilation was an absolute pain last I tried it, it's a big change for an ecosystem that was always designed as modular and dynamic. I love Java, but for CLI apps I'll take Rust whenever possible.
