on Dec 19, 2012
So I’m using Linux Mint now. I’ve been installing Linux now and again over the years. It’s always interesting, but eventually I end up back on Windows after running into a problem with an unreasonably difficult solution, or discovering some bit of needed software just isn’t available. Each time I try Linux, I make it a little farther before I hit the point of “it would be easier to return to Windows than to put up with this.”
I haven’t gone back to Windows 7 because in order to properly install Win 7 this time I really ought to go in, back up EVERYTHING, and re-partition my hard drive so it makes some kind of logical sense. I’m not eager to do that, which is why we’re having this Linux Adventure of Discovery and Bafflement! and not just sucking it up and installing Windows.
We’re on day five of the experiment now. Here are a bunch of random observations about the experience so far:
I have reached a point in my life where using a computer that can’t run Minecraft is simply not an option. I’ve disqualified Minecraft from all future GOTY awards, because otherwise it would just keep winning. Forever. It’s more than just a game, it’s part of how I relax and think. If I get stuck on a bit of code or want to listen to an audiobook, I do it while Minecraft-ing.
I’m happy to say that Minecraft worked more or less flawlessly for me, right from the start. In fact, the Technic pack also worked flawlessly, which is good since that’s my double-favorite collection of Minecraft mods.
I used FileZilla on Windows for all my my FTP needs, which includes uploading every single image you’ve ever seen on this site. FileZilla is available on Linux, and looks and operates just as before. Nice, sensible, stable, lovely software.
Long-term, this is probably a deal-breaker. Linux support for games has been improving by leaps and bounds, and Steam for Linux is looking very promising. But we’re not quite there yet. I managed to get into the Steam on Linux beta, and under Linux my games library drops from 174 games to 16. That’s not Steam’s fault. That’s just the simple, understandable fact that less than ten percent of all developers bother making a Linux port. I was actually surprised to find the number was that high. (Most of my Linux games are indies. I’m sure the ratio would be even more depressing if I stuck to AAA games.)
I’ve installed WINE, but I haven’t actually used it yet.
Some interesting notes on performance:
In using the Technic pack in Minecraft, my framerate seems slightly lower than it was on Windows. Under windows, I could use the (Technic) mod to increase the view distance above the normal Minecraft maximum and still enjoy a smooth experience. Under Linux, I have to lower the view distance down to Minecraft standard, and even then I get occasional hitches if I turn around quickly.
The Technic pack also has a mod where sleeping in a bed will drop the game into a high-speed simulation mode. (This is so that crops can grow and furnaces can cook while you sleep.) In Windows, the game usually ran at ~7x speed while sleeping, so that one minute of sleep was the equivalent of simply standing beside the bed for seven minutes. Under Linux, the sim runs at ~11x speed.
Note that the first issue (visibility and framerate) is related more to graphics card and memory, while this latter issue (simulation speed) is mostly CPU bound.
I can’t really draw any firm conclusions about this. The framerate problems could be an issue with the Java environment on Linux, or a problem with graphics driver throughput, or a problem with something the OS itself is doing. It’s impossible for me to say. Still, I find the discrepancy interesting.
This is the big one. I’ve used Developer Studio for years. I love it. I don’t often love software, particularly from Microsoft, but if there’s a better development environment then I have yet to see it. Even the Hippie Freeloader Edition is excellent.
More to the point, when my computer died I was in the middle of working on some very Windows-centric code. I’ve been trying to make portable code (or at least theoretically portable code) over the last couple of years, and leaning away from Microsoft-specific interfaces. But for this project I had thrown away this forward-thinking attitude and just embraced the Microsoft Windows API with reckless sloth.
See, when you want to write some code to make a window, you want to use some pre-made code. API stands for Application programming interface, which is the system you use to talk to code that someone else has written. Assuming you don’t want to re-invent the wheel and make your own code to draw Windows with beveled edges, track low-level data coming from input devices, and re-implement all the logic behind minimizing, maximizing, resizing, closing, overlapping, clicking, dragging, copying, pasting, highlighting, focusing, and disabling windows, then you want to use some existing code.
The problem is that for Linux, Apple, and Microsoft, the code to do this is completely different. Not just different in the way that the code is written, but different in the way that the code is used. When the user clicks maximize, one GUI sends your application a Maximize message. Another one sends a resize message with a footnote that “this resize happened as a result of the user maximizing the window”. Perhaps the other one sends the application a notification that the window position has changed, and the program has to ask for more details if it wants to know the particulars.
The upshot is that a programmer who wants to port a project from one operating system to another can’t just do Find & Replace on their code to replace CreateMicrosoftWindow () with CreateLinuxWindow () and call it a day. The programmer is going to need to re-write huge sections of the program. The more Windows code you use, the more re-writing you need to do and the more complex porting it will be. At some point the changes are so extensive that you’re basically starting over.
In this project, I had used a LOT of VERY specific windows code. For the record, I’ve been working on the software that I used to make my Drawn To Knowledge videos. The interface is very complicated. (I’d show you a screenshot, but I can’t run it right now, because I’m on Linux.) There are many edit boxes, sliders, buttons, drop-down boxes, color pickers, and all kinds of other fussy little controls.
Now I’m on Linux and cut off from my Microsoft development tools. I have a few options:
- I could port to Linux. It might be good to learn how coding works here in Linux land. Porting my project would take a long time, and if I ever decided to move back to Windows then I’d have to port it again. This would be good for educational purposes, but not good for the project itself.
- I could port to Qt. This is exactly the sort of situation Qt was made for: A platform-independent, interface-heavy application. On the other hand, I am not a fan of the Qt development environment. When I ported Project Octant from Qt to Visual Studio, it was like being given a hammer after spending all day pounding nails with a brick. You can grow accustomed to a clunky interface, but that’s not the same thing as having a good interface to begin with.
I could use Qt and it would be The Right Thing To Do for the purposes of portability. (My speed problems with Qt wouldn’t really be an issue. I wouldn’t be rendering interface elements into a 3D window, and speed is not as critical on this project.) But I really dislike the Qt environment and what it does to my workflow. Bleh. But maybe.
- I could look for some other third-party solution. In the past, my search for interface code has been focused on looking for things that will render interface stuff into a 3D window. Here, I just need generic window controls. Something like wxWidgets could get the job done. I’d still need to pick a development environment for Linux. But in theory once I was done with this port I ought to be able to go back to Windows if I wanted.
I dunno. It’s a big decision and I don’t really know enough to make it yet.