Seven months ago, I wrote a post about buying an HP Slate 7 and returning it right away. I didn't really use the tablet heavily before returning it because it wouldn't charge on my standard USB charger. That was enough to declare the tablet "crap". It seems that other people have reached the same conclusion as me. A little more background first.
My company logs the device model for everyone that logs on. This gives us the ability to generate statistics on what devices are being used. We wanted to gather the data based on our clients, not based on the number of registered phones or whatever metric some other company uses to determine market share. When we gather the device models, we know it pertains to our user base. This data comes in handy for multiple reasons but the one reason that came up today was test hardware purchasing. We buy phones and tablets to test our software on and we want to buy the hardware that is most common among our user base.
When generating this report, I noticed something weird. There was a device model called "cm_tenderloin". I was something I had seen before because one of our clients with an issue had this device. "cm_tenderloin" is the Cyanogenmod device name for the HP Touchpad. The HP Touchpad that doesn't run Android....it runs WebOS. On its own, this is not weird. People install after market firmware on lots of devices. It wouldn't be weird to see "some" hits with this device name. The weird thing was the "cm_tenderloin" device name showed almost 5 times (about 4.8x for the month and a half window) more logons than the HP Slate 7!
This tells a rather interesting story. It seems that people would rather buy an old HP Touchpad and install Cyanogenmod on it than buy an HP Slate 7. It seems the Cyanogenmod install process must be easier than the HP Slate 7 install process (which was difficult for me, given the charger issues). This is even more incredible because Amazon (as of 2/21/2014) lists the HP Slate 7 at $200 vs $270 for the HP Touchpad (16GB models for both). I know a big difference is size. The HP Slate 7 is a 7in screen while the HP Touchpad is a 10in screen. Our clients still feel the Touchpad is the better buy.
Friday, February 21, 2014
Monday, February 10, 2014
Stealing Syntax Trees
I had to write a parser for a language. I decided to break out my Programming Language Concepts text book from my 3rd year of college. In that class we learned not only how to compare and contrast programming languages, but we learned how to write parsers for those languages. Since this is a direct application of the course material, I brought my text book to work. I gave myself a refreshing on the theory behind parsers.
With this refreshed knowledge, I started with writing down the Backus-Naur Form of the language. I created a Lexical Analyzer for the language based on a Finite State Machine that returns Token classes that I created. I created classes for an Abstract Syntax Tree that represent the expressions in the BNF. I created a parser that converts the token stream from the Lexical Analyzer into the Abstract Syntax Tree.
So far, everything I did to write this parser was quite literally text book. I created a text book parser. Imagine my surprise when someone accused me of stealing the code!
For starters, the developer couldn't believe I would be able to write a full featured parser for the language so fast. It was just not imaginable. Second, he didn't know what an Abstract Syntax Tree was. You see, I used a naming convention for my tree classes. I prefixed all of them with AST for Abstract Syntax Tree. Since this developer had never heard of an AST before, he did a quick google search for ASTExpression (one of the classes that I wrote). He saw some open source projects that used the same class name. He immediately assumed that I must have stolen the open source code. Nevermind the fact that the contents of the classes were different. It would be impossible for two developers to use the same class name! Therefore, I am a thief!
For me, my code was an example of software engineering done right. I used documented practices that multiple software engineers use. These standard practices mean people who are familiar with the standard practices can support my code. Unfortunately, the legacy of this code is an accusation theft.
With this refreshed knowledge, I started with writing down the Backus-Naur Form of the language. I created a Lexical Analyzer for the language based on a Finite State Machine that returns Token classes that I created. I created classes for an Abstract Syntax Tree that represent the expressions in the BNF. I created a parser that converts the token stream from the Lexical Analyzer into the Abstract Syntax Tree.
So far, everything I did to write this parser was quite literally text book. I created a text book parser. Imagine my surprise when someone accused me of stealing the code!
For starters, the developer couldn't believe I would be able to write a full featured parser for the language so fast. It was just not imaginable. Second, he didn't know what an Abstract Syntax Tree was. You see, I used a naming convention for my tree classes. I prefixed all of them with AST for Abstract Syntax Tree. Since this developer had never heard of an AST before, he did a quick google search for ASTExpression (one of the classes that I wrote). He saw some open source projects that used the same class name. He immediately assumed that I must have stolen the open source code. Nevermind the fact that the contents of the classes were different. It would be impossible for two developers to use the same class name! Therefore, I am a thief!
For me, my code was an example of software engineering done right. I used documented practices that multiple software engineers use. These standard practices mean people who are familiar with the standard practices can support my code. Unfortunately, the legacy of this code is an accusation theft.
Friday, February 7, 2014
Time to replace the hard disks
One of my hard disks is starting to have issues. I know this because I use ZFS. I run a weekly scrub and email myself the results. Every once in a while I see read failures coming from the USB hard disk. Recently, I started seeing checksum errors, however. If I were running a standard RAID 5, I would be suffering from "bit rot".
Jim Salter over at Ars Technica has a great article about bit rot and ZFS. At a high level, bit rot is when you attempt to write a 1 to a hard disk but the hard disk actually stores a 0. It could be a single occurrence, or it could be a sign of a dying hard disk. In my case, it might be a bad cable or enclosure. I have needed a new hard disk enclosure for a while, so I decided to buy a new enclosure and a new hard disk. I am going with a 4tb hard disk since I need more disk space.
What is important is I didn't lose any data for two reasons: ZFS (RAID-Z) checksums that data to identify where the bit-rot took place and ZFS tells me about a faulty hardware before it becomes a catastrophe.
Jim Salter over at Ars Technica has a great article about bit rot and ZFS. At a high level, bit rot is when you attempt to write a 1 to a hard disk but the hard disk actually stores a 0. It could be a single occurrence, or it could be a sign of a dying hard disk. In my case, it might be a bad cable or enclosure. I have needed a new hard disk enclosure for a while, so I decided to buy a new enclosure and a new hard disk. I am going with a 4tb hard disk since I need more disk space.
What is important is I didn't lose any data for two reasons: ZFS (RAID-Z) checksums that data to identify where the bit-rot took place and ZFS tells me about a faulty hardware before it becomes a catastrophe.
Monday, February 3, 2014
Examples of Progress
Mainframes started using 64bit processors in 1961. SGI Irix graphic workstations started using 64bit processies in 1991. The Nintendo 64 launched in 1996 with a 64bit processor. AMD releases a 64bit processor for servers and desktops. When Apple launched the iPhone 5S with a 64bit processor in 2013, that is progress, not innovation. There was no leap of the imagination that phones would eventually get 64bit processors. The question was when it would happen. With most technologies, you can't release it too early or too late. You have to time the release correctly. Eventually, all phones will run 64bit processors. Likewise, having the first 64bit watch or microwave is not innovation.
Once mini-computer technology took off with the launch of various ARM devices, it is not innovation to stick an ARM processor in anything that you can conceive of. Now that you have tiny and cheap SoC systems, people want "smart" everything. Someone is going to make a smart watch. Someone else is going to make a smart picture frame. Someone else is going to make a smart camera. Someone is going to make smart thermostats and smart smoke detectors. SoCs will be everywhere. It is not innovation every time someone puts an SoC into something that didn't have an SoC before. That is progress. The innovation is the design of the first SoC that started to be used with smartphones like BlackBerry (did you think I was going to say the iPhone?)
A pattern should emerge in these examples. Having an idea, like SoC, is an innovation. Different arrangements and designs of the SoCs are innovation. Slapping an SoC in every inanimate object you can find is not an innovation; it is progress. Designing a unique user interface for the SoC is innovation. Innovation is the seed of progress. Once someone comes out with a great innovation, that spurs off progress to make that initial innovation better. Both the innovation and the progress are important. Someone needs to make progress. It just doesn't take as much effort and research to make progress. Progress should not be patentable and you shouldn't be sued for making progress. That is one of the major problems with the US Patent system.
Once mini-computer technology took off with the launch of various ARM devices, it is not innovation to stick an ARM processor in anything that you can conceive of. Now that you have tiny and cheap SoC systems, people want "smart" everything. Someone is going to make a smart watch. Someone else is going to make a smart picture frame. Someone else is going to make a smart camera. Someone is going to make smart thermostats and smart smoke detectors. SoCs will be everywhere. It is not innovation every time someone puts an SoC into something that didn't have an SoC before. That is progress. The innovation is the design of the first SoC that started to be used with smartphones like BlackBerry (did you think I was going to say the iPhone?)
A pattern should emerge in these examples. Having an idea, like SoC, is an innovation. Different arrangements and designs of the SoCs are innovation. Slapping an SoC in every inanimate object you can find is not an innovation; it is progress. Designing a unique user interface for the SoC is innovation. Innovation is the seed of progress. Once someone comes out with a great innovation, that spurs off progress to make that initial innovation better. Both the innovation and the progress are important. Someone needs to make progress. It just doesn't take as much effort and research to make progress. Progress should not be patentable and you shouldn't be sued for making progress. That is one of the major problems with the US Patent system.
Subscribe to:
Posts (Atom)