Hacker News new | past | comments | ask | show | jobs | submit login
Jörg Schilling has died (tuhs.org)
542 points by stargrave 53 days ago | hide | past | favorite | 94 comments

I recognise his name as something that flitted by on copyright pages, for tools that made my life easier, better, and for free.

And sad though his passing is, it marks something else for me - that a person committed to "improving the world a little" is recognised without having made billions in an IPO or become a media celebrity. Maybe we can all aim a little lower (or higher depending on how you see it) now.

Thank you Jorg.

Our condolences to your loved ones.

First of all, compassion and condolences for Schilling’s family.

Second of all, I had a very recent positive interaction with him. I recently was in contact with Mr. Schilling to report a bug in CDR tools. Even though he was (looking back) dying, he was very prompt in replying to me and discussing the bug with me over email. However, even though I gave him a fix, he was unable to apply it, probably because of his poor health.

Thirdly, there is a really serious bug in CDR tools: It will start creating bad timestamps in 2028. That’s not a typo: 2028 (not 2038). Because of how ISO 9660 filesystems store timestamps (8-bit number, 0 is 1900), on 2038 (1900 + 128), unless the 8-bit number is explicitly made an unsigned number (assumed with other ISO 9660 implementations), there will be issues with timestamps. [1]

A full bug report, complete with a bugfix is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990468

A fork of cdrtools with this bug fixed is on GitHub: https://github.com/samboy/iso9660

Again, prayers for Schilling’s family, and he was very professional in his interactions with me, even in his final days.

[1] The issue is with how Schilling’s CDR tools calculates timezones; the time zone becomes an invalid number starting in 2028.

Hehe. I’m not sure someone’s epitaph is the appropriate place to report a bug. On the other hand, after thinking about it, I hope someone reports a bug in one of my tools in my obituary thread :)

Donald Knuth has a unique solution to the “bugs after death” problem. When he dies, TeX goes to version pi, and METAFONT to version e. All bugs become features.

> May his software immortalize him.

I wish we had a better word for what strenholme is doing besides "maintainer".

To have known the deceased and decide to continue their work is something special indeed.

It is sort of beautiful in a way. It reminds me of how people will look back on a musician's discography when they pass. For programmers, maybe looking through their code and the unique voice they expressed through it is what we do.

Well it looks like cdrtools is in need of a new maintainer now, if the outcome is that you carry on the legacy and let the tool live on, that would be great!

Yes, indeed, I’ve been annoyed that there isn’t a maintainer for the Debian port for a while. I will maintain the code based on the final pure-GPL version of the code, to avoid the entire licensing issue.

If Eric Youngdale could come out of the woodwork and retroactively add a “CDR tools, as a special GPL exception, can integrate CDDL licensed code” clause, that might allow us to use Schilling’s more recent code, but, to be safe, I prefer to work with the older codebase to keep the license simple.

> I will maintain the code based on the final pure-GPL version of the code, to avoid the entire licensing issue.

But that's what Debian did already with wodim/cdrkit much to Jörg's dismay. I don't think it received much development and afaik never got BluRay support.

The wodim / cdrkit stuff is what I would maintain -- there are a lot of bugs for it which have been ignored for too long:


> to be safe

If the copyright holder is dead, there is nothing to be afraid of in violating his license, surely...? At worst you could ask his heirs to add that exception.

It'll be up to the estate of the rights holder, and they are less likely to understand the nuances of open source licensing.

Yes. In the 'reverts to copyright' view of GPL, the estate gets full rights and can proceed however they wish. Which, thanks to the Mouse Corporation, is a long time.

> Copyright protection generally lasts for 70 years after the death of the author. If the work was a "work for hire", then copyright persists for 120 years after creation or 95 years after publication, whichever is shorter.


I hope that SCCS and bosh will also have new maintainers. I use them both.

I guess there is a typo the second time you wrote "2038".

Yep, and of course the edit window is now closed so the typo now stays.


> A fork of cdrtools with this bug fixed is on GitHub: https://github.com/samboy/iso9660

I dedicate this repo this his memory. --> I dedicate this repo to his memory.

> While it has not been brought to court, some lawyers, include the Free Software Foundation’s legal counsel, feel the CDDL may be incompatible with the GNU General Public License (GPL).

Which is irrelevant as the code does not contain any GPL code, right?

The cdrtools stuff is GPL because Schilling maintained the code after Eric Youngdale [1] stopped working on it.

[1] Youngdale at one point was one of the Yggdrasil Linux developers, for people using Linux long enough to remember that long since abandoned distro.

Ah! I see. Thank you, I missed this part of the story.

I know as well as anybody that he was a man with strong opinions and a willingness to share them, but he also had a willingness to laugh at himself and his work. In the unlikely event that you ever made to the bottom of the cdrecord manpage, this is what you found:


  Cdrecord has even more options than ls.

RIP Jörg, many probably don't know him, however his work was at the basis of k3b, Brasero and many other software programs that allowed burning CDs in early 2000s. At least that's what I know him for.

Linux expanded and thrived thanks to CD copies and the support of CD recorders was often poor. His work surely affected many and he did his part in bringing Linux to where it is today.

I've burned many a disc thanks to his tools, and going way back! I never had a coaster that wasn't either defective media or my fault.

Thanks, Jörg, for useful tools that have kept on being useful.

Indeed - the name did ring a bell when I saw it, and then it all came back when I saw cdrtools at the top of the list (early 2000s in my case as well).

Thanks Jorg.

He was my colleague several years ago, sitting just one door from mine (but not working on the same projects) He had an office with lot of hardware stacking up. I tried a few times to talked with him about new promising techs like Nix and Rust, to push him a bit outside of his boundaries. He did not really cared and derailed the conversation and asked if the Nix shell was POSIX compliant (I think it was more or less the situation, time has passed...). I didn't follow all the drama with regards to the licensing of his code but it was clear that he had strong opinions and it was not easy to change them.

He was super specialized in C and Unix and I had a lot of respect that he used the same tech his whole career.

You could not ignore him when he was in a room, he had a strong presence. I always saw him joyful. He used to told me some stupid jokes regularly also.

My sincere condolences to everybody that will miss him.

Besides cdrecord, he created several other high quality tools. I especially remember star, a tar with features that made it much better suitable for real-world tape backups than GNU tar. A friend used it to implement a backup system.

I think people in the German nerdsphere had an affection for him because he was a fanatical fan of Solaris, which he liked to get into in all kinds of situations, notably in heated comments on heise.de. It was kind of cute to see such an obviously intelligent guy behave like that. Many geeks and nerds have things that they care much more about than would be considered "normal", after all.

Do you know why those features never got adopted into GNU tar?

Perhaps not on the surface. GNU tar, for instance, to this day uses the pax header fields introduced by star for storing extended attributes.

I don't. But I think it was something about splitting an archive over multiple tapes and / or modifying such archives.

I had a sparc 2000e, running solaris, with a 1tb disk array built of many 23gb, 8lb monster SCSI disks that had already lived a long life in a TV stations video array. Spread over like a dozen SCSI controller channels. slightly flaky.

Many of the things I made that machine do were only possible to me because of Shilling's shared knowledge. Thanks for that.

I shall burn a terminator in salute.

I‘ve had my share of flamewars with Jörg, as had many others. But it was always civilised and never went ad hominem. I will miss him. The few times we met in person, we had some good laughs about many things. Tough, but nice guy. Left too soon.

Oh god, I remember cdrtools. It was such a cool software on the Linux desktop in the 2000s. Converting and Cloning CDs felt simple at Linux where it was notoriously challenging on Windows (I know I know. That's just my impression).

Unfortunately I don't know the other projects of Jörg Schilling.

He created Schillix, the first opensolaris-based distro, before even Belenix.

rip-ping jorg

That's very sad. Like many others, I used `cdrecord` and `mkisofs` back in the day.

But mainly I remember him for his work on SCCS. That code was AT&T proprietary for a long time, but it was open-sourced as part of OpenSolaris. Schilling made it portable and produced binaries for several platforms, including the Mac. He even gave some conference talks on this topic. By the time he did that work, most projects had already moved onto other version control systems. But there are older, closed-source histories of various projects (such as Java) that are still in SCCS, and I find his tools useful to this day for investigating those histories.

Condolences to his family.

Such sad news.

I remember him from cdrtools. It was amazing because I recall that it ran everywhere in the late 90s. SunOS, Solaris, DEC UNIX, FreeBSD, Linux, etc. That was remarkable for a piece of software that interacted with hardware.

One of the main reasons I started using Linux was to reliably burn CDs, and cdrecord was part of that.

The same hardware on Windows was very hard to dedicate enough power to the recording software in the 95/98 era.

There was also a Windows port of cdrecord that worked. I remember using it.

Indeed. I still use the Windows port of CDRtools to burn CDs in Windows; CDs burned with Microsoft’s built in tools can have issues (such as, if I’m not careful, burning with a UDF filesystem which some CD players will not recognize; also the Windows CD burner can have issues burning a CD which is sector-by-sector the maximum size a given CD blank can fit) which are best fixed by using Schilling’s software instead.

Very nice guy!

I will remember him for his CDDL flames and my invitation for him to answer the CDDL/GPL debate over at the brand new SE OSS site right at the launch in 2015, which he gladly accepted.

I vaguely recall making this question explicitly for him to answer, seeing that he was already on the site, and me needing a total of 10 QA entries to get an Area51 badge for a follow-through on the launch of the site as a founding member. He didn't disappoint and provided a great answer!

He was not shy of having a good argument and defending the position he thought was correct even if such position was extremely unpopular and futile to have and to defend:



Very sad to learn he's gone. RIP.

It's unfortunate that we'll probably never get a legal answer to the question from any authority - but it appears that more and more people are considering them to be "compatible enough" - see Ubuntu shipping ZFS in the default image.

It boils down to being a contractual dispute, and until the stakeholders decide to spent the millions of dollars to battle it in courts, it'll remain an unanswered question.

Of course, the difficulty of many GPL projects is in identifying the stakeholders, and getting them to agree on action.

The real risk comes from OpenZFS, where the majority of the copyright is held by Oracle (formerly Sun). Oracle is an evil, evil organization in regards to IP, so I can only assume their reason for not taking action is 1) it's not worth their time or 2) they're waiting until a big wealthy organization depends on it before they can spring their trap.

> they're waiting until a big wealthy organization depends on it > before they can spring their trap

I don't think they can any more. The principle of laches applies: https://en.wikipedia.org/wiki/Laches_(equity)

This is why Microsoft's threats against the Linux desktop in around 2007 failed: the IP that they claimed, the Windows 95 desktop look and feel -- Start menu, taskbar etc. -- is stuff that Microsoft 100% did invent, but 12 years later is...

Well, _the Hitch-hiker's Guide to the Galaxy_ was published 42 years ago today, and it still rings true. To quote Chapter 3 of the Guide:

"You've had plenty of time to lodge any formal complaint and it's far too late to start making a fuss about it now."

ZFS has been included in Ubuntu since 16.04. Oracle has known and has had five years to raise an objection. It has not done so. It is now too late, by the principle of laches.

It may try, of course, but the lawsuit should be pretty brief because the defense is right there: why didn't Oracle file a complaint in 2016?

Thanks, good to know!

> Of course, the difficulty of many GPL projects is in identifying the stakeholders, and getting them to agree on action.

I should highlight that this is the reason the FSF has the "copyright assignement" clause, because they understand well that without it, the GPL is hard to enforce.

Sadly, such a clause has been co-opted by other companies to give them the power of relicensing the software under more closed terms.


Profile: Jörg Schilling (2005) - https://news.ycombinator.com/item?id=28827572

I think many can remember the sheer magic of their first cdrecord run (and the terror of producing a coaster). Instantly recognizable name, really sad news.

I remember that magic as well and also that cdrtoools ran very stable - while buffer under-runs often ruined the then expensive CDRs on Windows. RIP and condolences to the family, he was one of the little known IT heroes despite probably millions having used his software.

cdrecord first induced me to try Linux in 1997. I had spent $400 on the Sony 2x CD burner with the caddy but Windows wasn't stable enough to reliably burn a disc. cdrecord was free and worth changing operating systems for.

For years there was nothing else as dependable as cdrecord for me -- a true gift from a gifted. Sad news.

Damn, I remember working with him to bring cdrutils to solaris back in the day, he was quite no-nonsense but we had quite a lot of fun on irc poking around, star was always faster than gnutar too.

Will raise a glass to you tonight, friend.

"May his software immortalise him."

I wish this was true just a bit. Software goes away with the time almost like no other human artifact.

Sad but true, that was also my first thought when reading this sentence. Especially since he is best known for writing CD/DVD recording software. Small anecdote: this March, I have upgraded my desktop PC, and the new motherboard doesn't have a PATA port, so I haven't been able to use my Plextor CD/DVD recorder anymore for a few months. But I haven't really missed it enough to get me to buy a PATA interface card. And even before, I was only using it to rip audio CDs - I can't really remember when I burned my last CD (or was it a DVD?)...

I mean, unless it's a particularly special PATA drive, why not get a SATA BD-Writer?

I have a USB-3.1 BluRay writer I use for burning 50GB-100GB BDs with family photos/videos (alongside other media).

The downside is that buying a portable HDD is significantly cheaper TB for TB but I feel they'll fail quicker, who knows, so I keep copies on both.

> buying a portable HDD is significantly cheaper TB for TB but I feel they'll fail quicker

It depends on your usage model. If you "burn" a HDD and store it in a drawer, then pull it back after 15 years, chances are it will work fine - whereas the CD might well have lost a lot of data. It might not be cheaper per TB, though.

I think flash drives and SSDs decay a lot more quickly than traditional magnetic HDDs, and may decay more quickly than CDRs.

As a practical matter, I can generally read 20-year-old CDRs I burned just fine (I have only had issues with cheap CDR blanks, such as Fry’s old house brand); for things I want to last long-term, I use archival grade CDR blanks.

I've been burning to Blu-ray and putting a sha256sum file on the disc with the contents so that in theory, I can check the sums every so often and re-burn them to increase the longevity.

Granted I have not been using archival grade Blu-ray's because the cost to store terabytes is prohibitive.

As an aside, as a favor to your loved ones, I would put only really really important files on a single archival grade CD-R or, at most, DVD-R. This should be a really concise “here is the stuff worth remembering after I pass away” collection of files.

As someone who lost three close family members in the last five years, the last thing your relatives will want to do after you die is go through multiple terabytes of unorganized files to try and find relevant pictures and other heirlooms worth keeping (one relative had a nicely organized folder with relatively few important pictures on his hard disk, so I was able to fairly easily make a DVD of his photography for the family).

My “after my pass away” CD-R has one picture I took per month, starting in the mid-2000s decade when digital cameras started being widely available. There are notes about who is in each picture, where each picture is taken, and other relevant details about the pictures.

I also have 320k MP3 files of the better music I have composed over the years, since I am also an electronic musician.

In terms of open source software, it’s more likely than not that one of GitHub/GitLab/Sourceforge/Bitbucket or even Sourcehut will outlive me; my important projects are on multiple Git hosting services. Even if all of today’s Git repos go down, important software will be uploaded by others to what passes as Git to whatever repos exist in the future (See: The number of open source projects when never used Git mirrored on GitHub)

I'm sorry for your loss.

You make very good points and these are things I've put some thought into (particularly) since becoming a father.

The only stuff I consider really important is the photographs and videos, most of the things before our child(ren).

I think the interesting and most important point I've taken from you here is putting the "what/who/why/where".

We were looking through my childhood photos/videos at my parents recently but had no context for some of them and the people who might have known are no longer with us.

As for code, all of my code is open source when I finish a project (rare) but nothing that the world would miss (so far) so I haven't put any real effort into preserving it.

I think, for keeping pictures long term, the best format is to buy a photo album (but not one with sticky pages -- those go bad) and print out the pictures and put them in the album. I have a photo album with a number of pictures and handwritten notes about where I was, who is in the picture, and what we were doing.

Second best option is an archival grade CD-R or DVD-R (but not Blu-Ray: There was/is not enough support for Blu Rays, but at one point, CD/DVD support was universal), with the contents clearly marked on the front of the disk so your loved ones can quickly know what is on the disk. Images should all be in .jpg format (converted as necessary), and notes should be in .txt files. (.webp will probably work long term, but I would use .jpg to ensure compatibility, since that is the lowest common denominator format for photos)

Music, if one is a composer, should be either 16/44.1 .wav files or 320k mp3 files; the music files should be in stereo.

I would have videos be 24p (24 frames per second) or 30p (30 frames per second) 720p resolution (hi-def: 1280x720) video in H264 .mp4 format. Be careful: Some open source applications will write a .mp4 they themselves can play, but won’t play (or won’t play well) on other video players. H264 format .mp4 looks to be pretty much universally compatible, however. I suggest keeping the resolution and frame rate down to minimize problems.

It's an interesting problem, but obviously not one in willing to guess at.

I guess I'll find out in 20 years or so which lasted longer.

The video cassettes my parents recorded my childhood on in the 80s and 90s are still going strong, I don't know if modern media will last as well.

The pen drive my wedding photographer gave us our photographs on was used exactly once, I tried it ~5 years later and it's was dead.

I suppose each form of media has its issues so I'm simply trying not to rely on any single technology.

It depends very much on the materials used and the development quality.

But we know who he was, in the nerd-sphere.

Bad software sticks around forever though.

>I wish this was true just a bit. Software goes away with the time almost like no other human artifact.

You might be surprised. Vernor Vinge's A Deepness in the Sky (recently discussed here) describes in some detail the job position of programmer archaeologist (<https://en.wikipedia.org/wiki/Software_archaeology>).

I haven't thought about him in ages, or cdrtools, but I benefited heavily from his software once upon a time. The cdrtools flamewars seem positively quaint these days. Clearly a talented developer and his work definitely was a help in open source catching on.

    We will of course also remember him for his flames.
No kidding. I remember pretty well the cdrecord drama back in the day if only from a distance.

Very sad to hear this news. RIP.

What was the drama?

This seems like a clear analysis.


Hopefully, someone (maybe me) will step up to plate and maintain the Debian fork of CDR tools again, for Schilling’s memory if nothing else (and to fix bugs, such as the issue with post-2027 CDR images [1] which I have already fixed).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990468

Follow up ("The unending story of cdrtools", 2009): <https://lwn.net/Articles/346540/>

Aside form the licence stuff already linked there were also endless flamewars on how to specify devices when invoking his tools. Schilling was a proponent of SCSI-adressing, and pretty much everyone else wanted to use /dev.

I think his last posts on Heise.de Forums were from around Sep 18 2021. On heise.de he commented almost daily, on all sorts of topics.

I never interacted with Mr. Schilling, but when I saw the title, I was telling myself: "Jorg Schilling, Jorg Schilling, I know that name for sure" - then I remember: I would see that copyright notice a thousand times waiting on a mkisofs + cdrecord session back when GUI tools weren't quite there yet.

In Hebrew they say: חבל עד דאבדין ולא משתכחין (well, technically it's part Aramaic)

Rest In Piece and honor for paving important stretches of the road on which the world of software marches on.

I clearly burned a lot of CD-Rs in my day because I immediately recognised that surname but didn't know why. Condolences to his loved ones.

It's wonderful to see his OSS work celebrated. One can only hope to be recognized for great work like this at the end of their life. I don't do much open-source work, and most corporate systems I worked on will probably be obsolete by then. Alas! A life comprises many things.

I didn't know him, but saw him on at least two different projects. He contributed a hell of a lot (including the first standalone OpenSolaris distro) and seemed like a man of very clear and definate tastes and principles.

I'll continue to remember him fondly

We (engineers in Sun/Solaris) have couple of opportunities to meet him and discuss with him. He was really unforgettable personality on FOSS scene. Many thanks Joerg for your work and opinions.

We had our differences, but in the end he was a great developer. May he Rest In Peace.

if I use Mastodon, is there a way I can re-toot that?

You can share it as a link.

There are also a few (one-way) bridge gateways.

So ... kind of.

A true software hero was lost today.

My deepest condolences to the family and friends.

RIP schily

Uncompromising on software reliability, worthy of respect

I used star as part of my companies backups for many years.

I loved his opinionation.

Fuck cancer.

We will miss you schilly.

Thanks for all your excellent software. May you code in peace with the *nix gods.

Not really. Your linked post is referring to a retweet of the announcement by fuz (Robert Klausecker) on twitter (in German), while this thread is linking to his original post in english as email.

Note that "dupe" refers not just to a single link but to a given story. Generally the first submission is given preference, though here HN mods elected to stick with this later submission (there were several others posted within a few hours of each other).

I agree that this is a more informative link.

RIP Schily

Isn't this the sort of death that warrants the HN black bar?

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