> You can get cheap LSI PCI cards and do miniSAS to SATA if needed.
People say those generate a ton of heat because they're normally in a rack mounted server with plenty of airflow. Probably a significant drawback for a "cheap prebuilt PC".
jeffbee isn't offering any explanation, maybe because it's obvious to them they don't think they need to, or something like that... so I'll volunteer one.
If you send an email, your client would talk to your local MTA (i.e. the SMTP server you own or are authorised to relay mail through, e.g. ISP). The local MTA usally just accepts the email to insert it into a queue for attempting delivery. When your MTA processes the queue, and talks to another and gets 5xx or 4xx response, your MTA will generate a "bounce" (non-delivery report) email that lands in your inbox with the details of the response it received.
So jeffbee is correct that when the local MTA gets a 5xx or 4xx response code in the SMTP session with target MTA, that /the response code is not a bounce/. Microsoft responding with 5xx or 4xx in the SMTP session, they are not bouncing the email. They are refusing to accept delivery.
For Microsoft to "bounce every email" from the original parent commenter, it would have accept each email first, and then use the return path address of each email accepted to send a bounce email asynchronously, i.e. the bounce is not part of the original session.
If a MTA talks to another MTA who accepts a message for delivery, they can then bounce the email at any later point via the address specified in the return path header. Why? Maybe incoming email is queued and scanned, because it would take too long to determine if it passes secondary rules when it's initially being accepted.
Given how this works, you could take an email inbox you received a year ago, or five... and send an email with whatever content to the return path address, and you have "bounced" the original email.
Magical? Those are some rose tinted glasses. Having to install a binary blob from a free-software hostile vendor that wanted a monopoly to load a website was always ridiculous ask. Flash was a constant embarassment of RCEs vulns and virtually non-existent Linux support.
I have to wonder if some online stores have been drip selling stock, trying to sell at the top of the market. A few extra $k on thousands of units from a day-to-day price change is probably tempting for small pc part businesses.
The only thing I've found that's annoying with these POS/Office builds across various brands and models from 2013-2017 is the PSUs are less reliable and end up failing if you're doing more than just running excel and outlook. The OEM PSUs are often priced at ~25-70% of the value of the entire machine. I've seen some people end up cutting a hole in the case and bolt an ATX PSU to the exterior.
The only thing being added in this commit is the warning presented to users that they're at risk of instability, including data corruption with their current kernel as since 6.12, there is a new default configuration for scheduling behavior, which is worth paying attention to and so a valid concern. Debian trixie (stable) uses the 6.12 kernel for context.
ZFS is an out of tree filesystem, so one can not expect everything to go smoothly with kernel upgrades (it's recommended to hold kernel upgrades for production with ZFS, and test thoroughly, but here 6.12 is already a default for trixie), so this commit is a good road-sign to throw up infront of users to stop and think. Debian's opt-in usage stats (popcon) suggests that ZFS usage is a bit of niche, but I figured it is post worthy here, as some of us are in exactly that kind of niche.
> This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions, at the cost of slightly lower throughput.
> This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is under load.
It is possible to boot with preempt=none on 6.12, and on 6.13 preempt=lazy was introduced, where "the task gets one HZ tick time to yield itself" before being forced.
The video doesn't even have to load to know it's AI generated. The channel profile thumbnail and the video description are dead giveaways. The first frame of the video has too many errors to be worth repeating here. The first 0.5 seconds of the video has implausible movement.
The obfuscation hardware vendors do is so trivial, why do they even bother?
One of the current vendor provided consumer SSD firmware update utilities for Linux as a live-usb decrypts the firmware and writes it out to disk decrypted before uploading it, so simply using seccomp to fail a rmdir syscall nets you the decrypted version without having to reverse engineer any of the updater/decryption code.
I deleted my own negative rant about SSD manufacturers not opting in to lvfs/fwupd when drives have a high risk of bricking without firmware updates.
From people who have been using Linux since the 90s, the long term view is that nvidia has always been mostly fine since the early 2000s for hw acceleration if you didn't mind a binary blob. Yes, there have always been driver bugs - but that was never unique to a specific platform, i.e. nvidia on macos had opengl driver bugs that went unfixed for eternity until support was dropped, then the bug reports could be closed.
Comparatively the leading alternative was a dumpster fire of a broken mess for the longest time on Linux. All through the 2000s, ATi provided a binary blob driver known as fglrx which some people joked was a half-baked codebase from somemthing that started on HP-UX, passable enough for running sales demos and then was thrown at an intern to port it to Linux. If you went with ATi and tried to do much with foss opengl programs, you could expect daily or weekly kernel panics and performance that was <50% of that of the windows driver for an identical build. The solution was always to buy nvidia if you wanted stability.
Nothing has really changed for Nvidia on Linux, it still continues to perform adequetly. Plenty of people, including myself have used the binary blob for games and other 3D software with wine through the late 2000s, 2010s and proton in the 2020s without much comment because it works fine. The exception being that if you buy a used card, coming up on 10+ years old because your requirements are minimal - don't expect current driver support. Nvidia drop support for old cards on Windows too.
AMD is definitely night and day in terms of meeting the free software ecosystem properly, and so arguably the reason to go with a new AMD card is voting for that kind of support with your wallet.