Posts by ReaperX7

It's about time Intel, AMD dropped x86 games and turned to the real threat

Getting rid of X86 won't happen. Just stop with this ARM pipedream. You're making a fool of yourself. RISC CPUs simply do NOT have the same processing power and capabilities that CISC CPU do.

There's a reason they call x86 a CISC and it's because it can do complex integer set computing. It can perform complex mathematical and algebraic equations and calculations to run programs and applications with extreme precision and efficiency.

RISC is called Reduced Instruction Set Computing for a reason. It's NOT meant to process high level mathematics or operate with efficiency. It's a low power part for basic instruction sets for small form factor devices.

RISC has been attempted many times and every time it has tried to even begin to replace x86, it's been a complete failure. The Snapdragon X still can not emulate x86 within 65% efficiency in CPU instructions per cycle. Even the Just-In-Time Recompilers used by LLVM/Clang can run RISC code at 75%+ efficiency, and RPCS3 is a living statement to that.

X86 can emulate ARM at 75%+ if you look at BlueStacks.

SPARC is dead, IA64 is dead, PowerPC is barely relevant, the Motorola 68K is dead. The Ricoh 65c816/6502 is dead. Every attempt has failed. Because it simply can not be done.

X.org lone ranger rides to rescue multi-monitor refresh rates

X.org isn't dead, it's stable.

I don't understand how people think little to no development, outside of minor patches, means a project is dead...

Xorg has been stable for years now and requires very little maintenance. Multi-monitor technically was fine if you made a 10-monitor.conf file and set up everything properly. Adding code to help out the automated modesetting driver is fine though.

systemd 256.1: Now slightly less likely to delete /home

Honestly, this once again sets off my feelings against systemd adoption, and how this went under the radar for far too long. As much as I like the functionality of the systemd init and core management systems, this part feels like the old proverbial 1 step forward, but 2 steps back as far as how we as users have felt treated regarding systemd adoption and the rush there was to start using it.

The era of HDDs is dead and gone and now SSDs are everywhere and boot times as less of an importance. We need reliable software and having a feature/bug, or whatever you want to call it in Ubisoft terms, that can nuke data on this scale is never a good sign. Poorly documented features have no place in software, especially with anything running PID1, the foundation of the system. There was no excuse for this. Red Hat and Poeterring pushed this mess like a mad hatter onto every distribution they could. The real question is, how long had this been a problem? Day 1? Day 100? Day 10000? How long was this bad software in the system waiting to cause problems?

Open source versus Microsoft: The new rebellion begins

Open source has already won. Microsoft themselves is a major contributor to FOSS because it's profitable.

Windows to be fair, is dying slowly, and is on life support. As it is, Proton/Wine duplicates much of the functionality of win32api and DirectX API.

Microsoft, about fifteen years ago was looking to pull the plug on Windows with the infamous Singularity/Midori project. They know Windows is on borrowed time.

So to say there is still a battle between Microsoft and open source is a fallacy. The realm battle now is who will get the better win32api and how much longer proprietary software can survive.

Data-destroying defect found after OpenZFS 2.2.0 release

The specific use-cases where ZFS zpools are being corrupted is not even commonplace in normal usage scenarios if you actually READ the article.

Under traditional usage, ZFS zpools will be stable and secure, and will not suffer corruption.

This article is not meant for general usage scenarios in any way. So please do NOT spread FUD about ZFS or any software to entice a panic that isn't needed.