Avid Amoeba

@avidamoeba@lemmy.ca · Joined ⁨Jul⁩ ⁨2023⁩

Replying to @⁨Faceman2K23@discuss.tchncs.de⁩

This is true but it’s nice to have the whole app, data and database in one place, going together, snapshotted together, “backupable” together. It’s slower for sure. That said it can be reasonably fast with a large pool (more disks). With the magic of SSD cache, database reads fly and reads are the majority of the loads in my heads. In the future I would put root on ZFS as well and either do SSD cache or have root on ZFS SSD pool that gets send/recved regularly onto the spinning pool so it’s easy to restore when needed.

Replying to @⁨FiniteBanjo@feddit.online⁩

Wrong. Plenty of German large corpos helped Hitler come to power and made good money under him, and are prime brands these days. E.g. Agfa, BASF, Bayer and Sanofi. Our capitalists definitively do not want democracy. Plenty of them have said as much and their interests are aligned with autocracy. Democracy means taxes and regulations and they def don’t want either of those.

Replying to @⁨DeLancre@piefed.social⁩

A smart decision which the Americans are probably not gonna make would be to nationalize Micron once they become unviable for-profit business, in order to keep the competency and ability to make RAM, which is an essential economic input these days. Instead I think they’ll just let the CXMT gang buy them at that point, just like they’ve let that happen to so many important firms. That’s unless democratic socialism has taken enough control of the US political power.

Replying to @⁨avidamoeba@lemmy.ca⁩

This shit is so over. This gang ain’t gonna collude on price with Micron. They’re in for eating Micron. First its market share, then its IP by buying it for pennies on the dollar.

Especially pay attention to the CCP’s directive to share IP among RAM manufacturers. They appear to be looking at this problem as a supply shortage of an essential component for the rest of the economy, which it is. But that also means they aren’t playing for profit.

posted in Technology

Chinese CXMT to Match Micron's DRAM Manufacturing Capacity This Year

A particularly surprising discovery is that CXMT is constructing its cleanrooms—where the actual silicon is produced—in just around 12 months, whereas the rest of the DRAM manufacturing industry typically takes 21-24 months, nearly a full year longer.

Finally, the report notes that the Chinese government is encouraging CXMT to transfer its DRAM technology IP to other Chinese DRAM manufacturers such as JHICC, Swaysure, and YTMC’s subsidiary XMC. This initiative aims to alleviate memory shortages domestically before CAMT-designed DRAM enters other markets, such as the EU and possibly even the U.S.

www.techpowerup.com/350726/chinese-cxmt-to-match-microns-dram-manufacturing-capacity-this-year
TechPowerUpChinese CXMT to Match Micron's DRAM Manufacturing Capacity This YearChinese memory giant CXMT has been expanding its capacity so rapidly that the company is now able to compete with one of the largest memory manufacturers in the world—Micron. According to analysis from Citrini Research and their proprietary data, CXMT is projected to produce about 350,000 DRAM...

Replying to @⁨KairuByte@lemmy.dbzer0.com⁩

Thanks for the pointer. Checked, tried a couple others - they don’t know about it. They have some other non-random DNS records. AFAIK they can absolutely find it if they scan for all domains, but it’ll take forever if the name is randomly-generated and sufficiently long. Someone has to be determined to spend the resources. This doesn’t guard against that but against bots trying to fuck with the service at the port. I could move it to a wildcard though. There’s an overlap with another subdomain (they’re actually sub-subdomains and the first sub is common) but I could move that.

Replying to @⁨zr0@lemmy.dbzer0.com⁩

Thanks for looking into it. As far as I read they moved to an ORM with 10.11 as a prereq to supporting other db engines. I’m guessing the db connection code would be undergoing major changes when they do that so I wouldn’t rewrite the current implementation. I’d either follow that work and help them get it right or rework the implementation after they’re done. We’ll just suffer through the mean time. 😄

Replying to @⁨ragingHungryPanda@piefed.keyboardvagabond.com⁩

64K is generally small recordsize. For media they recommend 1M. My db was sitting on the default 128K recordsize and perforned fine on 10.10. It doesn’t matter much for reads because ZFS keeps it in RAM and if it gets evicted it goes into SSD cache (l2arc). But for writes the cache wouldn’t help unless I disable sync which risks data loss. I don’t think 10.10 did much writes during lib scan so write perf only mattered when something changed.

Replying to @⁨Carol2852@discuss.tchncs.de⁩

Not sure if this is the problem I was hitting with my Home Videos library type. It’s got directories with YouTube videos. I tried re-adding it in 12-rc3, which was released a month after the nightly mentioned in the issue thread. Still couldn’t complete. I ended up re-adding the media as Shows library. Works okay with the directory structure I have.

The write performance was recorded without the problematic library (deleted).