There is a team, not a sole dev.
I'm not saying everything is roses and rainbows, but this is FUD messaging being spread openly by the mbin dev team.
Kata1yst
joined 2 years ago
They put ads in.
But what if they don't need that many people working on Firefox? What if AI, VR, and Network programmers are fundamentally different in skills from a web browser programmer, and don't want to change their career trajectory?
What if, by not firing these people, Mozilla folds in 3 years and everyone ends up without a job?
Not every project makes 2x the money with 2x the people. It's the "Why can't 9 Mom's give birth in 1 month" problem. Hell most projects will slow down significantly with an influx like that.
Look, layoffs suck, but it's quid-pro-quo. Employees can leave at any time too. If a company isn't abusive or arbitrary with their layoff decisions, has decent layoff benefits, and doesn't refuse to give job recommendations, it's hard for me to hold it against the employer.
I've had great experiences with exactly one vendor of second hand disks.
Currently running 8x14TB in a striped & mirrored zpool.
Zettlr for technical writing into any format.
Obsidian for a second brain based on the molecular notes method. And yes, I've tried all of the FOSS alternatives. None are ready to replace Obsidian yet.
Wallabag for saving resources offline for easy and permanent reference.
Lunarvim for actually sitting down to work instead of fiddling with and optimizing my setup.
In my experience, nope. I tried so hard to use Logseq, but I had massive issues with speed, stability, and database corruption.
Really I think the root of the issue is their database. The database causes so many problems and makes their synchronization methods dirty hacks at best.
Agreed. Every generation is chock full of idiots, just basic math. Two generations ago this would have been an idiot blasting his boombox on the bus.
Really all I do is setup fail2ban on my very few external services, and then put all other access behind wireguard.
Logs are clean, I'm happy.
Yeah, you should be scrubbing weekly or monthly, depending on how often you are using the data. Scrub basically touches each file and checks the checksums and fixes any errors it finds proactively. Basically preventative maintenance.
https://manpages.ubuntu.com/manpages/jammy/man8/zpool-scrub.8.html
Set that up in a cron job and check zpool status periodically.
No dedup is good. LZ4 compression is good. RAM to disk ratio is generous.
Check your disk's sector size and vdev ashift. On modern multi-TB HDDs you generally have a block size of 4k and want ashift=12. This being set improperly can lead to massive write amplification which will hurt throughput.
https://www.high-availability.com/docs/ZFS-Tuning-Guide/
How about snapshots? Do you have a bunch of old ones? I highly recommend setting up a snapshot manager to prune snapshots to just a working set (monthly keep 1-2, weekly keep 4, daily keep 6 etc) https://github.com/jimsalterjrs/sanoid
And to parrot another insightful comment, I also recommend checking the disk health with SMART tests. In ZFS as a drive begins to fail the pool will get much slower as it constantly repairs the errors.
And most decent indexers these days.
Using automation software like the Arrs, dramatically improves the UX/UI, providing another layer of filtering too.
The cost for these things isn't terribly high. You can get three excellent indexers and a good provider for less than $12USD a month.
ZFS is a very robust choice for a NAS. Many people, myself included, as well as hundreds of businesses across the globe, have used ZFS at scale for over a decade.
Attack the problem. Check your system logs, htop, zpool status.
When was the last time you ran a zpool scrub? Is there a scrub, or other zfs operation in progress? How many snapshots do you have? How much RAM vs disk space? Are you using ZFS deduplication? Compression?
Yeah honestly no idea regarding moderation. But the codebase is maintained by a team.