grumbles something about developers saying "Linux" when they mean "only supported on Ubuntu"
I'm an Arch Linux guy. I strongly dislike both Ubuntu and Canonical, on technical, political and ethical grounds. But I get it.
And you know, a huge part of the problem is that "we", as the Linux community, have no direct interest in pushing compatibility between distributions. It takes a lot of effort, a lot of political reach, and the distros will just run with their own thing a few months later anyway, nullifying the efforts.
Besides... have you seen what happens when people are actually successful at pushing compatibility? Have you seen the shit people throw at Lennart/RH for Systemd? Why would anyone ever want to play that game?
Anyway, not to detract from the topic - it's fantastic news. Unity3d is huge in the game development world and this is a big win.
No, say that Unity comes to Ubuntu.
Gone are the days when distros decided if something worked or didn't. Thanks to things like SystemD this will continue down that road (Ducks). Also hoping we finally do package management in a elegant modern way soon and not like we are right now.
How? systemd touches a completely different layer. The main thing that might prevent ELF interoperability across distributions is if the distro has some esoterically configured binutils/glibc toolchain and the provided application is a dynamically linked binary blob.
Before SystemD we had init scripts in our thousands of packages. Each package system would have different init systems and procedures. This is one of the big reasons why things were not inter-operational between distros. This is why Arch and Debian among others distros jumped off their old init systems and adopted SystemD.
They're completely orthogonal tools.
And no, it was hardly a "big reason" why distros weren't interoperable. Initscripts were rarely supplied by upstream vendors and frequently written downstream. Then many other people didn't use them at all, but wrote runscripts for some flavor of daemontools in about 4 lines or something.
The main reason has always boiled down to the toolchain. One proposed way to get around it was fat ELF binaries, but that effort got metaphorically curbstomped by the Linux community. Universal package managers aren't supported for political/branding reasons.
In any event, systemd doesn't help with this.
Never said integration saying packages have scripts to init themselves and that was different based on your distro.
Don't know why you feel the need to correct a point that distros are becoming more and more alike and that systemd is one of the elements that has helped this? Anywaysssss SystemD is the standard now for most of Linux and I am hoping for MORE standardization.
(To be pedantic, there is no "standardization" so to speak of. It's more like an informal fiat than anything.)
And if you question this you are simply an ignorant infidel that will see the light in due time, they just need to spread the gospel more fervently (or should i say forcefully?).
The general lack of compatibility between distributions usually leads software publishers to packaging and testing only one or two versions of their software. The community will then try to repackage it for other distributions. When the apps are not 100% open-source, it usually leads to huge delays for updates and broken packages after a while.
One difference is that as an ISV you don't have a lot of control on the way the system is setup, you have to start with assumptions and then work from there. -> Your job is to make your software work on fragile systems.
When you are dealing with managing systems at scale, hopefully you know exactly what you're dealing with. You don't have to make assumptions, you _control_ what components are on each box. -> Your job is to make your systems run broken apps :)
However, the incompatibilities come from how these tools are configured: there are numerous ways of interfacing/configuring X.org, syslog, networking and wireless tools, etc. Generally each distribution comes up with its "own true way" of doing it. This introduces a lot a pain for anyone trying to come up with a generic way of working with underlying subsystems. It's not impossible but it takes a lot of effort, is very fragile and needs an ongoing maintenance to keep up with the changes introduced by the distributions.
My point is that systemd exposes a set of capabilities and known interfaces you can rely on being there. This is far from being enough but it still an improvement in my eyes.
Linux software is compatible with any GNU/Linux distribution (and even some non-GNU Linux distributions). It's only a matter of having the right libraries and environment installed. That might be easier when things standardize on things like systemd, but for most software, such implementation details rarely matter.
Let's not bait with systemd, that's a different issue.
Package manager interoperability is certainly a political issue. A lot of distributions are identified by their PM infrastructure, so adopting a universal one like Nix or Guix would mean losing their identity. Conflict of interest, quite clearly.
We might end up with, GNOME-based distros at least, running a NIH version of Nix called xdg-app, however.
What truly affects companies wanting to release and support their software on multiple distributions is the lack of universal fat-apps. And yes, xdg-app is the way to go - sadly, only GNOME has been leading that front and cross-desktop talks have stopped.
The XDG mailing list is dead. Sending an email there is equivalent to pissing in a violin.
Meh, I'm pretty jaded. But I totally do think systemd is a clear example of what happens when a group tries to push for less NIH and more standardization. Tools get replaced and people get upset.
The Linux community has rejected fat apps (primarily fat ELF binaries) many times, so that's not out of the ordinary.
I find the idea of systemd being less NIH to be quite baffling, though. Just look at its ad-hoc LISTEN_FDs protocol rather than adopting something well designed like UCSPI.
Heck, a RPM is pretty much a fancy tar.gz at first glance (and a DEB a bit more elaborate).
I swear i wonder of far up the devops exhaust channel the Linux userspace thinking has gone these days...
They even provide a distro agnostic installer. Sure, it would be better if they provided RPMs and a bit more "official support", but it's not practical to promise and support it working on every distro.
1) Deb
2) RPM
3) Tarball
Though OpenSUSE Build Service is the most under used Linux technology period. Build on it and send out packages to whatever distro you want. https://build.opensuse.org/
It's unreasonable to ask them to support all kinds of Linux distributions; it all depends on how well it actually 'will work'. E.g. Blizzard's Hearthstone does not officially support Linux (despite using Unity, btw.); also it doesn't support graphics chipsets as old as Intel GM45 (Intel's integrated graphics circa 2008; gen.4; last Core2). Yet I've been able to run this game on Ubuntu on my ThinkPad X200 reasonably well since beta and it's only getting better with time. Part of it are improvements from Wine and Mesa 3D (I didn't believe I will get performance improvements for the 5+ year-old hardware, but it happened last year: mesa 9.3(?) brought a solid improvement to 3D including Ubuntu desktop experience[sic!]) but also I believe Blizzard is actually fixing Linux-related glitches, even though the game is not officially supported. This could be better than some companies 'supporting' Linux by doing a half-assed port and forgetting about it.
the editor will run on most ‘modern’ 64-bit Linux distributions
The fact that it's only supported on one distro doesn't mean it hasn't come to the others. It has, but in an unsupported way. Anyone who uses a Linux desktop running anything besides Ubuntu should be quite used to that.
http://download.unity3d.com/download_unity/unity-editor-inst...
I'll take that over zero linux support anyday. Usually it's pretty easy to make these things run by yourself too. ldd the binary, fetch the missing libraries and/or grab the ubuntu packages set the library path and you're done.
Go fork another distro and shut up. Perhaps a new window manager? Steve Jobs took a bankrupt company and turned it into the world's most profitable company in less time.
On a related note, it's currently not working on Arch/Manjaro/Void Linux http://forum.unity3d.com/threads/service-not-available.35033...
But anyway, they are probably doing this because Valve supports Ubuntu, and Valve is doing it because Ubuntu comes with GPU drivers out of the box (contrary to Debian, where you must apt-get them).
A Debian installer with support for non-free software would go a long way towards changing all that. (Or even better, a deb-multimedia installer.)
Actually they're advertising Linux as SteamOS these days which is essentially Debian.
Let Linux take the desktop and THEN we can start forking over minute details.
Because MS has basically cockblocked all attempts at getting something other than Windows preinstalled on store shelf hardware.