Yes, I can see the learning curve is steep, I must be missing something, though, because lowercase letters (26), uppercase letters (26), digits (10), punctuation (26), and "meta" keys like Escape, Tab, Backspace, Delete, and enter (to name a few) exceeds the 32 chorded characters mentioned in TFA.

I've often wondered if Morse Code could be a viable option for data entry on a small screen. Admittedly, there are some punctuation and capitalization issues with this, as well. Yet, it WOULD permit one to text while not requiring one to keep their gaze on the screen.

I suppose one could split the screen in half (e.g. left/right) to distinguish lowercase from uppercase and to allow additional symbols to be defined. I doubt I'm the first to think of this, but I've not seen anything like this being available, I thought I'd toss it out for consideration and discussion.

Thanks so much for the timely (9AM, on a Sunday? WOW!) reply!

Glad to hear the GPL should be fine, and I see you've given thoughts as to how to coordinate code/data contributions. As much as I'd like to see us able to contribute to the effort, I can well understand why a read-only repository may be necessary. People could still e-mail diffs, if they so desired, without opening the possibility of someone checking in a malicious update.

"NH mandates paper ballots"... thanks for the info. I've wondered about the feasibility of a two-step approach. Voter fills out an electronic ballot (which checks for things like over-voting, etc.) and then outputs a printed ballot which the voter then verifies and submits THAT as their ballot. The printed ballot is scanned, read, and retained. This permits manual AND automatic [re]counting. Though it might border on Rube Goldberg, I see some promise in the idea and offer it for your consideration, should the opportunity avail itself.

Again, many thanks for your efforts and may you have continued success!

I am impressed; well done!

I read the bill (gasp!) and saw procedural mechanisms to encourage the adoption of open data and software... not just a "thou shalt", but rather feedback steps to hold people accountable for the decisions they make. Kudos!

I also noticed in one of your replies in this thread that you are a geek and contributed to the kernel. So, I would appreciate your thoughts on what kind of open source licenses would be acceptable under this legislation. BSD? GPLv2? GPLv3? MIT? Apache? Obviously, you needed a *specific* definition of "open source software" to work from. Here is the bill's definition of "Open source software":

21-R:10 Definitions. In this subdivision:
I. "Open source software" means software that guarantees the user:
(a) Unrestricted use of the software for any purpose;
(b) Unrestricted access to the respective source code;
(c) Exhaustive inspection of the working mechanisms of the software;
(d) Use of the internal mechanisms and arbitrary portions of the software, to adapt them to the needs of the user;
(e) Freedom to make and distribute copies of the software; and
(f) Modification of the software and freedom to distribute modifications of the new resulting software, under the same license as the original software.

It seems to me that there would be no problem using BSD-licensed software. The wording is quite nuanced, though, and a careful reading suggests it was intended to also allow GPL software.

1. At some point, someone will propose using a GPL v2 application . Will that be permitted?
2. At some point, someone will propose using a GPL v3 application . Will that be permitted?
3. Can the state make changes available between departments without being obliged to make the software available to the public?
4. If the state uses GPL code to enhance in-house code, and distributes it to one or more users and/or departments, must it make it publicly available, too?
5. If so, where and how it such access expected to be made available? (e.g. public GIT repository?)

Okay, one more question: Electronic Voting Machines -- What impact do you see this law having on their design and selection?

Thank-you for your efforts to get this law passed; I look forward to your responses!

Sorry that I don't know the author, but I've found much wisdom in those few words. Perhaps it explains why puns and double entendre(sp?) are so popular?

The first top 500 list was published in June 1993. The fastest computer on that list was a CM-5/1024 made by Thinking Machines Corporation. It was rated at: 59.70 Rmax(GFs) and 131.00 Rpeak(GFs).

Last place on that first top 500 list (scroll down) was held by a VP-200 made by Fujitsu/SNI which had 1 core and was rated at 0.422 Rmax(GFs) and 0.533 Rpeak(GFs).

I've heard the expression about carrying a supercomputer in your pocket - how close are we? I'd expect most of the latest Android/iPhone/smartphones can beat that last-place finisher from 1993. I'm doubtful that any of these devices could beat that first place finisher, but I suspect desktops (especially with GPUs) should be there by now. If you're are interested, you can get the software from here.

Any takers? How does YOUR system compare?

Time keeping is getting better and better. I just happened upon this article recently which gives some history on timekeeping and what some of the latest efforts are working on: http://www.sciencenews.org/view/feature/id/334983/title/The_Ultimate_Clock.

Here's an excerpt (emphasis added):

The metrology of time is not holding still. In the April-June issue of Reviews of Modern Physics, experimental physicist Hidetoshi Katori of the University of Tokyo and theorist Andrei Derevianko of the University of Nevada, Reno declared dramatic ambitions for a record-breaking atomic clock based on emissions from mercury atoms.

âoeIf someone built such a clock at the Big Bang and if such a timepiece survived the 14 billion years, then the clock would be off by no more than a mere second,â they note in the paper. That is actually conservative. The goal formally is to lose or gain no more than one out of every billion billion seconds. That is one second in about 32 billion years, and is 10 to 100 times better than any existing clocks.

Algorithms + Data Structures = Programs by Niklaus Wirth

I read this book back in the late 1970's. (I was still in High School where we had time-shared access to a PDP/11-70 running RSTS/E. Programming was in Basic-Plus. To put this in perspective, this was the same time frame as the TRS-80, TI 99/4A, and Commodore PET!) Our SysOp at SPHS saw my voracious appetite for all things computing and STRONGLY encouraged me to get and read this book. (Thanks Mike!) But enough with the background!

This book made an indelible impression on me. It introduced different approaches to tackle problems (algorithms) and different ways of organizing the information I had available (data structures). But, most importantly, it encouraged me to iterate between the Data and the Code to find a reasonably optimal synthesis of the two.

Prior to this, my experience with data structures had been limited to "scalars" (integers, floating point, and some character strings) and multi-dimensional arrays. It was a real eye-opener to be exposed to structured records as well as linked lists and trees!

Similarly, my coding experience was limited to combinations of the usual control structures of sequences, conditional statements, looping, and subroutines/functions. Did I ever struggle trying to understand recursion!

Then, toss in a generous helping of structured programming and step-wise refinement. This single work completely transformed my perspective on programming, its challenges, and its promises... I was hooked for good!

Amazon Link. Prentice-Hall 1975; ISBN 0-13-022418-9; 366 pages, 102 figures.

I later had the good fortune to read a number of the other books recommended here, K&R, TAOCP, Mythical Man Month, and I'd highly recommend those, as well. Nevertheless, I read Wirth's A+DS=P first, and it's made a world of difference in my life.

What is needed just as much as a spell checker is a grammar checker.

Yes! I occasionally need to proofread OCR'd text that has been generated into an HTML file. I've written some code that extracts the text and flags misspellings. That catches a lot of things for me. But, it still misses many errors that a grammar checker *would* find.

Back in the late 80's or early 90's, I purchased an add-on for Microsoft Word 5.0 called something like Grammatik IV. It did a wonderful job of finding and flagging possible errors for review. Now this is back in the days of DOS! Basic operation was to load a file into Word, activate the grammar checker, and it would step you through each possible error, giving you an opportunity to accept the recommended change, ignore the error, or let you make an ad hoc correction. Then it would step on to the next error.

my google-fu must be slipping as I've been unable to find anything comparable. I thought LibreOffice might help, as it has a grammar checker, but it only seems to be available whe entering new text. Can't seem to find a way to tell it to just start checking from the current point, and proceed onward.

What grammar checking tools have you found useful? (Currently using an old Win/XP SP3 system.)

P.S. Typed on my mobile phone, so I apologize in advance for any typos.