• My First Hackathon wasn't a Complete Disaster...

    Jul 7, 2019, 9:45:41 PM | 4 minutes

    In fact, it turned out great.

    I was at a company hackathon at the end of the last week, and I had some reservations about whether or not it would amount to anything, or if I would even enjoy it. I was skeptical about whether or not my company would make us work overnight unpaid on a project that would end up belonging to the company, and which I had no rights to, or if we would be in a competitive setting, or if there wouldn't be any interesting ideas I cared for, or if my team consisted of people who wouldn't be great to work with. Thankfully, it wasn't that kind of a hackathon, and nobody was forced to stay beyond the usual hours they're paid for, and there was no competition or prize or anything like that, and there were some nice ideas*. As for the teams, I guess it depends on a combination of the kinds of ideas people would gravitate towards, my own choice, some politics, and sheer dumb luck.

     I didn't exactly have any ideas I wanted to work on for the hackathon, because most of the ideas I'm already working on aren't new, or they aren't relevant for my company. I did, however, want to introduce Mithril somehow because I felt it was useful; it's a tiny library (8KB gzipped) and doesn't require any special framework knowledge like Angular does; it's just plain vanilla Javascript. The fact that it's so unopinionated and just Javascript makes it easy to learn. And what better way to introduce Mithril than with a new project where we have yet to decide the technology stack for it. The only problem was that I didn't know what project my company needed it for. Thankfully, somebody else in my company noticed this and came up with an idea where I could introduce Mithril.

    That's nice, but now what about the people I'll be working with? From my previous experience working with people in my company, there are definitely people I know I do not want to work with on a project like this. I don't like to work with them because they either don't communicate properly or because they aren't pulling their weight. Having any of those kinds of people in your team on a hackathon can spell disaster. You don't have a lot of leg room to mess about if any one of these people fails at communicating or contributing to the team. You do not want to spend extra time dealing with their shortcomings, because that's extra time that could have been spent on actually working on the hackathon project. I was lucky and the people that ended up my team not only weren't any of these people that I didn't want to work with, but they contributed in ways I wasn't aware of when we started. I may not have worked with them previously, and there was always the chance that it wouldn't have worked out, but it was better for them to have been people I've never worked with before than to be people I know for sure aren't worth working with.

    We didn't encounter too much friction introducing Mithril into my team; they didn't mind learning something new, even if they weren't used to it, and it wasn't a serious show stopper. We got a lot done, had something nice to show off at the end, and everybody in my team pulled their weight. Does this mean I'm more receptive to hackathons? Well, not necessarily. The reason this hackathon turned out so nicely was because I got lucky. I was lucky that I had a nice team and none of the people I didn't want to be on my team were on it, and I was lucky that there was an idea that matched what I wanted to introduce to the hackathon. I think hackathons are in a way like any kind of team project; you have to be lucky. Teams don't magically create great things by virtue of being a team; you have to get the right people together or else it doesn't work. If you have a team with people that don't communicate properly or aren't pulling their weight, they aren't going to make anything that amounts to much. It doesn't matter if you put them together and call them a team; it's not going to happen. Not without a lot of blood, sweat and tears. Which is frankly sometimes not even worth the trouble. 

    This has always been my experience working in a group. If you never get to choose what team you're on, or you're not sure what your team members are going to be like, whether or not your team succeeds or fails is often just due to sheer dumb luck. I tend to think of hackathons the same way. You just have to get lucky. I probably still wouldn't attend a hackathon if I had a choice. I'm not interested in testing my luck and I already have plenty of other projects to work on anyways.


    *Not every idea was nice, or appropriate for the time frame of the hackathon, but at least they weren't the only ones and I didn't have to choose them.

  • How to pick a Mastodon Instance

    Dec 11, 2018, 12:30:26 AM | 8 minutes

    TL;DR: Best instances for NSFW content creators without loli/shota: https://monsterpit.net, https://mastodon.host, https://artistalley.porn, https://mastodon.social. I also looked at https://humblr.social, https://pawoo.net, https://baraag.net, https://mastodon.art and https://kinkyelephant.com, but I suggest staying away from them for now.

    In the previous article, I explained the motivation for moving to a federated network like Mastodon, but actually picking which instance to be on isn't exactly easy. However, depending on the platform you've chosen, migrating to a different instance may not be so difficult, so it might not really matter too much.

    When I decided to move to Monsterpit.net, I looked at a few instances that might be suitable for the kinds of content I post, and used some criteria to determine which ones I wanted to end up on. Your mileage may vary, of course, but here's what I looked at:

    Most instances are open to registration, although depending on the target audience of the server and how many users are already on it, the registration may be restricted by invitations, closed completely or be tied to an account on another platform. Pawoo.net, for example, which belongs to Pixiv, is tied to your Pixiv account, so if you don't have a Pixiv account, you can't get a pawoo.net account either.

    Server Location
    Not all servers disclose what country they're from, but you can usually tell, from a combination of the instance's rules and other online services that try to detect what country a server is from. If the rules mention anything about not allowing Nazi content, then they're probably from Germany or France. Server location was a deal breaker for me though, because I didn't want to be on an instance that would be subject to the same US laws that would affect Tumblr's NSFW content as well. Most of the European servers don't have this problem; France or Germany are fine, Switzerland, even better. Avoid humblr.social for now though; they appear to be on a US server.

    Code of Conduct
    Most of the time, the specific rules aren't usually an issue, but because every instance is run by a different admin, they're allowed to have their own rules. On most Mastodon instances, there is just a standard code of conduct, with very similar wording where you just need to be nice, tag your NSFW content, and not espouse any sexism or racism. Which seems pretty reasonable on the surface, but I've seen worse codes of conduct elsewhere in open source spaces that ended up in things like witch hunts on Twitter and overpolicing of free speech. I guess we'll see what happens, but I prefer shorter codes of conduct with simpler wording. Not the monstrosity that exists on the mastodon.art instance, for example.

    NSFW Content
    Most instances allow NSFW content, but will ask that you tag them. A few of the instances which are intentionally designed for NSFW content won't ask that you tag your work, but might be subjected to blacklisting from other instances because of the lack of tags (and on their server, they have rules about tagging NSFW content). It's not a big deal if you're required to tag NSFW content anyways, so long as you remember to do it, since you can choose whether or not sensitive content should be hidden behind a clickable overlay.

    I'm one of the artists who aren't interested in loli or shota, but there are definitely people with those interests, and there are instances that cater to them. Originally, I thought it was no big deal to be on baraag.net which allows people to post loli/shota content. The only problem appears to be because there are so few other platforms that allow it, one would expect that the platforms that do allow it will be flooded with them. This caused a problem for me because it meant I didn't want to look at the instance's local timeline, and I had to unfollow the default followers when I signed up to avoid looking at loli and shota content. It also meant that all the bigger instances, which don't allow loli/shota, blacklisted baraag.net, and a user like myself, who has no interest in loli/shota wouldn't be seen on the other federated networks that had such a blacklist, just because the instance I signed up for happened to allow loli/shota. So bottom line, if you're not into loli/shota, and you see an instance that allows it, better avoid it to be sure people on other instances can actually find you.

    In order to ensure good visiblity from other instances so that people can follow you and interact with you, you should pick an instance that isn't blacklisted by the major instances. Mastodon.social is probably the biggest instance on the Mastodon network. Usually, an instance will list what instances they've blacklisted, either on github or directly in their code of conduct/TOS page. Another way to find out is to search for specific tags that you see on the instance that you're trying to test. If you can see posts from that instance, then it's not blacklisted. So for example, go to mastodon.social and type in a tag from another instance you're trying to check. If you can see posts from that instance in the results, it's not blacklisted. If you're not logged into mastodon.social or some other bigger instance, you can just use something like https://[domain name]/tags/[tag] to search for a tag from that instance.

    Conversely, you may prefer to be on an instance that doesn't blacklist other instances, if being able to see all kinds of content is important to you. However, finding out what that instance blacklists, if it isn't mentioned at all, is even harder than finding out if a specific instance is blacklisting it.

    Character Limits
    Another advantage of Mastodon is that each instance is separately configurable. Because it's like Twitter, Mastodon also has character limits. However, the exact character limit is determined by the administrator of the server. Some instances will mention explicitly that they've changed it; others won't. If it's not mentioned, it's probably safe to assume they're using the defaults (I think it was 512 characters per toot).

    Now that I've explained the criteria, here are some of the ones I've looked at:

    The two that I like the most are monsterpit.net and mastodon.host.

    Monsterpit is specifically for teratophilia and other monster type content, but they're pretty free about what that is. I've seen vampire and werewolf things in there, as well as more alien looking monsters. They have a "Be Excellent to Each Other" code of conduct, which is pretty simple and seems reasonable, as well as a 6666 character limit for toots. They're also hosted in Germany, so you don't have to worry about what will happen to your NSFW content.

    Mastodon.host is more general, but is also itself pretty interesting. It does have some minimal rules about tagging, and just being nice, but nothing too crazy or oddly specific. What's interesting about it is all the other platforms and features it offers you when you sign up and the instance is set up specifically to not blacklist any other instances. If you're looking for something specific, even if you don't end up signing up to that instance, you can still use it to tag search for pretty much everything on the entire Mastodon network. It also has a 2048 character limit for toots and 512 for profiles. It's hosted in France, so don't worry if you plan to post NSFW content.

    Mastodon.social is probably the biggest Mastodon instance around. It's nothing too special, and has a standard code of conduct. But it's not a bad place to be on if you plan to post NSFW content, as they are hosted in Germany.

    Artistalley.porn - Another one for NSFW stuff. It generally seems like a nice place, and you won't have issues with it as it's hosted in Germany.

    The instances I've mentioned so far do not allow loli/shota content. The ones I'm going to mention next either allow it, and are therefore, blacklisted by mastodon.social or have other issues, and I cannot advise signing up for them just yet.

    humblr.social appears to have been made as a tumblr replacement. It's specifically aimed at NSFW content, has a minimal code of conduct and appears not to be blacklisted by bigger instances just yet. The only problem with it is as far as I can tell, its servers are hosted in the US, which means it may end up having the same problem as Tumblr in the near future. If this changes though, then it wouldn't really be a bad place to post content on. I'd probably still prefer artistalley.porn though, if your content is illustrated, and not photography.

    pawoo.net is Pixiv's own Mastodon instance. You'd need a Pixiv account before you can sign up to use it, and it doesn't appear to have much of a code of conduct (not one I could read anyways), but the biggest problem I have with it is that like Pixiv, it allows loli/shota, and bigger instances have blocked media coming from it. Even if it weren't for posting loli/shota, I'd still have an issue with it because their servers are in Japan, which means you can't legally post uncensored NSFW content on them.

    baraag.net - I was on this instance previously because I heard of it from a different post on Tumblr. I kind of joined it first without really realizing what the implication of being on a loli/shota instance would be, and while it's otherwise not a bad place, it wasn't good for my visibility because it's been blacklisted by so many other bigger instances.

    Mastodon.art is already closed for sign ups anyways, so if you had any hope of being on it, that ship has sailed. For now anyways. Despite the closed sign ups, I still wouldn't join it because their code of conduct is oddly specific and restrictive.

    kinkyelephant.com is aimed at photographers. It doesn't look like a bad instance either, as they've got a minimal code of conduct and are hosted in France, but their sign ups are currently closed. I'm not entirely sure if their rules about no child porn applies to illustrated works either, although that may just be because it's for photographers and not illustrators.

  • The Importance of Federated Networks

    Dec 11, 2018, 12:23:52 AM | 6 minutes

    TL;DR: Federated networks are important if you want to consistently keep posting NSFW content. The concept may be difficult for some people to grasp, but it may, in the end, be the only safe place to continue posting NSFW content on.

    I’ve been aware of the existence of federated networks around the time I started using Tumblr. It basically started with Diaspora, and I’ve hinted about it subtly on my Tumblr about page. Which it seems most people don’t pay much attention to anyways. But when I originally learned about federated networks, I knew at the time, that it had an important place among the other social networking platforms, even if most people were instead using centralized platforms like Twitter, Tumblr, Facebook, and among others. I knew that federated networks were created by people who cared about their users, and wanted what’s best for their privacy. They were created and managed by people who wanted to provide a space for users to express themselves freely without a central platform being held hostage to government censorship (you can find plenty of examples of this from Stallman’s rant about Facebook.) At the time, I hadn’t specifically thought this would mean that people would want a platform like this to post NSFW content or loli/shota on, though at the time, and even now, it’s definitely possible. But at the time, I didn’t have any reason to believe that being on Tumblr would be a ticking time bomb, and still, I posted on other platforms, as well as Diaspora, because there wasn’t really any reason not to. In fact, posting on other platforms is the only way to be sure you’re not going to lose all your viewers because the one platform you rely on goes down, for whatever reason, tomorrow. But now, there’s no better time than to hop onto a federated network and continue posting NSFW content because in the end, it could very well be the only choice left.

    Most people I’ve met who aren’t that interested in computing or free software don’t know what federated networks are. They haven’t been as enthusiastic about joining a federated network as I have because they don’t understand them. I don’t blame them, but the only way to be sure you’ll have a place you can continue freely posting your content on, besides being on multiple platforms is to join a federated network, where instead of one central entity controlling the servers, the rules and the entire platform with only a limited number of poorly paid employees to moderate users, many independent administrators run their own servers using the same libre* platform software, with their own rules and own choice of where the server is hosted. This has several implications. Users have more choice about which server they want to be on. If you don’t like the rules governing a server in one country, you can try a server in a different country. If you don’t like any of the servers, or their rules, you can even make your own. Of course you’d still have to learn how to do it and pay for the server hosting, or pay someone else to do everything for you, but it’s at least possible. On Tumblr and other central networks, this isn’t even an option. Tumblr and Facebook don’t open source their platform software** for other people to use. Secondly, all the accounts on a federated network can interact with each other. This means that if you choose to be on one server and a friend chooses to be on another, you can still follow each other and stay in contact. This is possible because both servers are using the same platform software. It is designed to work like this. Thirdly, because every server is operated by a different entity, and has different rules, all the staff members on one server need only be responsible for the content on their servers; not the entire federated network. This makes managing and moderating users much more managable.

    On the other hand, in addition to most people being confused about how federated networks work, there are some other things worth looking at in a server or instance before you sign up for it. Firstly, you may be interested in an instance which is already full, which means the server admin might decide to close sign ups, and you’ll have to look elsewhere if you want to join an instance. Secondly, depending on the content and rules on the instance you’re looking for, your server may be blacklisted by other instances, making it harder for other people to find you. Conversely, your instance may blacklist other instances (particularly if they contain loli/shota or are too free with their rules), which means you can’t find certain kinds of content from the timeline of your instance. But all of this is very much a consequence of a federated network, where users are the ones who decide what content they want to have on their servers. It may mean that there are instances that promote racism or sexism. It can mean there are instances that contain other kinds of objectionable content. But this is what a free platform looks like; it will enable people to create servers for any kind of content you can think of. It need not be about racism or sexism, and often, it isn’t. You can create a server on a federated network for content that most commercial entities have no interest in supporting, but is otherwise not objectionable.

    The freedom to choose an instance to be a part of or to create your own instance is a small price to pay for the freedom to post NSFW content consistently. I’ll understand that some people wouldn’t choose to be a part of such a platform, despite the benefits, but until something better comes along, it’s the only place I can think of where I can safely post NSFW content on without being told tomorrow that I have to pack up and go elsewhere. And I don’t care if people don’t follow me there; I’m going there because I think it’s what’s best for my NSFW content, and because in a world where we are constantly losing our privacy and freedom, using and developing free software like federated networking is the best thing to do.

    *In English, there is some ambiguity with the term “free”, because it can mean free, as in beer that costs nothing, or free as in free speech. So we use libre to mean free as in free speech.

    **Most notably, Facebook open sources React, one of the components that makes up their social networking platform, but it uses (at the time of writing) a questionable open source license that isn’t compatible with the spirit of free software, and the Facebook platform itself is still proprietary.

  • How I spent Easter putting Linux on an old Macbook Pro (part II)

    Apr 4, 2018, 12:11:10 AM | 9 minutes
    Before I get on to how it went down, here is what I needed my Macbook to do:
    • Web browsing
    • Playing flash games
    • Mounting, reading and writing to the other partitions
    • Triple booting. Mac OSX for my GodotEngine game build testing and dmg packaging, Windows 7 for games and Linux for everything else.
    I did as much research as I could about what I'd need to do to get Linux on my Macbook and play nicely with the other OSes, how to do the partitioning and installing the boot loaders, whether or not I need rEFInd and any of its quirks I needed to know about, and whether or not there would be any hardware incompatibilities. Unfortunately, I made the mistake of thinking I had a Macbook Pro5,5 when I had a Macbook Pro7,1, and didn't figure that out until I ran into Nvidia problems and journalctl reported I was using a Macbook7,1 (more about Nvidia problems later). From experience, setting up the boot loaders and partitioning are the most crucial and important parts of installing any OS, especially when you do it manually with a distro like Arch Linux, and you plan to boot more than one OS on the same machine. I needed to be sure that the partitioning and boot setup I planned to have made sense.
    The partitioning was in part alleviated by the fact that the Macbook already came with a boot partition, so I didn't have to figure out how big it should have been, or where it should go, and it was possible to have all three OSes boot from it with rEFInd.
    I ended up having to clean up a lot of cache and log files in my system, as well as backup older files and applications, but it got the job done, and I had the space I wanted for a Linux partition while comfortably having enough free space on the Mac partition to run OSX when needed.
    I upgraded rEFIt to rEFInd first in case it was necessary to use kernel parameters, as rEFIt doesn't support them.
    I ended up splitting the Mac partition for the Linux partition and was warned that it might break my BootCamp setup. All the guides said I should split the partition this way if I wanted to triple boot, so I thought nothing of it and created it. Well, the notice was actually correct; Windows 7 couldn't boot properly.
    Fortunately, the fix was easy; it turns out splitting the Mac partition destroyed the hybrid MBR tables, and all I had to do was install gdisk and re-create it.*
    Then after that, installing Arch Linux was actually pretty easy; just follow the Wiki, make a few Mac specific changes, and everything boots up in Linux just fine with systemd-boot (and the other OSes continue to boot as well).
    Unfortunately, that wasn't the end of that. Remember when I mentioned I had Nvidia problems earlier? Well, just getting to a virtual console with Arch Linux was easy enough, but trying to get the Xserver** up with Nvidia was a real hassle. At first, it didn't work, and Nvidia crashed the Xserver (I could still SSH into the device from another computer though). This is about the time where I find out I have been looking up guides on the wrong version of the Macbook Pro I have, and according to a few threads, Nvidia on my current version of the Macbook Pro didn't work because Nvidia wasn't loaded properly at boot time in EFI mode, and the current hack required installing grub, the boot loader and configuring it to run a script. Unfortunately, systemd-boot is too light and doesn't have such features. I didn't really know what kind of udev hook would have been appropriate to fix this problem, and I really didn't want to make another boot partition just to install grub, so I ended up giving Nouveau, the open source graphics driver a try.
    Nouveau worked at first, but it was somewhat slower than Nvidia and caused my GPU to heat up more. I later found out it wasn't actually necessary to install grub on a separate boot partition, and it could be shared with the existing boot partition OSX uses, and in order to decide whether or not Nouveau was worth it, I ended up trying grub on CSM mode to see if Nvidia would work. I originally wanted to use syslinux because it was lighter (that's how badly I wanted to avoid grub), but unfortunately, it doesn't support the 64bit ext4 file system, which I used and didn't think too much about when I formatted it. Thankfully, grub didn't give me as much trouble as it did when I attempted to use it on Virtualbox, and I didn't have to create another boot partition just to use it.
    This fixed my problem, and now I get a graphical environment using Nvidia. It does perform better, and it probably runs somewat cooler than Nouveau does, so it's worth using if you can get Nvidia to work.
    Unfortunately, CSM booting takes longer than EFI does, as CSM is just an emulation layer. So I decided to try installing grub in EFI mode with the scripts. That worked, and Nvidia runs with Xserver in EFI mode.
    Sadly, that wasn't the end of my troubles with Nvidia. It worked fine until I tried to log off or stop the Xserver, and then it crashes. This is unfortunately a bug that hasn't been fixed because Nvidia is proprietary, and nobody's been able to figure out how to fix it. Additionally, I later found out that the keyboard backlights also weren't getting picked up in EFI mode. I guess there's another parameter that needs to be added to the script for that. I wouldn't at all be surprised if the screen backlight wasn't being picked up either. For a stable, consistent system, this was unacceptable, so I went back to booting in CSM. Despite the handicap though, it still beats the boot times of Windows 7 and Mac OSX.***
    While I was messing with Nvidia on the Xserver, I noticed my trackpad wasn't working that nicely. It needed to be properly configured to get some semblance of "right clicking" to work, as Macs don't make a distinction between left and right click, but rather normal click and ctrl key + click. Most of the guides said I should use the xf86-input-mtrack framework, but it never really worked all that well, and the bottom half of the trackpad wouldn't register clicks, so I opted for the newer xf86-input-synaptics package, and it mostly worked. It still required some tinkering, but it works better now.
    After all those trials and tribulations, you might be wondering if all this time spent installing, tinkering and configuring about was worth it. If I had chosen a different distro like Mint or Solus, there probably would have been less manual configuration required, so don't think that my choice of Arch Linux reflects on what it's really like to install Linux on a computer alongside other OSes (wait until you get to Gentoo...). 
    Well, I did end up with a system that runs more efficiently and faster than OSX does. It boots faster, it responds faster, and saves me more precious RAM for the actual web browsing. I chose a lightweight windows manager called i3, and I have as much control over my desktop with it as I feel comfortable with. I'd never be able to do this on OSX. i3 on startup takes up about 3MB of RAM. On a system with less than 8GB of RAM, you're going to need all the RAM you can get, so why waste it on a desktop environment when you can give it to more resource intensive programs like browsers that really need it? I don't plan to use Windows 7 for browsing, so I can't directly compare and say if it's more efficient than OSX, but I can say that Linux doesn't waste its resources on fancy effects if you don't want it to.
    I now feel more comfortable running updates every weekend, knowing that I'm not going to have hundreds of MBs or more of disk space dumped on me just because I need the latest security patch or whatever. And Linux on my Macbook will probably continue to work just fine after an update. I've never had to worry much about this on all the computers I've already installed Arch on, as all the updates are incremental.
    I use the i3bar on my newer computer to monitor system resources. Occasionally, I'll learn something new like systemd eating up disk space when an app crashes and it creates a coredump**** or having to clean out the package manager cache, but for the most part, my new, beefy computer hasn't done anything too wild while I was watching the i3bar stats. However, I'd imagine my older Macbook with less resources will need more supervision, and instead of waiting for swapping to happen or for programs to go sluggish, I can watch the RAM with i3bar, and kill or restart programs when they start taking up too much RAM. Web browsers are typically guilty of this. Or if some process is causing my CPU or GPU to overheat, I can figure out which one it is and stop it. Mac OSX never had good handy tools like this and conky for watching system resources.
    Linux is essentially the only OS on my Macbook that can access all three OS partitions. Mac OSX can't read ext4 at all, and can't write to NTFS, the partition Windows 7 uses. Windows 7 can, with another program, access the HFS partition where Mac OSX resides, but it also can't read ext4 at all.
    For fun, I decided to time how long it would take for each OS to boot from selecting it from the rEFInd screen to actually displaying a login screen (or the equivalent in a virtual console). Linux grub with EFI takes 24 seconds, Linux grub with CSM takes 37 seconds, Mac OSX takes 1 minute and 19 seconds and Windows 7 takes 1 minute and 35 seconds. Even if CSM booting is slower, it's still a huge improvement over Mac OSX.
    Of course, all this means nothing though if installing Linux doesn't do what I need it to do. Well, it does do everything I needed it to do. I can browse the web, play flash games and access the Mac partition just fine while still being able to boot into the other two OSes.
    I'm very happy with the results of this experiment I did over Easter, and I'll actually be glad to keep this Macbook around for awhile longer, even if it still has less than 8GB of RAM and an outdated CPU.
    * This part actually freaked me out a little because I read plenty of warnings that a hybrid MBR with GPT is actually a bad idea, and that you should be careful, but there's really no way around it if you want to dual boot Windows 7 on a Macbook Pro7,1 with OSX. It ended up being easy in retrospect, but anytime you use gdisk to modify your partitions, anything can happen...
    ** This is the graphical server used on some Unix systems. You need it (or Wayland) to run any graphical desktop environment or windows manager on Linux.
    *** If anyone knows how to boot CSM faster or fix that Nvidia bug in EFI mode, I'm all ears! Let me know if you figure it out. If it helps, the Nvidia GPU that comes with my Macbook is a GeForce 320M.
    **** You are free to turn off systemd coredump if you don't like it taking up all that space.
  • How I spent Easter putting Linux on an old Macbook Pro (part I)

    Apr 4, 2018, 12:07:36 AM | 3 minutes
    So I spent nearly the entire Easter weekend, trying to get Linux on my Macbook. This article will be written in two parts: The motivation behind why I did it, and how it actually went down.
    Before, I wasn't entirely sure if I wanted to put Linux on my Macbook for lack of space for the Linux partition itself, among other reasons. I was also too afraid that Apple had designed the Macbook to be difficult to put anything else on other than their own OSes and Windows through BootCamp. In short, my Macbook already had too much history, and if anything went wrong, I wouldn't have a computer I could draw or develop my game on. That's changed however, as I have a new laptop that does all these things better, leaving only a few tasks that I still use the Macbook for. I've also gotten more experience using Linux and going through installing boot loaders and partitions on other devices, so I'm a bit more confident in the outcome than I was a few years ago.
    With that out of the way, the other reasons I considered it worth doing was because my Macbook is nearly 8 years old. It's not nearly as old as the Macbook I replaced with my new laptop, but it's still getting old, and hasn't had any of its hardware components replaced with better ones. It's not as fast as it used to be because every new version of OSX requires more and more resources to run well enough, and there will come a time when Apple will eventually stop supporting my older device on newer versions of OSX, and I'll be forced to get a new computer. I could just leave an older unsupported version of OSX on it, but then I wouldn't get any security patches, and for a web browsing computer, that's a bad idea. Now I could just replace the RAM or the hard drive, and maybe it will work better. And certainly, a Macbook as old as mine is not nearly as difficult to take apart as the newer Macbook Retinas are. However, installing a better OS is also a viable alternative to gaining back speed as well. A web browsing computer need not have the same resources as the computer I use to draw prints or stream my art with. Not to mention Linux is not built with planned obsolence in mind.
    Since I've been using my new laptop to do most of the more processor and RAM intensive stuff, my Macbook has been delegated to a web browsing machine that I occasionally use for Windows 7 and flash games. Linux can do all of those things except the Windows 7 games, and does just what I need it for on my Macbook.
    Lastly, I like to have the feeling that I'm actually in control of my own computing. With Mac OSX, I felt as if I had no freedom or choice over some of the stuff that OSX does for you. It's the same reason I decided not to get another Mac OSX computer and to put Linux on the new machine. I dislike the general feeling of not knowing how my computer works or what's wrong with it when it crashes, having to read cryptic error logs or feeling like I have no control over what my computer does. It's a typical problem with proprietary OSes.