Hacker News new | past | comments | ask | show | jobs | submit login

There's nothing wrong with asserting "no C++" in systems software, especially on *NIX. The stability of the C++ ABI has generally been terrible for a long time, and by avoiding C++ in a component that's heavily used, a lot of maintenance headaches are avoided.

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.




xscreensaver is not a "system" component. Nor is it systems software. It's a game engine that only rarely takes user input.


Xscreensaver is a security boundary, and has been better at avoiding lock screen bypass hacks than many other screensavers.


It's a system component in the sense that it's typically distributed as part of an operating system. Not in the sense that it's a "kernel" or something like that.

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."


Your definition is weird. Which distribution is this?

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.


Your definition is weird.

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).


what does an ABI matter here? Nearly all platforms that xscreensaver runs on produces its own self-consistent ABI and then links the apps against that ABI. When the ABI changes, the apps change with it.


An ABI matters here because it means that the Xscreensaver component would have to stay in step with the compiler component, which means you've created an extra build time dependency.

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: