A few drawings about Linux

I opened LibreOffice Calc and pasted spreadsheet it into Writer window without a problem. :-/ I even able to edit it.

It doesn't have to. A text editor could easily present its current buffer and other properties in the form of a file system interface. See e.g. how Linux allows to interact with processes through the /proc file system.

There's no reason to restrict this to kernel objects. FUSE also allows user processes to implement a file system but it's clunky as it breaks a lot of old assumptions.

See the Plan 9 operating system for an earlier clean implementation of this concept, including programmatic interaction with your text editor through file APIs.

It's probably historic and has roots in VMS.

http://www3.sympatico.ca/n.rieck/docs/Windows-NT_is_VMS_re-i...

I think there's many reasons for this, but the top couple are imo:

- Linux trusts their users to know what they are doing. They do not build layers of abstractions to make things "easy". These abstractions create complexity and just get in the way, especially if you know what you're doing technically.

- There is significant influence on the technical decisions by nontechnical people for business, personal, and political goals. Quarterly profits are the main motivator for Windows development. If it turned out that abandoning Windows would make Microsoft more money, they would do it. With Linux, the incentive is to have a "good" operating system. Money is important in the sense that it keeps Linux dev healthy, but making money is not the primary objective of the project.

- Because money is the main motivator, Windows is beholden to the people with the most cash. Often this is large enterprise organizations which make poor technical decisions. Microsoft in turn, must provide support for these technical decisions, forcing Microsoft itself to make poor technical decisions. I'm sure Windows developers would love if everyone stopped using old crufty tech from 2001, but since there's a lot of money riding on that tech, the show must go on.

Some significant portion of the complexity in Windows is around having many ways to do things, because Microsoft has committed to strong backwards compatibility. Because Linux doesn't have a strong backwards compatibility requirement, older apis get removed fairly quickly after new apis come through.

It is easy to make Linux complex as hell. Lot of man-hours is required to keep it simple. Major distributions and open-source licenses are playing major role in "simple Linux". Patching, bug hunting, fixing, development of standards (including File System Hierarchy Standard — thing unique to Linux), curating of packages, refactoring — it's lot of work.

It's about familiarity and how much you're willing to learn and keep on top of that knowledge. I work for an ISP and hoster and need to know both Windows and Linux fairly in-depth. I don't find either OS particularly complex or complicated either for software development or when third line trouble tickets get thrown over the wall. You can do this provided you keep on RTFM'ing and keep a couple of lab VM's around to learn the new stuff for an hour or so each week or fortnight.

e.g. http://man7.org/linux/man-pages/man2/fork.2.html vs https://msdn.microsoft.com/en-us/library/ms682425.aspx

I think the difference is that with Windows you not only get a kernel API, but also a GUI api and more. To get the same on Linux you need to add X11 (or maybe Wayland down the road, though the comparison is not strictly accurate) and perhaps some toolkit (GTK, Qt, etc).

Its really difficult to compare the two. Lots of Linux simplicity might be just very superficial, hidden in the rarely visited dark corners, whereas in Windows the complexity commonly is bit more upfront. Much of this stems from the fact that NT is just much more modern design overall, while Linux builds upon the ancient UNIX design. So when you look at Linux you might only see the relatively simple original UNIX there and then think Linux as simple. But in reality lot of the complexity rises from trying to cram in all the new features we expect these days into the old design, especially when in factor in the complexity in userland.

Second view on the matter (which is more hearsay than hard fact) is that with the relatively advanced kernel WinNT team had built they were running into critical performance issues. This probably was exacerbated by Windows more often running on weak PC hardware at a time when UNIX systems were heftier workstations and servers. These perf issues required them to make major compromises to the system to make it sellable.

Another more minor reason might be that WinNT was from the ground up designed to be both portable (at least to Alpha in additon to i386) and flexible enough to provide different userland interfaces (in addition to Windows, it also had POSIX and OS/2 interfaces), whereas Linux was very much i386 and POSIX only early on.

edit: oops, forgot one more thing: Windows offers an API for drivers whereas in Linux drivers are generally considered a part of the kernel itself and the APIs they use are not public. This design decision makes Windows API surface inherently larger.

One thing to keep in mind is that the "everything is a file" paradigm breaks down with newer hardware. For example, you can't use the file metaphor to eject a CD.

To get around this, we have the ioctl subsystem, which adds a whole lot of complexity. Modern I/O programming involves heavy use of ioctl and thus isn't nearly as simple as those drawings suggest. Per Wikipedia, "A kernel that provides several hundred system calls may provide several thousand ioctl calls."

https://en.wikipedia.org/wiki/Ioctl

I've probably spent 2% or less of my programming career coding directly against Win32 and POSIX APIs, so I'm not the best person to be answering, but I find the other replies miss an important point.

Linux developers look at the Win32 API and think it's too complex. But Win32 developers might look at Linux (or any POSIX) and think it just pushes the complexity out into user code.

Someone in this thread brought up process creation (fork/exec vs. CreateProcess). fork/exec is simple, but there are a lot of pitfalls you have to be aware of. If you don't care about the result of the process, too bad, you still have to set up a SIGCHLD handler to waitpid or whatever or else you'll end up with a zombie process--which you probably won't notice, but your customers eventually will, at the most inconvenient moment.

Or if your process is running as root and you want to launch a child process as a different user, you have to do this VERY carefully (calling setsid, setgid, setgroups in exactly the right order--oh and I almost forget about seteuid and setresuid, setegid and setresgid).

Or take a look at writing to a socket; the individual APIs involved are all very simple but you have to know to ignore SIGPIPE or else your process will terminate if the connection is broken while you're writing.

Bottom line is that when I write against Windows I spend more time reading docs, and when I write against POSIX I spend more time googling and debugging.