The fact that the company is using legal threats to suppress investigation into the errors is a good argument for using open source equipment that anyone can inspect. I do NOT trust a proprietary solution. Open voting consortium needs volunteers and money. Unlike a normal open source project where all that matters is the quality of the code. This one needs feet on the ground and money to travel in order to get laws changed in 50 states to allow the use of the equipment. (for example many states have laws about how ballots are defined that this protocol requires changing. Many states require certifications which are far from free. But mainly it takes demonstrations and lobbying.)
Right now they have a matching grant challenge, so nows a good time to offer cash. But think about also being an advocate in your state for getting the laws to allow this system.
OVC not only has open code but it also has an open bussiness model. They won't require you use it on any hardware they offer. It runs fine on off the shelf equipment. Any company could use the code, states could use the code. OVC would simply maintain it and certify that it is being deployed correctly.
Open voting solutions is another open source project with a different bussiness model but open code.
what makes no sense to me is why the jury was not told that her paramour has confessed to killing 8 people. Given two suspects, both whom are intimate with the deceased and one is a mass murderer, would this not sort of raise a reasonable doubt about the other? Given the the murders were also inspired by domestic issues (i.e. not robbery, etc...) surely this is even more relevant. Given the murder knew the defendant very well (best friend) and presumably would know how to get to his house and car. Know his habits. etc... Why was this not presented?
Given the evidence against resiser it seems pretty damning for him in the absence of a plausible alternative. But there was a very plausible one.
The article notes that it comes with Leopard installed but that YOU CANNOT REINSTALL it yourself from a leopard CD (Which comes with it). (and you presumably cannot install Lion or whatever the next OS is) So if You want to run mac OS then you have to pay them to install Mac OS of $150. it also lacks firewire, blue tooth, and wifi. They will add Firewire for $50. Shipping is another $50 (macs ship free).
so the total price is $609 without wifi or blue tooth. compared to $599 for the mac. The cpu is a bit faster, the disk is bigger and faster.
You can buy the mac at macmall where they will upgrade your memory and and give you a "free" printer for the same price (provided you can stomach the "rebate" spanking machine).
so basically a mac is cheaper, smaller and quieter. Not to mention the mac comes with software updates and you can re-install the software.
----
the psystar's big brother, actually is cost competitive with the powermac however.
No, I think the correct answer is "Why are you asking the question?" There might be a more interesting (and perhaps answerable) question that underlies it. And how does that make you feel?
I must be imbued with electron-ness, I'm made of electrons so by this logic I must have to connect with my inner electron to manifest my existence.
No, wait, that's all negative. Let me connect with my inner proton, that's a positive outlook. Me thinks that these people who require one to "be the thing you think about" are searching for more than is there. One might say they are "more"-ons.
Why do I have to have a carrier signal to planet math to use math?
That said, I do know that when I'm deep inside a program it is a left brained experience. I'm fully aware of the rest of the programs existence even though my right-brained eyes see but a few lines at a time. I feel it's flow though the coed itself never moves.
To there is a sensory nature to programming that is like being able touch things that are abstractions.
I recall the great "aha!" when I tried to figure out how Woz did the graphics on the Apple and discovered he took advantage of the 6502's symmetric clock cycle to put the screen access to memory on the backside of the cpu access to memory.
this had the side effect of hitting every (lower byte) address every 60th of a second. That in turn solved the great problem of how to refresh dynamic memory without wait states for the cpu. This allowed the apple to avoid using static ram.
this in turn let them have a smaller power supply, one of the first to use a switching power supply that were the new thing in electrical engineering.
As for the cards, woz was clever again. By pre-decoding the address space for the cards on the motherboard he saved having to have circuitry on every card to recognize it's own address. Thus the cards were half the size of the s-100 cards and used less power.
all that was pretty freakin innovative. Not that they invented it but they made it all work.
Oh and look at the python packages scipy and matplotlib, these use numpy and provide zillions of high level libraries and plotting functions. matplot lib has a syntax resembling matlab for plotting. Scipy uses ftpy under the hood so installing scipy will give you both numpy and f2py.
it takes a day to compile scipy and matplot lib so do it overnight.
if you have a mac, they can be found in both fink and macports. fink also is on linux.
final tip: ipython is an IDE that plays nice with matplotlib by running the interactive xwindows in another thread.
if you use ipyhton, look at the "run" command for the best way to run code without polluting your namespace.
Best advice: purchase the numpy users guide. very brief intro to f2py but you also get to learn the data types in python that work with fortran calls.
A program to add to 1-D arrays to each other element by element might look like this:
from numpy import * import f2py f = """ Subroutine foo(a,b,c,N) integer N real a(N),B(N),C(N) cf2py intent(out):: c integer i do i=(1,N) c(i) = a(i)+b(i) enddo return """ f2py.f2py(f,module="bar") import bar
a = arange(5) # dummy array, size 5 b = sin(a) # the sine of this array's elements
c = bar.foo(a,b) # the sum of a and b, executed in fortran
when you run this it compiles the fortran at runtime and creates the python module bar.so that can be imported into any python program (on the same kind of computer). In this example, the fortran is embedded as a string in the python and recomplied every run. One could just run f2py at the command line on the fortran file one time and then just import the module.
flourishes that make fortran more pythonic: f2py is smart enough to figure out that N is just a dummy length argument equal to the array size, and so it will drop it from the required arglist (or you can supply it if you want to as an extra arg).
if you use f90 it will also figure out which variable are purely output variables and move those to the lefthand side. if you use f77 like above you can either leave them on the righthand side or you can add comments to the program that hint to f2py to move it to the left side. (see above code for example)
Thus c = foo(a,b) has no need to specify N, and the output is on the right hand side.
I can if I want to make foo() a method inside of a class. Thus I hold multiple instances of the data structures in python and use them to call the single instance of foo()
The big achilles heel of python is that it currently truly sucks for multi-core programming and it would appear that attempts to solve this are not coming quickly. Jython? Iron Python? These Python implementations don't have the same global interpreter lock issues that CPython has. Those are worthwhile suggestions but not panceas--Cpython continues to dominate for solid reasons: in particular jython has to load the JVM so is slow, may 20 times slower than a python program with a short lifetime (consider CGI or network management). It lags in development, it does not gaurantee certain behaviors like object destruction happen in the same manner as python. It supposedly has wonky Bools. I'm not aware of IDEs for it. Iron python is not worth considering since it's windows only.
JAVA was written with threading in mind from the beginging. So it can potentially embrace the multi-core revolution that is coming more quickly than other languages. Java was written with a lot of things in mind, but in my opinion, it didn't fully achieve many of them. Locks and explicit threads are increasingly regarded as not a very good model for handling concurrency.
Fortunately, whilst Java may have problems, other JVM based languages like Scala and Clojure handle concurrency extremely well in comparison. Yes you want implicit parallelism. But that can be done under the hood like it can in fortran. But you do need explicit control too. it's not that you want to do it all with sync and lock. You just want them available. Moreover you want a language in widespread use with good libs and lots of programmers.
If all I wanted was the potential for parallelism I'd choose a functional language. But that's not what I want. I want a useful language that clearly has paths to easy parallelism. My bets on java. But there's other contenders. See Fortress for a vaporware language that kinda gets everything right from a numerical computation point of view. But it won't have and programmers or libs for a long time.
I'm not convinced Java's "synchronized" facilities are a significant improvement over Python's global interpreter lock. Java gets a (somewhat) linear speed-up when you add cores. Python gets virtually zero and in some cases it loses over unthreaded. Big difference!
Um, is "for i = 1.3" a for statement or a variable assignment? (Variables with spaces??):-) well since there's not a "for" statement in fortran to make this confusing it resolves to fori = 1.3 as long as you declared the variable fori.
Replying to myself because I forgot to add why I think Java+groovy has a big future.
The big achilles heel of python is that it currently truly sucks for multi-core programming and it would appear that attempts to solve this are not coming quickly. It's global interpreter lock means that multi-threading gains almost no speed over a single processor. It's darn clumsy to fork in part because it takes so long for python to unwind it's stack when a job exits. And it's never written from the ground up to be thread safe.
Fortran95 and 2003 have huge potentials for multi-cores since vector ops and out of order loops are part of the core language, the memory order of arrays can be favorable to vector ops, and the developers have been thinking about High performance Computing as a driver.
however neither fortran95 or pyhton has notions of Syncronizing and locking so all the parallelism is implicit not explicit. You'd rather have implict paralellism to be sure, but sometimes you need explicit control.
JAVA was written with threading in mind from the beginging. So it can potentially embrace the multi-core revolution that is coming more quickly than other languages.
Using a language with garbage collection for the kernel is a bit of a joke....
I'm sure we'll reach the point evenutally where a micro-kernel written in C or C++, with the rest of the OS written in Java or something, will make sense. Mac OS is written in Objective-C. Objective C now has garbage collection. And it arguably is more like java than C++. (e.g. run-time linking).
The message passing interface of Objective C also seems to be a good match to the message passing interface of the mach kernel.
As long as computers need an OS, C/C++ will be in wide use. All major OS's are written in C/C++ and will be for the foreseeable future. Ahem. Look at mac OS. it's in objective-C, which is more of a cousin to Java than to C++.
In the work I do--scientific calculations with a lot of fast numerics, , python + fortran seems like nirvana, as each overcomes the shortcomings of the other. One could just as well use C except the efficient numeric libs and memory layout give fortran an edge.
This of course is not the match made in heaven for everyone but numerical scientists should look hard.
What's so good? Utility: Well there's a strong base of numeric libraries in Python that are fortran array freindly so there's a good base to grow off of.
Second F2PY, which creates python modules out of fortran subs works so well it's almost transparent and painless. Even cooler is that because fortran compiles are ludicrously fast compared to C++, you can generate fortran code in the python compiler at run time and compile it one the fly for creating modules optimized to your problem.
Given you are wrapping in python, the availability of groovy C++ libs is not really very enticing at all given the pain you will pay for having to write the whole program in C++.
Practical: Fortran as a stand alone language kinda blows for versatility and modern program architectures. But if all you are doing is writing a function then it's a sweet language because it's language syntax is so tight that it's harder to make a syntax error that compiles, and hard to logic errors seem to be less evasive than in C. (e.g. using i++ instead of ++i or doing I=4 instead of i==4 are not possible in fortran's limited syntax).
Thus you write functions and let python deal with all the memory management, human interface, file management, command line arg parsing and all the messy bits that end up being a lot bigger than the function where the program spends all it's time.
Fortran is also very optimization friendly since things like matrix multiplies and out-of-order loops are part of the core language.
This is debatable but I find that fortran seems to have a more logical memory order in 2-d arrays. Namely if you take a sub-array you get elements that are consecutive in memory and thus for most microprocessors will all get pulled into the cache on the same page. Slices of C-arrays have consecutive elements spaced by the row width apart in memory. One can of course find cases where one is preferred over another.
I do however which python had some way of optionally typing variables that was less cumbersome and slow than decorators or explicit run-time type checking. I virtually never write python that takes advantage of introspection or dynamic typing so the ability not to have some protection--optionally and just to debug--by type checking is annoying.
But If I were starting from scratch and did not have a compelling need for all those wonderful fortran numeric libs, I think the optimal choice in the future is going to be
Java+ Groovy.
basically you learn one syntax and get the best of both interpreted and compiled languages. Develop it in groovy then migrate the slow bits to JAVA. import all the great JAVA libs.
And since it's nearly the same syntax it's easy to read.
Dang! I remember wanting to buy an 80 column card for my s-100 buss and agonizing over whether to get one using 5x7 dot matrix or go for broke with 6x8 dot matrix. Or possibly building my own using the TV_typewriter cookbook.
By the way, please advise, Should I get the new fangled double-buffered version or try to write to memory during the re-trace?
Here's a site showing the best atari games ever complete with the awesome box covers. So real gems in there, many you probably never heard of. Get an emulator and enjoy the nostalgia.
Slashdot Mirror
Right now they have a matching grant challenge, so nows a good time to offer cash. But think about also being an advocate in your state for getting the laws to allow this system.
OVC not only has open code but it also has an open bussiness model. They won't require you use it on any hardware they offer. It runs fine on off the shelf equipment. Any company could use the code, states could use the code. OVC would simply maintain it and certify that it is being deployed correctly.
Open voting solutions is another open source project with a different bussiness model but open code.
what makes no sense to me is why the jury was not told that her paramour has confessed to killing 8 people. Given two suspects, both whom are intimate with the deceased and one is a mass murderer, would this not sort of raise a reasonable doubt about the other? Given the the murders were also inspired by domestic issues (i.e. not robbery, etc...) surely this is even more relevant. Given the murder knew the defendant very well (best friend) and presumably would know how to get to his house and car. Know his habits. etc... Why was this not presented?
Given the evidence against resiser it seems pretty damning for him in the absence of a plausible alternative. But there was a very plausible one.
The article notes that it comes with Leopard installed but that YOU CANNOT REINSTALL it yourself from a leopard CD (Which comes with it). (and you presumably cannot install Lion or whatever the next OS is) So if You want to run mac OS then you have to pay them to install Mac OS of $150. it also lacks firewire, blue tooth, and wifi. They will add Firewire for $50.
Shipping is another $50 (macs ship free).
so the total price is $609 without wifi or blue tooth. compared to $599 for the mac. The cpu is a bit faster, the disk is bigger and faster.
You can buy the mac at macmall where they will upgrade your memory and and give you a "free" printer for the same price (provided you can stomach the "rebate" spanking machine).
so basically a mac is cheaper, smaller and quieter. Not to mention the mac comes with software updates and you can re-install the software.
----
the psystar's big brother, actually is cost competitive with the powermac however.
Hole a "Bottomless" party and see the poles and zeros in the lower half plane.
Oh, and the correct answer is "discovered"
No, I think the correct answer is "Why are you asking the question?" There might be a more interesting (and perhaps answerable) question that underlies it. And how does that make you feel?
I must be imbued with electron-ness, I'm made of electrons so by this logic I must have to connect with my inner electron to manifest my existence.
No, wait, that's all negative. Let me connect with my inner proton, that's a positive outlook. Me thinks that these people who require one to "be the thing you think about" are searching for more than is there. One might say they are "more"-ons.
Why do I have to have a carrier signal to planet math to use math?
That said, I do know that when I'm deep inside a program it is a left brained experience. I'm fully aware of the rest of the programs existence even though my right-brained eyes see but a few lines at a time. I feel it's flow though the coed itself never moves.
To there is a sensory nature to programming that is like being able touch things that are abstractions.
But so what I can use it without being it.
Why would someone steal the tapes? What is there value.
I recall the great "aha!" when I tried to figure out how Woz did the graphics on the Apple and discovered he took advantage of the 6502's symmetric clock cycle to put the screen access to memory on the backside of the cpu access to memory.
this had the side effect of hitting every (lower byte) address every 60th of a second. That in turn solved the great problem of how to refresh dynamic memory without wait states for the cpu. This allowed the apple to avoid using static ram.
this in turn let them have a smaller power supply, one of the first to use a switching power supply that were the new thing in electrical engineering.
As for the cards, woz was clever again. By pre-decoding the address space for the cards on the motherboard he saved having to have circuitry on every card to recognize it's own address. Thus the cards were half the size of the s-100 cards and used less power.
all that was pretty freakin innovative. Not that they invented it but they made it all work.
Oh and look at the python packages scipy and matplotlib, these use numpy and provide zillions of high level libraries and plotting functions. matplot lib has a syntax resembling matlab for plotting. Scipy uses ftpy under the hood so installing scipy will give you both numpy and f2py.
it takes a day to compile scipy and matplot lib so do it overnight.
if you have a mac, they can be found in both fink and macports. fink also is on linux.
final tip:
ipython is an IDE that plays nice with matplotlib by running the interactive xwindows in another thread.
if you use ipyhton, look at the "run" command for the best way to run code without polluting your namespace.
Best advice: purchase the numpy users guide. very brief intro to f2py but you also get to learn the data types in python that work with fortran calls.
:: c
A program to add to 1-D arrays to each other element by element might look like this:
from numpy import *
import f2py
f = """
Subroutine foo(a,b,c,N)
integer N
real a(N),B(N),C(N)
cf2py intent(out)
integer i
do i=(1,N)
c(i) = a(i)+b(i)
enddo
return
"""
f2py.f2py(f,module="bar")
import bar
a = arange(5) # dummy array, size 5
b = sin(a) # the sine of this array's elements
c = bar.foo(a,b) # the sum of a and b, executed in fortran
when you run this it compiles the fortran at runtime and creates the python module bar.so that can be imported into any python program (on the same kind of computer). In this example, the fortran is embedded as a string in the python and recomplied every run. One could just run f2py at the command line on the fortran file one time and then just import the module.
flourishes that make fortran more pythonic:
f2py is smart enough to figure out that N is just a dummy length argument equal to the array size, and so it will drop it from the required arglist (or you can supply it if you want to as an extra arg).
if you use f90 it will also figure out which variable are purely output variables and move those to the lefthand side. if you use f77 like above you can either leave them on the righthand side or you can add comments to the program that hint to f2py to move it to the left side. (see above code for example)
Thus c = foo(a,b) has no need to specify N, and the output is on the right hand side.
I can if I want to make foo() a method inside of a class. Thus I hold multiple instances of the data structures in python and use them to call the single instance of foo()
also try googling performance python.
Iron python is not worth considering since it's windows only. JAVA was written with threading in mind from the beginging. So it can potentially embrace the multi-core revolution that is coming more quickly than other languages. Java was written with a lot of things in mind, but in my opinion, it didn't fully achieve many of them. Locks and explicit threads are increasingly regarded as not a very good model for handling concurrency.
Fortunately, whilst Java may have problems, other JVM based languages like Scala and Clojure handle concurrency extremely well in comparison. Yes you want implicit parallelism. But that can be done under the hood like it can in fortran. But you do need explicit control too. it's not that you want to do it all with sync and lock. You just want them available. Moreover you want a language in widespread use with good libs and lots of programmers.
If all I wanted was the potential for parallelism I'd choose a functional language. But that's not what I want. I want a useful language that clearly has paths to easy parallelism. My bets on java. But there's other contenders. See Fortress for a vaporware language that kinda gets everything right from a numerical computation point of view. But it won't have and programmers or libs for a long time.
I agree Lua is fast and slim. Perl seems to fork really well. Java threads really well and presumably so does groovy. Python is terrible at both.
In the end you want both powerful and language in wide use (for libraries and people willing to code). That sort of brings it back to Java.
Replying to myself because I forgot to add why I think Java+groovy has a big future.
The big achilles heel of python is that it currently truly sucks for multi-core programming and it would appear that attempts to solve this are not coming quickly. It's global interpreter lock means that multi-threading gains almost no speed over a single processor. It's darn clumsy to fork in part because it takes so long for python to unwind it's stack when a job exits. And it's never written from the ground up to be thread safe.
Fortran95 and 2003 have huge potentials for multi-cores since vector ops and out of order loops are part of the core language, the memory order of arrays can be favorable to vector ops, and the developers have been thinking about High performance Computing as a driver.
however neither fortran95 or pyhton has notions of Syncronizing and locking so all the parallelism is implicit not explicit. You'd rather have implict paralellism to be sure, but sometimes you need explicit control.
JAVA was written with threading in mind from the beginging. So it can potentially embrace the multi-core revolution that is coming more quickly than other languages.
hmmm. well I learned something.
I'm sure we'll reach the point evenutally where a micro-kernel written in C or C++, with the rest of the OS written in Java or something, will make sense. Mac OS is written in Objective-C. Objective C now has garbage collection. And it arguably is more like java than C++. (e.g. run-time linking).
The message passing interface of Objective C also seems to be a good match to the message passing interface of the mach kernel.
So I'd say your statements don't really hold up.
In the work I do--scientific calculations with a lot of fast numerics, , python + fortran seems like nirvana, as each overcomes the shortcomings of the other. One could just as well use C except the efficient numeric libs and memory layout give fortran an edge.
This of course is not the match made in heaven for everyone but numerical scientists should look hard.
What's so good?
Utility:
Well there's a strong base of numeric libraries in Python that are fortran array freindly so there's a good base to grow off of.
Second F2PY, which creates python modules out of fortran subs works so well it's almost transparent and painless. Even cooler is that because fortran compiles are ludicrously fast compared to C++, you can generate fortran code in the python compiler at run time and compile it one the fly for creating modules optimized to your problem.
Given you are wrapping in python, the availability of groovy C++ libs is not really very enticing at all given the pain you will pay for having to write the whole program in C++.
Practical:
Fortran as a stand alone language kinda blows for versatility and modern program architectures. But if all you are doing is writing a function then it's a sweet language because it's language syntax is so tight that it's harder to make a syntax error that compiles, and hard to logic errors seem to be less evasive than in C. (e.g. using i++ instead of ++i or doing I=4 instead of i==4 are not possible in fortran's limited syntax).
Thus you write functions and let python deal with all the memory management, human interface, file management, command line arg parsing and all the messy bits that end up being a lot bigger than the function where the program spends all it's time.
Fortran is also very optimization friendly since things like matrix multiplies and out-of-order loops are part of the core language.
This is debatable but I find that fortran seems to have a more logical memory order in 2-d arrays. Namely if you take a sub-array you get elements that are consecutive in memory and thus for most microprocessors will all get pulled into the cache on the same page. Slices of C-arrays have consecutive elements spaced by the row width apart in memory. One can of course find cases where one is preferred over another.
I do however which python had some way of optionally typing variables that was less cumbersome and slow than decorators or explicit run-time type checking. I virtually never write python that takes advantage of introspection or dynamic typing so the ability not to have some protection--optionally and just to debug--by type checking is annoying.
But If I were starting from scratch and did not have a compelling need for all those wonderful fortran numeric libs, I think the optimal choice in the future is going to be
Java+ Groovy.
basically you learn one syntax and get the best of both interpreted and compiled languages. Develop it in groovy then migrate the slow bits to JAVA. import all the great JAVA libs.
And since it's nearly the same syntax it's easy to read.
TV-typewriter cookbook Link
Dang! I remember wanting to buy an 80 column card for my s-100 buss and agonizing over whether to get one using 5x7 dot matrix or go for broke with 6x8 dot matrix. Or possibly building my own using the TV_typewriter cookbook.
By the way, please advise, Should I get the new fangled double-buffered version or try to write to memory during the re-trace?
Here's a site showing the best atari games ever complete with the awesome box covers. So real gems in there, many you probably never heard of. Get an emulator and enjoy the nostalgia.
thanks!
how does it operate?