No, when it part of underhanded dealings by large multi-national corporations. So Linux has finally arrived! Sorry to see it was the Linux Foundation, I've always had high hopes for them.
0) Linux is just a kernel, so if taken literally, it never will be an OS. But I will roll with your terminology for now.
1) Linux was a Unix-like OS for tinkerers, programmers and soon for servers. A "real OS" is not defined by its availability on the Desktop. And indeed I very much used it exactly because of this, because I am a tinkerer who rather runs a Server OS on his private machines, that also allows him to do most Desktop-tasks with ease.
2) The voice of the Desktop camp inside of Linux is not ignored, if anything, the influence is too big. Think about systemd for example. This was not a move in order to run better on Servers, this was primarily Notebook and Server focused. The year of the Linux Desktop is not something we won't see because of evil big corporations, rather because it simply is not Linux's DNA to be that.
(And side note: Because of systemd I see more and more people using *BSDs)
Do you perhaps mean something else here? Notebook and Desktop focused maybe?
Systemd is useful on servers, especially for the DevOps people. On a desktop, it solves no problem that cannot be -- and that has not been for years -- solved without it.
I don't use it enough to question its technical merits. The fact that it was packaged in Debian and the world hasn't fallen over implies that people may be unhappy with it, but can still do their jobs, which would mean it's not that bad. But the necessity of its existence on notebooks and desktops is questionable at best.
Edit: I know this is going to incite a lot of posts about how the times have changed and now storage devices aren't statical anymore and we NEED systemd. From a lot of people who are too young (or too recent Linux users) to remember the days when udev was still news.
Guys, we've been easily hotplugging devices on Linux, on USB, SATA and PCI for about half a decade before systemd's first release (and not as easily but reliably, nonetheless, for at least seven or eight). We've been reliably booting and using Linux off a combination of USB and NFS filesystems for even more than that. All that yadda yadda about devices coming and going at boottime is not without its technical merits, but unless you boot your computer with its case open while frantically plugging and unplugging SATA drives, trust me, it's of absolutely no consequence.
Devices appearing and disappearing dynamically used to be a problem. In 2.4. Do you remember the 2.4 kernel? That was (boy, does time pass...) more than ten years ago. Do you honestly think the smart people writing Linux sat on their thumbs for ten years while the arcane world of tape drives and 10 MB hard drives around them was giving way to this new world of magic SSDs and USB?
The conspiracy theory would be that it's a deliberate RedHat effort to cripple competitors like Solaris. Unfortunately \*BSD and freedom will be caught in the crossfire.
Systemd is just the end result of RedHat employing a dominant share of infrastructure-critical Linux developers and making too much money compared to other players.
This fork seems to have put RH on a war path, as their subsequent releases no longer separated out kernel patches from the main kernel source etc.
And now CentOS is part of the RH flock, where before it was an independent repack of RHEL.
And while Solaris itself may be "dead", there are still various tech that came out of its development that is of interest in the -nix world.
Just look at the continued lamentations that you can't get ZFS support in Linux because of incompatible licenses.
I can understand RedHat being pissed about that.
A lot of people seem to think that portability is just a way of being nice to people who use obsolete devices. Nothing could be further from the truth. First, the simple act of isolating platform-dependent (whether "platform" means software or hardware) operations behind an uniform interface makes software more future-proof, makes the code better organized, and forces you to think about the problem until it's clearer in your own head.
I've seen a lot of software that was not meant to be portable, 'cause hey, we're only going to use it on <this CPU> running <this OS> and doing <these things>. Ten years down the line, no one is buying machines with <that cpu>, <that OS> hasn't been supported in half a decade and you have ten new customers that want different things, so <these things> are now <these 1000 things that we never thought about>. The software is now full of various small hacks and quirks and a compatibility layer has been bolted on top of a hundred thousand lines of code that make fifty small assumptions about the underlying platform.
As for conspiracies... I don't think there's an evil masterplan behind anything, but I'm hesitant to be happy about a big company playing an important role in a critical piece of unportable infrastructure. A lot of people jump on the "it works and I don't care about other platforms" bandwagon. Suuure, they'll say, systemd is Linux-specific, but there are good reasons for that, they use Linux-specific things so that they can be as well-integrated as possible and give the most flexibility to their users.
Win-win, right? Linux users win a better platform, systemd developers don't need to be worried about platforms their users don't care about.
Except "systemd developers" is Red Hat, a bunch of really young people who hope to work for Red Hat one day, and a community of people who have been writing SysV scripts for so long that they'll give a kidney for anything that will put a nail in that crap's coffin. It's basically Red Hat and a few people that the PR machine calls "community", but make no mistake about it, when the people who do it for fun go have fun somewhere else, Red Hat is still going to be the main engine behind it.
"Platforms their users don't care about" is -- by no mere coincidence -- Red Hat's competition. In this context, lack of portability is just a glorious term for vendor lock-in. Your infrastructure depends on systemd? Great, I hope you like Linux, 'cause you won't be moving it to something else any time soon.
Oh, but the options are open, you'll move to CentOS, you say? Right -- for now, that's an option, because the Linux enterprise market is still, by and large, up for grabs, and there are very few Linux companies that are large enough that Fortune 500-class companies can talk to. If Red Hat goes evil now, they'll just go out of business. Wait for ten more years, until it supports enough projects that are too vital to fail, before you tie yourself to their platform.
Remember all the fun we had with SMB and Kerberos a long, long time ago? Just because they have fluffy penguins doesn't mean they won't go Microsoft on our asses.
Even if you don't care about software quality (which is a bad idea but I've seen enough people who think that "it's good" means "it makes money for the people selling it"), portability is great, it's a free ticket to say you know what guys, fuck you, fuck your shit platform, fuck your shit licensing schemes and especially fuck every single one of you fuckers, I'm switching to <this>. FREE TICKET! All you have to do is talk to your sysadmin team and utter the words if they think it's a good idea.
You need not be.
One of the lirc maintainers a few months ago moved all Debian support out from the main source tree (http://sourceforge.net/p/lirc/git/ci/44696400eb92de342444665...) and this month proposed dropping its System 5 rc scripts (which is what Debian still packages up and uses for running lirc even in "unstable" and "testing", incidentally) and providing only systemd service and socket units.
The issue of Debian kFreeBSD came up. As an exercise, I took the FreeBSD binaries for lirc, which I built from the FreeBSD port, ran the service and socket units through the conversion utilities in the nosh toolset, and (after selecting "ideal" mode and fixing a bug) the converted services successfully supervised the FreeBSD binary under the nosh service manager. This was on actual FreeBSD: on PC-BSD version 10.2, specifically. Even in a world where its maintainers provided only systemd ancillaries, lircd could be run on FreeBSD.
The bug was in the lircd units themselves that the lirc maintainers were wanting to switch to, ironically. lircd is putting stuff in an ephemeral runtime directory /var/run/lirc , without either making the directory itself or declaring it with a RuntimeDirectory=lirc directive in the systemd service units. I simply added RuntimeDirectory=lirc .
Lots of other posts about LF, the license issues, other companies doing similar things, etc. Not sure how or why this sub-thread got taken so far off topic. Are we, at the start of 2016 still so sensitive about Linux that a 10 word setup sentence starts a frenzy and draws me a reprimand on "flame-bait?" In that case I'm sorry, I'll be much more careful in the future to not write posts that assume the reader will make it past the first dozen words.