I keep hoping that a technical solution to the unaccountability of
current voting technology is right around the corner. Unfortunately,
each time I think we are moving in the right direction, I see more
politics added. So, although Linux Journal is
a technical magazine, I think we need to look at the politics
of the situation and figure out how to get from politics to technology.
The problem is current voting machine technology is flawed, but
we, the public, don't get to see those flaws. Beyond that, your
elected officials seem to be doing their best to cover up for those
selling flawed systems. Rather than write about the examples, take a
The site contains a lot of history on this topic, and it continues to
add more and more information every day.
The basic situation is a company makes a voting machine and
sells it. (Diebold is the example you read about most often, but
it is not the only company involved.) System designs are proprietary,
so there is little review of how they work. Beyond that, some federal
standards are in place, but there are clear examples of them being
ignored. For example, although federal standards say the program
running in the machines cannot be interpreted--that is, interpret-ly
executed rather than compiled--there are "approved" systems that
don't meet this standard.
Now, there are many reasons we could assume that these systems are
installed and continue to be used. These reasons include:
- Kickbacks by the vendors to government
- Government employees not wanting to admit they made
a bad decision
- Election corruption in which the intent is to modify
Additional reasons are likely. The reason, however, doesn't matter.
What does matter is these closed systems have been proven to be flawed.
The victim is the voter.
The technical question is "Why would an open-source system be
better?" This is a common question, and it clearly is not limited to
voting systems. The answer is simple: you (for any value of you) can
see how it works. This means that errors in the system--design
errors, software bugs and other vulnerabilities--can be located. If
they can be located, they can be fixed.
I don't know about you, but I would prefer to have 20 software geeks
rather than 20 politicians looking for flaws in the system that is going
to count votes in the next election. But, today, you have companies
with vested interests in not exposing flaws in their products and
politicians deciding what "you" want.
My writing of this editorial was inspired by what sounded like an effort to
get an open-source solution in place. I read an article about
the Open Voting Consortium and went to the
page with great hopes. Unfortunately, after a few minutes of
reading, I saw more politics.
The most prominent information on the site is the group's request for
contributions totaling $1.5 million to "take back our election system".
The Consortium uses the word "open" over and over on the site, but what
it wants to do with that $1.5 million isn't very clear.
That is, the Consortium says its computer scientists have begun
programming, and it needs the $1.5 million "to fund project completion,
including certification". Now, if someone had offered Linus Torvalds
$1.5 million to write Linux, he probably would have felt it was a
sufficient amount. But, a voting system is pretty damn small compared to
Linux. And I think we can assume it will not be a complete OS and,
most likely, will be built on top of the Linux kernel.
So, back to politics. If I was to start an organization to solve this
issue of unaccountability, here is what it would do:
- Write and publish specifications for the design of an
open-source voting system.
- Open a public comment period on the specifications. The
comment space likely would need both a "political issues" section and a "technical
issues" section. For this effort to succeed, it needs to be
- Refine the specification based on the comments received and
openly publish the final design documents.
- Recruit open-source programmers willing to work on the
- Recruit legislators willing to support the effort. This
hopefully could mean getting some public funding for the project.
- Build the system and make it available for free to
What if some company "steals" the idea and builds a system based on it?
So what? That would be good. As long as all of the software remains
open and free, we have addressed the problem. If, for example,
Diebold wants to sell new machines totally based on this software and
is willing to keep everything open, it is a win for Diebold and a win
for the voters.
In the long run, this "commercialization" is likely to bring money
back to those involved. That is, although the programmers might receive
"stipends" from possible public funding, the long-term benefit for
them could be working for companies that produce these
machines or starting their own companies.
In conclusion, I am saying that if we can replace the politics of the
current voting system scandals with the politics of open source, we
all can benefit. Now, is there someone other than me out there that
wants to start this organization, or did I just create yet another job
Phil Hughes is Group Publisher for SSC Media Corp.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide