Online communities spawn, grow, and die. Why? How? What can be done? Here’s my story of my time online.
Quoting a friend from years past:
IRC channel death is similar to the slow process of erosion. Conversation has ceased, yet it may be years before the channel is empty. I think about that frequently.
This post was inspired by some controversy with Valve and their support for Linux, but the bulk of it comes from long-term observation. One of the biggest impacts with the viability of Linux on the desktop was Valve’s Proton, a Wine fork integrated in Steam allowing almost any Windows game to work out of the box. To Linux users, life was good. However, with the recent announcement of the Steam Deck, a handheld device powered by Linux, Valve’s marketing towards developers explicitly mention no porting required. Valve’s been aggressive with this message enough that they’ve allegedly told developers simply not to bother with Linux ports anymore; enough that it makes commercial porters like Ethan Lee concerned.
However, I suspect this is the long-term result of other factors, and games are only one aspect of it. After all, we all know the Year of the Linux Desktop is around the corner, along with nice applications. Linux won’t rule the world just from games, even if some people really want it to be true. How did it come to this, and why?
I collect vintage computers and phone systems. Why? They frequently require repair, obscure knowledge, or dwindling parts supplies. Let me tell you how and why.
While making devices more repairable is pretty much seen as universally a good thing, right? Unfortunately, engineering involves tradeoffs, but some of those tradeoffs that are seen as bad for repair (or are actually desirable in spite of it), or actually improves reliability. These are some things I suspect right to repair advocates forget.
This article is intended to unify some disparate thoughts on the subject I’ve had on Lobsters comment, this blog (i.e. the ThinkPad one), etc. as one post. I intend to do this more often for other things…
After being successfully up and running for over a year with very few major changes needed, now seems as good a time as ever to break down how sporks.space runs, what secret sauce we use to run it how we like it, and so forth.
Inspired by cb’s post earlier this week, and by the same friends’ musings, I felt it would be fun to go over what my every day equipment is. This probably won’t convince you to use it, but serves more as a clarification of why I use it. With that out of the way, let’s talk about what’s on my desk.
This is a stream of consciousness (so don’t expect my usual polish) based off of some friends’ musings on the tools they use. I’m doing this to explain some of the tools I use, in the hopes of conveying my feelings on them. I doubt (and sometimes probably hope I won’t) I’ll convince you on the merits or if you should use any of these tools, but you’ll at least know why I care. As I write this, I consider the tools I use to be fairly pedestrian, but perhaps this document might have sentimental or historic interest later. Consider it like usesthis.com – and I also use a Mac!
I had some code trying to scale an image in gd using the
imagescale function, that looked something like this:
/* makes a copy of the image, instead of modifying in place */
$target = imagescale($image, $width, $height);
However, the images it created were heavily distorted when using bilinear filtering, and didn’t quite look right with neared neighbour either. For example, with bilinear filtering…
I’m someone who cares about making software portable. In fact, I actually have a job basically doing so. For most Unix-shaped things (better known as things, since Unix destroyed all competition), the POSIX standard exists to codify common attributes and provide a common ground. Unfortunately, this is made far more complicated by systems both doing many things outside of POSIX’s lowest common denominator, and systems just not implementing POSIX correctly. People tend to think “portability” is whatever operating systems they use, and assuming the lowest common denominator is that. While many guides recommend writing software in a disciplined (or tortured, if you disagree) manner with separate compilation units for platform differences when possible, the reality is your codebase will have
#ifdefs and a configure script if it does anything useful. Not to mention the increasing irrelevance of the standard itself.
Context: So I wanted to implement drag and drop with files the quick and dirty way; specifically,
WM_DROPFILES. (You can also do this with COM, but it’s a bit more involved, especially from raw C. I haven’t written about drag and drop yet, so the comparison is covered elsewhere for now.) My use case is simple, so I didn’t need the benefits or complexity of COM drag and drop. Turns out it’s just marking it as having the extended style in the resource editor or calling
DragAcceptFiles, or so I thought. While I could get my dialog to accept the files, I couldn’t get the list view to do so. It turns out that the list view doesn’t handle these messages, nor does it send a notification back to the parent.
One strategy to deal with this is subclassing, although we aren’t going through the formal channels to do. That’s trickier, because it involves using things like
CreateWindowEx, and might be a pain with dialog resources that already have a list view. Instead, we’ll actually replace the window procedure out from under the already materialized dialog control – basically monkey patching. In fact, Microsoft’s own documentation mentions this (and a better way with caveats). However, it doesn’t provide a concrete example. This article will quickly show you how, and provides an interesting, if brief example of Windows API principles.