This is a pretty terrible comparison, suitable for those X-vs-Y websites. While on paper Go and Java have a lot in common, in practice their philosophies differs enough to produce different enough languages.
I've used both Java and Go and I can tell you, there is no right or wrong but they differ a lot in their ecosystem, tooling and in design patterns. I don't see myself going back to Java because of the virtual threads.
For sure it’s an intentional strategy to keep books cheap. And indirectly also to prevent any competitors from selling the same books at a higher price.
Meson generates Ninja files. At first, you were supposed to run ninja after Meson yourself but modern Meson support meson compile which calls ninja under the hood
Yup, and Wikipedia says it very clearly too. Thanks!
> In contrast to Make, Ninja lacks features such as string manipulation, as Ninja build files are not meant to be written by hand. Instead, a "build generator" should be used to generate Ninja build files. Gyp, CMake, Meson, and gn[9] are popular build management software tools which support creating build files for Ninja.
I don't remember all of the times I've encountered it but a couple of examples I remember are rustup with its 700 lines of shell script (although you can install rust normally of course) and pi hole with its whopping 2700 lines of shell script.
I wouldn't trust a shipping shell script with less than 200 lines just re: sanity checks.
Large shell script programming stinks. The person who wrote it probably swore off shell as soon as they were done. But it is portable and it isn't half the pain that packaging for several distros is.
All of these are at consumer level pricing, you can get 2TB of PCI-E 4 from Western Digital for £130 at the moment, usually about £180. The issue is sustained writes more than reads for consumer verses enterprise drives where the speed drops off due to a lack of SLC caching and lack of cooling and TLC/QLC which is slower for sustained writing.
The example given is very much a consumer level device and not a particularly quick one by today's standards. You can also expect much faster reads cached than that on a DDR5 system I suspect.
It should be noted that those SSD speeds are all protocol limits rather than NAND flash limits. ~7GB/s is literally the maximum speed PCIE4 can provide, likewise ~3.5GB/s for PCIE3 and ~500MB/s for SATA3.
Consumer SSDs are trash for sustained writes since they get their top speeds from cache and use slower NAND. Enterprise SSDs tend to have better write endurance, and faster NAND. I have a small Ceph cluster and as an example when I first bought SSDs for it I tried consumer Samsung 870 Evo's. They performed worse than spinning rust.
Consumer SSDs don't really use slower NAND; the QLC vs TLC ratio might be higher for the consumer SSD market than the enterprise SSD market, but a consumer TLC drive is using the same speed of NAND as an enterprise TLC drive (and likewise for QLC drives).
Enterprise SSDs only really have significantly higher endurance if you're looking at the top market segments where a drive is configured with much more spare area than consumer drives (ie. where a 1TiB drive has 800GB usable capacity rather than 960GB or 1000GB). Most of the discrepancy in write endurance ratings between mainstream consumer and mainstream enterprise drives comes from their respective write endurance ratings being calculated according to different criteria, and from consumer SSDs being given low-ball endurance ratings so that they don't cannibalize sales of enterprise drives.
Your poor Ceph performance with Samsung consumer SATA SSDs wasn't due to the NAND, but to the lack of power loss protection on the consumer SSDs leading to poor sync write performance.
If that had been true what you say then we wouldn't be able to saturate the PCIe 3.0 x4 bus with consumer NVMe SSD which we absolutely can. The biggest difference is in the durability as mentioned in the comment below.
Read speeds are similar between consumer and enterprise SSDs; they use the same flash and there's overlap with high-end consumer SSDs using the same controllers as entry-level and mid-range enterprise SSDs.
The main difference is in write performance: consumer SSDs use SLC caching to provide high burst write performance, while server SSDs usually don't and are optimized instead for consistent, sustainable write performance (for write streams of many GB).
Server SSDs also usually have power loss protection capacitors allowing them to safely buffer writes in RAM even when the host requests writes to be flushed to stable storage; consumer drives have to choose between lying to the host and buffering writes dangerously, or having abysmal write performance if the host is not okay with even a little bit of volatile write caching.
You are always welcome to use the opportunity and start a competing service in a fraction of the cost. Mastodon is indeed inefficient but you also pay a lot for peace of mind.
More to the point: the masto.host guy has been there working on making starting an instance accessible from early on. People don't seem to mind paying a little premium to support someone who's done a lot of work to jumpstart the fediverse. Starting a competing service might be easy from a technical aspect, but reputation counts for a lot here.
I'm using Firefox but if you are that paranoid you should be using Chrome. Firefox is a child play compared to Chrome in term of security (but not privacy).
As always, it's important to remember that people choice of messaging depends on network effect more than anything else.
But even without it, they are both E2E encrypted. Of course you could ship new code that send the messages unencrypted but it would be extremely risky for Meta and the government, depending on the target
Samsung DeX feels like a POC, sure it works and I've used it for about a week while my laptop was being repaired but it had lots of paper cuts, most applications were out of place, even some of their own.
