Bus1: a new Linux interprocess communication proposal
lwn.net
lwn.net
Have these people lost their effing minds? Do they think we don't care about compatability? Just because Lennart said "screw POSIX" doesn't mean you should do it.
So perhaps the real solution is to provide some kind of mechanism for userspace processes that act like kernel drivers, in that they are definitely running all the time, but actually run in userspace.
The reason this is in the kernel is that DBus is slow (according to Linus, because it could have been written better by monkeys with typewriters), and Lennart wanted it in the kernel/systemd, and Greg KH agreed, and Linus trusts Greg.
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...
Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.
So now you have two ends of the spectrum where this effort does matter, performance wise.
This only leaves the middle (desktop), but there are other reasons why that evil desktop crowd wants IPC in kernel, however high on a ‘priority list’ they might be.
You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.
It’s not about tight loops.
Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.
For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to have two message routing processes, one for low priority messages and one for high priority messages.
As far as 4 context switches versus 2 with regards to latency. A context switch takes microseconds... This is vastly smaller than the 250ms UI response time.
Again, this looks like a solution looking for a problem.
Fixing wifi or screen before working on micro-problems in the kernel for the sake of global power efficiency is founded in every kind of logic. It's literally Amdahl's Law: reducing power usage in a component that already has the most minimal power usage is a waste of effort for no noticeable effect. The cost-benefit ratio is indefensible. This is insanity.
Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.
Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument.
The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.
* for priority inheritance, have multiple daemons for each message priority level. Only privileges processes can use the high-priority message router, but can optionally use the low-priority message router when they want to inherit the priority of their sender.
* like I said, context switching is irrelevant since context switching is not the bottleneck in event latency nor in power usage.
* if FD accounting is important, move it out of the broker and make it p2p with broker coordination.
* kernel and LSM hooking feels like a feature looking for a use-case. If anyone really wants to do that, I'm sure the specific use case can be accommodated. Not every user space program need be trackable via LSM.
* for side channel and message ordering, why is this a core feature of the transport layer? I don't think all applications need this and if they do, something simpler and more specific to the application protocol could be developed. Generalized message ordering guarantees as part of the transport layer seems like it violates end-to-end design. A robust application protocol will end up ensuring this on its own anyway.
There you have it. I'm sorry but you don't have a strong case. Linus is even more opposed to this than I am and is probably better about system design than I am as well.
Obviously, if you do not care about any of the features, then you should not be using bus1. But that does not mean that others don't care, so why are you objecting so strongly to us providing a solution to these problems?
Firstly, if you don't want a bus IPC with multicast messaging, then use something else. But if you DO want that, then you cannot ignore message ordering, that is the whole point (otherwise you could just use repeated unicast instead).
If you want message ordering you cannot split things into several daemons, or you break the order (unless you add some more communication on top). Same with p2p (side-channel) communication for FDs.
The broker is basically doing work on behalf of the sender, but without proper time-slice accounting it is not accounted accordingly. Obviously in many cases that does not matter, but you cannot simply ignore the problem if you want a general, lasting solution.
It is true that performance is not the main feature, but that is not to say that it does not matter at all (to anyone, ever), so you cannot simply brush it aside, proposing a solution that would have (almost by definition) hundreds of percent worse performance (as you are just doing more round-trips, even ignoring the context switching). To say that IPC latency is "not the bottle neck" only makes sense if you have a specific use-case in mind. With sufficiently low latency, we open up the possibility of using IPC for things that could only be done in-process today. This is not the MAIN purpose, but ignoring it is short-sighted.
I just got an email today from people asking about the LSM hooks, so there certainly is interest, and this (like the message order) is not something you can bolt on top.
I have not seen Linus comment on this, please give a link if you have. Whatever reservations he had about kdbus should not apply to bus1.
Look, there are plenty of things that could be improved on bus1, and I'm sure some careful review will find things we could and should do differently, but please at least spend more than five seconds looking into what we did and thinking about the problem. We want a multicast IPC system, but we want one done properly. You cannot simply say that doing one that is several times slower, doesn't do proper resource accounting, gets the message order wrong and cannot integrate with LSM is "good enough for me" and expect that to be the end of it.
Multicast messaging as your main motivation for a message ordering layer when that layer has drastic effects on performance and operational characteristics is a strange proposition. I'm willing to argue that 99% of application protocols will have no use for baked-in multicast as you've implemented it. What exactly is the killer use case for multicast messaging with side-channel aware causal message ordering? What prevents an application that cares about this from ordering incoming messages according to a lamport clock itself?
I see no downside to these features in general, it's just that the justification for putting it in the kernel is weak. Kernel code has an infinitely high maintenance cost and it's not clear bus1 is the end-all messaging layer you want it to be. There are lots of past failed examples, inotify, dnotify, and fanotify come to mind...
Finally, He said what we're all thinking!
> o scale with the number of CPUs available [...]
It seems to me that these two goals are conflicting. If they give up the first goal then suddenly the need of a broker disappear.
edit: quoting from the message linked by parent.
edit2: by reading the description of the ordering guarantees, it seems that they actually only guarantee partial ordering.
There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.
The last is something you need kernel help to enforce.
Most programs are dealing with vastly slower bottlenecks. Like network or disk latency. IPC latency is so far down the list of priorities in terms of things to optimize.
Not to mention that regular user-kernel-user buffer copying is plenty fast now, especially since the buffers will likely be cache-resident. Zero-copy is mostly hype without performance numbers to back it up. Don't need this complex message sealing mechanism.
As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.
As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1.
As for portability, what other OS will implement this muck? None of them. It's portable the same way systemd is: "apps that depend on us are portable, so long as every os copies all our stuff, and re-implements all our APIs"
Forcing other OS's to implement your stuff isn't portability.
But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes.
The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.
You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc.
bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic.
When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...
The fact that Bus1 doesn't need init cooperation is good.
However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS.
As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland.
High-level abstractions for applications don't belong in the kernel.
There is no sealing in bus1.
The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish.
kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween.
High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.
The whole point of capability based security is that there is no permission system, because permissions are implicit in the capabilities. So this is much simpler than e.g. SysV message queues.
If you find this content useful, and you aren't already a LWN subscriber, you should consider becoming one!
More info is here: https://lwn.net/op/FAQ.lwn#subs
Subscription prices are here: https://lwn.net/subscribe/Info
Well, for starters they're a bolt-on that doesn't fit with the actual classic Unix philosophy.
2) They want the ability to insert a broker that manages permissions among the peers, but have the kernel enforce those permissions on a per message basis so the broker doesn't become a bottleneck. That's not easy to with the filesystem.
I mean, strictly speaking it's theoretically possible using the file system considering that in practice the only real broker would be systemd with a fixed set of policies, so theoretically the traditional Unix model of user, group, and supplementary groups would suffice by assigning users and processes into the proper groups, and binding message files into protected group-readable directories. But for whatever pretense, people want the solution to implement a system of opaque, ephemeral identifiers/capabilities.
It sort of reminds me of SMF, launchd, systemd, and similar changes. For example, I was installing Solaris 11.3 on a VM yesterday and was trying to figure out how to set the hostname. You used to set it by storing the hostname to /etc/nodename. Now it's stored in some opaque tree data structure deep in the bowels of SMF, which you set with some long and impenetrable command-line utility invocation. You can still set /etc/nodename; if no hostname is configured then SMF will initialize the hostname from /etc/nodename and delete the file. It boggles the mind.
* Inotify events are coalesced. Great for notifications, may be bad for discrete messages.
* The sender may want information about # of messages sent, synchronous delivery, etc.
Some call-outs for you:
> * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy).
The downside of the alternatives that you mention is that they're not available as kernel features in Linux. Bus1 is inspired by that previous work and aims to make a new attempt at inclusion in the kernel, which they believe is required to provide the features they're targeting:
> A user-space implementation of bus1 (or even any bus-based IPC) was considered, but was found to have several seemingly unavoidable issues.
> o To guarantee reliable, global message ordering including multicasts, as well as to provide reliable capabilities, a bus-broker is required. In other words, the current linux syscall API is not sufficient to implement the design as described above in an efficient way without a dedicated, trusted, privileged process that manages the bus and routes messages between the peers. (...)
But this paper makes a good quantitative case for POSIX not meeting the needs of modern computing: https://news.ycombinator.com/item?id=11652609
A good example is that Linux distros, Android, and OS X all have their own non-POSIX IPC mechanisms. Applications are somehow voting with their feet and not using Unix domain sockets and pipes.
It leaves me scratching my head because I don't think serialization is that hard a problem. But it seems that most people want IPC with structured data. Android is a bit of a special case because it's a single-language OS.
"Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
Specially when the majority nowadays has the idea that GNU/Linux == UNIX and never tried to write an actual portable UNIX application.
In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux.
I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.
I don't miss my days of writing portable POSIX code across DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian and the respective #ifdefs.
You were asserting that the majority of programmers think Linux == UNIX and have never tried to write a portable application.
Thst is clearly false as the majority of programmers probably confuse Mac OS X for UNIX and most modern unix-like software is portable to at least Linux, Mac OS X, and FreeBSD. Portable is more general than "portable across every UNIX that has existed."
Increasing the specificity of your argument mid-way to avoid the incorrectness of your initial general argument isn't very genuine.
But yes, your revised second statement is probably correct: most UNIX programmers have never tried writing portable code across "DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian" exactly because there is no practical reason for it.
It is a hard problem, at least if you want to achieve concision, make it parseable, and support schema upgrade.
> "Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."
And good riddance. File systems are almost universally terrible [1]. Threading with shared state is also a terrible idea because it's too general, not to mention the poor APIs used to manage them.
IPC is something that's still unfortunately undergoing constant revision, and the structured binary vs. text wars unfortunately both have merit. I think structured text output via a domain-specific language (DSL) is really the proper answer, somewhat like how a REPL works. This DSL is ultimately simple to construct within C since it would be lisp-like in its structure so it doesn't need an IDL compiler, although its textual syntaz shouldn't be lisp-like.
stdin can then nicely format DSL output for the user. Best of all worlds between text, binary, and structured formats.
Yes and no. There's significant utility to standardizing serialization in your IPC layer. IPC consists of exchanging domain-specific messages, so the message types can be specified in a header shared between endpoints, and data gets serialized in a standard format.
The IPC API then simply reduces to sending/receiving data to/from endpoints, like channels in CPS. And ideally it should be higher-order so you can send an endpoint to another endpoint.
So you don't need to standardize the serialization, but then you just get a plethora of incompatible formats.
> Large automotive companies have built huge systems on top of QNX
> messages, creating large libraries used by their applications.
> They would like to be able to use those libraries
> on Linux, but often don't know that there is
> a way to get the QNX message API for Linux. It is called SIMPL
> and it works well.
http://www.qnx.com/news/pr_2471_1.html
And now I notice it was almost ten years ago! Nevertheless, too little too late...
You can't pass file descriptors over sockets. You can't do RPC over pipes. Anonymous sockets can only be shared with children. Named sockets require write permission and a filesystem. SysV is prone to resource leaks.
Binder has authentication, shared memory, reference counting, weak references, dead object notifications.
The descriptors and authentication part is key, as it allows Android's trusted system_server to open a device or socket for an untrusted process such as an App if it has user permissions. The receiver of a binder request can check the requester's PID/GID and with confidence from the kernel.
Most importantly, I don't think it's healthy to think of POSIX as being done. Some experimentation and discovery of better APIs and better systems should be encouraged.
gah, I'm driving myself crazy; I swear I saw somewhere a diagram of the Taxonomy of Unix IPC Mechanisms, with most of them crossed out and replaced simply with binder, please help me find it!
Good that my code doesn't know this. It would stop working.
> The descriptors and authentication part is key, [...]
If by "authentication" you mean "checking PID/UID/GID", we already have both in unix sockets.
If you mean "I send some bytes that describes the file to open, and keep my processes in sync manually", of course you can do that, but true passing would allow a number of cool things.
You can:
http://man7.org/tlpi/code/online/dist/sockets/scm_rights_sen...
I've seen that done several times, with defined request and response message formats.
Ergo, POSIX wasn't the end.
AF_INET sockets don't do FD passing or credentials.
There was a patch to add an AF_BUS socket family some years ago that sounded like a pretty general solution but the network maintainer said "over my dead body".
Just a quick list of features, from Wikipedia:
Location transparency of services in a network
Auto-discovery mechanism
Reliable transport
Standard socket interface support
Connectionless, connection-oriented and multicast messaging
Subscription to network eventswhat a bunch of jokers :)
The illumos kernel has been stable for decades now. Teams of five people here, three people there, four people over there, they roll up their sleeves, look at the issues the customers have had and are actually having now, professional engineers with formal education and insight, and in two years they have a working product which only needs a small fix here or there, and is tenable decades into the future. It goes to show that the number of programmers does not a quality, working product make.
For example: it's 2016, and my Linux filesystems in Vertica suddenly go into read-only mode, nobody knows why yet. In 2016! I cannot believe I just typed that, but it's true.
I've been running ZFS since 2006 both professionally and privately on Solaris and SmartOS at several large companies and I have never seen it go into read-only mode. The team which designed ZFS was only five people, not an army.
Bryan Cantrill summed it up so profoundly when, upon showing SmartOS running Linux applications, he ran /native/bin/dtrace and proclaimed:
I have clean water!!!
And while all that is constantly changing, its still possible to compile very old user space software and run it in on a current kernel.
On SunOS, I can install a driver built on SunOS 5.5.1 (Solaris 2.5.1) on the latest illumos or Solaris-based OS, without recompilation, thanks to the device driver interface / device driver kit ("DDI / DDK"). Solaris 2.5.1 came out in 1993; illumos came out, well, today (multiple commits every day).
Is the same possible on GNU/Linux?
I'm sure we could have something cleaner with a single, coherent team. But we also would have something that'd be useful to far fewer people.
Linux wins not by being best at everything. It has plenty of ugly warts. It wins by being accessible ranging from e.g. my ability to just take a job 20 years ago to port it to a custom x86 board with no bios or hard drive, because everything I needed was easily available, to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development, to the ability for people to just write "yet another filesystem" and have actual real people try to use it and give feedback and contribute code.
The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.
But with it, it stands head and shoulder above all kinds of technically very impressive solutions because I can do things with and to Linux that I can't do, or can't do cheaply enough or in short enough time, with alternatives (and yes, that can be because of lack of knowledge of alternatives, but that too is part of the community/network effect).
Don't underestimate the importance of people.
> The team which designed ZFS was only five people, not an army.
And that's great. But the whole ZFS saga is also an illustration of how licensing early on can hamper adoption (KDE vs Gnome is another good illustration of how important license is; and how lasting the effect can be even after the licensing issues are sorted)
This warrants a reply of its own, since it is the core idea of my essays: it is the very difference between a stable, working, reliable product and Linux: the people. The right people. Competent people. People with the neccessary education, experience, and insight.
If if ever need heart surgery, I guarantee you that I won't go to the local shaman, no matter how happy he will be to perform the operation voluntarily and for free. Same goes for the local exorcist. If I ever need one, I'll get my surgery done by a specialist in cardiology, because they have been formally educated, formally trained, and have the requisite experience to operate on a human heart. And in the case of illumos / SmartOS, they will even do it gratis, like "medical doctors without borders" organization does. Right people for the job. For some reason, people here and at large believe that when it comes to inter-process communication, NFS, or writing operating system kernels anyone can do it.
Why exactly people believe that computer science is different from surgery, I haven't discovered yet, but based on empirical evidence of Linux and other crappy software, I have a hypothesis, and since the sample size is large, I might have a theory soon...
Which is why I wrote what I did.
Your reply manages to turn it entirely on its head.
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
There are certainly niches where it is life and death. Let others take care of that - I don't want anything to do with it.
And it shows. However, just because you can get something to work, in some way, does not suddenly make you (or anyone else) a professional. Case in point:
http://meta.serverfault.com/questions/6229/frustration-when-...
...Nor does it make your playful experiment fit for production where people like me are trying to get work done.
"I got something to work. Because Linux! Because community! Um... I think I'll go get a job as a computer professional now. What could possibly go wrong? Linux is so awesome!"
People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.
An operating system's kernel is an extremely complex, special piece of software. A bug in such software can cause many people to die, which is why someday you might see disclaimers about running a nuclear facility and fitness of purpose. (Interprocess communication, the original topic, is part of an operating system's kernel.) Writing and diagnosing such software requires very deep insights, which very few have, even among computer professionals. Additionally, it absolutely and without fail requires formal education in the problem domain, it requires experience, and it requires apprenticeship, and I'm writing about physical one on one mentorship. It's not something one can pick up "from the community", never has been, and never will be, and if anybody tells you any different, they're either dangerously ignorant, or lying to you for the purpose of their own agenda.
Experimenting is all good and well, but when the entire armies of you start deploying your experiments in production and it becomes a trend and then the rest of us are, in fact, forced to take on such jobs because there aren't better ones, then it becomes a systemic problem. Not to mention that armies of you are currently in the process of artificially driving salaries down and it will be years before the market self-corrects, so make that a double whammy.
Now, me, I don't so much mind that cheap Linux labor is artificially driving salaries down, since cream always rises to the top, as they say, but I do so very much mind being forced by contract to work with things like ext3, which is based on concepts from the past century and which have since been long abandoned elsewhere, or that my really cool super slick database becomes unstable because of your experiment ticking underneath it (and before you ask, if it were up to me, I'd never put my database on your experiment). I mind even more when your (plural) experiements end up causing a priority 1 incident in the wee hours in the morning, when I'm busy getting my beauty sleep. In my case, you see, it's "because client contract!" Slightly different slant on things than in your case. Welcome to the industry.
The guys didn't have to get out of Oracle to reinvent the wheel: the engineering they did is sound and tenable enough for decades into the future, so they built upon it.
OTOH, some of the above you mentioned isn't bad. Linux's "just a kernel" philosophy can be useful, and allows people to experiment with new inits (s6, runit, &c) and new systems that come in handy.
And go see Brendan Gregg's talk on Linux tracers. It's not as simple is dtrace, given the tracing war hasn't been won, but it's at a place where you CAN do most of the things dtrace does.
Yes I am, because I picked a highly reliable, stable substrate to build my own private infrastructure on.
As for using Linux, I'm not dropping Linux until LX-branded zones can run Steam, and my game library. And I don't see that happening for a while yet.
It may not be ideal for infrastucture, but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
I chuckled when I read that, and I want you to know that I appreciated it.
but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat.
I have Mac OS X for UNIX on the desktop. Works like a charm, and never gets in the way of what I'm trying to do.
Have you looked at alternatives to GNU/Linux, like PC-BSD or FreeBSD? Did you find those inadequate / too much overhead?
I agree, that makes perfect sense.
and in any case I doubt they're good enough to get the games talking to my GPU properly.
Now that's a whole different story: NVIDIA provides Solaris-native packages for their drivers, and they JustWork(SM). Way back in the day, NVIDIA engineers were stunned that they didn't have to produce a completely recompiled driver for every Solaris release: thanks to device driver interfaces/driver development kit[1], one could develop the driver on an ancient version of Solaris and have it work flawlessly on the latest-and-greatest one.
When I wrote that I'm using Mac OS X, that was the truth, but it wasn't the entire truth: I am typing this on my intel-based workstation I put together myself, with Solaris 10 running on it. And it has an NVIDIA GTX 980 accelerator, the top of the line model one could buy at the end of 2014. Downloaded the driver from NVIDIA's site, installed it with pkgadd(1M), and it JustWorks(SM)[2]:
> pkginfo -l NVDAgraphics NVDAgraphicsr
PKGINST: NVDAgraphics
NAME: NVIDIA Graphics System Software
CATEGORY: system,graphics
ARCH: i386
VERSION: 343.22,REV=2014.09.11.17.06
BASEDIR: /usr
VENDOR: NVIDIA Corporation
DESC: X and OpenGL Drivers for NVIDIA Quadro graphics
INSTDATE: Dec 04 2014 22:37
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 188 installed pathnames
30 shared pathnames
2 linked files
42 directories
7 executables
405482 blocks used (approx)
PKGINST: NVDAgraphicsr
NAME: NVIDIA Graphics System Device Driver
CATEGORY: system,graphics
ARCH: i386
VERSION: 343.22,REV=2014.09.11.17.06
BASEDIR: /
VENDOR: NVIDIA Corporation
DESC: Kernel Drivers for NVIDIA Quadro graphics
INSTDATE: Dec 04 2014 22:37
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 6 installed pathnames
3 shared pathnames
3 directories
52151 blocks used (approx)
As for Mac, OS X has plenty of major and indie titles in the Apple app store. But, it's for people who are actually willing to pay for that.
And now, because you didn't ask for it, Game Reccomendations:
Have you tried out TIS-100? You can get it through Steam, and maybe a few other places, it runs on Mac, and I'm willing to bet it'll run in an LX-brand. It bills itself as "the assembly language puzzler nobody asked for," and has a focus on minimal instruction count, maximum speed, and paralellism. You should know by this point if you're interested.
You also may want to check out Xonotic, which is an arena FPS with a relatively lively community, which may compile on Solaris. Think a mixture of Quake and UT.
Apropos Qt, it is not for the faint of heart: even on platforms it officially supports, it is very hard to build, at least it was last I had to do it professionally, back in 2013. Qt is really unprofessional as a product, I remember it involved a lot of hacking and coercion of the build engine to get it to build. And it's monstrously large.
Post scriptum:
ah, "Xonotic" is a fork of "Nexuiz". Okay, that's clear now. "TIS-100" is a puzzle game. So these are individual titles, not technology which enables running on a different operating system. "The Ur-Quan Masters" used to build and run superbly on Solaris; it showcased just how good of a gaming platform Solaris could be if the code is good and clean.
lx-brand could be made to work, this screenshot shows it's possible:
https://www.perkin.org.uk/posts/whats-new-in-pkgsrc-2013Q2.h...
I haven't researched how to translate that into the lx-branded zone though (what the package equivalents would be), primarily because I viewed even the above as too much work: for example, the desktop would have to be brought over to somewhere with an X server. I don't see how it could be made to start on the bare metal's display when it's running in one of the hypervisor's zones?
Xonotic should run on Solaris. DarkPlaces, the engine codebase, is fairly portable last I checked.
TIS-100 runs atop Mono, but it's probably not using GPU heavily, so it'll probably run in an LX brand if you can get X up and running. As for running X11 on LX, the answer is both simple in its phrasing and hellish in its implications: X Forwarding.
I kid. Although it does seem like X forwarding is the easiest option. Luckily, you're not forwarding over the net, so you should be fine.
But yeah, it's nice to have a simple discussion about running video games in ways not intended, and what games are good, after spending a while explaining why systemd is a bad idea for the 15th time, because some people are still taken in by the sparkly unit files, and aren't paying attention to the beast lurking below the surface. (If such people are reading this thread, I'll give you a hint: Separation of concerns is a good thing, and if the process will panic the kernel if it crashes, I want it doing the job it's required to do. AND NOTHING ELSE.)
It might be better, but you can't strike out network effects. Because then you just end up with another rant why your thing is superior to that other thing everyone is using.
I am wondering if good old things are not just predestined to be unpopular. Probably only new things can get popular (even if they are just miserable copies of great old ideas). Next generation is more inclined to pick up something from the news than from history books. Next generation has their new lingo, so they will not understand easily old lingo. Next generation is cheaper to employ than older generation, so it's easier to get more in terms of quantity. Most (young?) people want everything, even if mediocre, now, than having few perfect things now, few perfect things later. The world belongs to the youth.