If you have do have a constructive question or a comment, please feel free to email me. I like email because it remains in my email. I have a really high level of control, and email is deliberately, obviously, asynchronous. I am allowed to read, process and respond without fear of additional comments or explosions that derail entire conversations. In short, we can actually communicate. In the same way, that control means I don't need to respond to trolls in my email. At worst, I click block and delete and no one who reads this site needs to see any of that. The troll loses it public opportunity via my platform.

To be fair, you can also reach me via social media (links are on the side). Odds are, though, that if a conversation is going to evolve it will happen over email.

Chen isn't wrong. His article just appears assumes there is only one option, to continue using and relying on the problematic platforms developed by those corporations and hope they "fix" it for us. They won't. The Internet trolls have "won" because the corporations that drive modern social media platforms make a ton of money off those trolls (see my Valve discussion for more on that). Until they stop making money (this is something that Facebook may actually be grappling with) the trolls will win. Of course, they only win on those platforms.

If you rely on those platforms, you're sunk. So you have a choice, you can wait for these social media companies to do something or, and apparently this is a radical thought, maybe you should choose to stop relying^[1] on those platforms. Reddit and Twitter aren't necessary. Facebook certainly isn't necessary. None of the current social media platforms are required for you to communicate and share with an audience. In fact, I would argue they probably are not very valuable unless you really want to be advertising. After all, that is what they were designed to do. Social media platforms are not for communication, they are for advertising. We as social media users should treat them as such, and nothing more.

This is, in part, why I get so frustrated with the current "the internet is revolutionary" refrain that so dominates digital rhetoric especially when uttered in the same sentence as social media. The internet can be revolutionary, social media is regressive. Social media is (and Chen notes this in the article) just interactive mass media. It's talk radio and call-in TV. I think Chen frames this really well by quoting Dr. Zizi Papacharissi^[2]:

Given the way things are going, our faith in the internet may erode until we distrust it as much as we do TV news.

I agree, except that we are not talking about the internet we're talking about private, corporate, social media sites and companies. They aren't trustworthy. They never were. We shouldn't trust them any more than we used to trust the crazy guy talking on Art Bell. When we reduce the internet to these platforms, we create an expectation that there are no other options. There are, and there always have been. Honestly, those options are doing fine^[3].

Dr. Papacharissi's suggestions at the end of the article are absolutely on point, but I would add one more - become your own curator. Don't rely on social media to supply information and engagement. Seek out content and (whenever possible) engage with it on independent sites, develop your own filters, and decide what you will and will not view. For example, I use a custom filter on Ublock Origin to block Youtube comments. Why? Because the comments don't matter, I'm there for the creator^[4]. You wouldn't believe how much nicer my Youtube experience has been since I removed those comments.

Ultimately, the trolls aren't winning. They're trolls. Every troll victory is pyrrhic at best. Platforms that encourage and support them ultimately die taking the trolls with them (looking at you Twitter). The internet is going to be just fine^[5]. It's an internet. A lot of platforms that use the internet are pretty terrible right now. That's okay. A Papacharissi says in the article, we haven't really learned how to use these technologies well. Social media is just an attempt to glue an older, more centralized model of mass media into this communicative space.

That will change.

We're connected in some really incredible ways to a world of movement and information. The trouble is we have an overload. We know this. We've known for a long while, and yet we're addicted to that same overload.

We're gluttons for media, we crave input. We are children of the screen. Technology and media companies know exactly how to feed our hunger. They use it to keep drawing us back in, and by god do we keep coming back. Media saturation is our favored drug, and we suck it up wherever we can.

Should we turn it off, then? No. I'm not suggesting we disconnect. Our technology may not be politically neutral, but there are ways to tactically appropriate its power. We need to exploit those ways. Sometimes, indeed many times, this always-on connection can be a benefit. We can act and respond faster. We can connect with one another. We can plan and gather needed information in ways we never could have before. What I am suggesting is that we actually get tactical. We consider our consumption pattern and we reduce and focus.

It's that focus we keep losing. We can't keep up, but we want to try. We are desperate to try. There is just so much out there.

This month has been hell. The constant of stream of news has been draining. We've seen horror after horror streaming in a near constant flow. If we look away, we feel guilty. So we watch and we rage. Then in response, and out of emotional exhaustion, we gather ourselves around other media. We escape into fantasies and comedy. We seek to forget, laugh, or find something to take us away from the hurt and the pain. The reality is that the horrors we are facing are real. They have been for a very long time. We're not doing any good watching in stunned silence. We're not doing any good obsessing. Yes, we need to fight what we can and do what we can to resist. This is not the way, though.

Resistance is not consumption. Do you need more news to tell you how horrible this regime is? Do you need more evidence? It's okay to turn it off. It is okay to walk away.

Resistance requires focus and attention not on the news but each other. Technology can help with that, but technology is not limited to Facebook or the New York Times or Google. Technology is that machine in your house. You own it and you have the power to control it. You can tell it where to go and where not to go. Start making decisions about what you read and watch. If an algorithm feeds it to you, you still have a choice^[1]. You don't have to click. You're not missing much, I promise.

Have you ever had one of those problems where you know the payoff isn't worth the work, but you can't step away because you have to solve it? That is where I am at right now. If you read my earlier post on troubleshooting, you know that I am working on getting a itch.io game to work in Linux. In that post, I fixed a few missing libraries, but then I hit a dead end. Something in my setup still wasn't quite right.

As I also noted in that post, this is not the only way to approach solving this issue. It may not even be the best, but it is a way. My real goal here is to convince you that you shouldn't fear the potential complexity of these tools or even your own lack of knowledge. Get in there and play around. It is the best way to learn.

So, to start, let's set the system context. I am running run Fedora 28 on an AMD Ryzen 1700X with an Nvidia GTX 1080^[1].

The logs reported thus:

Unable to find a supported OpenGL core profile
Failed to create valid graphics context: please ensure you meet the minimum requirements
E.g. OpenGL core profile 3.2 or later for OpenGL Core renderer
Vulkan detection: 0
No supported renderers found, exiting

Now, this is a bit surprising as I thought I had installed all the OpenGL libraries I needed. Indeed, I double checked that mesa-libGL and its corollaries were installed in both 32bit and 64bit versions. They indeed were.

I then ran ldconfig -p | grep GL to confirm that the OpenGL libraries were there.

$ ldconfig -p | grep GL
	libQt5OpenGL.so.5 (libc6,x86-64) => /lib64/libQt5OpenGL.so.5
	libQtOpenGL.so.4 (libc6,x86-64) => /lib64/libQtOpenGL.so.4
	libOpenGL.so.0 (libc6,x86-64) => /lib64/libOpenGL.so.0
	libGLdispatch.so.0 (libc6,x86-64) => /lib64/libGLdispatch.so.0
	libGLdispatch.so.0 (libc6) => /lib/libGLdispatch.so.0
	libGLX_nvidia.so.0 (libc6,x86-64) => /lib64/libGLX_nvidia.so.0
	libGLX_mesa.so.0 (libc6,x86-64) => /lib64/libGLX_mesa.so.0
	libGLX_mesa.so.0 (libc6) => /lib/libGLX_mesa.so.0
	libGLX.so.0 (libc6,x86-64) => /lib64/libGLX.so.0
	libGLX.so.0 (libc6) => /lib/libGLX.so.0
	libGLU.so.1 (libc6,x86-64) => /lib64/libGLU.so.1
	libGLU.so.1 (libc6) => /lib/libGLU.so.1
	libGLEW.so.2.0 (libc6,x86-64) => /lib64/libGLEW.so.2.0
	libGLESv2_nvidia.so.2 (libc6,x86-64) => /lib64/libGLESv2_nvidia.so.2
	libGLESv2.so.2 (libc6,x86-64) => /lib64/libGLESv2.so.2
	libGLESv1_CM_nvidia.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM_nvidia.so.1
	libGLESv1_CM.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM.so.1
	libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
	libGL.so.1 (libc6) => /lib/libGL.so.1
	libEGL_nvidia.so.0 (libc6,x86-64) => /lib64/libEGL_nvidia.so.0
	libEGL_mesa.so.0 (libc6,x86-64) => /lib64/libEGL_mesa.so.0
	libEGL.so.1 (libc6,x86-64) => /lib64/libEGL.so.1

I know, now, that there is a problem in this list ^[2]. At the time, though, it looked good.

So, this is where I found myself. No error message save a brief log file comment on OpenGL and nothing else.

Do I give up? Nope.

Is this a good way to spend my (valuable?) time? Probably not.

Am I going to dig deeper into this problem, anyway? You got it.

It's time for strace. Now, this is not an strace tutorial ^[3]. I am not going to show you all the cool things it can do. I am going to show how I used it in a very brute force sort of way to find out what was going wrong.

The strace tool allows us to see what an application is doing as it runs. We can see how it interacts with the system (what system calls it makes) and where it may run into to problems. This makes it a handy little tool, but it also means that it dumps a lot of information at you. In this case, I just want to know what happens with the OpenGL libraries. As you can see from the ldconfig output, not all OpenGL libraries have OpenGL in their name, but they do (usually) have GL somewhere in their name. So let's focus our attention on lines with GL in them. Will I still get some extraneous line? Probably, but I can sort through that.

strace ./"I woke up.x86" 2>&1 | grep GL

This command launches and traces the I Woke Up game as it runs and inevitably crashes. By searching only for those transactions with a GL, I can better track the problem I am looking.

A momentary aside

Now, you might be asking what does 2>&1 mean? Good question. In your terminal, output can be sent via two different file handles: stdout aka 1 and stderr aka 2. Think of these like channels. Your terminal is tuned in to both channels, so you see both stdout and stderr in your terminal. Terminal applications, however, are often tuned to stdout and ignore stderr. This is usually a good thing except when you are troubleshooting. The strace application sends its output to stderr which means you can see it in the terminal but grep won't. The 2>&1 tells the program to redirect all of the channel 2 output (stderr) to channel 1 (stdout). This will allow grep to find only those lines you care about.

Here is my output. Notice anything interesting (HINT: see all the -1 ENOENT (No such file or directory) lines? Those might be a problem.)

$ strace ./"I woke up.x86" 2>&1 | grep GL
openat(AT_FDCWD, "/lib/libGL.so.1", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/libGLX.so.0", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/libGLdispatch.so.0", O_RDONLY|O_CLOEXEC) = 4
writev(3, [{iov_base="b0\3\0\3\0\1\0", iov_len=8}, {iov_base="GLX", iov_len=3}, {iov_base="\0", iov_len=1}], 3) = 12
writev(3, [{iov_base="b0\3\0\3\0\1\0", iov_len=8}, {iov_base="GLX", iov_len=3}, {iov_base="\0", iov_len=1}], 3) = 12
openat(AT_FDCWD, "/lib/tls/i686/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/i686/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/tls/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i686/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/i686/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/i686/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/i686/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/tls/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/i686/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/i686/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/sse2/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libGLX_nvidia.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/sse2/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = 4
writev(3, [{iov_base="b\23\3\0\3\0\0\0", iov_len=8}, {iov_base="GLX", iov_len=3}, {iov_base="\0", iov_len=1}], 3) = 12
writev(3, [{iov_base="b\0\3\0\3\0\0\0GLX\0", iov_len=12}], 1) = 12
write(2, "libGL error: ", 13libGL error: )           = 13
write(2, "libGL error: ", 13libGL error: )           = 13
read(5, "              /usr/lib/libGLX_me"..., 1024) = 1024
writev(3, [{iov_base="b\25\3\0\3\0\0\0", iov_len=8}, {iov_base="GLX", iov_len=3}, {iov_base="\0", iov_len=1}], 3) = 12

Apparently, I am missing the 32bit libraries for the Nvidia driver. Now, Fedora doesn't include the Nvidia driver because the Nvidia driver remains closed-source. This means you will need to load your libraries from whatever repository you installed them from. You can find what repo and package that is by typing sudo dnf whatprovides libGLX_nvidia.so.0. Make sure you have installed both the 64bit and 32bit libraries. I use Negativo17's Nvidia Repo and needed to install nvidia-driver-libs.i686.

Once you have installed, you can confirm that the libraries are in place by running lddconfig.

$ dconfig -p | grep GL
	libQt5OpenGL.so.5 (libc6,x86-64) => /lib64/libQt5OpenGL.so.5
	libQtOpenGL.so.4 (libc6,x86-64) => /lib64/libQtOpenGL.so.4
	libOpenGL.so.0 (libc6,x86-64) => /lib64/libOpenGL.so.0
	libOpenGL.so.0 (libc6) => /lib/libOpenGL.so.0
	libGLdispatch.so.0 (libc6,x86-64) => /lib64/libGLdispatch.so.0
	libGLdispatch.so.0 (libc6) => /lib/libGLdispatch.so.0
	libGLX_nvidia.so.0 (libc6,x86-64) => /lib64/libGLX_nvidia.so.0
	libGLX_nvidia.so.0 (libc6) => /lib/libGLX_nvidia.so.0
	libGLX_mesa.so.0 (libc6,x86-64) => /lib64/libGLX_mesa.so.0
	libGLX_mesa.so.0 (libc6) => /lib/libGLX_mesa.so.0
	libGLX.so.0 (libc6,x86-64) => /lib64/libGLX.so.0
	libGLX.so.0 (libc6) => /lib/libGLX.so.0
	libGLU.so.1 (libc6,x86-64) => /lib64/libGLU.so.1
	libGLU.so.1 (libc6) => /lib/libGLU.so.1
	libGLEW.so.2.0 (libc6,x86-64) => /lib64/libGLEW.so.2.0
	libGLESv2_nvidia.so.2 (libc6,x86-64) => /lib64/libGLESv2_nvidia.so.2
	libGLESv2_nvidia.so.2 (libc6) => /lib/libGLESv2_nvidia.so.2
	libGLESv2.so.2 (libc6,x86-64) => /lib64/libGLESv2.so.2
	libGLESv2.so.2 (libc6) => /lib/libGLESv2.so.2
	libGLESv1_CM_nvidia.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM_nvidia.so.1
	libGLESv1_CM_nvidia.so.1 (libc6) => /lib/libGLESv1_CM_nvidia.so.1
	libGLESv1_CM.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM.so.1
	libGLESv1_CM.so.1 (libc6) => /lib/libGLESv1_CM.so.1
	libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
	libGL.so.1 (libc6) => /lib/libGL.so.1
	libEGL_nvidia.so.0 (libc6,x86-64) => /lib64/libEGL_nvidia.so.0
	libEGL_nvidia.so.0 (libc6) => /lib/libEGL_nvidia.so.0
	libEGL_mesa.so.0 (libc6,x86-64) => /lib64/libEGL_mesa.so.0
	libEGL_mesa.so.0 (libc6) => /lib/libEGL_mesa.so.0
	libEGL.so.1 (libc6,x86-64) => /lib64/libEGL.so.1
	libEGL.so.1 (libc6) => /lib/libEGL.so.1

Notice how the nvidia libraries now have (libc,x86-64) and (libc6) entries? Things are looking a lot better now.

The real proof is in the running, though. Sure enough, the game launches and runs without error. Result!!

Was this a lot of effort for a game? Yes, it was. At a certain point, though, the game wasn't the point. We should understand the tools we have and the systems we use everyday. Black boxes are inevitable. We cannot live in a non-black-boxed world. We'd get nothing done. If we accept that everything is a black box, however, we cede control. When this comes to computers, this means we cede control over the very tools we use for communication and expression. This isn't a call to code. Nothing I did here involved you writing in a programming language. Rather, this is an invitation to take back that really cool hunk of plastic and metal that sits on you desk or in your lap. Computers can be awesome. More importantly, their users are awesome. Learning to take control of that machine just gives you more ways of proving your excellence.

The newer versions of the Koenig editor have drastically improved on the performance and operation of the editor. I am still not fond of writing within a card, but my overall workflow is no longer as heavily impacted as it was in the earlier betas. To that end, I am happy to see Ghost working to improve the editing experience for their users who prefer a Markdown-based editing environment. Now, if I just had cleaner export functionality.

If I wanted WYSIWYG, I would be using Wordpress.

I used Koenig for a week, and then turned it off. If it becomes mandatory, I will probably end leaving Ghost as a platform. This isn't about bugs. Beta tests have bugs. This is about usability, writing, and inevitable feature creep.

The only reason I decided to step away from a static site was because I wanted a better Markdown writing experience with a faster publication path.

Ghost, to its credit, has given me that. The SimpleMDE-based editor has been great. I really enjoy writing in it and my posting has increased because of it. Now Ghost seems ready to take that experience away in the name of rich media. I hope that it finds a way to capture a better balance, instead.

It is true that I can still use Markdown via the Markdown card, but that card adds needless visual clutter to my writing environment. Frankly, I want the simple clear text that I have in my current editor. This movement away from a plain text standard (which has been going on for some time now in Ghost) bothers me. I can't even export my posts in Markdown. Rather, I get a JSON export with HTML formatted data. If I want to migrate posts, I (or someone else) have write a JSON import tool for the engine I am transitioning to. Thankfully, this is not a complex problem but it is a frustrating one.

This is also a problem if I want to convert my posts to another format. When I was using a static site generator, if I want to provide pdf copies or develop a series of posts into a slide presentation, I could do so. I'd make a few small updates to the front matter of my markdown files and then pandoc handled the rest. There is no way to really do this in Ghost. I accepted this limitation because the value that Ghost provided more than made up for that small loss in functionality.

This new editor is a step backward for me, though. I understand the need and I know a lot of people are excited for it. I even think it makes sense for Ghost to implement the new editor. It just isn't for me, and I hope that Ghost developers consider those of us who just really wanted a nice Markdown-based writing experience. As the Koenig editor moves from beta to production, I hope that I can continue to use my simple little Markdown editor just the way it is with no card and no visual clutter. That would be a win-win for everyone.

I want to start with one sentence in Erik Johnson's post that bears review.

If you're a developer of offensive games, this isn't us siding with you against all the people you're offending.

And yet, Steam is providing a sales channel for these games through its site. Steam is also providing platform support for the distribution and marketing of these games, and Steam is actively taking money from the sales of those games. Steam may not be siding with offensive game developers, but it seems really seems happy to have those games and their developers side with it.

Steam isn't a forum, it's a store. As such, it should be known for the quality and type of content it sells. Apparently, Steam wants to be known as the "anything goes" game provider: the slush pile of gaming. I wish them luck with that.

However, offending someone shouldn't take away your game's voice. We believe you should be able to express yourself like everyone else, and to find others who want to play your game. But that's it.

If that was it, then Steam isn't needed. Developers can already do that. Contrary to its statement here, Steam isn't the arbiter of game expression. No one is silencing these developers. They have every right to make and distribute their game. In the same way, sales platforms, like Steam, have every right to not sell a game. Steam isn't taking away anyone's voice by not selling their product. They are making a choice about the company they want to be and what products they think they should be selling.

Steam is the current powerhouse in gaming, but that power comes at a considerable price. We've all spent a lot of money on Steam games. In doing so, we need to acknowledge that we don't actually own anything purchased through Steam. We only own the right to access those games via the Steam client. That is it.

Steam's policy decision is banking on that powerhouse position. It prioritizes quantity and sales over quality content. Beyond the offensive content, these are the decisions that lead to a growing slush pile of bad games. What is especially galling is that they'll even get kudos for their decision as if they are doing something noble. In all reality, they are just taking money from whoever will give it to them. The sad fact is that Steam does this because it honestly thinks it will make more money this way. In the short-term, I think it will, but this kind of tactic is not sustainable. It shows that Steam doesn't care about the broader community it serves and the messages it conveys via its platform.

I hope Steam reconsiders this approach. It has done a lot of good things as a company, and I hate to think that this kind of policy will define what it becomes in the years ahead. The good news for those of us who care about the content we buy is that Steam is not the only game sales platform. There are plenty of places out there that still care about the games they sell. Thank goodness for that.

What follows is an example of troubleshooting in Linux. It is not the only way, it may not even be the best way, but it is one way. Note, too, that the solution is less important than the procedure. You may have a different issue, but this process can help you discover the clues to a workable solution. One of the great strengths of Linux is the power it gives it users, but that power requires a willingness to dive in and explore. While not always easy, I have found those explorations have given me a far greater appreciation for the power and potential of the modern PC.

The Problem Game

I've been shopping around on different gaming platforms. I've always liked itch.io. Their approach to indie gaming and to the broader open source community is one that I respect and value. So, I grabbed a free game from the site as a test.

I use Fedora as my everyday OS which means I try to game, as much as possible, in Linux. The game I picked up was i woke up next to you again. I picked it up in the spirit of trying new things. I haven't played a visual novel game like this before, and I was curious.

But, there was a problem: the game wouldn't start. Instead, I received the following error:

Not to be discouraged, I decided to figure out what the problem was.

The Log File

Don't fear the log file. Yes, there is a lot of gobbledygook. No, I don't know what every little thing in the file means. I know how to find out what things mean, though. That is the important part. We have manuals for a reason.

So I clicked on the "Examine cause of failure" and in the log file the first error I saw was (HINT: The first major error is usually a good place to start looking.):

Unable to preload the following plugins:
	ScreenSelector.so

After that, there was a missing data archive error (not surprising as I didn't have any saved data) and a stack trace for the application.

At the end of the stack trace was:

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Linux applications often require a collection of shared libraries in order to run successfully. In this case, as the log file suggested, I was pretty sure I was missing a library or two. The question is: which ones?

Using ldd to Find Missing Libraries

When it comes to Linux applications, ldd is one of the tools we can use to discover those clues. In this case, the missing libraries.

The ldd [ ldd(1) ] command lists the shared libraries that a program or shared object needs.

I wanted to start by running ldd against the main application. I suspected this wasn't the problem, but better safe than sorry. So I opened the itch.io app and in the lower right hand corner, there is an entry that says "Show local files."

Clicking on this in Gnome 3 (which is the default Desktop for Fedora) will open the file manager (aka Nautilus) to the directory with the game files. In the top bar you can see the path to those files. If you right-click in the file manager you will see an option to open a terminal in that folder. Otherwise, get the path (which should probably be something like /home/[your username]/.config/itch/apps/I woke up next to you again, open a terminal, and cd to the path (remember that the ~ is a shortcut to your home directory).

$ cd ~/.config/itch/apps/I woke up next to you again

In this directory there are two directories. We want the Linux folder.

$ ls
'I woke up_Linux'   __MACOSX
$ cd "I woke up_Linux"/
$ ls
'I woke up_Data'  'I woke up.x86'

The 'I woke up.x86' file is our primary application executable. Let's check to see if any of the shared libraries are missing.

$ ldd "I woke up.x86" 
	linux-gate.so.1 (0xf7fc1000)
	libdl.so.2 => /lib/libdl.so.2 (0xf7f8b000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xf7f6c000)
	librt.so.1 => /lib/librt.so.1 (0xf7f62000)
	libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7dd2000)
	libm.so.6 => /lib/libm.so.6 (0xf7cd0000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7cb2000)
	libc.so.6 => /lib/libc.so.6 (0xf7b0f000)
	/lib/ld-linux.so.2 (0xf7fc3000)

What we can see here is the list of shared libraries that the application needs and and their locations. Note that none are missing. This is a good thing, but it also doesn't help us fix the problem. Don't forget, though, the log file was pointing us to a game plugin called ScreenSelector.so. Notice the .so at the end of that file. That means it is a shared object that also relies on shared libraries. So, we need to find where ScreenSelector.so is hiding in our directory. Now, we could go searching through the folders by hand, but it is a lot easier just to find the file.

$ find . -name ScreenSelector.so
./I woke up_Data/Plugins/x86/ScreenSelector.so

Now that we have the file location we can run ldd against it.

$ ldd "./I woke up_Data/Plugins/x86/ScreenSelector.so"
	linux-gate.so.1 (0xf7ef5000)
	libgtk-x11-2.0.so.0 => not found
	libgdk_pixbuf-2.0.so.0 => not found
	libgobject-2.0.so.0 => not found
	libglib-2.0.so.0 => not found
	libdl.so.2 => /lib/libdl.so.2 (0xf7eb4000)
	libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7d24000)
	libc.so.6 => /lib/libc.so.6 (0xf7b81000)
	/lib/ld-linux.so.2 (0xf7ef7000)
	libm.so.6 => /lib/libm.so.6 (0xf7a7f000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7a61000)

Note: If you are lazy, like me, you could find and run ldd all in one line.

$ find . -name ScreenSelector.so -exec ldd {} \;
	linux-gate.so.1 (0xf7f1b000)
	libgtk-x11-2.0.so.0 => not found
	libgdk_pixbuf-2.0.so.0 => not found
	libgobject-2.0.so.0 => not found
	libglib-2.0.so.0 => not found
	libdl.so.2 => /lib/libdl.so.2 (0xf7eda000)
	libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7d4a000)
	libc.so.6 => /lib/libc.so.6 (0xf7ba7000)
	/lib/ld-linux.so.2 (0xf7f1d000)
	libm.so.6 => /lib/libm.so.6 (0xf7aa5000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7a87000)

When you add the -exec switch to the find command you can run a command against all the files it finds. The {} expands to become the full  file and path for every entry found. Make sure to close the command with \;, though.

Hey look, there are missing files there. That might be why the file isn't loading. Great! Now we have something to fix. So, how do we find out how which packages we need?

In Fedora, you can use dnf whatprovides to find what packages have the missing libraries.

$ dnf whatprovides libgtk-x11-2.0.so.0 libgdk_pixbuf-2.0.so.0 libgobject-2.0.so.0 libglib-2.0.so.0
Last metadata expiration check: 11 days, 7:02:21 ago on Sun 27 May 2018 04:27:54 PM CDT.
gtk2-2.24.32-2.fc28.i686 : GTK+ graphical user interface library
Repo        : fedora
Matched from:
Provide    : libgtk-x11-2.0.so.0

gdk-pixbuf2-2.36.12-1.fc28.i686 : An image loading library
Repo        : fedora
Matched from:
Provide    : libgdk_pixbuf-2.0.so.0

glib2-2.56.1-2.fc28.i686 : A library of handy utility functions
Repo        : updates
Matched from:
Provide    : libgobject-2.0.so.0
Provide    : libglib-2.0.so.0

glib2-2.56.1-1.fc28.i686 : A library of handy utility functions
Repo        : fedora
Matched from:
Provide    : libgobject-2.0.so.0
Provide    : libglib-2.0.so.0

glib2-2.56.1-2.fc28.i686 : A library of handy utility functions
Repo        : updates
Matched from:
Provide    : libgobject-2.0.so.0
Provide    : libglib-2.0.so.0

glib2-2.56.1-1.fc28.i686 : A library of handy utility functions
Repo        : fedora
Matched from:
Provide    : libgobject-2.0.so.0
Provide    : libglib-2.0.so.0

In Debian-based systems (including Ubuntu), the apt-file command can do something very similar. See apt-file (Debian Wiki) for more information on how to use it.

What I can see from the output above is that I need to install three packages: gtk2-2.24.32-2.fc28.i686, gdk-pixbuf2-2.36.12-1.fc28.i686, and glib2-2.56.1-1.fc28.i686 in order to add all the necessary shared libraries.

Fedora Note: If you look carefully at the output above, you will see both glib2-2.56.1-1.fc28.i686 and glib2-2.56.1-2.fc28.i686 are listed. Install packages from the fedora repo before the updates. In my case, the files listed  in the updates repo were not even listed as found.

$ sudo dnf install gdk-pixbuf2-2.36.12-1.fc28.i686 gtk2-2.24.32-2.fc28.i686 glib2-2.56.1-1.fc28.i686

After the install process completes. Rerun your ldd command against ScreenSelector.so to confirm that all is well. If all libraries are found, you should be able to launch the program.

One Problem Solved. n Problem(s) to Go

One of the more challenging parts of the troubleshooting process is that it rarely ends easily. Quite often, you resolve one problem only to find that another one has popped up. That is what happened here. Once I installed the shared libraries, I found myself dealing with new problems. Those issues, however, can be addressed in later posts.

Update: This was a originally part of a larger post. I decided to split these discussions into two separate posts for better clarity.

Let's start with a simple fact: if your content is not controlled and not stored by you, you don't own it. You never did.

There's been a lot of anger and fear surrounding the recent news that GitHub has been sold. For many, the worst part of that news was that they would soon have their code hosted on a Microsoft-owned platform. Of course, they were already storing their code on a centralized server owned by another company. We know that never ends well (Finley 2015), but no one seemed to be concerned about that. Instead, they only became upset when GitHub was bought by Microsoft because Microsoft is "evil."

Apparently, these people have been living under a rock for the past couple decades. I have my issues with Microsoft, but let's be clear, compared to the surveillance monstrosity that is Google,  the crushing giant tendrils of an ever-present Amazon, and the "we will happily sell out our users until we're caught"- mindset of Facebook, Microsoft is not the worst company on the Internet. In fact, if I had to create a list of companies that I would want to buy GitHub, Microsoft would be pretty high on that list.

And, here is the reality, GitHub was always going to be sold. No one should be shocked. The only shock for me was that it took so damn long.

As users, we like to tell stories about the platforms we use; especially when those platforms work to become a part of our identity.  GitHub certainly does that as do many other brands. Indeed, this connection is the core of modern marketing. We don't buy products we buy an identity built around a myth about who we are and who we should be (Strizhakova, Coulter, and Price 2008).  Naomi Klein has called this form of corporate development "hollow branding"  and has discussed it at length in her book No Logo (2000)  and revisits in her discussion on the 2016 elections in No Is Not Enough (2017).  We need to be careful about buying into these stories, though.  GitHub isn't a community resource. It is a company. It wants profits. Now yes, those profits are earned by providing a service to the community. Never doubt, though, that profits will always come before anything else.

As customers, I completely agree that we must hold our platforms responsible for their actions. The GitHub sale is not an action worth leaving over. In fact, as I mentioned in a tweet a short while back, I am very interested to see how Microsoft deals with the GitHub acquisition. This is an opportunity for them to show that their commitment to the Open Source community is as real as they say. Indeed, their recent actions in this space have (for the most part) been quite encouraging.

That said, we cannot forget that these platforms are not our own. We are storing our content on the servers of another company. Plan accordingly. I will still use GitHub the way I have been. It is a great tool and platform. I use it to store a few public and a few private repositories. I do not store anything that I consider confidential, and all critical repositories (aka my dissertation) are backed up elsewhere. I don't trust GitHub. I use GitHub. I trust my private backups and my private servers. GitHub is a service I use because it makes some work easier, but I could do without it if a problem does arise. Don't rely on platforms you don't own. This is particularly important for small businesses who use these services as critical tools. Sooner or later, they will suffer for that choice.

What is instructive here is that Nakamoto described Bitcoin a democratic like system with “one-CPU-one-vote” which meant that any person could participate. But if it is only robust with specialized chips, that democratic philosophy is undermined. In other words, Bitcoin is only likely to be long-lasting and robust as an institution because technology has subverted the very democratic-style principles that were core to its founding vision.

He wonders if critique and constructivism have helped to usher in that age. Certainly, modern academia has dealt with that accusation for quite some time. By showing how facts and truth are constructed, socially or otherwise, it is suggested that we undermine a universal faith in that truth. We do. We should. Indeed, we are at our best when we are peeling back the veneer of truth and fact to reveal the deeper relationships involved. Yet, it is difficult to believe that critique, alone as it stands, is enough. For Latour, and I tend to agree, critique has its own adherents who take great pleasure in tearing down the social and technical structures in which we all live. In doing so, they reveal much, but they never offer an alternative. They disprove and walk away. As Latour himself says, "The question was never to get away from facts but closer to them..." (231). For Latour, this meant a return to the primacy of Things and a movement away from a heavy, almost singular, focus on social construction.

We needed that push. Moving away from a singular form of critique has been incredibly useful in opening up new considerations in the rhetorics of science and technology. It has helped to develop new approaches in which social construction plays a part but not the whole. We can explore how people and things interrelate and build off one another. We can examine how systemic structures become objects in an of themselves extending beyond the human limits of their creation and yet still carrying with them the initial ideological biases that drove their birth. Critique has expanded and for the better.

But as I read and write, I find myself considering a nagging concern: what do we do with that expanded critique? Latour suggests that no one would want their cherished cultural objects to be subject to social critique and inquiry (240). To think that expanding such inquiry would somehow render that concern moot is patently false. We cannot remove ideology from our analysis of object interactions and say "We fixed it." We haven't, and honestly very few would go so far as to suggest such a course of action. In the end, I think the problem may be critique, itself. The "post-truth" age requires a "post-critical" approach. This is not a new claim, but it is something that has been weighing on me a lot in the past few months. I am not sure it is enough to point out the flaws. Certainly, that is important but without an approach that says "This is broken and here is how we fix it." We remain in the same spot we always have been, tearing down the structures without offering any help.

Maybe that is why I am so attracted to pedagogy and teaching. When I teach, I am interested in helping students understand and use that knowledge. In preparing them not to be good critics, but to use critique to better understand, engage, and hopefully change their world for the better. I hear that a lot from many who, like me, are early on in their academic careers. The research we do is fascinating, but without that movement from theoria to praxis we end up going nowhere.

Of course, praxis has its own dangers most notably from those who critique. In some sense, all form are doomed to the limitations of their time and place. Critics will highlight the failures and the flaws of those practices. They should. If we are to be post-critical, we cannot ignore that critique. We should invite it. We should make it our ally. If Latour is right and the goal is to get closer to fact or truth, whatever that may be, then we need the power of critique. We cannot, however, succumb to the inertia of critique. We must learn from it and keep pushing ahead using our skills and our knowledge to make things better while acknowledging our own flaws, frailties, and limitations.

Dissertation Research - Technology, Policy, and the Formation of User and Developer Publics : 1112 words

Daily Writing Progress (2018) - May 6^st

Dissertation Research - Technology, Policy, and the Formation of User and Developer Publics : 471 words

Daily Writing Progress (2018) - May 1^st