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

In the analogtv.c source code, by Trevor Blackwell (part of XScreenSaver) is this comment [1]:

    A maxim of technology is that failures reveal underlying
    mechanism. A good way to learn how something works is to
    push it to failure. The way it fails will usually tell you
    a lot about how it works.
To mimic the image on a 1970s-era colour TV, XScreenSaver uses an accurate DSP simulation of all the analogue circuitry, including bandwidth limits, noise, and distortion. A gigahertz processor is just capable of keeping up with this.

[1] In XScreenSaver: a collection of free screen savers for X11 and MacOS by Jamie Zawinski [2].

Edit: if you want to read the source code---highly recommended!---retype the address below by hand or you'll become acquainted with jwz's countermeasures.

[2] https://www.jwz.org/xscreensaver/xscreensaver-5.34.tar.gz

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

I think he's had that HN redirect for years. He is blocking hotlinking directly to files.

Try https://www.jwz.org/xscreensaver/

No, he blocks/redirects all traffic with HN as referrer. Kind of a jerk move, which sucks because his site is full of useful stuff.

jwz is a smart guy, but ultimately ... a bit inflexible and jerkish. I used to argue with him over using C++ in xscreensaver (I wrote a couple savers, glplanet, pulsar and glextrusion). I wanted to write a full scene graph implementation, a physics library, and a bytecode VM to implement screensavers without having to write a ton of low-level C++ code. Unfortunately, jwz's constraints include "Every screensaver must be a single C file" and "no C++", which while possibly wise when he first expressed it, has become a canard.

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.

What would be the problem with releasing all that stuff with some other name?

(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 am not an expert on licenses, but since jwz chose the X11 license, it may be possible to take the screensavers and releasing them under another name. I don't know what that would achieve.

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

I think it makes more sense to make NuSaver

Yes, this is what I meant. How big a justification does he need to refuse code when such a thing is possible?

It's not worth it. Most ppl screenblank so savers are mostly for nostalgia these days.

Sure, I assumed as much.

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?

I suggest learning the full history of the thing which is jwz to understand why jwz is a jerk. He's amazingly smart, but extremely impatient and outright hostile to nearly every software engineer he encounters.

He's often right (see CADT) but in a way that is jerkish, and that's really limited the adoption of jwz code.

Correct. Even / redirects to imgur if the referrer is HN.

That redirects to imgur.

Copy and paste the url.

Looks like JWZ didn't like your linking, and it now has a redirect to an offensive(?) picture on imgur

I assume it's temporary. For posterity, the image is http://imgur.com/32R3qLv

No, he's been blocking all links from HN for a while.

To open jwz links, right click > open in incognito window.

He blocks links coming from HN. I believe he always has.

no, it started after a few times people posted jwz links on HN and he didn't like the comments he got from HN users.

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