Wednesday, 20 January 2016

How trans-people are really people, like all of us

Having spent a considerable and unfortunate amount of time around bigoted people, I came to a rather interesting train of thought that I want to share widely.

Let me start by asking you a simple question: would you treat a woman differently based on whether or not she had an appendectomy performed? What about a man who was born with six toes; would it change your opinion of him whether or not he had it removed? For the vast majority of people, and even the bigoted crowd that inspired this train of thought, the answer would be a resounding no: who are we to judge someone based on a corrective procedure they had to repair a defect with their body?

Okay, now here's a similar and still simple question: would you treat a woman differently based on whether or not she had her penis removed?

"Stop," I hear some of you calling. "That is a completely separate subject," you ration. Why?

What makes the correction of a birth defect involving sex organs any different from correcting birth defects or ailments with any other organ? Are we, as a culture and society, so hyperfocused on sexuality that we can't accept some people have congenital genital defects?

I have begun to wonder why trans equality and trans rights are even being discussed or even exist; that is like stating we need kidney failure equality or diabetic rights. They are all life-long conditions, involve a part of the body being defective, and often require surgery. What is so offensive, so different, so awful about a person having incorrect sex organs? The fault lies with those people who 'other' people who suffer from transsexuality, labelling them and saying they are different or somehow less of a person due to a birth defect.

There have been numerous studies that have proven beyond a reasonable doubt that the brain can develop independently of primary sex organs, and that the brain can and does sometimes end up with the wiring of the gender opposite that with which a person is born. It is not a "mental disorder" in that there is no psychological problem; the brain is that of a man or woman, in a woman or man's body. Why should it matter what organs they have?

You can argue that reproduction is a factor, and you may even be right for a few years; but there are numerous research programmes being done as you read this to find a way to reproduction for people with all manner of reproductive organ troubles. Transsexuality is a subset of that; but some women are born without ovaries, some men are born with undescended testes, and so on. Why should we treat people who were born with the wrong set of organs any different from people born with any other problem?

The way I see it, the labelling itself - the fact that people who have this condition are considered a different kind of person - is the problem. It is a medical disorder akin to spina bifida or cleft palette, not a label or category of people. I would be hard-pressed to find anyone who would discriminate against a person for having cleft palette; after all, it isn't their fault, they were born that way. Why should we treat transsexuals any differently?

To a final point, some may also claim that you must have the surgery performed to count as a "true" transsexual. This belief is wrong for a number of reasons. In the same way some people cannot have cleft palette corrected - their body may not be capable of undergoing surgery; they may be allergic to anaesthesia; they may not be able to afford the cost of surgery; and in some communities where healthcare is not readily accessible, they may not even know that a treatment even exists. The same factors can apply to a man with a vagina or a woman with a penis. Some of these people are still able to use hormonal therapy (also known as HRT) to correct at least some of their attributes to more correctly fit with their gender and feel better, while others are unable to obtain even that small amount of help. Instead of ostracising them, we should be embracing them. We must begin to acknowledge that we as a society should be caring for those who have real, physical ailments instead of antagonising them.

After all, wouldn't you want compassion if you had a birth defect? What about a birth defect that perhaps even persisted in to adulthood or even beyond? Open your heart and mind, and show your fellow people dignity and respect.

Saturday, 19 December 2015

Time moves too quickly

I have many things to blog about and ideas in my queue - a few half-written drafts and one almost finished final copy. But none of that is important right now.

I'm incredibly late in finding this out, perhaps a side-effect of spending the last two months of my life packing to move to a much better, happier place than where I live now. It was reason enough to drop off of some of the places I frequent, I thought, because it's not like the same people won't be there when I have finished my move.

But I've just learned that Telsa Gwynne has died. Possibly not a whole lot of people who read my blog will know her, but she was quite active in the open-source community when I was growing up. I loved to read her "diary entries", what today we would call a blog. It was during a re-read of her diary last year that I became inspired to create this blog, and indeed, my musing posts are basically my own version of it. It is directly as a result of her writing that this blog exists, and that I have been able to help others whether it be in FreeBSD, Gentoo, Python, or elsewhere. I am grateful to her and I am quite sorry that I never was able to tell her about it. I had considered it, at one time, but felt it would be silly, especially since I am not very well known yet outside of some FreeBSD circles. Who am I to bother someone whom I greatly respect, with a silly story of a small blog? Regret does not begin to express the emotions I feel from not telling her anyway.

Fare thee well, Telsa. I did not know you personally, but your writing style would betray that in my heart and mind, and those of many like me. You may have been removed from the open source communities you were once a large part of, but your legacy lives on, and will always live on. Your perseverance inspired me. And I give all of my deepest condolences to your family and friends, who will surely miss you more than I ever could.

Saturday, 28 November 2015

Web browsers, music players, workarounds, and PulseAudio

As security researchers have discovered yet another horrible security bug in Chrome, and Google yet again decides to put off fixing it, I decided to finally give up Chrome entirely. I had dwindled down my usage of it from primary browser in 2009; to secondary browser for Flash and videos in 2013; and finally using it solely for streaming Google Play Music and Spotify, along with the occasional site compatibility test for my work, in 2015. Firefox's inspector tools and Firebug are good enough, and I have a Mac running Safari if I need a WebKit test, so I decided it was no longer important to test on Chrome. That left the issue of music streaming.

Can't handle it, can't handle it

Google Play Music, however, has a fatal flaw. It is a mess of terrible "one page" JavaScript. After only a few hours of music streaming, it had already leaked 150 MB(!) worth of orphan DOM nodes, and 282 MB(!!!!) worth of uncollectable JavaScript objects. This basically means it created buttons, links, and so on, and didn't properly remove them when it was done, so that memory is leaked out and I would have to restart Firefox to get that memory back. Restarting Firefox multiple times a day is not an option for me.

What's worse is that one of Firefox's best and most unknown features was also making my life worse. Every 10 seconds, it scans its memory to see if any of it can be reclaimed, to make sure that it does not use too much memory. Since Google Play Music's interface had leaked so much memory, the scan was taking about 2 seconds - during which the browser became completely unresponsive. That means that for about 20% of the entire time it was open, it was unresponsive (frozen, locked, etc), all because Google has no idea how to write JavaScript.

My mother (bless her soul, she's openly embraced Debian) suggested I try Rekonq, but it could not even load Google Play Music's user interface. I also tried Opera Classic (pre-Blink), and it too could not load Google Play Music. At this point I am very upset at Google; why did you write such a cluster#*$@ of terrible code instead of writing a simple multi-page player like YouTube? YouTube does not suffer from any of these issues, and is a Google product!* Anyway, my next goal was to see what I could do for streaming music that did not require a Web browser.

* I am aware that YouTube has a single-page mode, but I found a way to disable it except while using playlists. It works great and does not leak half a gigabyte of memory.

Done, done, and I'm on to the next one

It turns out that Google Play Music has no official API and no non-browser clients. Even Spotify has unofficial ones that are of questionable quality and legality, but Google has done a very good job of making their API so hard to use that nobody bothers to even try with them. (Future project idea.)

Then I realised their Android app is pretty reliable and certainly better than having my browser locked for 20% of the time it's open. However, I still need to be able to hear other things on my computer (if someone links me to a video or presentation, for instance), and I don't want to have to keep flipping back and forth between my phone and desktop.

My work-provided desktop did not come with a sound card (even though we use sound a lot internally...), so I am using a USB Griffin iMic as my sound "card". It works fantastically in Linux/ALSA, but one thing I could not figure out was how to make it play line in as a monitor (i.e. playthrough, listening to line in/mic with headphones/out, whatever you like to call it). Thankfully, I found a very helpful blog post about this very issue, and a solution involving PulseAudio: pactl load-module module-loopback was all it took to listen to crystal-clear, low-latency, glorious Nexus audio on my desktop!

Final thoughts

  • While it certainly is great that PulseAudio offers the same great passthrough functionality that OS X had since Jaguar (and lost in Mavericks), they really need to document PulseAudio modules better.
  • Google needs to rethink making their music player in one page JavaScript. A native app would be amazing and make me a much happier catfox.
  • It just feels like... if Google hadn't royally screwed up Chrome, and they hadn't royally screwed up their music player, then hours of my life would have been saved because then I would not have had to learn how to monitor line in within Linux. It was interesting learning all this, but I still have this feeling that it should be entirely unnecessary, and like this is a very unclean workaround for what amounts to "Google is terrible at writing code".

Oh well, at least Android 6.0 is good. (For now.)

Friday, 4 September 2015

The Joys of Unix Programming: MAP_ANON(YMOUS)

I was trying to do a little late-night hacking last night on SuperGameHerm, the Game Boy emulator my friends and I are writing, and I hit an error in the memory mapper. Specifically, certain OSes that used to be named after cats don't like calling mmap on /dev/zero (neither does Android). I thought it was odd that it was falling back to that code in the first place, though, because Apple's Mac OS X — I mean, certain cat themed OS — has always supported MAP_ANON, and I confirmed that by going to man mmap on a Mac.

What was going on? I dug deeper and saw MAP_ANON was guarded in sys/mman.h, so CMake wasn't finding it and it was instead compiling our fallback code. And so I started digging up other issues related to big endian machines and realised that I had only tested OS X and FreeBSD on big endian, and never tested OS X or FreeBSD on little endian. So was my big mistake.

This is a comprehensive guide to How to Make MAP_ANON(YMOUS) Visible, for every OS I could find information on:

Mac OS X

On 10.3 and below, this is easy; it's always there! It is not guarded by any #ifdef.

On 10.5 and above, it is slighly harder; you must define _DARWIN_C_SOURCE to cause MAP_ANON to be visible in a public scope.

On 10.4 only, it's much harder! It is only protected by #ifndef _POSIX_C_SOURCE, so to use MAP_ANON against the 10.4 SDK, you must completely undefine _POSIX_C_SOURCE. You don't have any other choice.

I suppose that means my overall advice then is to use the 10.5 SDK no matter what, if you have a Leopard computer handy, because it can target as low as 10.0. Otherwise, use the Panther SDK included with Tiger's Xcode Tools. Don't ever use Tiger's SDK if you want MAP_ANON.

FreeBSD

Before 5.0, it's always visible, just as in OS X 10.3. There are no preprocessor options to show or hide MAP_ANON.

On 5.0 or above, the only way to cause MAP_ANON to be visible is to define __BSD_VISIBLE somewhere. Undefining _POSIX_C_SOURCE won't save you here.

Other BSDs (NetBSD, OpenBSD, DragonFly BSD)

It's never guarded. MAP_ANON is always available.

Solaris

I could only get my hands on OpenSolaris, but considering the header having a copyright date of 1989 (by AT&T), I can't imagine it's any different on Real Solaris (or Oracle Solaris). There are no guards here, either; that's to be expected since they invented the damn thing.

Linux

glibc: I don't understand /usr/include/bits in the slightest. It seems to be always available no matter what options I toss to clang, but it is guarded by.. __USE_MISC? I presume this is some sort of feature macro buried deep in glibc that I don't care about or understand.

musl: It's always available, at least on 1.1.11 which is what I have on my test box.

Android: After searching through their spaghetti of includes to get to the actual file that defines constants, it appears they are all completely unguarded, though that isn't surprising since it is Linux and embedded.

In conclusion

Perhaps it's best to avoid anonymous mmap(2) in applications that you want to actually be portable.

Tuesday, 28 July 2015

Musings: More Python 3 compat, Project Sunrise, InspIRCd modules and Portage

Some good news: as I eix-sync'd this morning, I noticed that dev-python/ndg-httpsclient and dev-python/ipaddress now have Python 3 compatibility. That means two of the packages I had thought had no chance of being upgraded actually have been. As for my own efforts, I have been very busy with work and musl support patches lately, but I have been looking at fixing up the htop package next.

I've found Project Sunrise, a way for me to be able to contribute ebuilds to Gentoo in hopes of someday getting them in the master Portage repository. I'm hoping to add a few Python libraries first, then moving up to packaging SuperGameHerm and PyIRC once they've matured enough to be useable by external users.

While testing PyIRC, I needed to be able to use a few modules that are not a part of InspIRCd's main package. Since Portage didn't allow any way of including them in the installed package, I simply checked out the source code package, ran modulemanager to add the modules, then built only those modules. I copied them to the /usr/lib64/inspircd/modules directory and added them to modules.conf, and voila! Now I can do more IRCv3.2 testing.

Tuesday, 14 July 2015

Foxtoo: Gentoo + musl C library on 100MHz Pentium laptop

I haven't yet finished up writing all the content I want to write about the process needed to get this working, but I do have a little teaser picture to share:

That is a Compaq LTE 5150 with a 100MHz Pentium CPU and 40 MB EDO RAM running Gentoo Linux! The kernel version is 4.2-rc1 (because I'm an incorrigible ricer), it was all built with GCC 4.9.3 and it is using the venerable musl C library instead of glibc. Boot up takes only about 15 seconds off the 5400 RPM laptop IDE disk, and once booted, the minimal kernel I have + bash use only about 3 MB of the 40 MB total.

It may not seem like a very useful thing to have done, but I had a lot of fun building it up, and I've ended up finding and closing various bugs in everything from procps to the kernel itself. So I feel that not only has this been a fun personal project across two weekends, but it has been productive for the entire community :)

Sunday, 5 July 2015

Python 2 -> 3 upgrade: status update

This is a small update on my bringing packages in Gentoo to Python 3.

I haven't had time to contribute as much to this effort as I had hoped, but I have successfully finished with two packages and the patches are now in the hands of upstream maintainers. I've been toying with the musl C library as an alternative to glibc (and I'll be posting about my experiences with that later), which has distracted me a bit from Python 3 work.

app-misc/ca-certificates
Required a bit of effort. Debian #789753 filed. Maintainer seems happy enough with it, but it's not in master yet.
dev-libs/evdev
This was simple enough; libevdev has had upstream support for Python 3 since 2013. Gentoo #553110 filed with a patch to update the ebuild accordingly. No response as of post time.