All posts by madscientist

About madscientist

I've been a free software advocate and hacker since I first encountered GNU Emacs at college. Currently I'm the maintainer for the FSF's GNU make utility. Professionally I've been involved in software engineering/development for my entire career and continue to be enthralled by new technologies and the opportunities they provide. I've been using UNIX-based systems at home and at work since college, and GNU/Linux since 1993. I tell my family, "I don't do Windows!" For recreation I ski, scuba dive, bike, run, and take walks with our dogs. ----- Linux Counter #5235

Mastodon for Business?

Opinion

I’ve never been much of a social media person. I’ve never had a Facebook account, a Twitter account, an Instragram account, etc. The only social media platform I ever used much was G+ … which could tell you it may not be worth your time to read the rest of this post.

But with the latest Twitter imbroglios I was motivated to dust off my circa 2017 Mastodon account and see what’s going on over there. I was looking for Mastodon feeds for the news sources I follow but was unable to find any and it got me thinking that these companies are (so far) missing a huge opportunity.

Consider a media company such as the NY Times or Wall Street Journal. They use a subscription service model which to me seems perfect for Mastodon. They can publish a short summary as a tease with a link to the full article behind a paywall. People who are interested can follow these accounts and see the summary, and if they get interested they will get a subscription.

Well, that sounds like Twitter, so why should they switch to Mastodon? I’ve seen so many articles recently discussing how the federated nature of Mastodon seems to make things harder: you have to choose a server and how to sign up and why it’s a pain.

Unfortunately these articles don’t follow the logic to its conclusion and so they are missing the opportunities that federation gives. They are so focused on “you have to find some server that someone is running out of their basement” that they don’t take the next step and really grok what that means: it means that anyone can run a Mastodon server. And “anyone” means someone like… the NY Times or the Wall Street Journal!

Why aren’t these media companies creating their own Mastodon servers, such as mastodon.nytimes.com, and providing accounts to their reporters? This seems perfect: you are not beholden to a separate company like Twitter; you don’t have to worry about what kind of ads will pop up next to your posts; you don’t have to worry about someone pretending to be a NY Times reporter on Mastodon because any real NY Times reporter will have an account on the NY Times Mastodon server… and a fake one will not. No worries about moderation, etc. because only your employees are posting there and you have complete control over the content.

Now you have a verified communication chain directly to your readers, without having to create something on the scale of Twitter… through the power of federation. And best of all, it is not at all hard to create and manage a Mastodon server. The web services folks at these large companies could do it over their lunch break.

For reporters who don’t work directly for the Times but still publish there, they can keep their own Mastodon account on a different server if they prefer while still getting that account verified using the NY Times website, with the link-back feature.

There can be different accounts such as @frontpage, @sports, etc. where articles are boosted to allow users to follow based on their interest.

So, what are you waiting for? When will we see all the NY Times, WaPo, Wall Street Journal, etc. bylines show not just a Twitter handle but also a Mastodon address, using the company’s local server?

Date yourself!

Opinion

When I was in elementary school one of the first things I was taught was to always write my name and the date at the top of my papers.

I’ve noticed on the Internet people have no problem remembering to put their name on their posts, blogs, rants, etc. (or, anyway, putting some name on them). On the other hand it’s astounding to me how many people forget to simply add a date! For many social media platforms and forums the date is added automatically, of course. Ditto with some blogging environments. However, I see lots of articles online where someone has gone to a lot of effort to create some useful information and post it… but without any indication of when it was posted. This can be critical information, especially in the tech world where things change very rapidly.

When I read an interesting critique of something or a “howto” article with no date attached it seriously detracts from its usefulness: how do I know whether it was posted last week, and thus still quite relevant, or three years ago and hence more likely to be out of date?

Please people, remember your elementary school teachers and put a date on your content… even online.

Why Autoconf ain’t so bad

GNU

Autoconf often gets a lot of hate from developers, who think its syntax is obscure, its implementation is baroque, and in general it’s too difficult for the purportedly simple task it is asked to perform.  In response to a thread on the autoconf mailing list with the subject “just one of a million reasons why autoconf is a worthless piece of shit“, I wrote this rebuttal.  Hopefully it will explain why the autotools suite works the way it does, and why it’s really not over-engineered for its purpose.  And, why you should consider using it even though you don’t have to love it, or even like it.

You have two misconceptions which are contributing to your frustration, I think: the first and largest one is that the goal of autotools is to make the maintainer’s life easier.  As has already been stated a few times, autotools is not about the maintainer.  Autotools is about the USER.  In fact this is a philosophy that underlies all of GNU, starting with the GPL itself.  The idea is that packages should automatically configure themselves for the user.  You probably don’t remember, but back in the day building a new software package was a time-consuming and frustrating experience of reading various README and INSTALL files, editing makefiles and header files by hand, etc.  It would usually take the better part of a day, or longer, and all the knowledge was unique to each package and had to be relearned every time you wanted to update it.

Now, users just run configure and make.  There are standard and simple ways for them to do very complex things, and all that knowledge is applicable across a huge spectrum of free software.  Even packages that don’t use autoconf quite often provide a configure script, for compatibility (and the number one complaint for those packages is that their configure script doesn’t support some particular feature that autoconf configure scripts do).

Consider the kinds of things that users of any properly autoconfigured package can and expect to be able to do:

  • cross-compilation
  • installation into alternate directories, either wholesale or on a very granular scale
  • easily adding common prefixes or suffixes to installed targets
  • support for all sorts of bizarre platforms, most of which the maintainer of the package has never heard of, much less has access to.

And, they get it all using nothing more than configure and make.

All of this capability, and most especially making it all simple for the user, comes at a cost, and that cost is complexity in autoconf and extra work for the maintainer of the package.  But that’s OK, because that’s the design philosophy we are committed to.  We don’t see complaints from users about how hard it is to work with autoconfigured packages (quite the contrary!), and to us that means we’re doing a good job achieving our most important goal.

The second misconception is that you can greatly simplify package configuration by targeting what you call “the real world”, implying that autoconf spends too much effort on obscure capabilities that no one really uses.  In fact, autoconf deals with the real “real world”, where people have systems with strange characteristics and they still want to compile free software for them.  We want to support that, because our ultimate aim is to promote the use of free software.  The world that your “simple” solutions work for is an idealized one where everything is tidy and perfect and no one wants to do anything out of the ordinary.  That world only exists in test environments.

If you release your software with your configuration environment, and it gets at all popular, I will bet that you will get countless requests to add support for lots of features and abilities that autoconf packages already have, along with reports of problems building and/or installing on machines autoconf already supports.  And by the time you get done handling all this you will have spent MORE time and effort on it than you would have if you’d just used autoconf, AND your environment will be less portable, more brittle, and frustratingly (for your users) non-standard.

Cheers!