biggestdecision

Client-API round trips matter, because the latency is very high. API-DB latency will be much lower, so the number of round trips there is less important. GraphQL allows you to query any nested structure in one Client-API round trip, but there may be many API-DB round trips per query.

Sure it's not a new concept. But on the web graphQL is the most prominent implementation of that concept.

You can roll your own version of the concept, but why bother when a perfectly serviceable one already exists? With already written client & server implementations in your language of choice?

Sure, it's possible to setup a REST api with those features (return full objects for fields rather than ID's, client specifies which fields to return in the query). But then you've basically just built a graphQL api. Any syntax you pick for allowing the client to specify which (nested) fields to return is going to look like a graphQL query. And using graphQL gives you some nice tools to use on the client side.

> Anybody suitably competent to pull off the technical side of the attack is likely to be able to spoof MAC addresses.

From reading the article, the technical side of the attacks seems to be illegitimately using an administrators password. There are no details of how the hacker obtained the password, perhaps they just glanced over the shoulder of the library staff member as they entered it?

This bug only applied to grub authentication, which isn't a widely used feature. And you could achieve the same result with boot from disk/USB if that is enabled.

The vuln doesn't give you access to the actual accounts on the computer.

I agree this would be positive. But the source only get's you halfway there though, you still need to actually be able to reproduce a compatible build system. And the longer ago the software was originally developed, the more challenging that becomes.

There are lot's of old projects out there relying on some ancient VS2003 installation. Same will happen with modern languages in a decade - code goes stale, and it get's more and more difficult to pull down the versions of software it was originally built with.

The biggest issue with CMake is how many libraries seem to have really low quality CMakeLists.txt's.

CMake is very easy to use, if you do things properly with targets. include_directories and link_libraries should never never ever be used, use target_include_directories and target_link_libraries instead. This way there is no need to mess about with shell script style variables for dependencies. But so many resources online explain to people how to do things the wrong way, and so their libs end up being a pain to build or depend on.

If you write standard compliant C, don't use platform specific headers, and use some kind of cross-platform build system (I can't recommend CMake enough here), it's easy to use C/C++ across platforms. UI/graphics is harder, but cross-platform solutions do exist here (Qt, GTK, WxWidgets, OpenGL).

Valve has been doing a lot of work here lately, they've essentially made Wine into a first party citizen of Steam (in the form of Proton). So Wine is stable & easy enough for non-tech users - at least for gaming purposes. But there isn't the equivalent for general software yet.

Wine Is Not an Emulator - but to run x86 Windows applications on an ARM Android device with Wine you will need to use emulation.

Wine is essentially just a userspace implementation of the Windows API. Outside of API functions & syscalls, the actual instructions of the application are still running on bare metal.

So much of C++'s value proposition is based off the fact that it has such strong legacy compatibility. It's a language that is used today by businesses who are risk averse. Deprecating parts of the standard will make C++ a much less attractive language for the people who make up the majority of it's current user base. You also can't deprecate anything required for C interop, like the preprocessor.