1. 55

  2. 23

    It surprised me to learn that “#[cfg(unix)] was historically defined as #[cfg(not(windows))] so that having two configurations of #[cfg(windows)] and #[cfg(unix)] would “technically” cover all the targets.” Rust shouldn’t assume that all OSs in the universe are either Unix or Windows, and Fuchsia is as good a place as any to stop making that assumption.

    1. 21

      It used to, it doesn’t any more. Redox (OS written in Rust) support is upstream in Rust and Redox is marked as neither Unix nor Windows, as it should. The proposal here is to do the same to Fuchsia.

      1. 6

        Redox has no target_family:

        I laughed when I saw this. That’s awesome.

        1. 2

          If you interpret it as ‘POSIX-compliant’ vs ‘not POSIX-compliant’ it makes plenty of sense. Operating systems either conform to the portable operating system standard or they don’t.

          1. 12

            Why should you do that? There’s a lot more beyond just Unix or even POSIX if you insist on that. Assuming non-POSIX means Windows, Fuchsia, Redox and all the operating systems that have, do and shall exist are “basically the same” is peak *nix-arogance (along with calling it the portable operating system standard).

            1. 1

              And just because you implement a lot of POSIX doesn’t make you a POSIX system, especially if there’s key differences; i.e, VMS and i, which implement large swathes of POSIX but not fork, for example.

              1. -1

                peak *nix-arogance (along with calling it the portable operating system standard).

                It’s not arrogance any more than it’s arrogance to suggest a C compiler should conform to the C standard. Operating systems should conform to the operating system standard. If they don’t, they’re non-compliant, and that is its own category. That doesn’t mean they’re all the same.

                1. 19

                  C is a particular language and thus can have “the” standard for it. Operating systems are a category of software and POSIX is just one standard for them, it’s not “the” standard. Similar to how there is no standard for “programming languages” in general.

                  1. 4

                    That doesn’t mean they’re all the same.

                    My rust is rusty but from what I see cfg is something like #ifdef __unix__, #ifdef _WIN32, etc. If all the distinctions are “this is unix, so I can assume following behaviour” or “this isn’t unix” then there’s really not a lot you can do in the latter case.

                    But settings that aside, POSIX has an obvious *nix inclination. If I were to implement a totally different system like CLOSOS or a real-time, embedded OS, requiring it to “conform to ‘the’ operating system standard” would be absurd. What if I don’t want files or byte-stream pipes? What if I don’t want to use fork(2) for process creation? What if I don’t want the shell to be the primary UI/UX? What if I don’t want to use C? – There are so many possibilities what not-POSIX could look like, just like not-the number one has quite a few different variations.

                    This is all just even more absurd when considering that it obviously hasn’t been an issue to just add more operating systems to cfg. It’s an absolute non-issue.

                    1. 4

                      Fuchsia actually checks two of your lists. Fuchsia doesn’t use fork and doesn’t specify ABI in terms of C.

                2. 1

                  The linked article explains that Fuchsia is not POSIX-compliant and it never will be. So it makes sense to mark Fuchsia “not unix”.

                  1. 1

                    Yes, if anything the distinction should be ‘unix’ vs ‘not unix’ rather than ‘windows’ vs ‘not windows i.e. unix’.

              2. 10

                I’ve suggested the rust tag to this post because as far as I can the issue is internal to Rust.

                1. 3

                  I posted this for explanation of how Fuchsia is not unix from Fuchsia team, but okay. To summarize: no fork and exec, no child processes, no signal, no uid and gid, no unix filesystem permission, no global filesystem, no file descriptor, no C ABI, etc.

                  1. 3

                    Having ported C software to Fuchsia I can promise you it’s not UNIX.

                    1. 1

                      An issue for a specific language’s build processes is not the best forum for informing about an operating system’s internals.

                      Your title editorializes the issue title.

                      In the future: write a blog post summarizing the content (like in your reply to me), cite the issue as a source (ideally, look up more information about Fuschia and its goals), and submit that.

                      1. 2

                        Your title editorializes the issue title.

                        No, the issue title was edited, it was a joke initially but someone complained about the title not being descriptive enough :)

                        1. 1

                          So it has, I apologize to @sanxiyn for accusing them of editorializing the title.