[ ! -z ${COC} ] && exit 1

There has been some turmoil about FreeBSD’s new Code Of Conduct lately. While it was meant to maintain peace in the community, it actually lead to the opposite: Two fractions are more hostile towards each other than ever – and the new COC allows to simply get rid of unwanted (by one such group) persons.

Disclaimer: I’m just a FreeBSD user and advocate. I work with my OS of choice, write about it and encourage trying it out. However I’m not directly part of the project – and while that has been a mid-term goal for me for some time, that way is probably blocked for me now.

What’s a Code Of Conduct?

Basically a Code Of Conduct is a set of rules for people to follow. If you join any organization that has a COC, reading and understanding it is essential. It will tell you what you are expected to behave like and which behavior is objectionable.

The idea is to write up rules that make sense for the organization and that everybody can accept. It’s often simple things like: Respect your colleagues, shut the door when smoking outside, try to be helpful if somebody asks you for help, etc. In short: Behave decently.

Why all that fuss about it?

So – if that’s all, why write an article about it (let alone make all that noise about that topic)? Well… That’s not all, unfortunately. The main problem is not “a COC” – it’s FreeBSD’s COC. Scroll all the way down to the end of the COC and you’ll see the attribution. It reads: Geek Feminism Wiki. It’s no surprise that this is like a red rag to a bull to for some people: Feminism?! In tech??

People who overreact when reading the term alone should really calm down. Yes, stay cool. Why? Because it’s actually getting worse…


Yeah, everybody knows what feminism means, so why talk about it? Because there’s feminism and there’s… well, “feminism”. While the former is a just cause (unless you’re a true women hater), the latter is a crude ideology. “Feminism” is not about women’s right to vote, to live their lives free from oppression or their right to be an esteemed part of society. It’s about destroying society in the name of a just cause.

“Third wave” feminists will happily taunt married women who chose a traditional family life to be “slaves”. While everybody else knows that it’s a token of appreciation to hold a door open for a woman or help her out of a coat, they will aggressively deny this and state that they can do it themselves. Compliment them and you’re toast. And worse still: Dare to use a word that they deem evil and they will assault you (at least verbally). Plus: They are so obsessed with “minorities” that actual concerns of women come second – at best.

I’ve known a girl who went to an elite school. She spoke Latin fluently (as well as Greek mostly) when she was only 14 (she once corrected me before I even finished a Latin sentence that I read from an old exercise book of mine…). She had a very strong spirit, too, and rejected the religious belief that was expected from her. However she had very humble goals for her own life. When they were asked in school what job they would like to do later, she stated: Housewife and mother. After a moment of shocked silence, she was laughed at. As she told me, that had been the most painful moment in her young life. It’s a shame when a woman cannot become an astronaut if that’s what she dreams of doing. But it’s plain wrong to force women to take up paid jobs if they would prefer to live a traditional life.

Feminism is freedom of choice for women and means that each woman gets to decide for herself. “Feminism” is coercion and doctrine and it means that ideologists decide what women in general have to do (and what not). Feminism is sound, honest and all about emancipation. Whereas “feminism” is cruel, phony and enslaving.


When thinking about freedom, it makes sense to distinguish between what is commonly called “positive” and “negative” freedom. This does not mean that negative freedom is something bad – both freedoms are valuable. To avoid misunderstandings I prefer to speak of active and passive freedom. Active freedom is the freedom to do something while passive freedom is the freedom from something (e.g. paying taxes).

Those freedoms are in a direct and fixed relation to each other: To increase one you have to decrease the other. Want to give people freedom from the fear to be shot in public? There’s no other means but to take away the freedom to carry firearms with them. Other way around: To give women the right to breast-feed babies in public means to take away the freedom of others to never see any bare breasts by accident.

You will always find people who are easily offended by just about anything. And on the other hand you’ll find die-hard folks who demand that they are allowed to do whatever they feel like. Both are rather extreme stances. It’s not terribly hard to see that some kind of balance is necessary between them.

Making an example often simplifies things. So here we go: I like to listen to music. Various forms of Black and Death Metal are my favorite. It’s also quite common that Metal bands use artwork that’s a bit… special. Some of the clothing that I own displays blood, gore and human innards. Nude women are also not so uncommon nor is blasphemic imagery. What I loathe on the other hand is so-called Hip-Hop music. Monotony is a weapon and whenever I’m forced to listen to something like this, my brain twists in agony as I can physically feel getting more and more dull.

What I’m considering beautiful music is terrible noise for most people. I can live with that. I don’t feel the need to complain loudly that somebody just “disrespected” me with such a statement. On the contrary: Taste is entirely subjective. It’s ok that you don’t like my music. I’m also not going to annoy you with it. And yes, the aforementioned kind of clothing is fine when I feel like going to a club or Metal bar. It’s probably not the right thing to wear when going to church. I won’t show it in public – there’s no need to confront people with something that they find is disgusting. At the same time I’d prefer if people would stop annoying me with loud “rap music” and the like in public. I don’t want to have to listen to that! However I’m not going to demand it. I think that people should care for not offending others. But if they think otherwise (or don’t think at all), I value freedom enough to not go all drama about it.

Tyranny vs. democracy

Let’s talk about minorities next. In ancient Greece democracy was not what we use the term for today. Still it makes sense to look at what terms like that come from and how they evolved. Polis is the Greek word for “city”. But don’t think of today’s modern cities – the poleis were effectively city states (you can still recognize “city” in citizen, even if that refers to a state). That Polis is where the word “politics” is derived from; “politics” basically means anything regarding the rules of the city (or state). Tyrannis was what the rule of a single potentate was originally called and democratica the rule of the demos, the citizens. Neither women, slaves nor metoikos (established strangers) were citizens and thus could not vote or otherwise participate in the state affairs.

The very idea of democracy was that by the means of vote, the majority gets to decide. The modern idea of democracy makes one fundamental difference: Even though they are outvoted, minorities can still be citizens after all and thus – to a certain degree – need protection from the majority. This is a very important concept and protecting the weak is commonly agreed to be a noble thing. Therefore this is not where democracy ends as some people may claim.

There is this point however, where the whole thing is getting completely out of control. This is when the noble idea of protecting minorities is turned into a weapon to terrorize the majority. Sounds absurd? Agreed. But just look around you carefully… There’s this idiot making stupid claims and trying to get you into trouble. However you cannot even call him an idiot – because he’s black/gay/jewish/handicapped. That’s right: Attribute xyz doesn’t have anything to do at all with the fact that he’s an idiot, but in today’s society, sometimes that’s all that counts. And that’s where the most important freedom – which is hard-fought and not a gift at all – disappears: Your freedom of speech is gone. You are no longer free to even say the truth just because… Yeah, just because what? Because otherwise your reputation will be destroyed.

That’s pretty bad, yes. But fortunately we’re one step ahead on the path to complete insanity. People are free to arbitrarily declare that they belong to minority xyz – and you better “respect” that! Also they are free to “feel” discriminated by your behavior – and this can put you into real trouble. Don’t want to lose your job? Bite your tongue! Don’t want your neighbors to scorn you? Keep your trap shut! Oh, and welcome to the dictatorship of “political correctness”.

Embracing the absurd

If you want to protect every thinkable minority (and by “protect” mean to ensure that nobody is allowed to act in a way that could hurt their feelings) this is simply an impossible situation. Just one bitter example: Most people would agree that denying the shoah might hurt a lot of jews. But what about the people who… No, stop, you cannot call them holocaust deniers! They prefer to be called “people with an alternative opinion on the so-called holocaust”. And they are certainly a minority.

What about white supremacists? They are a minority, too. Learn to respect their feelings, will you! Or fundamental christians who are absolutely certain that homosexuals burn in hell. This belief is not exactly one that the majority shares.

And when it comes to “feminism”, some people even believe that it is “fair” to penalize others on account of an asserted privileged position in the past. This is when all ideas of equality vanish and certain people demand that discriminating against men/whites/christians/… and preferring women/blacks/$RELIGIOUS_GROUP is a good thing. But let’s not get deeper into this.


People shouldn’t hurt each other, that’s something (almost) everybody should be able to agree to. But it’s not a good idea at all to drive this to the point where it gets ridiculous. FreeBSD’s COC hits this point a couple of times, e.g. when

simulated physical contact (e.g., textual descriptions like “*hug*” or “*backrub*”) without consent

is declared “harassment”. This lead to the FreeHugsBSD fork because the original is now “hugs-free BSD”…

FreeBSD is not very often in the news and if it is, not too many people care about it. In this case however, the forums of the German tech community were full of posts (most of them making fun of us FreeBSD users – and mostly rightfully so). Others are sharing pictures like this.

My personal favorite however is the ban of “dead names”. Sorry people, but most of the time somebody wants to change his or her name, I’m not convinced. I don’t care if James comes back from Syria and wants to be called “Abu Khaled” or if Frank decides you should call him Charlotte. Don’t get me wrong, I wish them well. However I’m pretty sure that it would be best for both of them to go and see a psychiatrist.

Do we need a Code Of Conduct?

In short: No. We’re talking about tech here. If you cannot use UFS because it was created by McKusick – who married a man -, that’s your problem. If you use UFS because it was created by a gay person, I’d also not vouch for your mental health, but to each his own, eh?

Same thing for all those other minorities: It simply doesn’t play any role. Maybe you’re an atheist while I’m not. I’m pretty sure that we can get along just fine if we’re both passionate about BSD (and even if we meet in person and discuss religion, I’ve never had a problem with a polite person that doesn’t share my faith). If you have a disability, it might make sense to mention that on the net because it really affects how you use a computer. But why should you care that I’m a vegetarian? And why should I care if you were “born in the wrong body”? If you love a goat that’s of course a different thing in this case! 😉

But still: Why don’t we keep all this nonsense out of the community and learn to actually get along? Yes, there has often been a questionable tone e.g. in the mailing lists. There’s a lot of room for improvement. But does dictating strange rules really solve the problem?

So what now? Should you rage-quit FreeBSD? Stop donating? Yelling at core and cursing whoever proposed this? Certainly not. The best defence against all this madness – is keeping calm and taking it seriously. Stay with FreeBSD if you can and express your rejection of this disgrace. Freedom is never gone for good. It can return.

I’m out – for now

For me personally, joining FreeBSD is currently not an option. I’m a “live and let live” kind of person. Thus I can get along with people who I consider to be weirdos (and with those that consider me a weirdo – at least for my part in getting along!). Again: This is tech. There are a lots of rather special people around, often with their very own quirks. A lot of them are quite brilliant, too, and you wouldn’t want to miss them.

But never ever, under no circumstances am I going to pretend what certain people call “respect” (thus washing away the meaning of this grand word) for quirks that I can live with but definitely won’t approve of.

Oh, and I belong to various minorities, too, BTW. One is the minority of people who don’t speak English natively and whose tortured sense for grammar screams in pain when they encounter the abomination of a “singular they”. Won’t you have mercy with me? Please?

Blessed be the blind
For their conscience won’t collide
With the cruelty of sanity
And the prophetic signs
In the book of life
– Suidakra, Signs For The Fallen


“Permissive licensing is wrong?” – No it’s not! (2/2)

The previous post gave a short introduction into the topic of software licenses, focusing on the GPL vs. BSD discussion. This one is basically my response to some typical arguments I’ve seen from people who seem to loathe permissive licensing. I’ll write this in dialog style, hoping that this makes it a little lighter to read.


GPL fan: “BSD license? Really? You shouldn’t be using that!”
BSD advocate: “Why not? I like it a lot.”
Fan: “It’s a dumb decision. Don’t you even care about free and open source software?”
Advocate: “Oh yes, I do!”
Fan: “Then why not just use the license everyone uses? In contrast to BSD, the GPL ensures that code remains free.”
Advocate: “No, not ‘everyone’ uses that license. You wouldn’t claim that e.g. the Apache foundation doesn’t do anything for open source now would you?”
Fan: “Most of the important projects do. Apache and some others don’t, I’ll give you that. They should adapt the GPL, though.”
Advocate: “Version 2 or 3?”
Fan: “GPLv3, of course. It was updated for a reason after all! The current version offers much better protection for your code.”
Advocate: “Well… I don’t feel any need for this kind of ‘protection’. But for now let’s assume that you convinced me. Changing the license would be quite a bit of work!”

Simplicity vs. Complexity

Fan: “How’s that? Re-licensing stuff to GPL is pretty straight-forward.”
Advocate: “Reading – and understanding! – the license alone takes quite some time… Which is one reason I prefer the much simpler BSD licenses, BTW.”
Fan: “Nonsense! The GPL has been constructed carefully and is advocated by the FSF. You can read it, of course, but you could basically trust their judgement.”
Advocate: “I strongly prefer to work with things that I do understand myself.”
Fan: “The aim of the GPL is not hard to understand at all.”
Advocate “It’s a complex monster. Sure, I understand what it’s all about. But in life in general – and even more so in law – the devil is in the details. Finding out what I am allowed to do and what not is not an easy task – and it got more complicated with every new version of the license.”
Fan “It’s only as complex as it has to. You admitted that law is complicated and details are important. Of course it had to become more comprehensive over time! That’s for our own good.”
Advocate “‘Of course’? I’d doubt that. The BSD license has seen updated versions as well – and it has been shortened with every new revision… Anyway, my focus is on the software. For that reason I prefer a license that doesn’t distract me for quite some time from what I actually want to do.”
Fan: “You said that you care about your code? Fine. Then you really should avoid BSD licenses!”
Advocate: “Uhm… What?”
Fan: “Linus Torvalds put it this way: ‘Over the years, I’ve become convinced that the BSD license is great for code you don’t care about’. And he’s right.”
Advocate: “No he isn’t. It completely depends on what you want to achieve!”


Fan: “It’s common knowledge that the Linux kernel is so successful because of it being GPL’d so that every company using it had to give their changes back for the common good. Let’s see… How popular are your valued BSD-based operating systems today? Oh, nobody uses them anymore…”
Advocate: “Wow, Netflix, Whatsapp and others who exclusively use BSD are ‘nobody’? Not to mention other users and supporters of BSD operating systems like Yandex and VeriSign. The BSDs are less visible compared to Linux, that’s true. But by simply doing their job well and without all the community drama people are talking less about the BSDs is not a surprise at all!”
Fan: “Now you’re trying to make it look like Linux and the BSDs were on par! That’s completely wrong. Linux has a share of 100% on the TOP500 supercomputers since November 2017. Try to beat that!”
Advocate: “And with Android… yeah, I know what you’d point to next. True: Linux has reached a monopoly worse than…”
Fan: “Worse? What’s bad about open source software prevailing?”
Advocate: “Monopolies are not a good thing at all. I’m all for open source operating systems – mind the plural there.”
Fan: “Heh, you only say that because you’re betting on the wrong horse. Face it: Linux is the winner here and for a good reason!”
Advocate: “*mumbles* Yeah, and if only it had adopted the GPLv3 then it’d be at 200% share on supercomputers now…”
Fan: “Excuse me, could you repeat that just a little louder?”
Advocate: “I just doubt that it’s only a license thing that decides on success or failure. For the BSDs, historically it has been a state of legal uncertainty that was the big problem and allowed Linux to rise. And if your point was really valid – why do we need GPLv3 at all if v2 used by Linux to this day is all that’s required to conquer the world?”
Fan: “You’re just jealous! But sure, the GPL is just one key to the success of Linux. The BSD licenses are also one major factor in the demise of the BSD operating systems.”
Advocate: “There is no demise; there are at least four healthy BSD communities who continue to provide quality operating system releases. The claim that ‘BSD is dying’ has about as much truth to it as the prediction of the ‘year of the Linux desktop’! Of course you are free to prove otherwise.”


Fan: “Freedom is a good point, too! Permissive licenses may grant the user some rights but only copyleft ensures that nobody can take your freedom away. Isn’t that kind of important?”
Advocate: “Yes, freedom is extremely important – which is why I choose permissive licenses over copyleft ones. But we certainly won’t find a definition of freedom that suits both of us.”
Fan: “So that’s something you don’t want to talk about? Then what are you hiding there? Your weak arguments?”
Advocate: “Not really. The problem here is: I know and understand your point of view. Why? Because I’ve been there when I was younger and promoted the GPL. But now that I have a broader understanding of the matter I have a different view on it.”
Fan: “Yeah, just treat me like a young boy. ‘You cannot understand that now, grow a little older and wiser and you’ll be enlightened like me!'”
Advocate: “I didn’t say that. All that I’ve said is that I know your position and that it’s nothing that can be proven wrong easily enough for us to make sense to discuss it without going in-depth on it. If you insist, we should set aside a couple of evenings for a philosophical debate.”
Fan: “Which philosophical debate? I’m still claiming that you’re trying to avoid the topic.”
Advocate: “Yes, I am – for today. It’s a topic for itself and leads too far off for us right now. But here’s the core of the problem: The point of view you have is that ‘enforcing freedom’ is a good thing. From my point of view it is absurd. Force and freedom contradict each other.”
Fan: “Not necessarily.”
Advocate: “So you claim that it’s possible to force somebody to be free?”
Fan: “Hm. Why not?”
Advocate: “Because force takes freedom away. But the problem is in the term ‘freedom’. We use it differently and mean other things. That’s why this specific debate would require a whole lot more time. So can we agree on a draw for that topic for now?”
Fan: “If it really takes so long to discuss, that may make sense. So back to the characters of the licenses, right? But don’t think that I’ll let you get away with such claims on another topic again!”

Better with Copyleft?

Advocate: “So?”
Fan: “Copyleft is also superior to permissive licenses.”
Advocate: “Didn’t we already cover the topic ‘success’? Or do you mean the fact that it’s overriding the terms of permissively licensed code when the two are combined?”
Fan: “I meant something else, but that’s true, too, of course!”
Advocate: “I don’t think that this is a good thing. It’s virulent in nature.”
Fan: “Oh hello, Mr. Ballmer!”
Advocate: “I didn’t say that it’s cancer, even though that’s probably a valid point of view on it.”
Fan: “Anyway, it’s superior because it guarantees that companies using the code contribute their changes back. It’s pure logic to assume that this makes the software better than a competitor where you don’t have to give back.”
Advocate: “Hm… What about the incompatibilities of copyleft licenses?”
Fan: “What do you mean? And how would that impact the quality of an OS or something?”
Advocate: “Well, take ZFS for example. It’s the world’s most advanced filesystem – and it’s licensed under a copyleft license. However that license is incompatible with the GPL and for that reason cannot easily be included into Linux distros! FreeBSD for example doesn’t have this problem. Due to the permissive license of the main operating system components, including ZFS was no problem from a legal point of view…”
Fan: “Ah, we can do without ZFS, we have BTRFS! And if you really want it, you can use DKMS to build it!”
Advocate: “DKMS is quite an inconvenience in this regard and I won’t even comment on that other FS… But that was just one example that copyleft licenses are sometimes not as cool as you’d like to make them look.”
Fan: “Nah, Sun should have open-sourced ZFS under the GPL or at least made their license compatible with it. Then we wouldn’t have that problem.”
Advocate: “The more complicated licenses get, the more edge cases arise that lead to problems. BTW, have you ever heard the comparison ‘GPL is a license. BSD is a gift’?”

Gift vs. license

Fan: “The large corporations will surely applaud your stance on this matter!”
Advocate: “Oh, let’s stay clear of this childish behavior and refrain from insulting each other with poisoned compliments, shall we? Otherwise I’d reply with something like ‘great attitude! Congratulations on it from the national lawyer’s association’. But that wouldn’t be helpful either, would it?”
Fan: “Lawyers are not nearly as bad as the big companies.”
Advocate: “Right. Some of them are supporting your cause. Others are doing the opposite by helping big business to find new loop holes. Both make quite a bit of money without ever improving the code.”
Fan: “Good lawyers are necessary to help protect software. That’s a win for open source.”
Advocate: “If you say so… I still prefer simple things. I like it being a gift.”
Fan: “Others will surely like that, too. It’s a gift to the large companies that only care for open source when they can make profit with it! For that reason making such a gift is stupid.”
Advocate “Not so fast. It’s a gift to everybody. That makes quite a difference!”
Fan: “No it doesn’t. Greedy corporations will end up taking your code.”
Advocate: “Maybe they’ll actually do. But are you really saying: ‘Don’t give a blanket for a refugee – a terrorist might warm himself with it’? Are good deeds wrong if a bad person might benefit from it?”


Fan: “*Sigh* That’s not the point. When you use permissive licenses you are actively asking to be exploited.”
Advocate: “Sorry, that’s simply wrong. Software has the advantage of not disappearing when you give it away. I can give it to multiple people and don’t lose anything. When it comes to free software, the only thing that can be exploited are bugs.”
Fan: “Ha ha, very funny – not. You know exactly what I mean: You are asking to be exploited because you invested time into a project and somebody else simply takes it and generates revenue from it while you get nothing.”
Advocate: “I have a very different view on that. I open-sourced my code in the hope that it would be useful to people. If I had intended to make money with it, I would have chosen to commercialize it.”
Fan: “But they did commercialize it! And they make money from your work!”
Advocate: “Relax! Yes, that’s entirely possible. However I didn’t expect to make money with it in the first place, anyway.”
Fan: “But if your code is useful, somebody else surely will!”
Advocate: “And is allowed to do so, if he or she finds somebody who’s willing to pay for something that’s freely available. I’m still not losing anything, right? Besides: Anybody else could also try to sell it. It’s the same rules for everybody. I’d say that’s fair.”

Ethical issues

Fan: “That’s really egoistic thinking. Supporting unfree software is entirely unethical!”
Advocate: “You didn’t really say that, did you? I’m giving something away. For free, no strings attached and without trying to achieve any real benefit for myself. And you are accusing me of acting unethical?”
Fan: “Actually yes. By not making sure that your ‘gift’ remains free, you’re supporting unfree software.”
Advocate: “Wrong. It does remain free! Nobody is losing anything.”
Fan: “You know as well as I do that the BSD license allows closing your code and using it in closed-source software!”
Advocate: “Errr… Sure. But while you are trying to make it sound like that would mean a loss for open source this is not the case. The original code doesn’t disappear! It remains available under the BSD license and continues to be of use to anybody who wants to use it.”
Fan: “Bah, what a short-sighted argument! Yeah, your original code may still be available, but they will make modifications to their copy. And that’s when you’re cut off from good things that resulted from your code!”
Advocate: “I can live with that.”
Fan: “That’s ridiculous. Come on, don’t be an idiot! They are making others pay for something that was free software and now isn’t anymore. And you said that you care for free software?!”
Advocate: “You obviously can’t understand it. Why don’t you ask for my reasons instead of calling me an idiot?”
Fan: “Because there cannot be a legit reason for supporting unfree software!”
Advocate: “Excuse me but that’s a little bit arrogant, don’t you think? Let me give you an example. Think about Microsoft…”

Closed source

Fan: “Ha! You’re not going to defend M$, are you? You advocates of ‘permissive licensing’ are all the same! Why didn’t you start our conversation stating that you love Microsoft? That would have saved me quite some time!”
Advocate: “Please let me finish my sentences, will you? I certainly don’t love Microsoft. In fact I haven’t installed any Microsoft OS or program at home in about 10 years. I’ve been there when they used their market power with Windows 3.x to destroy DR-DOS. I haven’t forgotten the Halloween papers, either.”
Fan: “So? Windows is a terrible OS.”
Advocate: “Yes, for the versions that I know and have used in the past, that’s certainly true. What I wanted to say however is this: The web is a pretty bad place today and even though a lot was done over the last years, much of the software today is still a nightmare when it comes to security. Agree?”
Fan: “Sure!”
Advocate: “Fine. Especially Windows has been notorious for very bad security flaws in the past and all those hacked Windows machines are ruining the net for us all. Now imagine Microsoft couldn’t have taken the well-tested TCP/IP stack from BSD Unix because it had a different license. They would have been forced to write their own – would you really want to claim that would have made the world a better place?”
Fan: “Probably not… But nobody should use Windows in the first place then that problem would be hypothetical.”
Advocate: “In an ideal world we wouldn’t have any of those issues, right?”
Fan: “Correct. In that case we wouldn’t even need the GPL because everybody would be acting ethically anyway. But we aren’t living in such a world and for that very reason need GPL to support the FLOSS movement. You’re quite good at making esoteric objections against the GPL to make your lax license look better, BTW.”

Lax vs. pessimistic

Advocate: “Esoteric? I’d claim that the one case that I mentioned alone had quite some impact on the future of the net. But if you insist on calling my preferred family of licenses ‘lax’, I’m going to call yours ‘pessimistic’.”
Fan: “Why that? There’s nothing pessimistic about the GPL!”
Advocate: “Yes, there is. The whole idea is. Didn’t you say yourself that the GPL wouldn’t be needed in a better world?”
Fan: “In an ideal world! That’s different. But that doesn’t make it pessimistic.”
Advocate: “It does. You’re considering man to be bad – or at least sufficiently bad that instruments as the GPL are necessary.”
Fan: “They are necessary! That’s a fact. Just look around you with your eyes open!”
Advocate: “I disagree. And in fact I’m even going to top it: The GPL is not only unnecessary, it’s actively harmful.”
Fan: “Now you’ve completely lost your mind…”
Advocate: “Have I? Let me make another example. I’ve grown up using closed-source software. When I discovered open source, I was very happy that such a thing existed and completely made the switch.”
Fan: “And now you’re seeking to ruin it all…”
Advocate: “Not really. I’m actually happy enough with it that I developed a feeling of great gratitude and that created a desire within me to give something back.”
Fan: “That sounds great and all but I have no idea why the heck you are acting against open source.”
Advocate: “The point here is: I give back now because I want to. With the GPL I’d have to. The freedom of choice makes the difference here.”
Fan: “How nice for you! But a lot of people wouldn’t give back on their own and that’s why they need to be forced to!”
Advocate: “And by doing so you’re actively making it impossible for people to really grow ethically and make the morally superior choice themselves! You know, I hate that ‘four freedoms’ nonsense! It’s just a disguise for dictating rules that seem to make sense but in fact deny your freedom! All that ‘respects your freedoms’ is utterly cynical if any person’s most basic freedom – our free will – is denied!”


Fan: “Wow, impressive rant!”
Advocate: “That’s all you reply to the points that I make?”
Fan: “You’re a dreamer. All that ‘ethical growth’ and ‘personal development’ stuff is utopistic. Big money rules the world.”
Advocate: “It sure does, but in the form that we’re seeing today that will come to an end.”
Fan: “I doubt it, but if it does, that will be a victory we can only achieve with the GPL. It’s a powerful weapon we can use to defeat the big corporations.”
Advocate: “To found a world that people live in who never learned to make ethical decisions in the first place because it was already decided for them. Not a world I’d like to live in either.”
Fan: “Not a surprise that you’re defending capitalism and corporate power!”
Advocate: “I’m not a capitalist but I’m convinced that there’s a better way out of it.”
Fan: “By letting it all continue as it goes today?!”
Advocate: “As strange as that sounds – yes. And here’s why: Take companies like Juniper for example. They took FreeBSD as the base for their OS because… Well, it was free and allowed them to close the source and keep it for themselves.”
Fan: “And you like that…”
Advocate: “Yes, I do! You won’t believe it, but they hurt themselves by doing so: More and more new versions of FreeBSD were released and they were stuck with their old system which required a lot of maintenance and updating it got harder and harder since the system diverged a lot over the time. If they had given back as much as they could, they would even have saved a lot of money… Today there are already companies who understood this and even from purely capitalistic motivations started to embrace permissive open source: They give back as much as they can because it benefits everyone (including them).”
Fan: “That cannot be many. Otherwise BSD would be far more popular.”
Advocate: “It takes time for companies to learn. Give them the chance to hurt themselves and to eventually come to a good conclusion on how to act.”

Final victory

Fan: “Even if that was true, in your world open source would never succeed. You’d always feed your code to the companies who will improve it a bit and start selling a product that’s superior. We can never catch up with them this way!”
Advocate: “I’m going to claim the opposite: We’re catching up quickly and there’s no way that we’re not going to win.”
Fan: “How’s that? They will always be a step ahead! Code needs to be constantly improved and they have an advantage there.”
Advocate: “That’s today’s story, yes. But we’re rapidly approaching the point where open source software is no longer a somewhat limited ‘alternative’ to commercial software but simply good enough for just about any task.”
Fan: “And then?”
Advocate: “That’s the moment we’ve ‘won’.”
Fan: “Strange definition of winning… The companies will still sell improved products!”
Advocate: “Well, just let them if they find someone who really needs those additional features and is willing to pay for them.”
Fan: “What do you mean? Of course people want the best software possible and will pay for it! We live in a capitalist society. Your strange ideas won’t change anything.”
Advocate: “My ideas? Certainly not. But the very rules of capitalism itself will eventually defeat it. If you don’t believe me, just tell me: How to beat good enough and free from a capitalist point of view?”
Fan: “Oh my. You really are a weirdo. Keep your faith in mankind being able to change its ways. I don’t have it and will stick with copyleft!”

(Sorry for the delay in publishing this, but last month has been really, really chaotic for me. Two of my grandparents passed away just a few days apart, I had a deer accident (I’m fine but the deer and my car not so much) and I’m in the middle of moving houses… So if you comment on this and I don’t immediately respond, please bear with me!)

“Permissive licensing is wrong!” – Is it? (1/2)

A few weeks ago I’ve been attacked by some GNU zealots on a German tech site after speaking in favor of permissive licenses. Unfortunately a discussion was not possible there because that would require the will to actually communicate instead of simply accusing the other side of vile motives. Since I actually do care about this topic and a reader asked for a post about it in comments a while ago, here we go.

This first part tries to sum up the most important things around the topic. I deliberately aim for an objective overview that tries not to be one-sided. The second part will then contain my points in defence of permissive licensing.

Why license software at all?

Licenses exist for reasons of protection. If you’re the author/inventor of some software, a story or whatever product, you get to decide what to do with it. You can keep it for yourself or you can give it away. If you decide for the latter, you have to decide who may use it and in which way(s). In case you intend to give it to a (potentially) large group of people, you may not want to be asked for permission to xyz by everybody. That’s when you decide to write a license which states what you are allowing and explicitly disallowing.

Most of the well-known commercial licenses focus on what you’re not allowed to do (usually things like copying, disassembling, etc.). Open source licenses on the other hand are meant to grant the user rights (e.g. the right to distribute) while reserving some rights or only giving permission under certain conditions – and they usually make you claim responsibility for using the software. For these reasons licenses can actually be a good thing!

If you got an unlicensed piece of code, you’re not legally allowed to do anything with it without getting the author’s permission first. And even if you got that permission, your project would be risky, since the author can withdraw it later. A proper license protects both parties. The author doesn’t get his mail account full of email asking for permission, he’s save from legal trouble if his code breaks anything for you and at the same time you have legal certainty when you decide to put the code to long-term use.

Permissive vs. Copyleft (in a nutshell)

In short terms, permissive licensing usually goes like this: “Here you are, have fun. Oh, and don’t sue me if it does something else than what you expect!” Yes, it’s that easy and there’s little to dispute over.

Copyleft on the other side sounds like this (if you ask somebody in favor of Copyleft): “Sure, you can use it, it’s free. Just keep it free, ok?”. Also quite simple. And not too bad, eh? Other people however read the same thing like this: “Yes, you’re free to use it. Just read these ten pages of legalese and be dead certain that you comply. If you got something wrong, we will absolutely make you regret it.”

The GNU Public license (GPL)

The most popular copyleft license in use is the GPL (in various versions). It got more and more complex with each version – and to be fair, it had to, because it was necessary to react to new threats and loop holes that were found later. The GNU project states that they are committed to protect what they call the four freedoms of free software:

  • the freedom to use the software for any purpose
  • the freedom to change the software to suit your needs
  • the freedom to share the software with your friends and neighbors
  • the freedom to share the changes you make

These are freedoms that every supporter of open source software should be able to agree with. So what’s the deal with all the hostility and fighting between the two camps? Let’s take a look at a permissive license, too.

The BSD license

Unlike the GPL, the BSD family of licenses begun with a rather simple license that span four rules (“original BSD license”). It was later revised and reduced to three (“modified BSD license”). And the modern BSD license that e.g. FreeBSD uses is even just two (“simplified BSD license”).

Did you read the GPLv3 that I linked to above? If you are using GPL’d code you really should. In case you don’t feel like reading all of it, at least take a look and grasp how long that text is. Now compare it to the complete modern BSD license.

What’s the problem?

There are essentially two problems that cause all the trouble. The first one is the question of what should be subject to the freedom that we’re talking about. And closely related, the second one is where that freedom needs to end.

Ironically both camps claim that freedom is the one important thing and it must not be restricted. The GPL is meant to protect the freedom of the software and enforces the availability of the source code, hence limiting the freedom of actual persons. BSD on the other hand is meant to protect the freedom of human beings who should be able to use the software as they see fit – even if that means closing down former open source code!

The GNU camp taunts permissive licenses as being “lax” for not providing the protection that they want. The other camp points out that the GPL is a complex monster and that it is virulent in nature: Since it’s very strict in a lot of areas, it’s incompatible with many other licenses. This makes it complicated to mix GPL and non-GPL code and in the cases where it’s legally possible, the GPL’s terms will take precedence and necessarily be in effect for the whole combined work.

Who’s right?

That totally depends on what you want to achieve. There are pros and cons to both – and in fact we’re only looking at the big picture here. There’s also e.g. the Apache license which is often deemed as kind of middle ground. Then you may want to consider the difference between weak (e.g. LGPL) as well as strong copyleft (GPL). Licensing is a potentially huge topic. But let’s keep it simple here because the exact details are actually not necessary to understand the essence of our topic.

In the next post I’ll present my stance on why permissive licensing is a good thing and copyleft is more problematic than many people may think.


FreeBSD: Building software from ports (2/2)

My previous post discussed what ports are, where they can be found on FreeBSD and what the files of which a port is composed of look like. This post will now detail how to use ports to build software on FreeBSD (the other BSDs have ports trees that work somewhat similar but are not identical. There are important differences!).

Packages and ports: A word of warning

The ports system works hand in hand with FreeBSD’s package manager Pkg. It makes little difference if some software on your machine was installed via a package or directly from ports – packages are in fact actually built from ports! Still it is not really recommended to mix packages and ports. In past times it was strongly discouraged. Things have changed since then. I’ve done it a lot – and mostly got away with it. Don’t rely on it, though, especially if you’re new to the whole topic. Feel free to do it on a test system and be completely happy – or face subtle and annoying breakage. You cannot know up front.

What’s the deal here? Modern software is a complex thing. Most programs rely on other programs or external libraries. A lot of programs can be configured at run time in certain ways. There are however decisions about program functionality that have to be made at compile time. The ports system allows you to build software with compile-time options other than the default. Pre-compiled packages have no chance to know that you choose to deactivate an option when you built a library yourself that they make use of. They assume that this feature is present (it was available on the system the package was built on after all!). And what can one poor program do in that case? Crash, explode, malfunction… A lot of things.

And then there’s the problem of mixing versions which can lead to all kinds of fun. If you stick with either ports or packages, you always have a consistent system with versions that are known to play together well (as long as the maintainers do their job well – we’re all humans and errors do occur).

Just keep that in mind when thinking about mixing programs installed from packages and ports on one system. You can do that. But it doesn’t mean you should. Enabling more options is generally safer than removing ones set by default. It can still have consequences. This is Unix though. Do whatever you see fit – and claim the responsibility. Your choice.

Most basic ports building

Building a software from ports is extremely easy. Go to the directory of a port and type make. Yes, that’s all! Let’s assume the port has no unsatisfied dependencies. The ports system will then check to see if the source code tarball is present in /usr/ports/distfiles. If it isn’t, it will automatically download it. Then it extracts the source code, prepares everything for the compilation and compiles it.

Building the ‘pkg’ port

On my fresh example system I build the Pkg manager from ports first – it’s needed for every other port anyway. Once everything has finished I get my shell back.

Building of Pkg completed

Installing the program is just as easy: Use make install

Installing the newly built port

That’s it, Pkg is now installed. We’re basically done with that port. However there’s still the “work” directory left over from the building process. To tidy up our port’s directory we can issue make clean.

Cleaning up after the build

Dependency handling

On to a just slightly more complex example. I want to build and install an old version of the LUA interpreter which depends on another port, libedit. Of course I could build devel/libedit first and then lang/lua51. In that case it wouldn’t be so bad. But if you think of larger programs with hundreds of dependencies that approach would be a nightmare.

So what to do about it? Well, nothing actually. The ports system takes care of it automatically! Just have it build LUA and it will figure out that it has to build the dependency first.

Building, installing and cleaning up in one command

The parameters to make that we used above are called make targets, BTW, and can be combined. That means it’s perfectly fine to issue make install clean together as you can see in the picture above.

Dependencies are handled automatically

The clean make target is also applied to all ports that were built as a dependency for the current port. Things like this make ports very convenient to use.

More on make and targets

Make targets can depend on other make targets. When you issue make install these are the targets that are actually run:

  • make config (more on that in a minute)
  • make fetch (fetch all files needed to build the port)
  • make checksum (check integrity of downloaded file(s))
  • make depends (check for missing dependencies and build/install those)
  • make extract (extract distfile(s) for the port)
  • make patch (apply patches for this port, if any)
  • make build (actually build the port)
  • make install (install the newly-built program)

If you type make checksum for example, all targets up to and including that one will run (that is config, fetch and checksum in that case). Running just make without any target will assume the default target which is equivalent to make build.

Also make will take an argument to look for the Makefile in another directory if you wish. So instead of doing e.g. this:

# cd /usr/ports/archivers/bzip2
# make install clean

you could also simply do this:

# make -C /usr/ports/archivers/bzip2 install clean

You’re in control: Ports options

So far it’s all nice and well but there’s no real advantage to using ports instead of packages. May I introduce ports options? Let’s say you we want to build BASH. If issue make in shells/bash, this is what happens:

Build options for BASH

The port ports-mgmt/dialog4ports is fetched and installed. It’s so small that you might miss it but it’s quite important. It’s needed to display the menu in the picture above which lets you set various options for the port.

You can now e.g. choose to not install the documentation if you’re short on space on a small or embedded system (sure, you wouldn’t actually compile on such a system, but that’s only an example, right?). If you don’t want BASH to support any foreign languages, deselect NLS. In case you feel that BASH’s built-in help is useless (did you ever issue the help command when you ran BASH?), you can cut that feature. Things like that.

If you see the option configuration for a port the first time, you see the default configuration. In general it’s a good idea to leave options alone if you’re in doubt what they do (do a little research if you have the time). Of course you’re also free to experiment with them. It’s your system.

Once you’re happy, accept your selection and the source tarball is being fetched, extracted, etc. You know the score.

Build options for bison

But what’s that? Another configuration menu (for bison)? And another (m4) and another (texinfo), etc… It’s 8 menus for a rather basic program like BASH! And worse: The building process will run and build dependencies and when a port with options is reached, the process is interrupted and prompts the user.

Now imagine you’re building a whole graphical desktop like MATE… Currently even the basic desktop would build no less that 338 dependency packages on a fresh system! And there’s quite a few ports on the list which build rather heavy software that takes it’s time compiling. It would totally make sense to let it build over night or at least not require you to keep staring at the screen, waiting for the next options selection to confirm, right?

Recursive operations

Exactly that’s why recursive operations are supported by the ports system. The standard make target that was implicitly run to open the options dialog is make config. The recursive option which would run the same on each and every port that’s listed as a dependency for the current port is make config-recursive.

If you want to build MATE as mentioned in the previous example, that would start a true marathon of options for you to configure. However it’s still a lot better to be able to do this up front so that the build process can run uninterruptedly afterwards.

Oh, and don’t be surprised if you went through it all only to find that still another configuration dialog pops up later! Why? Most likely you enabled an option on some package that made it depend on another package that’s not a dependency by default. And that package may need to have its options configured, too. So if you changed any options it makes sense to run make config-recursive again until no more new option dialog windows are displayed!

Recursively fetching distfiles for security/sudo

You can also do make fetch-recursive to fetch the distfiles for the current port and all dependencies. Again: Keep in mind that enabling more options may lead to new dependencies. If you want to make sure that you have all the distfiles, you might want to run make fetch-recursive again after changing ports options.

Other things to know

Wonder where the all the options are saved? They are stored in text files in /var/db/ports/category_portname. But there’s no need to edit or delete them; if you want to get rid of them, there’s make rmconfig to do that. Also make rmconfig-recursive exists if you feel like blowing away a huge amount of them.

Ports options in /var/db/ports

Another thing that comes in handy is make build-depends-list which will show you a list of ports that will be built as build dependencies for your current port. If you want to see the runtime dependencies you would use make run-depends-list. And then there’s also make all-depends-list which will show you each and every port that would be installed if you chose to build the current port.

Showing port dependencies

You should also know that you can deinstall a port by using make deinstall. Yes, it is also possible to remove the package using pkg delete but that will lead to a problem. The ports infrastructure keeps track of installed ports separately and Pkg does not know anything about this. So even if your package is removed, the Ports infrastructure will insist that it is still installed and there’s something very wrong with your system!

Now what to do if you have that case? Use make reinstall to install the package again even though ports thinks that it’s already installed.

More on ports?

To be honest, there’s quite a bit more to ports than I could cover here. You may want to man 7 ports to see what other targets are available and what they do. Also we haven’t even touched how to keep your system updated when using ports!

The ports infrastructure is a great means of installing customized programs on your system. It’s quite easy to use as you’ve seen. But things can be made even easier – which is why there are helper tools available. I will write a follow-up article covering those (not the next one, though). But for now enjoy all of those new possibilities with software on your FreeBSD machines!


FreeBSD: Building software from ports (1/2)

In my previous two (link) posts (link) I wrote about using Pkg, FreeBSD’s package manager.

Pre-built binary packages are convenient to use but sometimes you need some more flexibility, want an application that cannot not be distributed in binary form due to license issues (or have some other requirements). Building software by hand is certainly possible – but with all the things involved, this can be a rather tedious process. It’s also slow, error-prone and there’s often no clean way to get rid of that stuff again. FreeBSD Ports to the rescue!

This first part is meant as a soft introduction to FreeBSD’s ports, assuming no prior knowledge (if I fail to explain something, feel free to comment on this post). It will give you enough background information to understand ports enough to start using them in the next article.

What “Ports” are

When programmers talk about porting something over, what they originally meant is this: Take an application that was written with one processor architecture in mind (say i386) and modify the source so that it runs on another (arm64 for example) afterwards. The term “porting” is also used when modifying the source of any program to make it run on another OS. The version that runs on the other architecture/OS is called a port of the original program to a different platform.

FreeBSD uses the term slightly differently. There’s a lot of software written e.g. for Linux that will build and work on FreeBSD just fine as it is. Even though it does not require any changes, that software might be ported to FreeBSD. So in this case “porting” does not mean “make it work at all” but make it easily available. This is done by creating a port for any program. That term doesn’t mean a variant of the source code in this case but rather a means to give you easy access to that software on FreeBSD.

So what is a port in FreeBSD? Actually a port is a directory with a bunch of files in it. The heart of it is one file that basically is a recipe if you will. That recipe contains everything needed to build and install the port (and thus have the application installed on your machine in the end). Following this metaphor you could think of all the ports as a big cookbook. Formally it is known as the Ports collection. All those files in your filesystem related to ports are refered to as the Ports tree.

How to get the Ports tree

There are several options to obtain a copy of the ports tree. When you install FreeBSD you can decide whether or not to install it, too. I usually don’t do that because on systems that use binary packages only. It wastes only about 300 MB of space, but more importantly consists of almost 170.000 files (watch your inodes on embedded devices!). Take a look at /usr/ports: If that directory is empty your system is currently missing the ports tree.

The simplest way to get it is by using portsnap:

# portsnap fetch extract

If you want to update the tree later, you can use:

# portsnap fetch update

Another way is to use Subversion. This is more flexible: With portsnap you always get the current tree while Subversion also allows you to checkout older revisions, too. If you plan to become a ports developer, you will probably want to use Subversion for tools like svndiff. If you just want to use ports, portsnap should actually suffice. All currently supported versions of FreeBSD contain a light-weight version of Subversion called svnlite.

Here’s how to checkout the latest tree:

# svnlite checkout https://svn.freebsd.org/ports/head /usr/ports

If you want to update it later run:

# svnlite update /usr/ports

Old versions of the tree

You normally shouldn’t need these but it’s good to know that they exist. Using Subversion you can also retrieve old trees. Be sure that /usr/ports is empty (including for Subversion’s dot directories) or Subversion will see that there’s already something there and won’t do the checkout. If for example you want the ports tree as it existed in 2016Q4, you can retrieve it like this:

# svnlite checkout https://svn.freebsd.org/ports/branches/2016Q4 /usr/ports

There are also several tags available that allow to get certain trees. Maybe you want to see which ports were available when FreeBSD 9.2 was released. Get the tree like this:

# svnlite checkout https://svn.freebsd.org/ports/tags/RELEASE_9_2_0 /usr/ports

And if you need the last tree that is guaranteed to work with 9.x there’s another special tag for it:

# svnlite checkout https://svn.freebsd.org/ports/tags/RELEASE_9_EOL /usr/ports

Keep in mind though that using old trees is risky because they contain program versions with vulnerabilities that have since been found! Also mind that it’s NOT a smart thing to simply get the tree for RELEASE_7_EOL because it still holds a port for PHP 5.2 and you thought that it would be cool to offer your customers as many versions as possible. Yes, it may be possible that you can still build it if you invest some manual work. But no, that doesn’t make it a good idea at all.

Oh, and don’t assume that old ports trees will be of any use on modern versions of FreeBSD! The ports architecture changed quite a bit over time, the most notable change being the replacement of the old pkg_* tools with the new Pkg. Ports older than a certain time definitely won’t build in their old, unmodified state today (and I say it again: You really shouldn’t bother unless you have a very special case).

Port organization

Take a look at the contents of /usr/ports on a system that has the tree installed. You will find over 60 directories there. There are a few special ones like distfiles (where tarballs with program’s source code get stored – might be missing initially) or Mk that holds include files for the ports infrastructure. The others are categories.

If you’re looking for a port for Firefox, that will be in www. GIMP is in graphics and it’s probably no surprise that Audacious (a music player) can be found in audio. Some program’s categories will be less obvious. LibreOffice is in editors which is not so bad. But help2man for example is in misc and not in converters or devel as at least I would expect if I didn’t know. In general however after a while of working with ports you will have a pretty good chance to guess where things are.

Say we are interested in the port for the window manager Sawfish for example. It’s located in /usr/ports/x11-wm/sawfish. Let’s take a closer look at that location and take it apart:

/usr/ports is the “ports directory”.
x11-wm (short for X11 window managers) is the category.
sawfish is the individual port’s name.

When referring to where a port lives, you can omit the ports directory since everybody is assumed to know where it is. The important information when identifying a port is the category and the name. Together those form what is known as the port origin (x11-wm/sawfish in our case).

How to find a port in the tree

There are multiple methods to find out the origin for the port you are looking for. Probably the simplest one is using whereis. If we didn’t know that sawfish is in x11-wm/sawfish we could do this:

% whereis sawfish
sawfish: /usr/ports/x11-wm/sawfish

This does however only work if you know the exact name of the port. And there’s a little more to it: Sometimes the name of a port and a package differ! This is often the case for Python-based packages. I have SaltStack installed, for example. It’s a package called py27-salt:

% pkg info -x salt

If we were to look for that, we wouldn’t find it:

% whereis py27-salt

So where is the port for the package?

% pkg info py27-salt
Name           : py27-salt
Origin         : sysutils/py-salt

Here you can see that the port’s name is py-salt! The “27” gets added when the package is created and reflects the version of Python that it’s build against. You may also see some py3-xyz ports. In those cases the name reflects that the port cannot be built with Python 2.x. The package will still be called py36-xyz, though (or whatever the default Python 3.x version is at that time)!

When discussing package management I recommended FreshPorts and when working with ports it can be useful, too. Search for some program’s name and it might be easier for you to find the package name and the port origin for it!

What a port looks like

Let’s take a look at the port for the zstd compression utility:

% ls /usr/ports/archivers/zstd/
distinfo	Makefile	pkg-descr	pkg-plist

So what have we here? The simplest file is pkg-descr. Each package has a short and a long package description – this file is what contains the latter: A detailed description that should give you a good idea whether this port would satisfy your needs:

% cat /usr/ports/archivers/zstd/pkg-descr
Zstd, short for Zstandard, is a real-time compression algorithm providing
high compression ratios.  It offers a very wide range of compression vs.
speed trade-offs while being backed by a very fast decoder.  It offers

Then there’s a file called distinfo. It lists all files that need to be downloaded to build the port (usually the program’s source code). It also contains a checksum and the file’s size to make sure that the valid file is being used (an archive could get corrupted during the transfer or you could even get an archive that somebody tempered with!):

% cat /usr/ports/archivers/zstd/distinfo 
TIMESTAMP = 1503324578
SHA256 (facebook-zstd-v1.3.1_GH0.tar.gz) = 312fb9dc75668addbc9c8f33c7fa198b0fc965c576386b8451397e06256eadc6
SIZE (facebook-zstd-v1.3.1_GH0.tar.gz) = 1513767

There’s usually also pkg-plist. It lists all the files that are installed by the port:

% cat /usr/ports/archivers/zstd/pkg-plist 

And finally there’s the Makefile. This is where all the magic happens. If you’re a programmer or you have built software from source before, there’s a high chance that you’re at least somewhat familiar with a tool called make. It processes Makefiles and then does as told by those. While it’s most often used to compile software it can actually be used for a wide variety of tasks.

If you don’t have at least some experience with them, Makefiles look pretty much obscure and creating them seems like a black art. If you’ve ever looked at a complicated Makefile, you may be worried to hear that to use ports you have to use make. Don’t be. The people who take care of the Ports infrastructure are the ones who really need to know how to deal with all the nuts and bolts of make. They’ve already solved all the common tasks so that the porters (those people who create the actual ports) can rely on it. This is done by including other Makefiles and it manages to hide away all the scariness. And for you as a user things are even simpler as you can just use what others created for you!

Let’s take a look at the Makefile for our example port:

% cat /usr/ports/archivers/zstd/Makefile 
# Created by: John Marino <marino@FreeBSD.org>
# $FreeBSD: head/archivers/zstd/Makefile 448492 2017-08-21 20:44:02Z sunpoet $

CATEGORIES=	archivers

MAINTAINER=	sunpoet@FreeBSD.org
COMMENT=	Zstandard - Fast real-time compression algorithm

	@${REINPLACE_CMD} -e 's|INSTALL_|BSD_&|' ${WRKSRC}/lib/Makefile ${WRKSRC}/programs/Makefile

.include <bsd.port.mk>

Now that doesn’t look half bad for a Makefile, does it? In fact it’s mostly just defining Variables! The only line that looks somewhat complex is the “post-patch” command (which is also less terrifying than it first looks – if you know sed you can surely guess what it’ll do).

There can actually be more files in some ports. If FreeBSD-specific patches are required to build the port, those are included in the ports tree. You can find them in a sub-directory called files located in the port’s directory. Here’s an example:

% ls /usr/ports/editors/vim/files/
patch-src-auto-configure        vietnamese_viscii.vim
patch-src-installml.sh          vimrc

The patches there are named after the files that they apply to. Every patch in the files directory is automatically applied when building the port.

What’s next?

Alright. With that we’ve got a basic overview of what Ports are covered. The next post will show how to actually use them to build and install software.


FreeBSD package management with Pkg (2/2)

The previous article covered basic operations with FreeBSD’s Pkg tool. This second part will deal with some more advanced (or rather intermediate, actually) functionality.

Good code travels well

My previous two articles have been linked to from the DragonFly Digest (a very valuable resource for topics in BSD and the IT in general that I’ve been reading for years now and would like to say “thanks!”) again. Justin Sherrill pointed out that everything applies to DragonFlyBSD as well – they have adopted Pkg quite a while ago. And in fact you benefit from knowing your way around with Pkg in a lot of places:

FreeBSD obviously and a lot of FreeBSD-derived operating systems like OPNsense and HardenedBSD as well as desktop-oriented offspring like GhostBSD and TrueOS.

But as mentioned before, DragonFlyBSD uses it, too. And thanks to the new (and extremely exciting, IMO!) Ravenports project it has already come to Linux and will be available on even more platforms in the future! So getting familiar with it is certainly not a waste of time.

Package versioning

Before we start updating packages, let’s take a look at the versioning scheme. The way FreeBSD versions its packages can be a bit confusing if you first see it. Here’s a sample package with a rather complicated version string:

# pkg search opensmtpd | grep OpenBSD
opensmtpd-5.9.2p1_3,1          Security- and simplicity-focused SMTP server from OpenBSD

opensmtpd-5.9.2p1_3,1 – what does that all mean? Well, first we have the package name: opensmtpd, followed by a minus. Then there’s the upstream version of the program, 5.9.2p1 in this case.

Then there’s the underscore and another number: _3 in this case. This indicates our package is “revision 3”. Any new package starts with a revision of 0. If a port is revised (probably to correct a mistake, add more configure options, etc), the revision number is bumped. So this port has been revised three times without changing the actual upstream version.

And finally, separated by a comma, we have what is called the “epoch”. It is used in such cases where the upstream versioning changes. Any package with an epoch of 1 is considered newer than a package without any epoch. Even higher epoch numbers are considered even newer but this is rare. When do you need this? Let’s assume some project released a version of 7.2017 but decided that it would be a good idea to release the next version as 5.0. For Pkg it looks like the first one is newer (as it has a higher version number). In such a case you’d set an epoch to make Pkg understand that in fact the other one is the more up-to-date package.

Updating packages

I covered updating the repository information before. Update the actual packages with pkg upgrade:

# pkg upgrade
Updating Synth repository catalogue...
Synth repository is up to date.
All repositories are up to date.
Checking for upgrades (30 candidates): 100%
Processing candidates (30 candidates): 100%
Checking integrity... done (0 conflicting)
The following 30 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        xinit: 1.3.4,1 -> 1.3.4_1,1
        xerces-c3: 3.1.4 -> 3.2.0_2
        virtualbox-ose: 5.1.26 -> 5.1.26_1
        vim: 8.0.0962 -> 8.0.1035
        sudo: 1.8.20p2_3 -> 1.8.21p1
        sqlite3: 3.20.0_2 -> 3.20.1
        rubygem-net-ssh: 4.1.0,2 -> 4.2.0,2
        rubygem-multi_json: 1.12.1 -> 1.12.2
        ruby23-gems: 2.6.12 -> 2.6.13
        pulseaudio: 10.0_4 -> 11.0
        pciids: 20170727 -> 20170825
        p11-kit: 0.23.7 -> 0.23.8
        open-vm-tools: 10.1.5_1,2 -> 10.1.10,2
        nano: 2.8.6 -> 2.8.7
        mesa-libs: 17.1.7 -> 17.1.8
        mesa-dri: 17.1.7 -> 17.1.8
        libreoffice: 5.3.5_1 -> 5.3.6
        libidn2: 2.0.3 -> 2.0.4
        libgcrypt: 1.8.0 -> 1.8.1
        libdrm: 2.4.82,1 -> 2.4.83,1
        hunspell: 1.6.1_1 -> 1.6.2
        harfbuzz-icu: 1.4.8 -> 1.5.1
        harfbuzz: 1.4.8 -> 1.5.1
        gdk-pixbuf2: 2.36.6 -> 2.36.9
        e2fsprogs: 1.43.5 -> 1.43.5_1
        doas: 6.0p0 -> 6.0p1
        chromium: 60.0.3112.101 -> 60.0.3112.113
        atril: 1.18.0_1 -> 1.18.1

Installed packages to be REINSTALLED:
        keybinder-0.3.1 (options changed)
        apache-xml-security-c-1.7.3 (needed shared library changed)

Number of packages to be upgraded: 28
Number of packages to be reinstalled: 2

The process will require 2 MiB more space.

Proceed with this action? [y/N]:

The packages to be UPGRADED section is pretty obvious: There’s a newer version available. But there are also two packages in this example that are being reinstalled even though no new version is available. Pkg gives the reason for this in parentheses:

Keybinder will be reinstalled because it was compiled with other compile-time options than before (more about this in the next post). The second one depends on xerces-c3, a package in the list of upgradable packages, which is why apache-xml-security-c was rebuilt against the new version of the library.

There are other reasons that packages are to be reinstalled; if you upgraded your OS from one major version to another, the reason might be “ABI has changed”. It’s also possible that some packages will be deinstalled for an upgrade. This is usually because they conflict with another package that is to be installed. This also means: Do look at what the update is going to do! There is the chance that it would do something that you didn’t intend to.

Will this update cause me trouble?

You can never know for sure. But there is a means to learn about known issues beforehand. For your important applications it is a good idea to read the so-called “UPDATING information”. This is a short text (or some of them) which might contain a heads-up that can be critical to know. To view it, use pkg updating. Here’s an old example showing how bad it could be to have missed it:

# pkg updating apache22                 
  AFFECTS: users of www/apache22                   
  AUTHOR: ohauer@FreeBSD.org                       
  The default version was changed from www/apache22 to www/apache24,                                   
  pre-build apache modules and web applications will also reflect this!                                
  In case ports are build by yourself and apache22 is required                                         
  use the following command to keep apache22 as default.                                               
  # echo "DEFAULT_VERSIONS+=apache=2.2" >> /etc/make.conf

Having missed that one would have had very bad effects… For such reasons it’s good practice to read the UPDATING info. You don’t actually have to read it and will probably get away with it for quite some time. But it’s there for your benefit. So if you choose to ignore it, don’t complain if an update finally bites when it finds you off guard!

Blocking updates

Let’s stick to the previous example and say that we want to do the update – but LibreOffice should not be touched because we’re working on an important document currently and don’t want to risk layout breakage (minor updates should be no problem but bigger updates are known to sometimes cause trouble). What to do in that case?

Let’s lock the package using pkg lock:

# pkg lock libreoffice
libreoffice-5.3.5_1: lock this package? [y/N]: y
Locking libreoffice-5.3.5_1

Attempting the upgrade again, Pkg should now show only 27 candidates and leave LibreOffice alone. There are a few good reasons to lock a package – and a lot of bad ones. Resort to locking packages when necessary but don’t trifle with it because you’re effectively cutting yourself off from updates on some packages. Those could have dependencies. Probably dependencies that they share with other packages. You can see how this gets a lot bigger than “just that one package” rather quickly.

Also if you decide to use locking, make sure to look for locked packages now and then and think over if the lock is still needed! If not, release the lock. But how to find out which packages are locked? Pkg info can help us out:

# pkg info -k -a | grep yes             
libreoffice-5.3.5_1            yes

Unlocking works just like you’d probably expect it to:

# pkg unlock libreoffice                                                                                                                                                                           
libreoffice-5.3.5_1: unlock this package? [y/N]: y
Unlocking libreoffice-5.3.5_1

Package comments

We’ve locked LibreOffice above – but how do we remember in four months or so why it was locked? This is what we can use an annotation for. Set one with pkg annotate:

# pkg annotate -A libreoffice locked-pkgs "This package was locked on 09/10 until I finally finish the manuscript for my fantasy novel!"                                                           
libreoffice-5.3.5_1: Add annotation tagged: locked-pkgs with value: This package was locked on 09/10 until I finally finish the manuscript for my fantasy novel!? [y/N]: y
libreoffice-5.3.5_1: added annotation tagged: locked-pkgs

The argument “-A” is to set an annotation to the following package. “locked-pkgs” is a tag – you could call it whatever you want. And finally the last field is the actual comment string.

Using pkg info and the package name will display the comment among a lot of other information. But it might make more sense to look for all packages that have an annotation with a certain tag:

# pkg annotate -a -S locked-pkgs
libreoffice-5.3.5_1: Tag: locked-pkgs Value: This package was locked on 09/10 until I finally finish the manuscript for my fantasy novel!

If you no longer need the annotation, delete it like this:

# pkg annotate -D libreoffice locked-pkgs                                                                                                                                                          
libreoffice-5.3.5_1: Delete annotation tagged: locked-pkgs? [y/N]: y
libreoffice-5.3.5_1: Deleted annotation tagged: locked-pkgs

Are those updates important?

Some updates mean new features, others mean fixing of critical security holes. How are you supposed to know? The easy way is to ask Pkg! Use pkg audit and it will tell you about known vulnerabilities of the software installed on your system:

pkg audit
libgcrypt-1.8.0 is vulnerable:
libgcrypt -- side-channel attack vulnerability
CVE: CVE-2017-0379
WWW: https://vuxml.FreeBSD.org/freebsd/22f28bb3-8d98-11e7-8c37-e8e0b747a45a.html

chromium-60.0.3112.101 is vulnerable:
chromium -- multiple vulnerabilities
CVE: CVE-2017-5120
CVE: CVE-2017-5119
CVE: CVE-2017-5118
CVE: CVE-2017-5117
CVE: CVE-2017-5116
CVE: CVE-2017-5115
CVE: CVE-2017-5114
CVE: CVE-2017-5113
CVE: CVE-2017-5112
CVE: CVE-2017-5111
WWW: https://vuxml.FreeBSD.org/freebsd/e1100e63-92f7-11e7-bd95-e8e0b747a45a.html

No way back?

Are you not feeling completely confident about an update? Does your customer demand “a way back” in case something goes wrong? You can use pkg create to package already installed software:

# pkg create chromium-60.0.3112.101
Creating package for chromium-60.0.3112.101

In this example I’ve packaged Chromium before updating so that I could reinstall the old version. Keep in mind, though, that this is just an example. If dependencies changed as well, you might not be able to use the old version, even when you reinstalled it! If you want to be really, really cautious, you can use pkg create -a to create packages of all the software currently installed on your system!

The package(s) is/are created in the current directory. I just deinstalled Chromium after creating the package and now want it back. To install software directly from a package (and not a repo), use pkg add:

# pkg add chromium-60.0.3112.101.txz
Installing chromium-60.0.3112.101...
Extracting chromium-60.0.3112.101: 100%
Message from chromium-60.0.3112.101:
For correct operation, shared memory support has to be enabled
in Chromium by performing the following command as root :

sysctl kern.ipc.shm_allow_removed=1

To preserve this setting across reboots, append the following
to /etc/sysctl.conf :


Finding the package a file belongs to

In many cases you can probably tell from the path and name of a file which package it belongs to. But sometimes you may wonder: Where does this come from? This is where pkg which is really helpful. Let’s pick a file with a non-obvious name and pretend we don’t know what it is. We better ask pkg where it belongs:

% pkg which /usr/local/etc/drirc     
/usr/local/etc/drirc was installed by package mesa-dri-17.1.7

Ah, mesa! We better leave that one alone.


If you looked closely at the output of my upgrade command, you have seen mention of a repo called Synth. I’ll cover that in a later post. But there is something you might want to know about the ordinary repos, too. Modern FreeBSD provides two package repositories: quarterly and latest. The later always holds the newest packages, the former gets version updates every three months and only security fixes in-between. The quarterly repository is a good choice for people who don’t want the newest software at all times but prefer a slower-moving environment. Since version 10.2 quarterly is the default.

If you want to use the packages from latest, you have to configure pkg to use it. Take a look at the file /etc/pkg/FreeBSD.conf to get an idea of how repo configuration looks like. Then create the necessary directory and another configuration file to overwrite the default:

# mkdir -p /usr/local/etc/pkg/repos
# vi /usr/local/etc/pkg/repos/FreeBSD.conf

Put the following lines in that file:

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"

Now use pkg update to refresh the repository database.

What’s next?

There’s a lot more that Pkg can do – and we haven’t even touched its main configuration! But the two posts were just meant to introduce you to FreeBSD package management (and chances are that you already know more now than many admins who occasionally use FreeBSD). I might or might not write about more features of Pkg in the future. But next stop now: The ports tree.

Edit: I got the patch level wrong with the version schema as leper pointed out in the comments. The wrong claim was removed.


FreeBSD package management with Pkg (1/2)

FreeBSD is a server operating system popular among more experienced administrators. It’s also often used in appliances or embedded products and it makes a nice desktop, too, if you are a bit more proficient with it. Sure, you don’t read about it all the time. This is because of two things: 1) Linux is usually absorbing most of the attention 2) FreeBSD just silently and reliably does its job. FreeBSD is also the basis of some special-purpose open source operating systems.

Are you new to FreeBSD? You’ve picked a good time to take a look: Version 11.1 has been released recently and a lot of people who have wanted to give it a spin for a while are getting an ISO and try it out. Also OPNsense 17.7, a popular router/firewall OS has been released, also not too long ago.

If you’re coming e.g. from OPNsense, you have a nice WebGUI at your hands that makes controlling and maintaining easy. That does not mean that you wouldn’t benefit from knowing more about how to do package management by hand, however. OPNsense is built on top of FreeBSD which means that you have all the power of that operating system available if you know what to do if the WebGUI doesn’t provide a simple option to do it!

Pkg – where is it?

If you’re using a FreeBSD-based project like OPNsense or a desktop spin like GhostBSD or TrueOS, it’s located in /usr/local/sbin/pkg. With vanilla FreeBSD it’s almost certainly in the same place of course, if you’ve been using the system for a while. What do I mean by that? Well, in the previous post about the history of *nix package management I made the claim that modern FreeBSD comes without a package manager. And that’s actually true! Take a look at the path mentioned above. See what I mean?

FreeBSD uses the directory tree under /usr/local for programs that are installed as add-on packages, i.e. software that is not part of the base system. Yes, that means that even the package manager is a package! How does that work? Well, there’s also /usr/sbin/pkg, which is part of the base system. If pkg is not present on the system, it’s able to bootstrap it as the first package on the system. If the package manager is already installed, it simply acts as a wrapper (thanks to its location and the default PATH variable it takes precedence over the actual pkg). Bootstrapping is as easy as pressing ‘y’, so we don’t really need to cover it beyond this.

Sounds a bit strange, right? Yes, but there’s a good reason for this. Pkg’s life begun as pkg-ng when FreeBSD still used the old pkg_* tools, so it made sense to develop it outside of the base system. But why wasn’t it imported into the base system when the old tools were retired? Actually, FreeBSD maintains ABI stability for the base system for the life-cycle of a release (e.g. 11). The last point release of the 10 branch, FreeBSD 10.4, is just about a month away from now. If pkg had been part of the base, that would mean the new release would have to ship with pkg 1.2 since 1.2.4 was the version available when 10.0 was released! The 11 branch would ship with 1.8, as 1.8.7 was the current version when FreeBSD 11.0 was released.

That would have meant slower progress, since no package would have been allowed to depend on features introduced after 1.2 until 10.4 went EOL – which might be as far away as somewhere near the end of 2019! Fortunately pkg is a package and thus could be improved rapidly: All versions of FreeBSD have pkg 10.1 today instead of 1.8 – or even 1.2.

How to get help?

If you have no idea how to use pkg, you can use pkg help. This will show a list of supported options and commands. And if you want to know even more, you can always type man pkg. There are also man pages for most of the pkg commands, usually named pkg-command. As a shortcut to those, you could also type pkg help command which will display the correct man page.

On the long run it’s not a bad idea to read a bit more about pkg, but if you are just getting started, all the possibilities might overwhelm you. So let’s discuss a few practical examples to get you up to speed easily and quickly, shall we?

Finding packages

As long as you just use pkg to gather information, you can run it as any user. Modifying anything needs root privileges, of course.

By default pkg operates on remote a repository. A repo (common abbreviation) is simply a place where packages are stored and kept accessible together with an index file. To be of any use, pkg needs that index and (with the default configuration) will fetch (or update if it deems the local copy too old) it before performing any action you might want it to do. If you just want to get/update the index, you can run pkg update:

# pkg update
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01    
Fetching packagesite.txz: 100%    6 MiB 548.9kB/s    00:11    
Processing entries: 100%
FreeBSD repository update completed. 26602 packages processed.
All repositories are up to date.

Provided you can connect to the repo, this will fetch the latest index and process it. Pkg uses a local sqlite database created from the index so that it can quickly and nicely get information from it.

To see if a package in any configured repository is available for installation, use pkg search:

% pkg search bash
bash-4.4.12_2                  GNU Project's Bourne Again SHell
bash-completion-2.5,1          Programmable completion library for Bash
bash-static-4.4.12_2           GNU Project's Bourne Again SHell
bashc-               GNU bash shell extended with visual two-panel file browser
checkbashisms-2.15.10          Check for the presence of bashisms
erlang-mochiweb-basho-2.9.0p2  Erlang library for building lightweight HTTP servers (Basho fork)
mybashburn-1.0.2_4             Ncurses CD burning bash script
p5-Bash-Completion-0.008_1     Extensible system to provide bash completion
p5-Term-Bash-Completion-Generator-0.02.8_1 Generate bash completion scripts

Pkg returns a list of hits, each with package name and version as well as a short comment to give you an idea what the package actually is. If you know either the package name or part of the name, searching is easy enough.

Now let’s assume you are looking for a light-weight web browser but you forgot the name! Since it’s not very likely that the package’s name contains “browser”, how do you search for it? You could simply search the comments e.g. for “web browser”, but that would lead to quite a list. Do you remember anything else about the browser? Let’s say we know that it uses the FLTK toolkit. Let’s see if we can find that package:

% pkg search -c "web browser" | grep -i FLTK                            
dillo-3.0.5                    Fast, small graphical Web browser built upon fltk

There we are, the browser’s name is dillo! If even searching in the comments doesn’t yield what you are searching for, you might even resort to pkg search -D keyword. This will search in the detailed description that each package comes with. Just be prepared for a lot of hits and a wall of text if you’re using common keywords.

Web-based package search

In many cases it’s not a bad idea to use a web-based search. That is what the site FreshPorts provides among other things.

If you’re trying to get into FreeBSD, this is a site that you might want to bookmark. Quite possibly it’ll come in handy rather often. Also spend a little while exploring what it offers. Getting familiar with it is in fact time will spent.

Installing packages

To install a package, just issue pkg install pkgname:

# pkg install chocolate-doom
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 7 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        chocolate-doom: 2.3.0
        sdl_net: 1.2.8_3
        doom-data: 1.0_1
        sdl_mixer: 1.2.12_12
        smpeg: 0.4.4_14
        timidity: 0.2i_1
        libmikmod: 3.3.8

Number of packages to be installed: 7

The process will require 22 MiB more space.
11 MiB to be downloaded.

Proceed with this action? [y/N]:

Just answer y to make pkg fetch and install those packages (any PC without DooM installed just isn’t quite complete after all – I still stick to that even though I haven’t found time to actually fire up that game in years!).

What’s installed?

To query the package database, use pkg info. Without any further arguments this will return a list of all installed packages (so you probably want to pipe it into a pager like less). Searching for a specific package? You can definitely do that using your standard Unix tools, but hold that grep right now! There’s a better way:

% pkg info -x mate-t

The -x switch enables searching with regular expressions. The search in my example shows all packages that contain “mate-t”. You may even want to get used to adding -i, too, which enables case-insensitive search – just in case (there aren’t that many packages in FreeBSD that contain uppercase letters, but some do).

If you found your package, just use pkg info [packagename] (without the square brackets, of course) to get a whole lot of information about the package! But that’s probably more than you wanted and it makes sense to know a few more switches that just give you some specific information.

A nice one is -D. Forget what that post-install message was that told you how to actually get your package to work? This option prints it again:

% pkg info -D chromium
For correct operation, shared memory support has to be enabled
in Chromium by performing the following command as root :

sysctl kern.ipc.shm_allow_removed=1

Use -d to query information about a package’s dependencies:

% pkg info -d galculator

With -l you can list all the files that a package installed in your filesystem:

% pkg info -l mksh

Deleting packages

The last one of the basic operations is removing packages. Here in my example I spotted a package called “tracker”, a filesystem indexer that comes with GNOME. If you don’t use that desktop and find it on your system: Kill it with fire! Nuke it from the system with pkg delete:

# pkg delete tracker
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):

Installed packages to be REMOVED:

Number of packages to be removed: 2

The operation will free 21 MiB.

Proceed with deinstalling packages? [y/N]: y

Deinstalling this package will also get rid of Nautilus as well (since tracker is a dependency for that). Since the GNOME team pretty much ruined that once decent file manager, I’m not going to shed any tears over that loss and press enter. Pkg will then delete all the files associated with the package and un-register it in the package database.

What’s next?

That’s it for the basics in my opinion. The next post will show off a few of the more advanced features that Pkg offers.