If you ever have the misfortune of managing e-mail servers, please do not ever attempt to use the SORBS RBL. Its false positive rate is amazingly high, and its support is downright terrible when your mailman mailing list (you know, an opt-in mailing list) is flagged.
I’ve loaded a part of my back-catalog of software to github. Included into the transfer is:
Note that this software is from the 2004 vintage, which reflects a previous era (before Git, before the end of college, etc). It was languishing on the StackFoundry website prior to its overhaul; I also couldn’t simply throw it away.
Also loaded onto github are slightly newer projects, such as:
Most of the previous pages at StackFoundry now redirect to the appropriate github page.
Enjoy!
Just a quick update for those browsing our source code – we are slowly decommissioning the local git code hosting (at git.stackfoundry.org) and moving either to Github or Gitorious.
Currently moved:
When you think of user documentation authoring systems, a couple of traditional tools often come to mind: FrameMaker, Microsoft Word, InDesign, RoboHelp, LyX, TeX files, MadCap Flare. Some are fully proprietary, while others embrace some standards. Some are semantic, while others are design driven.
With the evolving output formats that are present today (and tomorrow, for the future predictors), there is honestly no excuse to have your primary authoring environment be non-semantic. For the uninformed, semantic implies meaning – instead of making text large, you mark it as a section, or instead of indenting and changing the color of text, you denote that the text is a call-out or note.
Many editors, even our friend who can’t typeset Microsoft Word (thats another topic), have semantic capability integrated. You define headers, sub-sections, footnotes, and more. Systems such as FrameMaker and LyX are heavily geared for this workflow – they in fact make it a relative pain to not follow their conventions. Systems such as RoboHelp attempt to be semantic, but are so steeped in legacy that they become unusable: RoboHelp still depends on VBA macros and Word to generate PDFs – this is an Adobe product by the way.
What about semantic file formats which are designed for direct editing – preferably human readable or approachable? There are really two main contenders in my eye, and one of them you may not be considering: DocBook and Sphinx wih reStructuredText.
First there is DocBook. Its a standard. It was formally SGML and now XML. There are tools, XSLT transforms, and the like to output a variety of formats, include LaTeX typeset documents, webpages, and Windows Help files. However, its incredibly unfriendly for human editing. No one likes hand-writing XML – its simply not natural, even as much as HTML has established its self. DocBook is also an ecosystem – there are tools, but they all have different ideas of what they should do, and interoperability is not guaranteed.
What if you could fix the human problem and provide a better semantic system, one with a kick-ass implementation (and not an ecosystem)? Thats what Sphinx does. It is DocBook for humans. You may know Sphinx as a Python API documentation system. It is, and it excels at that job like none other. However, Sphinx is both extendable, and composable – if you never ask for API documentation, it will never give you any. It also typesets using LaTeX, spits out theme-able and gorgeous webpages, and even makes Windows Help files. And if your document has special needs, its very easy to extend to produce end user documentation.
The real question is how well suited Sphinx actually is for writing non-developer user manuals. How easily can you get a technical writer versed in reStructuredText? How easy is it to actually change the look and feel of a document? From my initial investigation, I see few issues. However, the only way to actually know is to drink the Kool-Aid. My test will be to create an end-user manual, involve non-coder friends, and identify strengths and weaknesses.
I feel that Sphinx is everything DocBook promised, delivered.
In iOS, there is no way to slug a background image into a UIView – making it slightly trickier to “linenfy” your new iOS application background (and who doesn’t like the new iOS 5 linen?).
However, you can apply a UIColor. Did you know UIColor can be a pattern? And the pattern can be defined by a UIImage?
Well, it can, and here is a one-liner to do so:
1 | self.view.backgroundColor = [[UIColor alloc] initWithPatternImage:[UIImage imageNamed:@"bgs/fileinbundle.png"]]; |
(This code depends on ARC in XCode 4.2 – apply reference counting as appropriate for other versions)
Please note that you have to set all the items which are in front of the background view to clearColor such that they will not cover the background image.
DigiChrome – DigiKey Enhancements now has version 0.2 available through the Chrome Extensions Gallery. The extension will auto-update, but you must re-enable it when prompted for it to function. The permissions have changed in order to allow some new features to work.
New in this version:
DigiChrome is Open Source, and available as source from http://gitorious.org/digichrome.
Ever got frustrated with DigiKey.com‘s interface, specifically the “In Stock” checkbox and the limited size of the search selector boxes? Are you using Google Chrome?
Then get my Chrome DigiKey Enhancements extension now!
The current version:
The extension has an options pages (under the Tools->Extension page, click “Options” under DigiKey Enhancements) which allows you to pick which modifications the extension performs.
Untested: International DigiKey pages, full ordering workflow.
More features coming soon!
A new version of Contribtastic, the 100% open source cache reading uploader, is now available. If you’ve been hit with the data.pickle corruption bug from previous versions, this is an essential upgrade.
Next release may actually add the CSV export option along with re-implementing login functionality. Contributions welcome!
I had the privilege of attending the Embedded Linux Conference in San Francisco this year. All in all it was a great experience, especially the networking opportunities with other developers working on core functionality. Personally, I found the following presentations and technologies the most memorable:
This is hardly a complete list of the talks I went to, and only reflects some of the most interesting and relevant areas to me (sorry, I don’t do much RT or media). To those not mentioned, I still enjoyed hearing you speak!
And yes, I do have a shiny new free Nexus One thanks to Chris DiBona and all of Google. You still should work on mainlining your code though
I thought I’d do a small interlude into the embedded hardware and firmware space (which is generally my main area of work) from the normal EVE-Central heavy side of this blog. I have been musing about the code security protections of the MSP430 micro-controller, specifically the Boot Strap Loader (BSL), which remains enabled at all times, even if the JTAG interface is disabled (via a fuse on most MSP430s).
The BSL disallows memory reads and writes until a “password” has been transmitted over the serial interface. The password is actually a copy of the interrupt vectors (32bytes) used by the micro-controller, which limits the entropy available by a significant margin: addresses are all even aligned, reset vector is generally start of flash, many interrupt vectors will be identical, general case has all interrupt vectors located in flash. The only defense against this low-entropy brute force attack is the rate limit of the BSL: some versions of the BSL prevent you from changing from 9600 baud until after the password has been verified. However, on devices with small amounts of flash (say, 8Kib), there are only about 61,000 passwords generally in use, which reduces the search time tremendously.
Some BSL versions are also susceptible to side channel attacks are discussed in this paper:
Practical Attacks against the MSP430 BSL
Texas Instruments has improved code security on the new F5xxx series devices in a drastic way: an invalid password will cause a complete device erase. Note that the flash memory also differs from the previous generation devices by being rated to erase and program as low as 1.8V (where the core voltage normally sits – the 5 series has an integrated LDO).
I can see two possible attack vectors – undervoltage to the entire processor (I have a ’5438A running as low as 1.5V, however the BSL is not yet tested down here), or “glitching” the processor (in this case, complete power down) if the start bit of the acknowledgement packet is not transmitted within an allowable window. The second scenario can be defended against in the BSL firmware (delay the acknowledge by a large value).
I have not tried either of these attacks on the 5xxx series yet (specifically, the 5438 and 5438A). Generally, there are easier ways to attack processors to capture embedded code, or simply replicate external functionality based on observed behavior (code security is not on most programmers’ minds). If small-memory variants of the 5xxx series become available (to allow the brute-force searching of the keyspace), the flash memory erase issue would have to be overcome.
In the mean time, you can use some chip disassembly techniques from Flylogic.
On another note, I will be announcing a security related, open source hardware project shortly. Its been keeping me distracted from EVE-Central (trade route tool version 2, specifically), Contribtastic, and working on the EVE-Metrics/EVE-Central unified uploader.
Powered by WordPress