• 0 Posts
  • 14 Comments
Joined 1 year ago
cake
Cake day: June 25th, 2023

help-circle





  • GNU wants people to believe that Linux distros took the GNU project, replaced the unfinished GNU Hurd kernel with Linux, and called it a day. But distros collected a lot of other stuff too.

    XFree86 and various window managers (back in the early 90s there were no free/open source desktop environments yet; KDE (1996) was the first I think, or at the very least earlier than Gnome. I don’t know what you mean by “And I’m not even getting into desktop environments.”: the way I see it, the topic X and everything running on it doesn’t exactly support your point.

    Editors vi and vim are not from GNU, and neither are mail clients Pine and Mutt, and the popular pager less.

    There was probably quite a lot of BSD code in Linux distributions too.

    So, I agree that calling a Linux distribution Linux is perhaps not entirely correct, but calling it GNU/Linux gives too much credit to GNU and too little to all the other people who wrote software that got included in Linux distros. GNU thinks their collection of software is essential enough to be included in the name, exclusively, and I don’t agree. Don’t get me wrong, GNU does deserve respect, and a lot of it, for all their accomplishments and contributions to the free source world in general and Linux distributions more specifically. But their insistence on the name GNU/Linux doesn’t seem the best way to get that respect. It has always felt somewhat childish to me.

    At the same time, no one is stopping the GNU project from creating their own operating system distribution using their userland tools and the Linux kernel, and calling it whatever they want, including GNU or GNU/Linux or GNU Guix System or whatever, I don’t care. It would be quite hypocrytical if they wouldn’t include Linux in the name though, since including Linux is equivalent to how they’re asking others to include GNU.


  • Arguably yes, but none of that is a good reason to put GNU in the name. I don’t think even Stallman argued that Linux distributions should use the name GNU to give credit to GNU’s influence.

    The reason always given is a different one: it’s because distros traditionally took a lot of code from the GNU project, which is a different matter. That reasoning does make some kind of sense, even though I don’t fully agree.



  • POSIX specifies the API available to programs, and also shell and commands and stuff available to users. It does not specify which functions should be available from the standard C library, and which should be available from the kernel: from the standpoint of POSIX, it’s all the same. POSIX doesn’t care how the API is implemented, just that it is implemented correctly.




  • I agree we should use operator overloading only when it really fits the use case. Especially the function call operator is easily misused.

    I don’t completely agree with Raymond Chen here though. Firstly I don’t think providing both an explicit Load() function and the function call operator is the solution. Just keep things simple and obvious: provide Load() and remove the function call operator.

    Secondly, why is StorageLoader even a class (or actually a struct here, but we know that’s the same thing in C++)? Unless Raymond is leaving out something essential, there is no state. Just make a function:

    template<typename DataType>
    LoadFromStorage(StorageOptions<DataType> const* options) {
        // ...
    }
    

    This solves all the problems: you can simply call it, even without operator overloading (because it’s already a function), and doesn’t make it awkward to specify the data type we need. We’re writing C++ here, not Java where everything has to be a class even if it doesn’t have any reason to be.


  • I agree we should use operator overloading only when it really fits the use case. Especially the function call operator is easily misused.

    I don’t completely agree with Raymond Chen here though. Firstly I don’t think providing both an explicit Load() function and the function call operator is the solution. Just keep things simple and obvious: provide Load() and remove the function call operator.

    Secondly, why is StorageLoader even a class (or actually a struct here, but we know that’s the same thing in C++)? Unless Raymond is leaving out something essential, there is no state. Just make a function:

    template<typename DataType> LoadFromStorage(StorageOptions<DataType> const* options) { // … }


  • I agree we should use operator overloading only when it really fits the use case. Especially the function call operator is easily misused.

    I don’t completely agree with Raymond Chen here though. Firstly I don’t think providing both an explicit Load() function and the function call operator is the solution. Just keep things simple and obvious: provide Load() and remove the function call operator.

    Secondly, why is StorageLoader even a class (or actually a struct here, but we know that’s the same thing in C++)? Unless Raymond is leaving out something essential, there is no state. Just make a function:

    template<typename DataType>
    LoadFromStorage(StorageOptions<DataType> const* options) {
        // ...
    }