Profile cover photo
Profile photo
Ingo Schwarze
Free software developer.
Free software developer.

Ingo Schwarze's posts

Post has attachment
Sometimes, nature can be beautiful even on the fringe of a city. Six pictures of tonight's sunset in the woods just east of Karlsruhe, and looking down on the city.

Post has shared content
#OpenSSL contacted on the order of 1000 contributors yesterday because they want to change the OpenSSL license to Apache 2. The script they used to extract the list of people from their repository history does not appear to be very reliable, it clearly mis-attributes some commits to the wrong persons, so i have little evidence to believe that the list of people they contacted is accurate. The mail sent out contains the sentence "If we do not hear from you, we will assume that you have no objection."

I asked Rich Salz whether he thinks the way they are doing this is legal. He answered, but avoided the question. I insisted and asked again. His answer was: "I cannot comment on this. There are reasons for why we are doing what we are doing." I wonder what that means. Do they think that what they are doing is illegal, but insist on doing it anyway? It almost sounds like that. Or are they unsure whether it is legal, but don't want to think about it? That wouldn't be much better...

Regarding how to do such a change in a legal manner, read my recent post on misc@:

Resharing Michael Lucas' take on the matter because it is so much to the point...
Silence is not consent.

Not in contracts. Not in sex. And not in #OpenSSL.

Post has attachment
Yet another nice Unicode XKCD...

While there is no doubt about the usefulness of Unicode in general, and while i do see the usefulness of having large numbers of rarely used codepoints (for example for extinct writing systems), all that has the ugly consequence that the average usefulness of codepoints is rather low, and the ratio of difficulty to usefulness for any given task is rather high (unless you write an arabic journal article about a linguistic comparison of Cuneiform to Hangul - then Unicode may actually provide about the right level of complexity). Adding a bit of ordinary going overboard that is hard to avoid in any large project, the following neatly sums it up.

Via: +Michael Jostmeyer

Post has attachment

Post has attachment
+Kai Baesler asked about reStructuredText. Posting independently because Google+ appears to consider this too long for a comment.

See my original Undeadly article: "There are a few others (for example AsciiDoc, reStructuredText, ...) but i dare not judge them because i have too little experience with them." I later noticed that AsciiDoc may be related to the DocBook toolchain, which sounds bad as far as it goes, but of course that only concerns implementation, not necessarily language design. But i don't know reStructuredText at all. Also see - "compatibility checks: look at pages generated from reStructeredText, e.g. devel/mercurial hg(1). These are a weird mixture of man(7) and custom autogenerated low-level roff stuff. Figure out to what extent we can cope. For details, see - noted by stsp@ Sat, 24 Apr 2010 09:17:55 +0200; reminded by nicm@ Mon, 3 May 2010 09:52:41 +0100" So far, i never really looked.

Having a very brief look (at the language design, not at the man(7) output module as requested in the TODO above) reveals:
- It is less starved for features than markdown, yet doesn't appear to go overboard with featurism.
- There appears to be some redundancy. For example, in a format designed for simplicity, it is not clear to me that definition lists, field lists, and option lists are needed as three different list types.
- Well, there is some featurism. The spec is too long to study in detail for such a short comment.
- It claims the design is not intended to be solely geared towards HTML, which would be good. It does not allow embedded HTML, which is definitely a huge advantage.
- Block scoping/indentation rules are clearly simpler and probably better, which would be little surprising in something related to Python.
- At many places, it allows arbitrary punctuation characters for markup elements. That is bad because it invites additional context dependency and maybe ambiguity.
- Escaping rules seem simpler.
- Inline markup syntax may suffer some of the same issues as markdown, but at least precedence rules look simpler.
- Given the length of the spec, i see ample opportunity for issues that escaped me during my first reading.
- Standardization appears to be better, and there may be less ecosystem fragmentation.

In conclusion, it is clear that some of my criticism of markdown applies to reStructuredText as well (in particular context sensitivity and mixup of semantic and presentational markup, and probably more), but i see some likelihood that reStructuredText might be a substantially better language design than CommonMark. Take that with a rock of salt. I can't really draw a final conclusion without writing a parser or a at least a formatter for it first.

Oh, i forgot to say, but maybe that goes without saying: Quite obviously, any of LaTeX, roff, and HTML are vastly superior to reStructuredText. So even if it would really turn out to be better than CommonMark, i would still strongly advise against using it when you have a choice.

Post has attachment
*More on markdown: Standardization*

Regarding the rant against markdown that i posted four days ago, an user calling himself "patrik" asked me:

> Did you consider targeting ?

Here is my answer:

"Not before implementing the output mode.

Because of your comment, i worked through the CommonMark specification, fixed about half a dozen bugs in my implementation where it violated CommonMark, and added a link to the mandoc(1) manual page.

The basic idea of the CommonMark project is laudable: consensus-based standardization as compatible with existing practice as possible, a reference implementation, and various testing tools.

Actually reading what they have so far, and what they consider almost finished, is not so much fun. The original idea of markdown was simplicity. The CommonMark specification is very long, very complicated, and in some places complicated to the point of absurdity. As the worst example, just read the long chapter about delimiter runs, which culminates in a list of seventeen (!!) precedence rules. Even though i inspected most of the rest, I'm not willing to study and implement that. It is plainly going over the top. There are various other examples of excessive complexity in the specification.

Ultimately, it only reinforces my point made in the Undeadly article above. The markdown language is utterly ill-designed from the ground up, and no standardization effort can cure the numerous ailments. It ought to be abandoned outright. DO NOT USE IT. If others force you to produce documentation in markdown, consider writing mdoc(7) instead and converting to markdown with mandoc. Comparing the CommonMark specification to the mdoc(7) manual, writing mdoc(7) is several orders of magnitude easier, and you get semantic rather than very primitive presentational markup."

Post has attachment
Also discussing markdown in general.

Post has shared content
mandoc-1.14.1 released.

A new release of the portable version of the best documentation management package on the planet. Coming to you soon, thanks as ever to +Ingo Schwarze​ and other contributors and downstream maintainers.

Post has shared content
Heh, Michael himself also posted about it...  :-)
I felt that publically available manpage repositories were lacking in one aspect or another (incomplete, hard to navigate, only offering plain text), so I set out to improve an existing one: the Debian manpage web repository. Check out e.g. for an interesting entry point, showcasing a couple of features.

For the full launch announcement, see

Hope this is useful to some of you!

Post has attachment
Michael Stapelberg just redeployed the official debian manual page web server, some months after it broke down because it couldn't cope with the traffic.  For generating the HTML code that is served, he now uses - mandoc!  So debian is not only the first major Linux distro to package mandoc, but also the first non-OpenBSD operating system to use mandoc for its official online manual pages (as far as i'm aware; both FreeBSD and NetBSD did have plans in the past, but they don't appear to have implemented them yet).

So far, i didn't look at the details of the implementation, but the feature set is impressive: support for multiple releases, multiple languages, links to the package tracker, and yet short URIs in the style developed for  In general, a very clean and nice user interface for both input and output.  No apropos(1) functionality yet, but given that it's serving static content, that would be even harder to accomplish than the work already done.  The research performed by Javier Fernandez Sanguino and Michael Stapelberg on available tools and performance is also quite interesting.

And if all that isn't enough - the first beta of the debian manual pages web server was set up more than a decade ago by Frank Lichtenheld, of sarge release assistant fame, who was my student (among the best i ever had) when i worked at the university years before that, and my team leader when i worked in the industry years after that...  No, this is not a small world, but most of us know but a small part of it.
Wait while more posts are being loaded