This is a configuration declaration abstraction issue. Systemd timers and services are more like primitives.
In NixOS, we have an abstraction that allows simple declaration of a service and timer that runs some script.
As an example, I use this to export my paperless for backup daily in a way that is safe (paperless itself cannot run during that time, guaranteed by systemd) and simple:
I think I'd split that into two machines; a low power 24/7 server and a on-demand gaming machine. Performance and power savings don't go well together; high performance machines usually have quite high idle power consumption.
It'd also be more resilient; if you mess up your server, it won't take your gaming machine with it and vice versa.
putting all the components together to be a step up in complexity too, when compared to going pre-built. For someone who is comfortable with building their own PC I would definitely recommend doing that
I'd recommend that to someone who doesn't know how to build a PC because everyone should learn how to do it and doing it for the first time with low-cost and/or used hardware won't cause a great financial loss should you mess up.
Interesting. I suspect you must either have had really bad luck or be using faulty hardware.
In my broad summarising estimate, I only accounted for relatively modern disks like something made in the past 5 years or so. Drives from the 2000s or early 2010s could be significantly worse and I wouldn't be surprised. It sounds like to me your experience was with drives that are well over a decade old at this point.
As far as data security is concerned, JBOD/linear combination and RAID0 are the same
With RAID0, you always need the disks in sync because reads need to alternate. With JBOD, as long as your reads are distributed, only one disk at a time needs to be active for a given read and you can benefit from simultaneous reads on different disks
RAID0 will always have the performance characteristics of the slowest disk times the stripe width.
JBOD will have performance depending on the disk currently used. With sufficient load, it could theoretically max out all disks at once but that's extremely unlikely and, with that kind of load, you'd necessarily have a queue so deep that latency shoots to the moon; resulting in an unusable system.
Most importantly of all however is that you cannot control which device is used. This means you cannot rely on getting better perf than the slowest device because, with any IO operation, you might just hit the slowest device instead of the more performant drives and there's no way to predict which you'll get.
It goes further too because any given application is unlikely to have a workload that even distributes over all disks. In a classical JBOD, you'd need a working set of data that is greater than the size of the individual disks (which is highly unlikely) or lots of fragmentation (you really don't want that). This means the perf that you can actually rely on getting in a JBOD is the perf of the slowest disk, regardless of how many disks there are.
Perf of slowest disk number of disks > Perf of slowest disk.
QED.
You also assume that disk speeds are somehow vastly different whereas in reality, most modern hard drives perform very similarly.
Also nobody in their right mind would design a system that groups together disks with vastly different performance characteristics when performance is of any importance.
Soft wrapping plain-text is surprisingly hard to get right. It's better to just hard wrap your text when writing an email. Any half-decent text editor/mail client has a feature to automatically hard-wrap a paragraph for you for convenience.
Personally I went with an ITX build where I run everything in a Debian KVM/qemu host, including my fedora workstation as a vm with vfio passthrough of a usb controller and the dgpu. It was a lot of fun setting it up, but nothing I’d recommend for someone needing advice for their first homelab.
I feel like that has more to do with the complexity of solving your use-case in software rather than anything to do with the hardware. It'd be just as hard on a pre-built NAS as on a DIY build; though perhaps even worse on the pre-built due to shitty OS software.
If you had 80GB worth of websites that did something actually useful with it, you'd want Firefox to use it all.
I usually have dozens of tabs loaded due to usage and I want Firefox to keep all of them into memory so that I can switch between them quicker.
Though I do also want Firefox to shed load by unloading some of them whe I need memory for something else. There just simply isn't a mechanism in Linux to do that AFAIK; Firefox will happily keep all of its tabs loaded all the way until OOM eventhough it could shed most of them with little impact on user experience. There isn't a way for the kernel to ask applications to shed memory load on their own and I think there should be.
macOS has such a mechanism and Firefox uses it but it didn't have much effect IME, so it might have been bugged. That was a good while ago that I tested it though.
Edit: I just found out that there actually is a sort of standard mechanism now: https://systemd.io/MEMORY_PRESSURE/
I don't think firefox implements it but it's also kinda new.
Firefox can automatically discard tabs when available memory gets too short. You need to configure it to do that though and probably disable the 10min minimum open time too if you're very short on memory.
Atemu @ Atemu @lemmy.ml Posts 63Comments 1,439Joined 5 yr. ago
The OS is Android but "degoogled", so no Google espionage services or play store etc. It's quite nice actually.
I'm pretty sure you can flash the stock FP4 ROM too though.