I’m finally getting the filesystem support on my Android pixel devices sorted out. I’ve had Samsung tablets and phones previously (until the Note 7 debacle) and they fully support exFAT. Given this is the default for almost everything larger than about 4GB that has been very useful.
When I got my two current Pixel branded devices I thought that my SD card readers were failing. It is not clear that the issue is a lack of exFAT support. Particularly curious as I appear to be able to read NTFS formatted SD cards in read-only mode.
I’m now at s point where things are workable but still rather annoying. Cards that I’ll use with my pixels are either small, crippled and FAT32 formatted (read/write) or NTFS and read-only. Cards I’ll use with my old Samsung tablet are exFAT formatted and won’t work with any of the pixel devices.
I suspect that if I rooted the tablets I could probably find a way to add exFAT filesystem support but I’d rather not make changes at that level. Really wishing that google had paid the extra bit to license exFAT for its flagship devices.
In Debian Linux recently the CryptKeeper encryption package fails to properly set passwords due to a bug fix in the command line handling of a package it runs (see this Register article for more details) .
It appears that the code was tested and worked perfectly in previous versions. The tool being used had a minor bug in its command line processing that resulted in the password being accepted even though it was placed improperly. Once the maintainers of this package fixed their big, the string sent by the CryptKeeper package resulted in the letter ‘p’ being taken as the password and the actual password being ignored and it would appear discarded.
It seems to me that Linux could use a universal (or nearly) –API switch that converts the command line and stdin/stdout/stderr to something like JSON with extensive and aggressive checking for validity in all inputs along with tightly specified outputs.
Most programmatic usage of command line tools that I’ve encountered to date makes broad assumptions about the details of the input and output formats for human usable tools. In most cases I’ve seen the checks for unexpected data are weak and porous. This generally results in tools that are fragile and often either need manual tweaking or are simply tied to a specific version of a particular distro. The alternative (less common but I’ve encountered it as well) is to force tools whose primary interaction is with humans on the command line to lock down the original output formats in ways that don’t necessarily work well for people in order to avoid breaking programs and scripts.
I’ve been digging through node.js code more over the last few weeks. Coming up to speed on JavaScript idioms and best practices (and a few things that feel like worst practices) . Looking at IDE options to streamline things as node has less structure to it than the languages I’m used to and emacs doesn’t help much on that front.
- Visual Studio 2015 has some node support but at first look it doesn’t seem to do the sorts of things for JavaScript that it does for C# or C++. It is also terribly slow.
- There are eclipse based options that I’ve seen. I’ve downloaded a copy of one option (Nodeclipse) but haven’t tried playing with it much yet.
- Folks at work use Sublime Text and seem moderately happy with it…not sure that it provides too much more than emacs does though.
- There’s another free editor that came up called Cloud9 that I’ll probably take a look at. Actually, now that I see their terms, nope…it would have to be something radically wonderful for $20 a month for personal use.
- WebStorm looks potentially interesting. It seems to get good reviews. It is a paid product but for personal use might be workable and if it looked sufficiently valuable might be worth swinging a license for it at work.
Much more to learn here…got to dig out my copy of Effective JavaScript when I get home and read through it again…I suspect that I’ll take away more from this reading now that I’ve been struggling with the stuff for a while.
I’ve been doing more reading on node.js, mongodb and related stuff (a bit of angular 2 in there as well). I got notification that my M3D Pro printer will be delayed by about two months. Work is keeping me busy as well.
On the 3D printer front I need to make a decision soon. I can defer delivery till summer and get a final production model or I can take delivery in my defined time slot and get the early production item that I ordered. I’m a bit torn as currently things are busy enough that I might very well get the thing on time and wind up leaving it on the bench in the basement until summer anyway. On the flip side, I’d like to find the time to get things started.
I do think that mongodb will likely work better for my needs than MySQL. The stuff I’m looking at doesn’t need the hard guarantees that MySQL provides and the flexibility of mongo would be nice. More reading to do. Need to get coding a bit soon as well.
Engineering execution and creativity mixed for the best results…
