Just thought I’d share the Getting Started guide that grew from my periodic use of Lubuntu to make old PCs useful to the needy.
It’s on GitHub and you can also view it online though the WebODF renderer doesn’t yet seem to obey instructions to stretch tables to fill a page’s width or span cells across rows.
TL;DR: This script collects hardware and OS info for reporting bugs in Linux games because, on Linux, the functionality of DxDiag is split up across several different tools.
The Humble Indie Bundle 6 just came out and, wanting Torchlight, I bought it. Now, like any early adopter, I did run into a bug (it’s already been fixed). This isn’t about that, though.
When I read the README.linux file, it asked me to gather a bunch of diagnostic information and, being the distractible geek I am, I ended up writing a script to automate it.
…I went above and beyond the call and expanded it into something more like a console version of the Windows DxDiag utility. (Which will also open a terminal for you if you double-click it) So, if you ever need to submit a bug report for a Linux game, run this script. It’ll gather all your hardware and system configuration in one easy-to-read, easy-to-attach file.
Note: I’m still working on figuring out what kind of data I should collect for debugging audio and input issues. If you have any suggestions, please leave a comment.
In case you don’t feel like scrolling past the embed or you’re not used to working with embeds from GitHub Gists, here’s the direct download link.
After writing what must be my third or fourth e-mail offering advice to an online service whose marketing completely missed the mark with me, I started to notice that I was touching on the same set of points.
Again and again, startups seemed to miss that, despite their differing goals and shorter attention span, smart users will act like investors. As such, it’s essential to address, at minimum, these concerns:
Now, when I write these e-mails, I tend to write them to people who strongly believe that their code is a trade secret, but when I’m actually choosing software and services for myself, there are two questions I ask (which are far more important to me) which marketers should have honest responses to:
All in all, it boils down to two very subjective questions that people try to answer when deciding to invest their time, energy, or money:
Update: For end users, this How Do They Make Money? explorer helps to streamline some of these questions for the more popular sites out there.
Having grown very used commands like these, nobody was more eager than I when PHP 5.4 introduced its own no-setup development server.
python manage.py runserver (Django)paster serve --reload (Pylons)nodemon (NodeMon for Node.js)jekyll --auto --server (Jekyll, used by GitHub Pages)However, in typical PHP fashion, there’s some assembly required and you’ll probably need code from either the comments or somebody’s blog to get it to behave the way you’d expect it to by default.
So, without further ado, here is what I came up with to get the basic “excise index.php from the URLs and pass static files through” behaviour most people use .htaccess for.
(There is a command-line option for this sort of behaviour, but it doesn’t match the behaviour of the net’s most ubiquitous mod_rewrite snippet.)
It’s been tested under Fat-Free Framework 2.0.6 through 2.0.12 and, if there are any incompatibilities with other frameworks or PHP applications, they should be minor.
Apparently, the CGI script powering my mail form slipped through the cracks when I was setting up health monitoring for this site and had been giving error 500 for an unknown period of time.
It’s now fixed and I’ve rewritten it in PHP so that, hopefully, if such a problem occurs again, the blog will have died too and I’ll notice immediately. I also added suggestions for alternate contact methods on the form page.
Finally, feel free to use the comments thread on this page to report trouble.
It used to be that GitHub vs. BitBucket was a no-brainer. GitHub was sleek, featureful, popular, and supported git, the godsend.
BitBucket was clunky, buggy, comparatively little-known, and required you to use that hg thing with the annoying workflow.
However, as time has gone on and Atlassian has continued to work on BitBucket, things seem to be shifting in BitBucket’s favor. BitBucket has added support for git, offers private repositories in their free tier, and continues to make minor improvements every now and then, while GitHub seems to be backsliding.
Oh, GitHub still looks nicer by a mile and continues to improve on that front, but what you can do with it and how you communicate are backsliding (and communication is the whole point of the thing). For example, in recent months, GitHub has:
GitHub claims that, by killing off their private messaging system, they’re serving us better by giving us one less inbox to manage… yet I still obsessively go into GitHub every few days to flush out the pointless “GitHub Pages built successfully” messages and duplicates of bug notifications that pile up in the “notifications” inbox.
(And the only button that applies to everything is “mark as read”, so I manually have to click every single entry to delete them… including a page reload after every ten clicks.)
Couldn’t they just have ditched both web inboxes, kept the PM form, and forwarded all messages directly to my primary e-mail address for handling?
Forcing me to expose my e-mail address to the world if I want to be reachable and forcing me to abuse the issue tracker to communicate with like-minded individuals is so bass-ackwards that it makes SourceForge seem superior!
Update: GitHub now supports only receiving notifications via e-mail, but they still haven’t provided a replacement for the PM form’s old status as a spam-proof, guaranteed-to-be-there way to contact another user.
user.email actually be an e-mailAt first glance, this may seem reasonable… except that git itself doesn’t enforce that constraint and git is famous for not letting you rewrite old commits without breaking push/pull with everyone else’s branches.
What makes it even worse is that, since GitHub used to support it, who knows how much data was submitted which once was valid and now isn’t. Smart move, guys.
I don’t know about you, but I’d rather give up having my commits hyperlinked to my account (or, even better, just switch to BitBucket, which still allows arbitrary strings) than leave a genuine e-mail address lying around where every spambot in the world can find it.
I’ll be sticking with http://www.ssokolow.com/ContactMe as my commit ID’s “e-mail address”, thank you very much.
As Christian Heilmann elaborated on, Twitter is not a discussion platform because its character limit kills nuance in discussion, it has no threading, and its structure makes it nearly impossible for anyone but the author of the blog post to gauge community reaction.
If I find news sites without comment systems unsatisfying and/or distasteful enough to avoid them, I’m not going to be very enthused about a “Web 2.0” code-hosting site that does the same with their public announcements. I don’t care whether it’s spin-doctoring or just laziness. (Again, if I wanted the latter, SourceForge has it in spades)
So, these days, what exactly does BitBucket do wrong, aside from losing the network effects battle?
Surprisingly little from what I’ve been able to tell… they just made some bad choices in what they did wrong:
Most of the time, when people host a project, they actually care about getting potential users interested in it. That means they need to host screenshots and logos and possibly even JavaScript demos so they can make a good first impression. It also means they probably want to give their project a memorable look and feel. Wikis, issue trackers, and repository browsers don’t do that.
I’m told BitBucket has support for a per-user Pages equivalent, but that’s not really a big help (It took me ages to find a use for GitHub’s per-user Pages support but I was using per-project pages from day 1) and it’s so under-documented that, despite looking for it, I spent months not knowing it existed. (BitBucket’s opportunity to be worse than SourceForge)
If I’m going to have to pay for site hosting anyway, I might as well just host my own git repository and bug tracker while I’m at it and gain more customization support.
With no equivalent to GitHub Pages, the full burden of making a good first impression falls to the project pages. Unfortunately, they are also in need of some TLC.
First, they still knock-off GitHub’s old theme, which now feels five years out of date. Not a good first impression to make when the projects you compete against for attention are probably hosted on GitHub.
Second, the default configuration for a project’s landing page shows off their most recent commits and their README file. The problem is, in my experience, there are three pieces of information, from most to least urgent, that I want to know when I visit a project’s landing page:
Yes, you can configure your BitBucket repository to show the tree browser as the default, but then it doesn’t display the README, which is even worse.
For now, I’ll continue to use GitHub… maybe with a public e-mail like use.the.mail.form at ssokolow.com which I can make valid only long enough for GitHub to accept it.
However, they’re on very thin ice and, hopefully, BitBucket will wake up, seize this opportunity, and give GitHub enough competition to restore progressive (rather than regressive) innovation to code-hosting sites.
(Seriously, Google Code? You thought it was helpful to remove the project activity overview when the majority of projects on established sites are dormant and possibly buggy?)
Update: While our needs differ on things like the importance of a valid e-mail address, Linus Torvalds also makes good points on GitHub’s shortcomings. Not sure how BitBucket compares though. Probably equally poorly. (A little something that came to my attention via Planet Mozilla)
If you’re neither a scientist, nor active in the open-source community, it can be difficult to properly understand why people write open-source software. Why would people just give away the products of so much hard work?
I fully understand why one would be wary of a free product with no apparent profit model. After all, it’s only proper caution to check for Trojans when receiving a horse.
The trick with open-source software is to think about it in different terms. Traditionally, if you needed a piece of software or documentation or some other product that can be copied or photocopied, you had two options:
Paying for an existing solution can get expensive if you need a lot of copies, but writing your own version from scratch usually costs even more.
Using someone else’s solution makes you dependant on them for fixing bugs and writing new features, but writing and maintaining your own draws resources away from competing in whatever markets you occupy.
Open-source provides a third option with a slightly different payment structure. Instead of money, open-source vendors want you to pay for their software in externalities and, if they’re lucky, maybe you’ll chip in with a bug fix or a new feature to sweeten the pot for everyone.
One popular way is to set up a business to sell support contracts to businesses using the software in mission-critical places… often at prices lower than companies like Oracle and Microsoft who know they have you by the unmentionables.
Here are a few other examples of externalities that commonly motivate people to give away their code:
Just because open-source developers and vendors aren’t getting paid for their software in money doesn’t mean they aren’t getting paid. To an open-source developer, their software is their business card, a pride-worthy piece of art they want to share with the world, a tool they crafted to fix their own problems, a foot in the door for related products and services, and the seed for a group of like-minded people to collaborate with.
Also, while it doesn’t necessarily affect the bottom line, programmers often have a deep understanding of how easy it is to copy software, which makes one’s job more satisfying if they know they’re being paid for their time (which is a scarce commodity) rather than copies of their software (which are vanishingly cheap to make).
As a final acknowledgement, if you are considering sharing software that you’ve written yourself, there are a few hidden gotchas to getting a community to form and they all boil down to whether or not potential participants feel empowered. Here are the basic rules:
In short, there needs to be a smooth learning curve that can take people from “just wandered in” all the way up to “respected participant”.
I'm Stephan, a Linux user with a passion for open-source, UI/UX design, and exploring what makes fiction work.
In my spare time, I focus on (and write about):
For notification of significant updates to existing posts, consider following me on Mastodon.
