tobias3

Already there. E.g. https://github.com/guardianproject/libsqlfs but I'd also count something like s3ql where the data is stored as s3 objects.

There is e.g. [1] which doesn't paint a pretty picture.

I'd btw. put blame also on introducing tax incentives for diesel cars in the first place. Without those this wouldn't have happened. And those were to prevent tax arbitrage between European countries :/.

[1] https://www.econstor.eu/bitstream/10419/200596/1/1668020459....

More realistic is taxing it (increasingly tax what you don't like till it goes away, like Tobacco).

Problem is the milk price is connected to the meat price. Which makes half the supermarket more expensive through milk products. Maybe there is a technological solution to abort the bulls like we do for chickens nowadays and give the cows hormons for milk production.

Maybe they should have asked Brett Redfearn (former SEC director working at Coinbase) about the SECs reasoning. He left Coinbase in July? I guess the revolving door corruption failed (and/or he figured out where the wind is blowing)...

This is really all too transparent and obvious. A risk-free investment with 4% APY. What-aboutism about other exchanges (which are unregulated and off-shore). Not "understanding" the problems the "SEC" has (even though they have all the money to buy even former SEC directors knowledge about SEC procceses).

There is no difference in outcome. VAT is paid on every stage on inputs by companies BUT they claim it back and if the input comes from a different country they don't pay VAT in the first place. The only one not being able to claim it back is the consume, like a sales tax. It makes detecting fraud easier since you can see a companies input vs output vs profit.

I haven't used seaweedfs yet, but it looks better (and small file/object performance should be miles better). W.r.t. to fsync/durability with the seaweedfs API to a volume server you have to turn fsync on via paramter and it is disabled by default. With S3 it is probably also off by default and you can turn it on per bucket: https://github.com/chrislusf/seaweedfs/wiki/Path-Specific-Co... .

Both should default to fsync on, with the option to turn it off. So not a great choice of defaults. Again, it probably looks good in benchmarks when people naively compare S3 stores. But it just shouldn't eat your data per default.

Minio isn't durable. Any S3 operation might not be on disk after it is completed successfully. They had an environment variable MINIO_DRIVE_SYNC for a while that fixed some cases. Looking at the current code this setting is called MINIO_FS_OSYNC now (for some reason) https://github.com/minio/minio/pull/9581/commits/ce63c75575a... (but I wouldn't trust that... are they fsyncing directories correctly? Making sure object metadata gets deleted with the data in one transaction etc.). Totally undocumented, too.

I guess this makes minio "fast". But it might eat your data. Please use something like Ceph+RadosGW instead. It might be okay for running tests where durability isn't a requirement.

Then you had a different experience from me. Some teachers in e.g. elementary school forbade binding our loaned books with plastic and had us use paper instead even though that broke much too fast and we had to redo it all the time. This was in Germany.

Sure, if a technological solution like a vaccine gets developed I'd be optimistic (cold fusion?). But I currently estimate the probability of that really low.

What made me pessimistic about climate change w.r.t. COVID-19 was that most countries only did something once the population was sufficiently affected, even when the consequences of doing nothing were perfectly clear and immediate. W.r.t. climate change most countries won't be affected much or it will be hard to attribute to climate change and the consequences will be hard to predict and delayed.

COVID-19 was the easiest case of a global tragedy of the commons problem and we failed w.r.t. to a globally coordinated solution. Climate change is much harder. Doesn't give me much cause for optimism.

It's also single threaded, i.e. it can only handle one read/write request at a time (fuse can do more but ntfs-3g doesn't implement it). That has kind of acceptable performance with hard disks but with SSDs it is really slow.

ZFSOnLinux just ignores the O_DIRECT flag if I remember correctly. Granted, this is what btrfs should do by default as well since there is an ugly issue where software can modify the O_DIRECT buffer after it was submitted causing btrfs checksum errors even though nothing was corrupted (and there is nothing to be done about it except disabling O_DIRECT or creating a buffer copy).

So this comes up every time Windows comes up. I have a "Pro" version, went into Group Policy Editor and changed updates to require user action. This setting is supported by Microsoft and persists through updates. It only updates if I tell it to update.

Is that too hard to discover? Do you use a Home edition? (Obviously if you use any unsupported registry hacks it can revert to default behaviour any time...)

One could see this in action in the Hellwig vs VMWare court case (one of the few GPL court cases).

As a first step they had to show that Hellwig had made changes to code that VMWare uses that can be copyrighted. Especially difficult since every line in Linux is modified by a few different people. They failed at that and that ended the lawsuit if I remember correctly.

Game servers is an especially bad fit for AWS. They often need a high single core performance for many players + high simulation tick rate. They (mostly) don't need ECC RAM or reliable storage. They do need networking optimized for latency not throughput.

Another example is EA hosting all their Battlefield servers on AWS. Can't imagine what this is costing them for subpar performance (rumor is they had to deactivate their anti-cheat system fair fight to get acceptable performance).

Being good at writing servicable prose and story. Writing for a genre that has an online following (litrpg isekai in this case). Consistent output (e.g. twice per week -- in this case it is kind of insane: a novella per week). Then post it to sites where the readers for that niche are (e.g. royalroad.com , topwebfiction.com).

I don't know where she gets the idea that serial publishing isn't done currently. Pirateaba, creator of wanderinginn.com has 4342 patreons (10k per month at least). At that point who cares about the NYTimes bestselling list?

WaitOnAddress and co. But that one was added with Windows 8, so it can't take you back 20 years :)

The UK vaccinated old people first. At least here in Germany we had the problem that AstraZeneca was only allowed to be used with people <65. That could be one explanation.

I think the EMA press release is a better source: https://www.ema.europa.eu/en/news/covid-19-vaccine-astrazene...

Specifically it doesn't say "safe and effective", it says "benefits outweight risks" (BBC says that at well, but they removed that bit from the headline).

No, like io_uring which Linux got in 2019 and still doesn't cover everything yet (e.g. currently mkdirat() is being added). It also often falls back to a kernel-level thread pool, since many e.g. file systems don't implement async IO.

I've used C++ coroutines (with io_uring). They are really useful in this case and allows one to write code like one would with the simple blocking API. And from what I've read they are better than Rusts coroutines for this use case (and for the yield use case they aren't good).

It adds an additional foot-gun w.r.t. to e.g. by-reference parameters to functions and their lifetime. The function parameter might not be alive anymore after a "co_await" and it doesn't require any capture (like lambda) or has any hint about this being the case.

Then, the tooling isn't there yet (other than the missing standard library). Gdb doesn't show correct lines and can't print local variables when in coroutines. If there is a deadlock one can't see the suspended coroutine (and its call stack) holding the lock, etc.. Back to printf debugging...

Here in the EU, credit card transaction fees are capped at 0,3%. So no shenanigans, but cryptocurrencies would have to fall within this range as well.

Great development! I'm certainly all for this becoming the standard/default. Unfortunately for those relying on fsync() flushing the whole file system (which one shouldn't) syncfs() isn't a great replacement. Last time I tested that it didn't return errors on failure nor was it making certain all changes to the file system before syncfs() made it to disk.

Btrfs had this "fast fsync" for a while already btw. (out of necessity -- otherwise fsync would be even more unbearably slow on btrfs). This seemed to be difficult to implement (lots of corner cases). Every release there were "fast fsync" bug fixes such as e.g. https://lore.kernel.org/linux-btrfs/20200220132949.20571-1-f... https://lore.kernel.org/linux-btrfs/20200722112837.15516-1-f... . Let's hope the ext4 version of this has less initial issues.

My guess is this (compared to ZFS): With a CoW-file system like btrfs you have to problem that you need new file system space to delete something. This is problematic if the file system is full and you want to be able to write to it again by deleting something. ZFS solved this by just saying one can only fill a file system to 90% usage. At some point they even decreased this (during upgrade) and I had the issue that I couldn't write to the ZFS file system because this was lowered.

Btrfs tries to fully use the space and gets all the associated complexities. Additionally, because data/metadata ratio is not fixed one can get into situations where the file system is full and there is no more metadata space. For every action it needs to carefully check if there is enough space to actually perform the action even if the file system is nearly full. Improvements in this area caused this regression.

And no Rust wouldn't help. How often do you get a kernel Oops, dead lock or memory leak? Rust would help with those.

Yeah, the accounting is there, but not the actual transfer. I.e. you're not transferring the actual money to France, which the French finance ministry would then have to send back to the German one once it got it from the French company (in order for the German one to give it back to the company buying the product).

And the accounting is there because of tax fraud, I guess. And I also guess that the US has a similar accounting system where they have to report the amount purchased per tax bracket and the IDs of the companies they bought from.

If it works the same as in Germany you only pay no VAT if you buy from a company in another EU country as a company.

Therefore the EU has both a sales tax and a VAT depending on if you look at individual countries or the EU as a whole.

Intuitively one should be able to approach the max speed for sequential reads via some tuning (queue/read_ahead_kb) even with the traditional, blocking posix interface. This would require a large enough read-ahead and large enough buffer size. Not poisoning the page cache/manually managing the page cache is an orthogonal issue and only relevant for some applications (and the additional memory copy barely makes a difference in OPs post).

One advantage of using high level (Linux) kernel interfaces is that this "automatically" gets faster with newer Linux versions without a need of large application level changes. Maybe in a few years we'll have an extra cache layer, or it stores to persistent memory now. Linux will (slowly) improve and your application with it. This won't happen if it is specifically tuned for Direct I/O with Intel Optane in 2020.

But yeah, random IO is (currently) another issue, and as said the usual advice is to avoid them. And with the old API this still holds. If one currently wants fast random IO one needs to use io_uring/aio (with Direct-IO) or just live with the performance not being optimal and hope that the page cache does more good than bad (like Postgresql).

This is Paul Milgroms repsonse to this: http://www.auctionomics.com/wp-content/uploads/2020/06/Fact-...

... invent a conspiratorial narrative ... fabrications and accusations of corruption .. In the fashion of a flat earther...

I'm sorry but if you have to resort to such ad hominem attacks your defense is significantly devalued and someone must have hit a nerve.

It's underreported (or justifyably not being picked up by journalists). Capitalisn't podcast had an episode on it as well. This is the original article of the Microsoft guy: https://promarket.org/2020/05/28/how-market-design-economist...

Promarket has more articles as well.

Canned tomatoes are really interesting. They are a different variety of tomatoes (Roma tomatoes) that can be picked via machine. That's also why they taste differently. The automated picking is why they are cheaper (plus the variety is better for quantity). One wouldn't be able to sell the automatically picked tomatoes uncanned since their skin gets damaged.