magic_quotes

> "the Palestinians are child-like and easy to befriend"

You might want to provide the source for this. (The phrase is not directly googlable.)

Here you go: https://www.youtube.com/watch?v=IpA9DORDkeE.

> we're obviously looking at the earth's dark side

We are not. Why would we?

Pretty much, they are fundamentally both RPC flavors, so it's impossible for them to have different properties beyond more or less convenient tooling. It's always jarring to see those heated GraphQL vs REST APIs (as implemented in practice) vs gRPC discussions as if they are as different as, say, client-side CRDTs.

As a yet another filthy Russian, I don't understand all this eagerness to give people "traitor" (enemy of the people, 5th column and so on) labels. Especially since this is pretty much the favorite communist/putinist activity. This is not a healthy mindset. At some point we'll have to admit different people might have different opinions on running the country.

That would be the amd64 driver port: https://wiki.freebsd.org/NvidiaFeatureRequests. For comparison, the first x86_64 driver version for Linux seems to be 1.0-4499 (https://download.nvidia.com/XFree86/Linux-x86-64/1.0-4499/) from 2003-09-02.

> FreeBSD got closed NVIDIA graphics driver support about a decade after Linux

Ahem, https://cgit.freebsd.org/ports/commit/?id=94fc89fbfbc7cd8886...

> some game consoles used FreeBSD as a basis and had proprietary NVIDIA drivers written for them

You mean proprietary AMD drivers? (Only PlayStation 4 and 5 are based on FreeBSD.)

Java / OpenJDK never used semver in the first place. Also, large projects like Java have entire layers of different APIs, whose compatibility guaranties can't really be described with a single number, no matter what versioning scheme they use.

I'd like my OS being deterministic, thank you.

> You're just trying your hardest to hate.

Manipulative much? I don't hate you (well, so far), you aren't being attacked, I'm just noting what a few informed people here don't like about your video. No, they aren't trolls. And, yes, everyone has different level of tolerance to exaggerations, of course.

Have you seen the video? The author even goes as far as suggesting the technique might useful for (generating?) entire operating systems at https://www.youtube.com/watch?v=udPY5rQVoW0&t=853s. That's just wild.

> You don't remember when GTX 1080 Tis could be had on eBay for as cheap as $400-$450??

That's slightly above half of its retail price (when it was new) and roughly in the same ballpark as RTX 2070 MSRP. Is this really "dirt cheap"? Do you expect video cards to never depreciate then?

More to the point, I don't remember the market being saturated with used video cards in way that could put a dent in retail prices. They always seem to sell at comparable performance/$ ratio to new cards. I'm genuinely curious if I missed any trends.

> Remember a few years back when used mining cards flooded the market and you could get a decent GPU dirt cheap?

No, not at all. Any references?

There is no different paradigm. Both GraphQL and "REST" as it's usually implemented are RPC protocols. GraphQL just doesn't pretend it is not.

> Closed source GPU drivers are not ordinary drivers. They have a lot of quirks and workarounds for programs, especially games.

The quirks part is a bit of a meme. Mesa contains a few application-specific overrides here and there: https://github.com/mesa3d/mesa/blob/c62996796cc46f1a1406f365..., https://github.com/mesa3d/mesa/blob/a678ec9b8c057311ed7e9697.... The reason Linux drivers, including the one from Nvidia, have fewer quirks is simply that Linux has fewer 3d applications overall. Those quirks also reside in userspace driver parts and should not affect system stability.

> When you try to port these drivers as-is to another platforms, things get awry.

Again, quirks are a property of a relatively high-level userspace part of the driver. There is nothing hazardous about porting them.

> why is AMD able to ship more stable drivers?

Well, they don't — AMD drivers for new hardware famously take a few kernel releases to stabilize. (G)GP specifically noted their stability problem started only 5 months ago, which means at least that issue is not really systemic. The real differentiator here is handling of existing complaints: Linux has mailing lists, Mesa has a normal open for everyone bug tracker, while Nvidia has a user support forum, which they mostly ignore.

Nvidia is completely boring and predictable.

FSF isn't vehemently opposed to permissive licenses either (they are merely discouraged), but that is the argument GP decided to bring here.

> If zig were licensed GPL, the zig foundation would be able to sell permissive licenses to companies

That would be against the spirit of GPL, which is ideologically opposed to all proprietary software.

> If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver.

In fact it is. For Linux and FreeBSD Nvidia distributes exactly the same blob for compilation into nvidia.ko; the blobs for nvidia-modeset.ko are slightly different. (Don't take my word for it, download both drivers and compare kernel/nvidia/nv-kernel.o_binary with src/nvidia/nv-kernel.o.) Nothing is locked in the closed source part.

New cards are fully supported. Why do you think they aren't?

Native Linux stuff is not at all native for FreeBSD. If Nvidia suddenly decides to open their driver (to merge it into Linux), FreeBSD and Solaris support will be the first thing thrown out.

> impression they stopped maintaining the FreeBSD driver.

It's maintained while simultaneously not receiving any new features.

Personally, I think the put-down was quite on point. I don't see the point of flagging it, that just leaves the content to imagination.

> Even AMD is often supported in a better way, be it opensourced, or relying on their binary blob.

AMD binary blob? You mean that amdgpu-pro thing? That doesn't exist on FreeBSD.

> changes in driver's EULA to deny the usage of consumer-grade GPUs in VMs

Which changes? Where? I'm looking at said EULA right now and I don't see anything related.

Unfortunately, half-assed vendor support is still quite compelling compared to no vendor support.

You are conveniently forgetting Durov never was the owner of Vk. Nor does his person constitute the entire "board of directors" or whatever management they had.

> hostile takevoer of VK.com

"hostile takeover" = bought with money

Nah, not quite the same. Jail makes it easy to avoid calling FreeBSD binaries from the Linux process by accident. If you must mix-and-match commands, jail is exactly of zero help.

> people will just run the Linux version

Don't worry, there are more than enough stumbling blocks in Linux emulation to ensure it would never be as convenient as native applications. For example, if you pass LD_LIBRARY_PATH with FreeBSD libraries to the Linux program it will predictably blow up in your face. Now, imagine running a shell script which calls FreeBSD and Linux executables.

Linuxulator is really a method of last resort and it always requires special care for each individual application.

> could not find any reasonably practical way to verify the CD image PGP seal

There is no easy or obvious solution here. You can not verify anything PGP unless you can directly (!) obtain the public key from the person in question. So-called Web of Trust is a theoretical construct.

> Who wants to install an OS without being able to verify the image seal?

Well, for example, Ubuntu downloads (and checksums) were available exclusively over plain http until 2018 or so. Flavors are still http.