Except it does not work that way in the US, you can freely incorporate in any state without worrying about this kind of tax drama. The EU really needs to improve the integration of their single market, as this is precisely the kind of barrier preventing people from exploring what other EU states have to offer.
It does not need to be all or nothing though. It simply needs to be true for a large enough number of people, to create an extremely valuable market.
We are over 8 billion on earth, even if as little as 1% of the population rely on it directly or indirectly due to some form of oppression real or perceived due to political opinions, a long investment thesis on bitcoin can make sense.
I am not a bitcoin holder once this is said. Arrived at the party too late IMHO, and i have better investment options for now from a risk-adjusted perspective.
However if i had more cash to invest than i know what to do with, i'd definitely take a long position on bitcoin.
I think you are making a big deal out of nothing: today adoption is tiny but there isn't any coordination problem. Anyone wanting to buy or sell bitcoins, even for very large amount has no problem doing so.
As adoption increases, liquidity (which may be what you allude to when you talk about coordination) will be even better.
I'd also note that facilitating liquity can indeed be a complex problem, but there are people specialized in making money out of it and who therefore have an incentive to continually keep the market liquid, read about "market makers".
The key thing is that on freebsd you do not risk bricking your system by installing a port. Even though this guarantee has become less true with PkgBase
> The key thing is that on freebsd you do not risk bricking your system by installing a port
What specifically are you trying to cite here? Which package can I install on Debian or Fedora or whatever that "bricks the system"? Genuinely curious to know.
I was referring to the need to be careful to not modify/update packages also used by the base system. Since all packages are treated the same on Linux, you often can't tell which package can put you in trouble if you update it along with the dependencies it drags with it.
This kind of problem happens frequently when users add repositories such as Packman on Linux providing dependencies versions different from the ones used by the base system of the distro.
Experienced people know how to avoid these mistakes, but this whole class of problem does not exist on FreeBSD.
> Since all packages are treated the same on Linux
This is no longer the case in "immutable" distros such as Bluefin/Aurora, which uses ostree for the "base" distro, while most other user packages are installed with homebrew. Nix and Guix solve it in a very different way. Then there's flatpak and snap.
A lot of poor *BSD advocacy likes to deride Linux for its diversity one moment, then switch to treating it as a monolith when it's convenient. It's a minority of the users for sure, but they naturally make an outsized share of the noise.
Done the same since 2018 circa, never looked back.
For a while even used it on the desktop, but was too much trouble due to specific tools we need that weren't supported properly. so we're using Linux on the desktop.
FreeBSD is stable, lightweight, gets out of the way, and without drama.
What you are looking for is called F#. You get native interop with C# and access to all .NET/C# libraries as a bonus. We use it as a daily driver for a complex B2B2C cloud platform.
Yes you are right, it does not properly support NativeAOT yet.
But it isn't a need for most use cases, unless you want to do mobile development and meet app store policies. But even then, mature F# frameworks like Fable transpile your F# code to React & Cie.
Since storage is a critical component, I closely watched it and engaged with the project for about 2 years circa as i contemplated adding it to our project, but the project is still immature from a reliability perspective in my opinion.
No test suite, plenty of regressions, and data loss bugs on core code paths that should have been battled tested after so many years. There are many moving parts, which is both its strength and its weakness as anything can break - and does break. Even Erasure Coding/Decoding has had problems, but a guy from Proton has contributed a lot of fixes in this area lately.
One of the big positive in my opinion, is the maintainer. He is an extremely friendly and responsive gentleman. Seaweedfs is also the most lightweight storage system you can find, and it is extremely easy to set up, and can run on servers with very little hardware resources.
Many people are happy with it, but you'd better be ready to understand their file format to fix corruption issues by hand. As far as i am concerned, i realized that after watching all these bugs, the idea of using seaweedfs was causing me more anxiety than peace of mind. Since we didn't need to store billions of files yet, not even millions, we went with creating a file storage API in ASP.NET Core in 1 or 2 hours, hosted on a VPS, that we can replicate using rsync without problem. Since i made this decision, i have peace of mind and no longer think about my storage system. Simplicity is often better, and OSes have long been optimized to cache and serve files natively.
If you are not interested in contributing fixes and digging into the file format when a problem occurs, and if your data is important to you, unless you operate at the billions of files scalability tier Seaweedfs shines at, i'd suggest rolling your own boring storage system.
reply