For those of you who enforce my Sundays on me (keep doing that, thank you!), I’ll be changing my Saturdays with my Sundays.
That’s right! In this new brave world, I’ll be taking Saturdays off, not Sundays. Feel free to pester me all day on Sunday, now!
This means, as a logical result, I will not be around tomorrow, Saturday.
More hardware adventures.
I got my Dell XPS13. Amazing.
The good news: This MacBook Air clone is clearly an Air competitor, and easily slightly better in nearly every regard except for the battery.
The bad news is that the Intel Wireless card needs non-free (I’ll be replacing that shortly), and the touchpad’s driver isn’t totally implemented until Kernel 3.16. I’m currently building a 3.14 kernel with the patch to send to the kind Debian kernel people. We’ll see if that works. Ubuntu Trusty already has the patch, but it didn’t get upstreamed. That kinda sucks.
It also shipped with UEFI disabled, and was defaulting to boot in ‘legacy’ mode. It shipped with Ubuntu, a bit disappointed to not see Ubuntu keys on the machine.
Touchscreen works; in short -stunning. I think I found my new travel buddy. Debian unstable runs great, stable had some issues.
A few interesting things happened after I got a macbook air.
Firstly, I got a lot of shit from my peers and friends about it. This was funny to me, nothing really bothered me about it, but I can see this becoming really tiresome at events like hackathons or conferences.
As a byproduct, there’s a strong feeling in the hardcore F/OSS world that Apple hardware is the incarnation of evil.
As a result of both of the above, hardcore F/OSS (and Distro hackers) don’t buy apple hardware.
Therefore, GNU/Linux is complete garbage on Apple hardware. Apple’s firmware bugs don’t help, but we’re BAD.
Some might ask why this is a big deal. The fact is, this is one of the most used platforms for Open Source development (note I used that term exactly).
Are we to damn these users to a nonfree OS because we want to maintain our purity?
I had to give back my Air, but I still have a Mac Mini that i’ve been using for testing bugs on OSX in code I have. Very soon, my Mac Mini will be used to help fix the common bugs in the install process.
Some things you can do:
One which ends in tears, I’m afraid.
A week or so ago, I got an MacBook Air 13” (MacBook Air 6-2), to take with me when I head out to local hack sessions, and when I travel out of state for short lengths of time. My current Thinkpad T520i is an amazing machine, and will remain my daily driver for a while to come.
After getting it, I unboxed the machine, and put in a Debian install USB key. I wiped OSX (without even booting into it) and put Debian on the drive.
To my dismay, it didn’t boot up after install. Using the recovery mode of the disk, I chrooted in and attempted an upgrade (to ensure I had an up-to-date GRUB). I couldn’t dist-upgrade, the terminal went white. After C-c’ing the terminal, I saw something about systemd’s sysvinit shim, so I manually did a purge of sysvinit and install of systemd.
I hear this has been resolved now. Thanks :)
My machine still wasn’t booting, so I checked around. Turns out I needed to copy over the GRUB EFI blob to a different location to allow it to boot. After doing that, I could boot Debian whilst holding Alt.
After booting, things went great! Until I shut my lid. After that point, my screen was either 0% bright (absolutely dark) or 100% (facemeltingly bright).
I saw mba6x_bl, which claims to fix it, and has many happy users. If you’re in a similar suggestion, I highly suggest looking at it.
Unfortunately, this caused my machine to black out on boot and I couldn’t see the screen at all anymore. A rescue disk later, and I was back.
Annoyingly, the bootup noise’s volume is stored in NVRAM, which gets written out by OSX when it shuts down. After consulting the inimitableMatthew Garrett, I was told the NVRAM can be hacked about with by mounting
efivarfs on /sys/firmware/efi/efivars type efivarfs. Win!
After hitting enter, I got a kernel panic and some notes about hardware assertions failing.
That’s when I returned my MacBook and got a Dell XPS 13.
This is a problem, folks.
If I can’t figure out how to make this work, how can we expect our users?
Such a shame the most hardware on the planet gets no support, locking it’s users into even less freedom.
What pushed me over the edge was finding the aiopg driver (postgres asyncio bindings), with very (let me stress - very) immature SQLAlchemy support.
Unfortunately, no web frameworks support asyncio as a first-class member of the framework, so I was forced into writing a microframework. The resulting “app” looks pretty not bad, and likely easy to switch if Flask ever gets support for asyncio.
One neat side-effect was that the framework can support stuff like websockets as a first-class element of the framework, just like
Moxie will be a tool to run periodic long-running jobs in a sane way using docker.io.
I’ve been learning about android development over the last few weeks, and I think I’m slowly getting the hang of best practices.
It’s a bit tough, there’s a lot of stuff that’s not super Java-idomatic that’s become Android-idiomatic, so getting over that stuff has been interesting.
I’ve been finding that Android tends to re-implement most things in a similar enough way, but always with some small tweak that feels kinda funny.
It’s working well enough, and I’m hoping that I can clean up a few android libraries to deal with some of the OpenGov datasets I’m interested in.
If anyone has any tips on proper handling of what to make a fragment, and what activities should look like, I’d really love posts about that.
It seems like sometimes I have a 1-to-1 mapping of Fragments to Activity, but I want to keep it a fragment for large devices.
Anyway, best practices welcome.
Great time, super well organized by this year’s TCamp staff. Really outstanding. Lots of really amazing discussion, and I feel a lot of effort is finally jelling around Open Civic Data, which is an absolute thrill for me.
Can’t wait to see what the next few months bring!