It was completely fair, because other OSes don't expect users to directly access kernel interfaces, most of them even forbid it, other than for writing device drivers purposes.

How can it be "completely fair" when you're not comparing the same thing? Linux applications can and should use higher-level libraries too.

On the other hand it's possible to use Syscalls on macOS or Linux to try out new low level functions, since these tend to be documented quite well unlike on Windows. For instance copy-on-write or ptrace to alter/inspect low-level calls.

That is the low level version available to applications on Mac and Windows.

The high level ones are Mac Frameworks in Objective-C/Swift and .NET/COM libraries.

Direct kernel access is out of bounds.

Without getting into the specifics here, it's fair to compare linux kernal calls - sometimes - to windows api calls, because that's simply a technical detail, and in fact - that's just how those OS's expect you to communicate with the respective "OS" (whatever that even means; the linux kernel is hardly the whole OS). Calling the windows api's isn't calling some convenience wrappers, it is the api - the kernel api isn't (generally) public, and they try to avoid stability promises too, though, this being windows, I wouldn't be surprised if the kernel "internal" syscalls were nevertheless usually stable for legacy support reasons.

The original speaker is comparing two totally different layers of abstraction. That's not a technical detail when considering if the comparison is appropriate. It's simply misleading when higher level libraries are available and widely used in Linux.

On the other hand, whether the kernel interface is documented or not is a technical detail which simply doesn't matter in this context.

It's just not that simple. A kernel syscall just isn't an abstraction on windows, so if you want to compare the two, you need to include other OS APIs. Whether something is a syscall or not is a technical detail in the sense that it simply doesn't matter for it's actual function, but does matter for lots of non-functional concerns; possibly including api usability, performance, etc.

I don't know anything about the USB issue here, so I can't comment on that. But, typically, if you're looking for the closest equivalent to linux syscalls on windows, you're unavoidably going to be looking at non-kernelmode dll calls (which internally may or may not involve a kernel-mode syscall - that's a private implementation detail).

It's not a question choice of abstraction, simply of how the OS exposes low-level functionality (at least - it's the OS's choice, not yours).

The point being that if you reject any comparison of linux syscalls vs. window api calls then you effectively reject all comparisons between linux and windows apis. Fair enough; if you want - but it's not very helpful.

If you want to compare the capabilities of Linux and Windows systems, comparing Linux kernel APIs and Windows library APIs might make sense. However, complaining that dealing with the Linux kernel interface directly requires more work than calling Windows API functions doesn't make any sense, because of course higher-level interfaces are more pleasant to work with regardless of the target platform. If you want to make that comparison in a meaningful way, you should be comparing Linux libraries against equivalent Windows APIs.

To make it a bit more clear, libusb would be a closer comparison to the Windows/MacOS APIs OP is talking about being better.

Sure; nothing wrong with that comparison either - you're just not going to get a straightforwards apples to apples comparison. Unlike libusb, the windows api really is part of the OS; whereas libusb is a convenience library that - on windows - must use the lower level api; it's not a peer. Then again, there's no reason to care much about great convenience from a lowest-level api, so I'm not really sure what all the fuss is about: as long as the api isn't so wrong-headed to make good wrappers difficult or error prone, inconvenience seems like a fairly small price.

The same high level libraries are relatively bad when compared against the respective Objective-C and .NET/UWP high level libraries.

But then I guess it would be considered fair.

If that is indeed the case, then I would agree. But then, the "everything is a file" mantra, which the whole USB example was supposed to be about, doesn't become relevant anymore. It seems like an entirely different problem.

> It was completely fair, because other OSes don't expect users to directly access kernel interfaces

Neither does Linux or any other Unix or unix-like OS.

Google libusb, which can be used to access most usb devices from user space.

Guess the video author hasn't heard of it either?

He mentions libusb two minutes into the talk.

Linux doesn't expect you to either. You are free to choose.

Not to mention, I'm not sure I prefer the Windows version of the USB API anyhow.

Sure, you have to snprintf these details of the USB device, to construct a path. But... You also have a general purpose facility available to explore USB devices with, which only requires the general ability to navigate the file system.

I still remember writing systems for data acquisition via RS232 serial devices, and GPIB, on Windows 98, and using specialized drivers, which gave some magical API, and then moving to Linux..

When I realized I could just cat from /dev/ttyS0, and use ioctl to set baud rate and other parameters, it was incredible. And I could share a lot of the code for interfacing with GPIB which was also just a character device.