Unlimited Vacation
I usually don’t spend much time on LinkedIn, but I signed in to check on something, and noticed a post near the top of my feed that illustrated a misconception that bothered me. The CEO of a startup posted saying that he didn’t like the concept of “unlimited vacation”1 because (he believes) what ends up happening is that high performers suffer because they don’t take enough vacation, and under-performers get away with taking a ton of vacation.
Another poster commented that they didn’t like these types of policies because they’re just a way of allowing companies to get around state requirements to carry unused vacation days as a liability, and pay out those days when an employee leaves. (This is true, at least in California.)
I reject all of these problems and submit that an unlimited vacation policy – assuming employees actually do have the latitude to make use of it generously – is a net good for employees. As long as you create a healthy culture around it.
First up, the financial argument: frankly, I don’t care if it makes it easier for the companies financials or not. If an unlimited vacation policy does make it easier, that’s great for the company, but whether or not the policy (and its implementation) is actually good for employees is unrelated to that.
Under-performers: if they’re taking a lot of vacation and are not performing well, this is a failure of management. Why is the employee’s manager approving so much vacation when there is a performance problem? Why is this employee not on a PIP, or, failing that, why has the employee not been fired?
High performers: this is a bit more tricky, because you don’t want to demoralize or send mixed or confusing messages to high performers. One option is to enforce a minimum vacation policy on top of the unlimited maximum. Enforcement can range from simply deactivating an employee’s work accounts for a period of time to get them to take time off, all the way up to penalizing them at review time (lower raise or equity grant, delayed promotion, etc.). Better would be to simply promote a culture of healthy time-off practices. Employees will implicitly look to their managers for cues on what they should be doing in these instances, and if they see their manager taking a generous (but not abusive!) amount of time off, they’ll tend to do the same. This needs to be done at every level: the CEO needs to take sufficient vacations just as much as the rest of management and the individual contributors do.
At this point in my life, I would think of an accrued/fixed vacation plan as a big negative if I were considering an offer from a new company.
vacation refers to a policy where employees do not accrue vacation days based on time worked, or have any other kind of fixed number of vacation days (though the company often will close down for some number of public holidays). Employees are expected to take as much vacation as they’d like, with their manager’s approval.
-
For those of you perhaps not familiar with the concept, unlimited ↩
Relaunch
I finally decided to redo my website, and ditch WordPress in favor of a static site generator (I decided to use Jekyll). I also took the opportunity to simplify the design.
There’s a bit more to do, and likely some broken links here and there (not to mention some broken WP-to-markdown conversion), but it’s time I finally got this done.
In theory, I’ll start blogging again as well, but… we’ll see.
Relaunch
I finally decided to redo my website, and ditch WordPress in favor of a static site generator (I decided to use Jekyll). I also took the opportunity to simplify the design.
There's a bit more to do, and likely some broken links here and there (not to mention some broken WP-to-markdown conversion), but it's time I finally got this done.
In theory, I'll start blogging again as well, but... we'll see.
Google TV and Native Libraries
The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I'm about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.
Phone-and-tablet Android doesn't look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It's fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.
From some simple investigation, I've learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn't get Chrome running against the Honeycomb version of Bionic.
Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is... sorta.
With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I 'adb pull'-ed the contents of /system/lib from my GTV and merged them with the new toolchain's sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you'd find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.
I didn't get to modifying the NDK's build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple "hello world" type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)
One annoying thing is that the ABI string in the Sony GTV is set to "none", so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.
There's also the possibility that Google doesn't want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works... in which case we're at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money's on this scenario, unfortunately.
One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV's filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC's APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so's dependencies as static libs, and then just make one big static library.
But I haven't had time to work on this over the past couple weeks...
Google TV and Native Libraries
The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I’m about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.
Phone-and-tablet Android doesn’t look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It’s fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.
Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is… sorta.
From some simple investigation, I’ve learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn’t get Chrome running against the Honeycomb version of Bionic.
With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I ‘adb pull’-ed the contents of /system/lib from my GTV and merged them with the new toolchain’s sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you’d find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.
I didn’t get to modifying the NDK’s build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple “hello world” type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)
One annoying thing is that the ABI string in the Sony GTV is set to “none”, so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.
There’s also the possibility that Google doesn’t want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works… in which case we’re at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money’s on this scenario, unfortunately.
One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV’s filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC’s APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so’s dependencies as static libs, and then just make one big static library.
But I haven’t had time to work on this over the past couple weeks…
Google TV and Native Libraries
The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I’m about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.
Phone-and-tablet Android doesn’t look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It’s fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.
From some simple investigation, I’ve learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn’t get Chrome running against the Honeycomb version of Bionic.
Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is… sorta.
With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I ‘adb pull’-ed the contents of /system/lib from my GTV and merged them with the new toolchain’s sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you’d find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.
I didn’t get to modifying the NDK’s build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple “hello world” type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)
One annoying thing is that the ABI string in the Sony GTV is set to “none”, so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.
There’s also the possibility that Google doesn’t want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works… in which case we’re at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money’s on this scenario, unfortunately.
One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV’s filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC’s APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so’s dependencies as static libs, and then just make one big static library.
But I haven’t had time to work on this over the past couple weeks…
Techie TODO
In no particular order.
Start blogging again.
Suck less at Javascript, even if it's a shitty language.
Learn jQuery, even if it's just a library to make a shitty language less shitty.
Learn Rails properly.
Get back into open source dev.
Find a project/idea I can potentially monetize, and build and launch it.
Throw out my website entirely and start from scratch.
Stop running MacOSX all the time on my laptop and get back to using Linux as my primary desktop OS.
Techie TODO
In no particular order.
- Start blogging again.
- Suck less at Javascript, even if it’s a shitty language.
- Learn jQuery, even if it’s just a library to make a shitty language less shitty.
- Learn Rails properly.
- Get back into open source dev.
- Find a project/idea I can potentially monetize, and build and launch it.
- Throw out my website entirely and start from scratch.
- Stop running MacOSX all the time on my laptop and get back to using Linux as my primary desktop OS.
Techie TODO
In no particular order.
-
Start blogging again.
-
Suck less at Javascript, even if it’s a shitty language.
-
Learn jQuery, even if it’s just a library to make a shitty language less shitty.
-
Learn Rails properly.
-
Get back into open source dev.
-
Find a project/idea I can potentially monetize, and build and launch it.
-
Throw out my website entirely and start from scratch.
-
Stop running MacOSX all the time on my laptop and get back to using Linux as my primary desktop OS.
How To Save Artwork from Weavesilk.com
I just discovered weavesilk.com, which I think is pretty cool. However, it looks like they don't give you a way to save your generated artwork. If you're running Google Chrome (or, as I am, Chromium), there's a trick you can use to save what you've created. This can probably be done with Firefox using Firebug, and maybe in some other ways, but here's how I do it with Chromium.
Create your artwork by dragging around.
Right-click somewhere on the page and select "Inspect Element."
In the new browser pane that comes up, click to the "Console" tab and enter the following:
canvas = document.getElementById('render') img = document.createElement('img') img.src = canvas.toDataURL()The browser will probably freeze for a few seconds (or more than a few), and your CPU usage will shoot up. Be patient.
Click to the "Resources" tab in the developer pane, and look in the list for something that starts with "data:image/png". Click it, and you should see your artwork to the right, on a transparent checkerboard background.
Right-click the image and select "Save Image As."
The image will save with a transparent background, but you can open it up in an image editor and add a solid background color if you like.