qalmakka

Seems like the "Theseus' ship" approach to RIIR worked wonders compared to a full rewrite.

Yeah but it made literally zero sense to write GObject in C. They've reimplemented inheritance and the like with macro BS while the GNU project literally had both a C++ and Objective-C compiler - Objective-C warts and all was a perfect fit for GObject.

C++, especially before C++11, was a total mess. Even today, it's super easy to shoot yourself in the foot and you literally can't learn the entirety of the language due to how massive it is. This still doesn't justify doing the absurdity of macro magic and garbage I've seen people pumping out in C over the years though.

IMHO if you deliberately use C it's because you want to keep things simple. Sometimes C++ will inevitably lead to overcomplicated designs nobody needs; there's a reason why 90's C++ feels massively outdated, while 90's C is still (mostly) accessible. C is a great way to keep the urge people have to shovel in OOP even when it doesn't really make sense. When I see some bullshit C++ code at work, I often think, "if people had to write this in C, they wouldn't have overthought this this much"...

My 2 cents is that there was a Java craze back in the '90s that basically infected all code designed in that time period, and that's how we got some very weird nonsense that in hindsight was poorly thought out. Just look at stuff like GTK+ and GObject...

Don't worry, as soon as this becomes production grade enough to justify buying less Mac Minis in data centres, Apple with shut it down faster than the speed of light. They could have done this themselves if they wanted, the reasons were never technical to begin with

Macs in CI are an absolute nightmare. For some reason (well, I do have a reason, they want to sell you more Mac Minis) macOS is the only modern OS that has no real container solution builtin. Windows has Docker and true containers, FreeBSD has jails, Linux has a bajillion solutions, Darwin (macOS)? Nothing. They've ripped half of FreeBSD already, just pull jails too!

Very nice! If only Adobe did Linux builds, that would be great.

Yeah, but XFS has literally a fifth of the functionality ZFS has. If you need ZFS features you're basically forced to pick between ZFS or Btrfs, the former being vastly more stable.

> I like to make silly things, and I also like to put in minimal effort for those silly things

Saying that and then use Rust is like saying, "I want hassle-free driving, that's why I drive a car with a 7-speed manual shift".

If you want a full-auto, then use it. "Minimal effort" is the reason why people wrote garbage collectors in the first place.

If Linux drops BCacheFS, it's dead. Let's be honest, nobody would be using anything but ZFS if it was in tree - not having it first-party is what keeps Btrfs alive. If you have to install it from external sources than you're probably better off simply installing ZFS to begin with.

Jesus Christ. I hope they can reconcile, because Linux _really_ needs a good, modern filesystem that's not a hassle to use. ZFS would be it but licencing stops it from being mainline, so it's always a pain to boot from it. Btrfs, well, is a lost cause. Linux needs BCacheFS TBH, so I think they should compromise somehow.

It's a long story. Basically it's become more and more GNOME specific, up to a point where it has become increasingly complex to use it outside of GNOME. Also migrating from one version to another is vastly harder than Qt, see how lots of applications and environments are still stuck on GTK+ 2 or 3.

On the other hand, Qt is completely independent from KDE and it's easy to use KDE frameworks in non-KDE apps.

Given how hostile GTK+ has become for anything that is not a GNOME application I'm surprised that this hasn't become the norm yet.

Also Qt makes it way easier to port applications to other platforms.

Why are patent trolls allowed to exist? A company that only holds patents and does no productive job with them (research, production, ...) should not be allowed to exist. It stifles development and innovation for the short-lived monetary gain of a few people.

GCC nested functions are atrocious and deserve being banned from existence. Like the article rightfully says they've been implemented using weird hacks that make basically impossible to use them safely. There's a reason why Clang has categorically refused to implement them.

std::regex has such horrible performance that it's probably better not to use it even in C++.

> C++ is relatively easy to read

Only if you suffer from a very high level of stockholm syndrome, that is. Rust's syntax is vastly clearer than C++ in basically all circumstances.

> The guy even admits it as well with his repeated "please don't actually use this in production" style messages - it's hard to give a greater indication than this that the code isn't yet ready for stable.

True that, and yet the kernel has zero issues keeping Btrfs around even though it's been eating people data since 2010. Kent Overstreet sure is naive at times, but I just can't not sneer at the irony that an experimental filesystem is arguably better than a 15-years old one that's been in the Linux kernel for more than a decade.

My 2 cents: these are the types of people that actually get the job done. All good software in my experience starts thanks to overachieving human representations of Pareto's law - people that can do alone in months what a team of average-skilled developers do in years.

In this industry it's very, very easy to run in circle, keeping doing stuff over stuff without realising you are in a bikeshedding loop, you're overengineering or simply wasting time. We need people that want to just push forward and assume the responsibility of anything that breaks, otherwise I'm sure that in 30 years we'd all still be using the same stuff we've always used because it's just human nature to stick with what we know works, quirks and all.

People that complain about Rust's syntax never have never seen C++ at its worst

Isn't this basically what `bubblewrap` already does?

leaving aside that most anticheats are useless and constantly teetering on the thin line between legitimate software and malware, not enabling anti-cheat solutions that support Linux on Linux is really an asshole move that almost definitely stems from an unmotivated or ideological hostility to Linux in general (I'm specifically referring to Tim Sweeney here).

Well, CL.EXE works pretty well on Wine too.... It _technically_ breaks a few terms of the EULA, but that's not too bad though.

This works pretty well: https://github.com/mstorsjo/msvc-wine

Use it alongside something like this CMake toolchain file:

set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR amd64)

    set(CMAKE_C_COMPILER cl)
    set(CMAKE_CXX_COMPILER cl)
    set(CMAKE_AR lib)
    set(CMAKE_LINKER link)
    set(CMAKE_MT mt)

    set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
    set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
    set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
    set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

after adding the various scripts to path.

If you want to speed up a little you can use `clang-cl` with the MSVC libraries, and it will work fine too.

I'm sick and tired of people expecting non-standard behaviour from C/C++ compilers when there are long estabished standards that clearly state what is allowed and what is not. If you are writing something like Unreal Engine and you resort on UB to get all of the performance you can get without writing assembly, then you also need to know you'll have to commit to a certain version of a certain compiler if you want a deterministic behaviour.

ZFS is just too convenient, IMHO:

- ZStandard compression is a performance boost on crappy spinning rust

- Snapshots are amazing, and I love being able to quickly send and store them using send and receive

- I like not having to partition the disk at all, and still be able to have multiple datasets that share the same underlying storage. LVM2 has way too many downsides for me to still consider it, like the fact that thin provisioning was quite problematic (i.e. ext4 and the like have no idea they're thin provisioned, ...)

- I like not having to bother with fstab anymore. I have all of my (complex) datasets under multiple boot roots, and I can mount pools from a live with an altroot and immediately get all directories properly mounted

- AFAIK only ZFS and Btrfs support checksums out of the box. I hate the fact that most FS can in fact bitrot and silently corrupt files. With ZFS and Btrfs in theory you can't easily restore your data, but at least you'll know if it got corrupted and restore it from a backup

- I like ZVOL; I appreciate being able to use them as sparse disks for VMs that can be easily mounted without using loopback devices (you get all partitions under /dev/zvol/pool/zvol-partN)

- If you have a lot of RAM,the ZFS ARC can speed up things a lot. ZFS is somewhat slower most of the time than "simpler" FS, but with 10+ GB availble to ARC it's been faster in my experience than any other FS

I do use "classic" filesystems for other applications, like random USB disks and stuff. I just prefer ZFS because the feature set is so good and it's been nothing but stable in day to day use. I've literally had ZERO issues with it in 8+ years - even when using the -git version it's way more stable than Btrfs ever was.

Btrfs is still unacceptably less reliable than ZFS, after _decades_ of development. This is unacceptable, IMHO. I've lost so much data due to btrfs corruption issues that I've (almost) stopped to use it completely nowadays. It's better to fight to keep the damned OpenZFS modules up to date and get an actual _reliable_ system instead of accepting the risk again.

> we all just wanted java with JIT

Java was literally the thing that made the term "JIT" popular, so I really don't know what you were going for here.

Also I just can't see how Typescript is in any way "closer" to Java - it's incredibly different IMHO. The only thing they have in common is probably the "Javascript" misnomer and the fact both support imperative programming, but that's it.

> Microsoft did not "cut off most of its QA"

Windows RTMs used to be shipped in a usable state (albeit buggy) for more than a decade. You installed it from a CD and it worked fine, you installed patches every once in a while from a random Service Pack CD you got from somewhere.

Modern Windows has had the habit of being so buggy after release in such horrendous ways that I can't imagine being able to use the same install CD for years. This is definitely putting less attention to detail in my view.

> You mean don't install Steam nor the Epic Store, nor many of the games.

...would you install Steam on a POS machine? Is your gaming PC a "mission critical system"?

I also had Windows Update fucking up my VMs and physical installs multiple times - this stuff just happens _with desktop machines, on desktop OSes_. The point is, lots of companies are using random cheap x86 computers with Windows desktop for mission critical appliances and systems, which is nonsensical. The rule of thumb has always been, do not put Windows (client) on anything you can't format on a short notice at any time. Guess people just never learn

In my comment I was referring to mission critical systems, which most definitely you don't put on cheap commodity hardware you buy in a brick and mortar store.

Linux is used EVERYWHERE for a reason. Most car HUD now run on some form of Linux embedded, like basically all embedded and low power devices. The problem here is that people still put embedded mission critical systems on a desktop OS and slap desktop software on it, which is _a bad choice_.