Ironic that JWZ takes offense to the link since the code in question is by Trevor, who is a cofounder of YC.
Mirror here: http://web.mit.edu/ghudson/dev/nokrb/third/xscreensaver/hack...
Mirror here: http://web.mit.edu/ghudson/dev/nokrb/third/xscreensaver/hack...
(he seems to port xscreensaver to all the things he uses, so I can understand not wanting to accept a huge pile of someone else's code in a different language than the rest of the package)
I was able to port many of my screensavers to other platforms easily; in most cases, the savers just have two functions: setup() and draw(), the first of which does any one-time initialization, the second which does all per-frame rendering. One can write a simple wrapper for any platform that initializes the GL contexts and handles user input, as well as any locking/unlocking code.
However, I don't think that would achieve much. Most of the savers were written in very terse, nasty form to achieve the various constraints the authors worked under.
I think it makes more sense to make NuSaver: the design I described (a scene graph, a physics engine, and a bytecode VM, then rewrite the good savers in the VM). In this case, I would probably just adopt an existing C++ scene graph (Qt has one built-in), a physics engine (I adapted Box2D to Qt, but you need a 3D engine), and a VM (I would use javascript).
Yes, this is what I meant. How big a justification does he need to refuse code when such a thing is possible?
But my point is that maybe he has reasons other than being a jerk. If it isn't worth it to you to do it otherwise, why does the discussion start with it being worth it to him?
He's often right (see CADT) but in a way that is jerkish, and that's really limited the adoption of jwz code.
As one of the maintainers of the C++ ABI for an operating system, I assure you, it is best avoided for system components unless there's a compelling justification.
As someone that helps build an operating system distribution, we consider Xscreensaver to be a system component.
Also, for licensing purposes, the GPL, as an example, considers software distributed with the system to be a system component in some scenarios. For example, "GPLv3 has adjusted the definition of System Library to include software that may not come directly with the operating system, but that all users of the software can reasonably be expected to have."
xscreensaver is X11, not GPL.
Why does a C++ ABI really matter in a system distribution? All the distros I've used are internally consistent in their ABI and update all their deps when the C++ ABI is updated.
Not from a distributor's perspective ;-)
xscreensaver is X11, not GPL.
Correct, but since it is distributed as part of the system, or is a component that most users will have, then, as an example, if you link your GPL'd code to Xscreensaver's API, that's ok, because it's considered a "system library".
Really, I was referring to more for the purposes of definition than anything.
Why does a C++ ABI really matter in a system distribution?
Because ABIs create a point of synchronization, and internally for that distributor, that create a flag day where a given set of components must be rebuilt at the same time.
Ideally, for a distributor, you don't rebuild the entire world every time one component changes. You only rebuild what you have to, since every delivery causes new binaries to be produced, which then in turn increases the amount of downtime for consumers that are upgrading.
As such, changing ABIs (thankfully GCC's doesn't change as much as it used to) create unnecessary churn, and if you can easily avoid them, you usually do (as a distributor).
It also means that if a user had their own Xscreensaver module, it too would be required to be using the same ABI.
In short, there's no particularly compelling advantage and a lot of disadvantages for a widely used and distributed component where you want to maximize its availability on platforms.
C++ is just a tool; it's not always the right one. The maintainer has made implementation choices to maximize compatibility and portability. You have to remember that Xscreensaver is designed to be used and executed on a wide variety of platforms, some of which are relatively old.