3 ms·

Not everything may be a file indeed, but I didn't get what he was trying to point out with the specific example he gave. To make his point, he compared the USB

Not everything may be a file indeed, but I didn't get what he was trying to point out with the specific example he gave. To make his point, he compared the USB APIs provided by Windows, macOS, and Linux. Then he went ranting about how Linux looks terrible because you had to manipulate files and use functions such as snprintf, ioctl, and fnctl. However, this is not at all a fair comparison because he was comparing the Linux kernel interface against much higher-level userspace library APIs in Windows and macOS. So what are the problems he encountered with this specific example, that had actually harmful consequences? I honestly can't tell.

pjmlp 7y ago
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.
- clktmr 7y ago
  Linux doesn't expect you to either. You are free to choose.
- soraminazuki 7y ago
  How can it be "completely fair" when you're not comparing the same thing? Linux applications can and should use higher-level libraries too.
  - pjmlp 7y ago
    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.
  - blablabla123 7y ago
    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.
  - emn13 7y ago
    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.
    - soraminazuki 7y ago
      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.
      - pjmlp 7y ago
        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.
        soraminazuki 7y ago
        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.
      - emn13 7y ago
        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.
- nottorp 7y ago
  Google libusb, which can be used to access most usb devices from user space. Guess the video author hasn't heard of it either?
  - fetbaffe 7y ago
    He mentions libusb two minutes into the talk.
- rumanator 7y ago
  > 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.
thedracle 7y ago
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.

pjmlp 7y ago

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.

clktmr 7y ago
Linux doesn't expect you to either. You are free to choose.
soraminazuki 7y ago
How can it be "completely fair" when you're not comparing the same thing? Linux applications can and should use higher-level libraries too.
- pjmlp 7y ago
  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.
- blablabla123 7y ago
  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.
- emn13 7y ago
  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.
  - soraminazuki 7y ago
    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.
    - pjmlp 7y ago
      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.
      - soraminazuki 7y ago
        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.
    - emn13 7y ago
      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.
nottorp 7y ago
Google libusb, which can be used to access most usb devices from user space. Guess the video author hasn't heard of it either?
- fetbaffe 7y ago
  He mentions libusb two minutes into the talk.
rumanator 7y ago
> 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.

thedracle 7y ago

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.