"Today’s build is what we call an experimental build; future support is not yet guaranteed. Your adoption and feedback will help us determine if this is something we can sustain alongside our Mac and Windows builds."
Even in terms of "Unity the game engine" it's confusing. Unity has supported building for Linux for a long time, and the majority of Unity games have been released for Linux. This is specifically the editor for creating games, which was not previously available.
Same here. In fact, I use the standard Unity based Ubuntu on my desktop only. I prefer to use a more traditional desktop environment like XFCE on all of my other machines and laptops. The Unity desktop is tolerable and not too difficult to get used to and switch back and forth from XFCE, unlike windows 8.
The Unity3D game engine announcement is awesome and they've been really changing the face of game dev.
People who are aware of Ubuntu's Unity will also know that it obviously has long existed on Linux, so there is no confusion. Simple heuristics made abundantly clear more than any additional title clarification could.
There are a lot of products in tech, and a huge number of name collisions. Context (such as the fact that the linked domain is unity3d) saves us all from having to add caveats and clarifications to every mention. Just as I can talk about Microsoft Windows without noting that I'm not talking about panes of glass.
Well, the title has context -- the URL of the site hosting the title, Unity3D.com, is right next to the title, both on the main page of Hacker News and on the discussion page.
I usually use unity3d to help narrow my google searches, however its important to note that almost all official literature refers to the platform as Unity, even more so given the recent emphasis on 2d games built w/ it.
Nice, so Unity is finally an option for me. Now it would be nice if the Unreal editor had official Linux support as well. (I know there's Wine, but it didn't work too well for me.)
Both are general purpose engines and can be put towards a wide variety of game genres. Out of the box, UE4's editor comes with about half a dozen templates (FPS, top-down, side-scrolling platformer etc) for rudimentary intro projects.
Unreal Engine is somewhat harder to use, but it's graphics engine is a bit closer to the cutting edge - it's the go-to engine for AAA devs these days. Unity's main user base (for people who use it to make games - some use it for academic ends, or for tech demos) tends to be the indie game scene.
They do the same job, but differ in the technical aspects and ease-of-use, and business model (though both are aiming to lower the barriers to making games), and they tend to cater to different segments of the market.
I have been running UE4 on linux since the community builds around 4.6, but 4.8 official builds are now pretty fully functional, minus the launcher, and my main gripe: having to build linux dedicated servers on windows...
I am pretty dedicated to releasing for SteamOS as a main target platform, and have been trying to untether from windows. I have a few friends are love unity and want me to join projects but my main complaint has always been that there was no linux editor. Looks like I will have to test out the this unity test build.
It is about the Unity editor. Unity3d can compile a game for a linux target, but until now, you couldn't design/edit/build your game on a linux machine.
This is great news and I hop they will support it.
The end-products - games - do have linux support. But the support is not that great, for example the unity engine on linux doesn't seem to support vsync (it says it does, but it doesn't in practise) which results in horrific and annoying tearing. It has been like this for well over a year, with no sign of any urgency to fix it.
It is nice that "linux support" is a bullet point that companies feel is worth having, but it isn't a significant enough part of their market for them to make it work without glaring issues, often.
> for example the unity engine on linux doesn't seem to support vsync (it says it does, but it doesn't in practise)
It does technically support it. It's just that for some mysterious reason, it's turned off by default. Games that explicitly turn it on, or let you change it in the settings (in my small library that's only MouseCraft and JazzPunk) run fine.
Everything else maxes out my CPU. As a laptop user, this does not make me happy.
This came just in time when I was thinking of switching to Mac. Blender game engine has features but not upto the mark to compete with game engines like Unity. The python scripting in Blender is good.
What would you have them do? Support it on every single distribution out there? They pick a mainstream one and run with it - I get it. It's normal. It's sad, but you can't blame them; you gotta blame the ecosystem we're in.
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.
It's supported on Ubuntu, but if it's available there, it's essentially compatible with Linux. You can't realistically not be compatible with Linux if you're available on Ubuntu.
Ubuntu is Linux, I don't use Ubuntu. I use mostly OpenSUSE/SUSE and sometimes Arch or a Redhat version and if I must Ubuntu or Debian. It will work in Linux just wish we had a solid second tier desktop Distro.
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.
Thanks to things like SystemD this will continue down that road (Ducks).
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.
SystemD pretty much takes over the core of the OS. This has helped the trend of Distros being interoperational with each other. This is why some people HATE SystemD.
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.
The package systems never had init system integration. What some PMs did was they ran procedures in the postinstall scripts to do things like update SysV symlink farms. In Debian, this was done by sysv-rc and in RPM-based distros, chkconfig or something similar.
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.
> The package systems never had init system integration
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.
Distros are undeniably becoming more alike thanks to systemd, but from this premise does not in any way follow that package interoperability will be improved, which was the topic at hand.
(To be pedantic, there is no "standardization" so to speak of. It's more like an informal fiat than anything.)
Does it have to be monetary? Best i can tell, the people involved are on what may border on a holy crusade to "improve" the desktop Linux experience. Meaning that to them the goal justifies the means.
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?).
Binary compatibility is certainly a major issue but I think you are downplaying the compatibility headaches introduced by the way each distributions are solving the same issues with slightly different methods. I'm thinking of: logging, default character sets, locale, timezones, mount points & encrypted block storage, basic OS versioning information, networking, service management, networking. And I'm forgetting a plethora of others areas.
There were/are attempts to have standardization around some this, like the FHS or the LSB for example. But it's hard to argue that systemd was far more successful into bringing a semblance of order than any past attempts. There's still a long way to go.
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.
Pretty much all of those were de facto standards, as provided by X.Org, util-linux, wireless-tools, the syslog protocol, fstab(5) and so forth. The situation was nowhere near as grim as is often presented, considering much of it was just standard kernel and shell interfaces. Encrypted storage has always had multiple different approaches, and remains so.
Automating large server farms is a very different job from being an Independent Software Vendor (ISV).
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 :)
I disagree.
You're referencing to specific _tools_ being used as a de facto standard and this is certainly true to some extent.
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.
As a Slackware user, I'd hardly attribute the compatibility of "supported for Ubuntu, other distros be damned" software on non-Ubuntu distros on systemd :)
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.
I'd argue that compatibility between distributions isn't a strictly good thing - but rather serves to hamper innovation and new developments in userland from distros in all but a few cases.
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?
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.
Package management is the least of our worries when it comes to cross-distro compatibility.
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.
xdg-app is a prime example of NIH. It poorly reinvents reproducible, deterministic and isolated builds when battle-tested and academically sound solutions like Nix are available off the shelf. People refusing to adopt it is a good thing in my book, it'll only be harmful in the long term.
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.
"fat-apps"? What is the difference between that and a tar.gz with all dependencies included? Mozilla offer Firefox that way, Opera used to offer, well, Opera that way (until they wen't full retard and cloned Chrome).
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...
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.
Yes, and with a little bit of work you can install these packages on pretty much every distro anyway. I've got a few packages on Arch which are only officially supported on Ubuntu, and I never had any problems with them.
I'm an Arch and Gentoo user, and I've yet to come across anything that only runs on Ubuntu, despite plenty of things only "supporting" Ubuntu. Something might only be distributed as a deb, or rely on specific package versions which are included in the latest Ubuntu release, but someone always packages them up in the relevant format/repository for every distro. And users of such distros are usually ok with fiddling around a bit too get it working anyway.
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.
Exactly this. If you provide your Linux oriented project in those three formats, you cover approximately 100% of the meaningful use-cases. Provide source as well, and you definitely cover just about every conceivable scenario.
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/
Even just the tarball is sufficient. Especially if it's structured so that it can be extracted directly on one's root filesystem (i.e. the Slackware style of package management), it's comparatively trivial for downstream distro maintainers to repackage accordingly using their preferred format.
That. I'd be glad if they supported any distro that is not user hostile.
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.)
grumbles something about Linux nerds not getting why Linux still only has 1% of the desktop 23 years after he first downloaded it
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.
Eh, there will be community supported LD_LIBRARY_PATH wrappers, effectively making it run on "linux" even of they only support ubuntu.
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.
Well, they say it 'will run on most ‘modern’ 64-bit Linux distributions, but official support is only provided for 64-bit Ubuntu 12.04 or newer'; that looks reasonable to me.
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.
In practice, this isn't that big of a deal. Steam is technically only supported on Ubuntu, for example, yet I have little if any issue using it and playing games on my Slackware-running gaming rig.
I have used both Unreal DK and Unity 3d. On any day, I'll pick Unreal based technology over Unity3d. Unity 3d was a total pain in the neck and is more suitable for art-heavy and relatively less programming kind of games.
Unreal is far more mature as a platform and you can do a lot more with it. (The code of the internals sucks a bit though).
I've been considering switching from Windows 8.1 on my main machine for a while but not being able to work on my game in Unity3d has held me back. This might finally put me over the edge.
Windows 10 is pushing me in that direction all by itself. ;-)
It's been about 2 years since my last attempt at Linux for my main desktop OS... about time for another go at it. Been my HTPC OS for almost a year and a half (since switching to xbmc/kodi for most playback anyways).
I use Linux full-time at work (Kubuntu ftw) and Ubuntu/Raspbian at home with the exception of my main desktop. I went Linux-only for a couple of years back in 2009. I came back to Windows because I got a job at a gaming startup, developing a game in Unity3d and using the .NET/Azure stack.
The third time I switched from Windows to Linux stuck for me :-)
It was always that I got a laptop or computer running Windows, after a year and a half or so I managed to crud it up badly, even while keeping everything as clean to the best of my abilities, it just got slower and slower, meaning to install Linux as a dual boot, until something breaks and I actually do it.
Next computer will just start out with Linux, though.
But there's something that has been bothering me for a while about games for Linux compiled with the Unity SDK.
Does anybody know what kind of dependencies a game written with the Unity SDK has? I'm pretty clueless about that stuff but I'd still like to know what it would take to get a game running on a minimal Linux install (like a naked Arch or Gentoo). Ubuntu obviously comes well equipped for the task but I don't really care about that.
So where do the graphics come from? Does it need some special libraries apart from OpenGL? Where do fonts come from? How does it interface with hardware, i.e. does it need X, or does it come with its own drivers for keyboard, mouse, gamepad?
I fear that it is necessary to install half of Ubuntu to get the games running but - as I said - I don't really know anything about that.
I am not sure this is the solution, but you could call "ldd <file>" on a unity generated binary to see system dependencies. If they statically compile stuff into the game, that's another question.
Or Cities: Skylines, another excellent game that uses Unity.
Between those two, I've probably sunk whole weeks of my lifetime. If someone were to make a game that combined the two into some kind of orbital city builder, I'd be set.
I know that steam has some 32Bit dependencies even on a 64Bit OS. I thought it might have only been the steam client's dependency. Unless you're using a 32Bit OS, it seems that Steam, or maybe even Unity3D, enforces the use of those 32Bit libs.
I wonder why.
Edit: I seems that you removed the references to lib32 and i386.
I think its a red herring. KSP (and unity games in general) ship as either x86 or x86 and x64. Full output for ldd of both of them is here http://pastebin.com/KAYF4TFw
So, having tried to offer support for a game on linux before it's a giant nightmare. If you don't want to open source you end up with a never ending support task.
Unity should solve that now. Maybe.
To answer a few specifics with out getting too ragey:
To get real usable 3d you need to be running the proprietary drivers. The opensource ones at least a year or so ago when I was paying close attention were uniformly too slow and supported such a limited subset of the specs that the were usually pointless.
The take away for me was to always assume that the user system is completely dumb and to ship EVERYTHING. We ended up packaging the kitchen sink to get rid of the majority of the "I installed this on <nightly build of obscure distro> and it says it can't find libc" issues.
Two of the open source drivers (radeonsi and nvc0) support OpenGL 4.1 now (though only if you've got a bleeding edge build of Mesa, built against bleeding edge LLVM). This is obviously still pretty far behind, but at least it's caught up to OS X.
The performance of radeonsi isn't terrible (though that's partly because the proprietary AMD driver sets the bar kind of low), though still generally slower than the proprietary one. There are some experimental instruction scheduling changes in an LLVM branch that appear to give better performance than the proprietary drivers for at least some benchmarks.
On the Nvidia side it's pretty much proprietary or bust though. Featurewise it tends to be in good shape (at least in comparison to the other open source drivers anyway), but there's no support for changing the GPU clock so performance is terrible.
Offering support for a game is a never ending support task. If you aren't willing to support your users, you aren't ready to publish games. Don't blame Linux users.
You're being disingenuous. Every platform requires support, which takes time. It's unreasonable to expect Linux to be an exception to this and not take any time. If you planned on Linux being the special platform which doesn't cost anything to develop for, your disappointment is due to unreasonable expectations.
Linux is the exception because the support burden is much, much higher per user because "Linux" is a catch-all for what is really several operating systems that share a kernel and some userland code, so supporting Linux is much harder than supporting, say, Windows.
Yeah, you can support Windows 3.11, Windows 95, Windows 98, Windows ME, Windows NT, Windows 2K, Windows XP, Windows 7, Windows 10, Windows CE, Windows with single simple exe file, while Linux users needs to execute complex commands, such as "yum install package", to install install software which will perfectly match their environment only.
You know as well as everyone here that "Windows support" generally means two or at most three versions of Windows, and that adjacent Windows versions are a lot more intercompatable than any pair of Linux distros. What do you gain by pretending to be stupid?
It's really a problem with two dimensions. There's versions of the same OS, and then there's incompatible operating systems. You can kinda make the case for Windows being three different OSes, but the Win3.1/Win95 tree has been dead for over a decade, and Windows CE was never really positioned as being compatible with other Windows anyway.
And it's not like Linux doesn't come in versions, and it's not like a change in versions doesn't have similar compatibility concerns as it does in Windows. (Honestly, I think it's worse on Linux -- it is a lot easier to run the same version of, say, MySQL on consecutive releases of Windows than it is on RHEL/CentOS.)
So post-XP, where Windows NT ate DOS-based Windows, you have Windows progressing version to version -- Vista, 7, 8, 10. You can see the same progression in Linux OSes -- Debian goes Etch, Lenny, Squeeze, Wheezy, Jessie over a similar timeframe. But at the same time, Fedora runs from version 6 around Vista's launch to version 23 due out in a few months from now. So, like Windows, you have a concern with making an application run on both, say, Squeeze and Wheezy. But you also have an additional problem where you need to make it work on Beefy Miracle. For most software Linux users come into contact with, developers will write software for one, maybe two distros or so, and each distro ports the software over, essentially. So every open-source project is essentially forked by each distro. It's not a model conducive to closed-source software. Which... there are plenty of people who are openly happy about this, as they would rather encourage open-source software over closed source, so it's not like this is strictly an accident or a mistake. But if you want to ask why games don't get Linux ports, or get Linux ports that involve running the Windows version in a Wine wrapper, that's a big part of the answer.
Commercial developers from Windows world are missing huge paradigm shift which happens outside of Windows world: there is no installers anymore. You cannot install Android app on drive C: or drive D:, you cannot install GMail into c:\googleapps, you cannot do "yum install --from app.exe --to c:/myapps", etc.
What will happen if Google will provide installers for all their services instead of publishing them on the web, if Android developers will do same instead of publishing in PlayMarket? How much support they will need to cover all hardware and software?
There is no problem with supporting of whole Linux, on all OS'es and HW if you understanding it. Opensource developers are doing that for free.
To support 3 major versions of Windows in at least two localizations and in few flavors (home, pro, server, etc.) with different set of software installed, which may affect installation process, you need farm of Windows machines and extensive testing. It looks like that to test various Linux distributions you need a lot more hardware and time resources, because there is so many of them.
In reality, to support a linux distribution, you need to install distribution in a virtual machine, install your application manually (on your side, not at client side, so you can skip all bells and whistles), package result, then publish result into your own repository. So to support 10 major distributions, I need 10 virtual images and about 10 days. Feel the difference.
PS.
Sorry, my English is not perfect. I cannot even talk in English.
The post you responded to specifically said that Linux support is substantially more difficult that supporting any given other platform. Do try to keep up.
Linux users aren't the issue. Nor am I attempting to blame them.
The problem is that basically you are always aiming at a moving target of system configuration when you release. Do you bet that your users have mechanical disks or SSD? If you aim for the latter you can make different choices. Windows as an operating system moves pretty slowly compared to the broader linux ecosystem, your percent users running a particular version of say DirectX is easy to guess, and easy to predict.
The problem when you move to linux is that the landscape is shifting rapidly. Everything from the kernel to libraries to what Distro is hot this week change nightly.OT steal mikepavone's example; In the last few years how many new families of windows video card drivers have come out? How much change have we seen in their capabilities? On linux the answer is, frankly, impressive.
This is great for linux, but it makes it hard to reach out to the smaller percent of the small percent of users who are having an issue and fix their issues.
The result is that at release you can just let that windows binary sit there and maybe fix a few bugs that crop up in your code. Your linux binary is more of a surfing act where things are great, then you are slowing down, and something breaks, and the whole tower comes down.
Fundamentally, it's why things like Unity are popular. The fewer people on a team, the less time you have deal with things like compatibility issues.
problem with games is that they are only good if multiplayer.
and it's only good multiplayer if you can't cheat.
that means every dumb game system rush to try to run as root. as you can see with steam.
then after they have that excuse they also use that new power to enforce DRM. as you can see with steam.
and cheaters continue to cheat. but now you have malware.
running games in Linux is easy. heck you've done it on windows, you can make it on Linux with better docs and apis. the problem with Linux gaming is catering to users that don't have their heads up their buts. that is the real problem, and nobody sees the monetary incentive.
that said, true Linux gaming holy grail will be achieved when you can run a windows vm with full 3d support. period.
That sounds like Unreal. Unity has a free version and a pro version, the latter is either a subscription-based one, or a one-off payment of $1500 or similar, which does sound awfully cheap to me.
They've had a bit of capability difference before. From the version 5, they've changed their model so aside from mandatory Personal Edition splash screen, the engine is identical but they do offer support and external feature for their paid version. (And they have $100000 revenue/funding limit to license Personal Edition.[1])
131 comments
[ 3.6 ms ] story [ 191 ms ] threadI think we all know the future of this then.
see: https://unity.ubuntu.com/about/
Though there is a certain appreciable irony in having two totally different things named unity.
The Unity3D game engine announcement is awesome and they've been really changing the face of game dev.
There are a lot of products in tech, and a huge number of name collisions. Context (such as the fact that the linked domain is unity3d) saves us all from having to add caveats and clarifications to every mention. Just as I can talk about Microsoft Windows without noting that I'm not talking about panes of glass.
Granted it was never popular, and it definitively isn't now, but still.
https://wiki.unrealengine.com/Building_On_Linux
Unreal Engine is somewhat harder to use, but it's graphics engine is a bit closer to the cutting edge - it's the go-to engine for AAA devs these days. Unity's main user base (for people who use it to make games - some use it for academic ends, or for tech demos) tends to be the indie game scene.
They do the same job, but differ in the technical aspects and ease-of-use, and business model (though both are aiming to lower the barriers to making games), and they tend to cater to different segments of the market.
I am pretty dedicated to releasing for SteamOS as a main target platform, and have been trying to untether from windows. I have a few friends are love unity and want me to join projects but my main complaint has always been that there was no linux editor. Looks like I will have to test out the this unity test build.
Or are there multiple game engines called Unity (on top of the existing confusion between the game engine and the Ubuntu thing)?
EDIT: I think the announcement is about Linux support in the SDK, not the actual software developed with Unity?
This is great news and I hop they will support it.
It is nice that "linux support" is a bullet point that companies feel is worth having, but it isn't a significant enough part of their market for them to make it work without glaring issues, often.
Hopefully though now that their main product is expected to work 100% correctly on Linux, that this will lead to fixes in their Linux compiler.
It does technically support it. It's just that for some mysterious reason, it's turned off by default. Games that explicitly turn it on, or let you change it in the settings (in my small library that's only MouseCraft and JazzPunk) run fine.
Everything else maxes out my CPU. As a laptop user, this does not make me happy.
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...
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...
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/
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.
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.
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.
Let Linux take the desktop and THEN we can start forking over minute details.
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.
Because MS has basically cockblocked all attempts at getting something other than Windows preinstalled on store shelf hardware.
It's often compared alongside the Unreal editor, which I unfortunately haven't taken for a spin yet.
Unreal is far more mature as a platform and you can do a lot more with it. (The code of the internals sucks a bit though).
It's been about 2 years since my last attempt at Linux for my main desktop OS... about time for another go at it. Been my HTPC OS for almost a year and a half (since switching to xbmc/kodi for most playback anyways).
I jumped over to Fedora and have been pleasantly surprised to find out that SLI, multi monitor, and sleep work flawlessly. Zero problems so far.
It was always that I got a laptop or computer running Windows, after a year and a half or so I managed to crud it up badly, even while keeping everything as clean to the best of my abilities, it just got slower and slower, meaning to install Linux as a dual boot, until something breaks and I actually do it.
Next computer will just start out with Linux, though.
But there's something that has been bothering me for a while about games for Linux compiled with the Unity SDK.
Does anybody know what kind of dependencies a game written with the Unity SDK has? I'm pretty clueless about that stuff but I'd still like to know what it would take to get a game running on a minimal Linux install (like a naked Arch or Gentoo). Ubuntu obviously comes well equipped for the task but I don't really care about that.
So where do the graphics come from? Does it need some special libraries apart from OpenGL? Where do fonts come from? How does it interface with hardware, i.e. does it need X, or does it come with its own drivers for keyboard, mouse, gamepad?
I fear that it is necessary to install half of Ubuntu to get the games running but - as I said - I don't really know anything about that.
Between those two, I've probably sunk whole weeks of my lifetime. If someone were to make a game that combined the two into some kind of orbital city builder, I'd be set.
linux-gate libdl libpthread librt libGLU libGL libX11 libXcursor libstdc++ libm libgcc_s libc libnvidia-tls libnvidia-glcore libXext libxcb libXrender libXfixes libXau libXdmcp
I know that steam has some 32Bit dependencies even on a 64Bit OS. I thought it might have only been the steam client's dependency. Unless you're using a 32Bit OS, it seems that Steam, or maybe even Unity3D, enforces the use of those 32Bit libs.
I wonder why.
Edit: I seems that you removed the references to lib32 and i386.
Unity should solve that now. Maybe.
To answer a few specifics with out getting too ragey:
To get real usable 3d you need to be running the proprietary drivers. The opensource ones at least a year or so ago when I was paying close attention were uniformly too slow and supported such a limited subset of the specs that the were usually pointless.
The take away for me was to always assume that the user system is completely dumb and to ship EVERYTHING. We ended up packaging the kitchen sink to get rid of the majority of the "I installed this on <nightly build of obscure distro> and it says it can't find libc" issues.
The performance of radeonsi isn't terrible (though that's partly because the proprietary AMD driver sets the bar kind of low), though still generally slower than the proprietary one. There are some experimental instruction scheduling changes in an LLVM branch that appear to give better performance than the proprietary drivers for at least some benchmarks.
On the Nvidia side it's pretty much proprietary or bust though. Featurewise it tends to be in good shape (at least in comparison to the other open source drivers anyway), but there's no support for changing the GPU clock so performance is terrible.
And then people wonder why so few devs support Linux.
And it's not like Linux doesn't come in versions, and it's not like a change in versions doesn't have similar compatibility concerns as it does in Windows. (Honestly, I think it's worse on Linux -- it is a lot easier to run the same version of, say, MySQL on consecutive releases of Windows than it is on RHEL/CentOS.)
So post-XP, where Windows NT ate DOS-based Windows, you have Windows progressing version to version -- Vista, 7, 8, 10. You can see the same progression in Linux OSes -- Debian goes Etch, Lenny, Squeeze, Wheezy, Jessie over a similar timeframe. But at the same time, Fedora runs from version 6 around Vista's launch to version 23 due out in a few months from now. So, like Windows, you have a concern with making an application run on both, say, Squeeze and Wheezy. But you also have an additional problem where you need to make it work on Beefy Miracle. For most software Linux users come into contact with, developers will write software for one, maybe two distros or so, and each distro ports the software over, essentially. So every open-source project is essentially forked by each distro. It's not a model conducive to closed-source software. Which... there are plenty of people who are openly happy about this, as they would rather encourage open-source software over closed source, so it's not like this is strictly an accident or a mistake. But if you want to ask why games don't get Linux ports, or get Linux ports that involve running the Windows version in a Wine wrapper, that's a big part of the answer.
What will happen if Google will provide installers for all their services instead of publishing them on the web, if Android developers will do same instead of publishing in PlayMarket? How much support they will need to cover all hardware and software?
There is no problem with supporting of whole Linux, on all OS'es and HW if you understanding it. Opensource developers are doing that for free.
To support 3 major versions of Windows in at least two localizations and in few flavors (home, pro, server, etc.) with different set of software installed, which may affect installation process, you need farm of Windows machines and extensive testing. It looks like that to test various Linux distributions you need a lot more hardware and time resources, because there is so many of them.
In reality, to support a linux distribution, you need to install distribution in a virtual machine, install your application manually (on your side, not at client side, so you can skip all bells and whistles), package result, then publish result into your own repository. So to support 10 major distributions, I need 10 virtual images and about 10 days. Feel the difference.
PS. Sorry, my English is not perfect. I cannot even talk in English.
The problem is that basically you are always aiming at a moving target of system configuration when you release. Do you bet that your users have mechanical disks or SSD? If you aim for the latter you can make different choices. Windows as an operating system moves pretty slowly compared to the broader linux ecosystem, your percent users running a particular version of say DirectX is easy to guess, and easy to predict.
The problem when you move to linux is that the landscape is shifting rapidly. Everything from the kernel to libraries to what Distro is hot this week change nightly.OT steal mikepavone's example; In the last few years how many new families of windows video card drivers have come out? How much change have we seen in their capabilities? On linux the answer is, frankly, impressive.
This is great for linux, but it makes it hard to reach out to the smaller percent of the small percent of users who are having an issue and fix their issues.
The result is that at release you can just let that windows binary sit there and maybe fix a few bugs that crop up in your code. Your linux binary is more of a surfing act where things are great, then you are slowing down, and something breaks, and the whole tower comes down.
Fundamentally, it's why things like Unity are popular. The fewer people on a team, the less time you have deal with things like compatibility issues.
This is why you use Steam Runtime and don't worry about that. It's does work even outside of Steam:
https://www.reddit.com/r/gamedev/comments/26pck1/selfcontain...
This could be a good use case for Docker containers. I remember they showed Quake running on Docker at a convention so it should be possible.
and it's only good multiplayer if you can't cheat.
that means every dumb game system rush to try to run as root. as you can see with steam.
then after they have that excuse they also use that new power to enforce DRM. as you can see with steam.
and cheaters continue to cheat. but now you have malware.
running games in Linux is easy. heck you've done it on windows, you can make it on Linux with better docs and apis. the problem with Linux gaming is catering to users that don't have their heads up their buts. that is the real problem, and nobody sees the monetary incentive.
that said, true Linux gaming holy grail will be achieved when you can run a windows vm with full 3d support. period.
You are tragically misinformed:
[1] http://unity3d.com/legal/eula