Without questioning this idea on political grounds, I am not sure if it would be at all possible for an Ascend 910C cluster to enter the supercomputer rankings. I could not find a public datasheet on this chip (would appreciate a link), but my impression is that it is an AI accelerator that does not target FP64, whereas TOP500 is looking at HPC (FP64) performance [1].
Not the poster you've asked, but I think you might be interested in Mark Fisher's "What is Hauntology?" (10.1525/fq.2012.66.1.16). It argues the contemporary culture is incapable of coming up with genuinely new ideas because postmodernism and late capitalism constraint our imagination to the point where we can no longer imagine a wholly different system of politics and values. We're left with the upkeep of an already established system, and this is reflected in how the present crop of films and music mostly sample and rehash what's been done in the past century.
As a personal addendum, I feel this can be (partly) attributed to the loss of the Cold War's ideological struggle that drove the West to innovate, not just in technology but in societal structures and freedoms as well. This is why it can feel as if we've arrived at "the end of history", the current system has won, so what is left to seek or prove?
Even the Chinese Character Heroes competition mentioned in the article seems a lot like the spelling bee in the US, doesn't it? I wonder if the anecdote about the PhD students has a cultural dimension in addition to language proficiency — could the students have refused not because they don't know the characters, but because they aren't fully confident they wouldn't make a mistake?
The official specifications are more conservative than what is possible with memory overclock profiles like Intel XMP and AMD EXPO. The Phoenix tests show 285K at both DDR5-6400 and DDR5-8000. It is possible to go higher than the official 5600 MT/s with Zen 5 as well, but there is less headroom, with 6400 MT/s being the limit according to TPU [1].
This review is focused on Linux application performance, where Arrow Lake is generally strong. Compared to its predecessor, 14900K, it ends up both faster (barring some outliers) and significantly more power efficient. Compared to Zen 5, however, it is not as impressive: AMD's 9950X comes out ahead in both raw performance and perf-per-watt, especially in workloads that use AVX-512 like CPU inference. Still, 285K does have some wins in tests that can take advantage of its DDR5-8000 memory support, in some single-thread benchmarks like PyBench, and notably in code compilation.
In Windows reviews [1], 285K's performance is even worse, particularly in gaming tests where it is slower than 14900K and 7800X3D (and with AMD soon launching 9800X3D, the gap should become even bigger). Just like Zen 5 on its launch, Arrow Lake seems to suffer from scheduling issues. As the linked review notes, "When pairing Windows 24H2 with Arrow Lake, performance will be terrible—we've seen games running at 50% the FPS vs 23H2". So there's some hope for improvement with future updates, but overall the Windows scheduler looks beyond suboptimal for modern CPUs with complex topology.
What problems have you encountered on Fedora that were caused by a distro upgrade? Asking this because I've been using Fedora for years across different machines and can't recall any breakages that were direct consequences of an upgrade, though I usually apply it a month or two after the release date, so maybe there are early kinks that get resolved by that time.
Just to offer a different point of view, I see it as the opposite. I like a lot of things the KDE community is doing and I think it's particularly good at power user oriented apps like Krita and Kdenlive, which may be the best open-source tools in their respective areas and which don't really fit in the modern Gnome framework. As a desktop environment, however, I feel KDE is too visually chaotic to be usable. This post [1] illustrates some problems, but the lack of design cohesion permeates KDE and cannot be fixed without a long concerted effort. I imagine it's never been a priority because most users can shrug these inconsistencies off as something inconsequential, but for me (and I don't believe I'm alone in this) they're instantly noticeable and distracting eyesores.
Gnome has its own problems, but it is very visually consistent and clean, especially as of late when most of the standard apps are moved to GTK4/libadwaita. The GP's comparison of KDE being closer in spirit to Windows while Gnome to Mac is spot on IMO.
I have to use Windows at work, and one thing that hugely improves the experience is the "Everything" search tool [1]. It searches across all files you have in something like a second or two, and when you type it narrows down suggestions as you'd expect instead of randomly bringing up something completely unrelated. I even use it to launch programs I don't have pinned to the taskbar (it will find both .exes and .lnk shortcuts with readable names).
Compared to that, search
in the start menu (or Windows Explorer for that matter) is so comically bad it makes me weep. Before I knew about Everything, I could maybe believe there is something about NTFS or Windows security or whatever that makes it impossible to do fast quality search across the filesystem in modern Windows. But no, it's clearly possible, and it's such a shame that Microsoft is incapable of doing that in its own OS.
Text-based workflow has one significant advantage over GUI-based design: diffability. This enables patch-based collaboration: you can easily share your diff with others, review changes line-by-line, resolve conflicts between concurrent modifications, etc.
Personally, I'm much more comfortable working on large documents in LaTeX compared to Word because I can see every change I make and easily revise/revert it. It's too easy to unintentionally hit some shortcut or button in a WYSIWYG editor that subtly changes the document and not realize it until much later, when the undo stack is useless.
It's worth noting that AMD had worked with Microsoft on Zen-specific optimizations in the past, too. Ahead of the Zen 2 launch, they touted improvements of up to 15% from Windows scheduler changes for CPU topology awareness [1]. And with Zen 5 having higher cross-CCD communication latency than the previous generations [2], it probably gets an even harsher penalty from poor scheduling.
While the less-than-stellar reviews for the 9950X are already out, AMD's recent strategy of staggering releases for desktop parts (first the regular, then the X3D SKUs) can improve this generation's perception, assuming there are meaningful performance gains they can reach in software for Zen 5 prior to the X3D release.
If your typical workloads are covered by Phoronix tests, take a look at their energy consumption results. In LLVM compilation, for instance, 9950X does run at higher average power (188W vs 140W for 5950X), but because it finishes the task much faster, its energy consumption is actually lower at 58500 joules per run vs 78700 joules per run for 5950X, so it should be more efficient.
The 9950X seems more exciting than the last week's 9700X/9600X. It is comfortably ahead of the previous gen (including X3D) in code compilation and video/image processing, which I care about more than performance in games, and it's also in a class of its own in workloads heavy on AVX-512, though they might be a bit niche.
I think the TDP on the 9700X and 9600X may have been set a bit too low (in fact, there are indications it will be raised in a future BIOS update [1]), which led to a relatively cool reception from reviewers focused on raw performance. When looking at performance-per-watt in Phoronix tests, 9700X and 9600X often fare better than the bigger chips with higher TDP, but for desktops I guess efficiency is just not that big of a concern.
Glad to see I'm not the only one missing Google Inbox! I don't believe it was widely popular, at the time I may have been the only one in my circle to use it, but for me its workflow was just perfect. It gave you a clutter-free mailbox that surfaced the right things at the right time with very little manual fiddling, something I never managed to replicate with Gmail since.
The article might be overstating things, "hate" is strong word and not everyone outside the US shares the political reasons, but having a Google service you like end up axed is an experience more and more people can relate to. From Reader, to Inbox, to Play Music, to countless others, the company is oddly insistent on breaking things that just work and offering a subpar replacement (if one at all) that inevitably loses your data or requires manual transfer to fit how the other service is designed to work.
Apologies if I'm misreading your intention, but are you suggesting that Valve's work on Wine is somehow worse than asking game developers to target Linux/other OSes natively? As a Linux desktop enthusiast, I much prefer the Valve's approach: the library of existing Windows-only games that are unlikely to be ever ported is too vast, and the benefits of targeting a disjointed[1] platform with <2% market share[2] for new games are not at all clear. It's only thanks to Valve that I (and hopefully many other Linux users) do not need to maintain a second Windows system for fun, as the majority of games run perfectly fine on Linux and require nothing more than clicking Install then Play in the Steam client.
[1] Case in point: glibc's compatibility guarantees are weaker than what you get on Windows. (For instance, your system's glibc cannot be older than what a game is built against, which may present problems for devs using Fedora/Arch and players on Debian/LTS Ubuntu, something I've experienced first-hand for my apps.) The X11 to Wayland migration is also still underway. (Though things are getting better, the attitudes of some Wayland maintainers are a bit concerning: "I don't [care] what you think is normal behavior for games. You get certain guarantees with wayland. Deal with it. If clients decide to do exactly what they do on windows or X11 they won't work correctly." [3] I'm not sure game developers would enjoy such reception.)
Steam is also the reason Linux desktop is becoming more and more viable for everyday use (yes, including gaming) through Valve's involvement with Wine, Mesa, and other parts of the stack. As a consumer, I'm glad this is where the store's cut is going to, instead of perpetuating the Windows monopoly and lootbox gaming. Not to mention that Steam has tons of quality of life features that EGS still lacks: written reviews, discussions, gifts, I could go on and on... There are many reasons people prefer Steam besides its popularity. Epic had so much time and resources to improve their storefront and expand platform support, but they just don't seem to care.
I'm not sure I agree that "most people don't care about the stuff you (as a Linux user) would care about". Some people put up with Windows problems because they don't know it could be different, to them that's just how computers work. Take automatic updates for example. More than once have I heard from a friend how they lost unsaved work or an overnight render because their PC rebooted for updates. While on Linux months long uptimes are the norm, and you can trust it won't reboot on you out of blue. Same with ads and other Windows annoyances.
Other people are bound to Windows by their software needs. You're right that many important programs are just not available on Linux (to your Office example I'd also add the Adobe suite). But the end user experience of Windows itself has been downright abysmal for a long time now, and for casual users who don't need much besides Chrome and a couple other Electron apps, modern Linux desktop might genuinely be the better choice.
I love using Rust in my toy projects (and wish my job was more open to anything but C++, but oh well). With its functional-style iterators, sum types and pattern matching, Rust lets me write code in a way that just feels natural. And the borrow checker stopped bothering me once I embraced reference-counted pointers for those cases where lifetimes are not obvious. Compilation time also hasn't been much of an issue once I moved to using dylibs for dependencies [1]. So if you want to use Rust but are wary of those problems, don't be! :)
With that said, I can't help but feel that Rust development has noticeably slowed down over the years. Don't get me wrong, I appreciate the hard work behind each release! It's just that, from my totally uninformed bystander perspective, there's been a sharp drop in people working on the language and compiler full-time since around Mozilla layoffs, and Rust still hasn't recovered from that. It's surprising and quite disappointing to see no significant manpower commitment from other corporations using Rust, like Microsoft [2] and Google [3].
As a result, while there's definitely new exciting things happening, more and more issues are piling up, many sitting unaddressed for years. Granted, it's mostly the small things that you can live without, but they all add up. Here are some examples just off the top of my head:
1. If-let chains [4] and if-let guards [5], proposed back in 2018, are still not there. I constantly encounter cases where having them would make the code much shorter and clearer. I guess that depends on what you do, though. My code is heavy on state machines and pattern matching, otherwise this may be less of an issue.
2. Const generics are still very limited (no const trait impls [6], no enums as const generic parameters [7], no float arithmetic in const [8], etc.). I understand those are hard problems, but most are known for 3-5 years by now, and there's no finishing line in sight. Comparing const in Rust to constexpr in modern C++ will leave you disappointed.
There's definitely more problems that I hit less frequently, but each compiler error linking me to some stabilization issue with years-long discussion takes away a bit of joy...
And yet I heartily recommend trying out Rust if you haven't done so yet! Behind those papercuts hides a very practical and empowering language that gives you functional constructs at high performance and with much lower chance of shooting yourself in the foot as a newbie compared to C++.
GPUs do not have thousands of physical cores, though. What's called a "CUDA core" is essentially a programming slash marketing abstraction for a SIMD lane. A closer analogy to a CPU core would be a Streaming Multiprocessor (RTX 4090, for instance, has 128 of them). But that comparison is still moot, because GPUs are simply not designed for executing branchy scalar code. They'd be laughably slow at it, so outside of easily vectorizable code that already takes advantage of SIMD instructions, I don't see how you could offload any CPU tasks to a GPU.
Personally, I struggle to see what's good about unspecified-but-fixed-width integer types as in C/C++. A lot of real-world code I see uses uint32_t (sometimes typedef'd to u32) and the like to get predictable data layout and to avoid cute gotchas like long being 64-bit on x86_64 Linux but 32-bit on Windows.
I also like how Rust makes both signed and unsigned types equally easy to type, because I feel that a lot of people use signed integers where they should be using unsigned simply because it's easier to type "int" compared to "unsigned (int)". And if you absolutely need a machine word size dependent type in Rust, you do have usize, which is the equivalent of size_t.
The point, I believe, is not about Linux kernel but rather "Linux userland". I'm sure you could replace "iOS" with "Android" and the meaning will stay the same: smartphone OSes go to great lengths to isolate apps and prevent them from messing with the user's data, while desktop Linux does not.
I hope the situation will change once Flatpak becomes more widespread and polished. On paper, it offers a comparable experience to smartphones — you get sandboxing with granular permissions, easy installation without messing with the command line, and so on. In practice, I had enough issues with Flatpak apps breaking in non-obvious ways to make me not recommend it to others. As a recent example, I tried using a JetBrains IDE from a Flatpak and spent quite a bit of time diagnosing issues with paths before resorting to Google and finding out that it's not supposed to work at all (https://intellij-support.jetbrains.com/hc/en-us/community/po...).
[1] https://top500.org/resources/frequently-asked-questions/