TLDR; Arbitration is legally binding across countries, so unless the contract specifies your country as where conflicts will be handled, there are significant risks in terms of fees (in my case $150000) and risk (all my personal assets). The other country may not share your country's view of limited liability, and madman clients may make claims that do not make any sense in your part of the world that you are forced to defend yourself against.
Just a friendly warning to people throwing out arbitration as the solution to many problems. Sometimes arbitration makes matter worse, because they are legally binding across countries. In my case an idiot client went broke, and when he stopped paying I stopped working. The contract had an arbitration clause in it, which would be handled under US law. My client had various issues and excuses for late payments, and eventually I stopped working. I was willing to take a loss of a hundred thousand USD, but my idiot client had another agenda; he wanted me to work for free, until he managed to make money off my product. So despite the fact that he had stopped paying and breached the contract, he said the only settlement he was willing to enter into to avoid suing me in the arbitration courts was if I was willing to work for free until the product made enough money that he could pay me according to our contract. He was in the US, I was in Norway, and the arbitration clause in the contract was under US law (big mistake). I got a legal opinion in Norway about just ignoring the case (it was ridiculous after all), and then defend me when/if he won a claim and came to collect in the Norway. Well, the legal opinion was "you should win the case in the US". Under arbitration law, if I lost in the US, they could collect in Norway. Even worse, in Norway, the goverment actually go a really long way of enforcing such collections, so I could stand to lose my house, car etc. So risking a default judgement (for not showing up) in the US was out of the question. The idiot client sued me, initially for a million USD, although this was later adjusted down. To have any hope of collecting anything in return, I had to counter sue. After spending $150000 in legal fees, I won and was awarded just below $600000 for his breach of contract. But differently from Norway, the US will not help me collect what I won, so I would have to sue him again in his state to collect. And since my claim is against his company, and the fact that he is a fraud, the odds are he would bankrupt his company, stealing any and all assets, and continue as before. So I would have to sue him again personally (with stricter burdens of proof) to demonstrate actual fraud from his side, and hope he has personal assets I could collect. The fraudsters name is Gregory Spear, and his prime vehicles of fraud are companies named Independent Investor, Spear Financial, Spear Publications and more.
If you're looking for a commercial hosted solution with limited storage, Dropbox is probably the best product there is right now. Unison also syncs great both ways against a central "master" copy (if you delete a file from _one_ child copy, it will get deleted from the master and other children as well), although I have no personal experience with Unison on Windows. It also doesn't come with a fancy UI AFAIK.
Great article. Let me tell you a different, yet somehow possibly related story about how things may progress in the future. In Norway we have lots of hydroelectric power (power from water running downhill through turbines). Some years back our goverments finally figured out that it would be a good idea to open up the powergrid and markets so people could buy power from whoever they wanted, not just their local supplier. Worked great for a while. Unfortunately, at the same time the local suppliers were given a monopoly over their own grids, i.e. the lines carrying the power into your house.
Guess what happened next? The price of power remained low and but the transportation fee started rising significantly. Today a lot of people in Norway pay more for getting the power transported to their house than for the actual power itself, and the cost of transportation keeps increasing every year while the cost of the actual power remains low.
Something to think about when the power companies / grid owners really start worrying about not being able to generated their profits from the power itself.
Depending on what kind of software you want to write, and for which platform, you might want to factor in whether you are going to develop client-side or server-side software. My personal opinion is that very few Java based client application feel native to any environment. A java client application looks "java" like. So if you are aiming for Windows client side applications, C# is probably a better choice for the future. If you're aiming server side, and you are already "invested" in Linux/Unix server systems, Java is probably a better choice right now.
It's java (which may be less than ideal), but it works just fine with linux. They also have the most datafeeds for an affordable price, if you want to look at futures and/or currencies in addition to stocks.
The question is a bit generic, as others have already commented. I will share some of my findings however.
Symbian is mature and used on lots of phones (Nokia, Sony Ericsson and more). However, if you look at which models actually runs Symbian and allow the owner of the phone to actually put more Symbian stuff on it, those are usually limited to the very expensive high-end phones. I can only speculate why this is so, but it does not seem unlikely that the phone network operators have little or no interest in phones that would allow users to download applications (and I'm not talking about java toys, but apps that would actually make your phone more useful) which would enable data-rate messaging and similar, potentially killing the SMS based revenues really fast.
Developer support for Symbian is poor as well. Yes, search for "linux" and "Symbian" and you will find some tools (GnuPoc). Good luck - those leave a lot to be desired. If Nokia/Sony Ericsson really wanted independent developers supporting their platform, make sure developers get the tools they need easily, and at low or no cost (and that includes the compiler, not only the API).
Based on my experience, Microsoft currently supports developers nicely and most of the Microsoft phones have not been locked down (meaning users are allowed to download and install "native OS" applications). I know some operators (in the UK I believe) have locked down their Microsoft based phones, but this is the exception rather than the rule as far as I know. Microsoft make the developer tools easily available at no cost (including the compiler,.NET framework, low-level C api's, emulator and more).
As for Linux based phones, I have not seen any in my part of the world (Northern Europe), but I've read about them.
So for now, if you want to develop and distribute applications independently (meaning being possible for a customer to download and install the application on his phone), your best bet would probably be to bet on Microsoft. Yes, there might be more Symbian-based phones out there, but in my experience very few of those actually allow users to install applications (high-end only, not the consumer models).
Based on my experience, the challenge is not the software but getting access to updated, correct and historical data. Mechanical Investing is a disipline that seeks to make investment decisions based on objective rules rather than subjective measures (typically "chart reading"), and attempt to measure the success of a strategy with extensive backtesting using historical data. Currently, the most common data sources are ValueLine reports, Stock Investor PRO (from aaii.com) or IBD (investor.com). Getting access to historical data, keeping the data clean and current and "normalize" it for any changes the providers do over time (and they DO change their formats every few years) is the big challenge, not making the software that uses that data to simulate strategies.
And if you want intra-day data, the data problems become even bigger. I guess quite a few of the Technical Analysis services have historical data for testing TA models, but from what I have found there are few cheap and good sources for fundamental company data which also offer historical data.
I believe they are doing this the wrong way. Instead of focus on the "top end", they should try to make it easier for "hardcore" developers to start developing on their phone in the first place. The first step would be a good emulator/simulator which run the same binary code as the phone itself (not some specially compiled "java" stuff). At the same time making sure that the most popular development environments are supported would be a good idea. This would mean supporting the *ixes with development tools. Supporting gcc and the similar set of tools would also make it easier to get started developing for Symbian, as it would be possible for developers to get access to complete development environments for the platform. If they do this, perl, python and most other useful stuff will come virtually "by itself". It would also mean that the most popular toolsets would be available even when Nokia decides their "perl porting team" does not serve its core business.
Not to mention the fact that the software on the Zen _really_ suck. At least on my Zen, there is no "play a random song from my whole collection" function. Managing playlists on the device itself is a pain in the ass. And finally, as somebody else already mentioned, the Zen and the protocols it use for communication are proprietary, so good luck in making it work easily from your nice default linux desktop (yes, there is at least one project for developing software that is able to grok the Zen protocols...).
And you would figure Creative would release some firmware upgrades to take care of missing basic functionality? Dream on.
Next time I'll buy an iPod or one of it's descendants.
Can anybody with a clue comment on whether this latest relase would be able to run fanless (e.g. using a hustechnologies.net case), and would the linux/XFree drivers be able to support widescreen resolutions (the review at mini-itx.com says only traditional resolutions are supported, but this might be different in the linux/XFree world)?
Exactly what would you recommend to get decent video capture and real-time encoding, if possible? I built my linux based PVR and even upgraded to a brand new motherboard and processor (1.5 GHz AMD) to see if that would improve video capture. I still only got 15-20 frames per second (because it was captured uncompressed I guess), and capturing sound worked poorly or not at all. Encoding "off-line" (after capture) is fine, but as long as capture was both poor quality and with serious frame dropping, building a linux-based PVR using off-the-shelf components is not something I would recommend.
I also had issues with LIRC. I used the remote control that came with my TV card (a BT based card) and set it up with LIRC. Worked fine - mostly. Unfortunately, LIRC also picked up signals from the other remote controls, and *sometimes* those signals lead to LIRC simply freezing. Restarting the LIRC client was the only solution to get it working again.
Don't get me wrong - it is not that I would not like a "do-it-myself-PVR" running linux, but without proper capture and with the problems with LIRC/remote controls interference, it was very hard to make it easy to use. I set it up so that my girlfriend could use it to play music (mp3/CDs) and watch videos and had to teach her to reboot the box when things froze up and I was not around.
And before people tell me to buy a Tivo - they are not available where I live (Norway), so that is not an option (and the program guide would probably not be supported either, which means it would not be very useful).
So please tell me I am wrong and that everybody else is getting 25-30 frames captured with nice video and sound (preferrably with real-time encoding or an embedded encoding unit before data is streamed to disk to avoid frame skipping) and I might consider giving it another try.
If not, I will wait for more hardware. Either a box that works in my country (Norway), or one that can be hacked to work (scraping programming from web sites), or better hardware to roll my own (a quite mini-itx board with embedded mpeg encoding would be a very nice start).
I do not think your comment about treating "undefined" as false will cause warnings is true. In Perl5, I see constructs with if statements where undefined is treated as false all the time, even with both strict and warnings enabled, and at least inside if statements they do not trigger a warning AFAIK. For instance:
my $value = SomeFunc (); if ($value) {
# Do stuff }
Most often the false return value will be undef and not 0...
Luckily, the Gentoo 1.4RC version includes pppoe. It worked out of the box for me by issuing the command "adsl-start" before starting installation (try to ping a well known site to confirm you are online before continuing).
But yes, it was not document. I was just about to install it myself from a floppy when I noticed it was already there.
I'm not picky about destinations, but prefer somewhere warm (I'm based in northern Europe). As for the suggestions mentioned so far the no-brainers that I'm already using include internet cafes and cheapo/dial-up links, but these are not sufficient for long time work (and I do check source code into CVS repositories, log in and sync web sites using ssh/rsync and more). And I fear the answers I would get if I dial up the local tourist office and ask for hotels with internet access ("yes, all the hotels have phones.."). So far I have received 0 suggestions, which indicate to me that there are few resorts offering _real_ internet access.
I've developed several applications using linux, gcc and qt and recompiling under windows (using Microsoft Visual C++) right before final delivery, and this works mostly great.
Be aware to do some ifdefs if you use "advanced C++" though. The libraries provided with Microsoft Visual C++ really suck (iostreams and STL), and be prepared if your clients try to work with your source code. Microsoft has a tendency to call different releases of the various "6.0" compilers the same (even after different servicepacks have been applied), and this will lead to some really wierd error messages when you use things like iostreams and STL and will cost you and your clients quite a few hours of work unless you are able to make sure that everybody is using the EXACT same version of VC++.
I have been able to compile the Qt examples under windows using the excellent mingw32 ("complete gcc development environment under windows"), but mingw32 is not as far as I know a supported platform from Troll (the developers of Qt) which means you will need to do some tweaking yourself.
But all in all, using Qt, gcc, and Microsoft Visual C++ I am able to develop and test under linux and then reboot and recompile (with some tweaks for iostreams and possibly STL) for Windows.
Assuming ming32/gcc becomes a supported platform from Troll Tech, cross development should be REALLY REALLY easy, and give you access to a more complete iostreams library and STL.
Slashdot Mirror
TLDR; Arbitration is legally binding across countries, so unless the contract specifies your country as where conflicts will be handled, there are significant risks in terms of fees (in my case $150000) and risk (all my personal assets). The other country may not share your country's view of limited liability, and madman clients may make claims that do not make any sense in your part of the world that you are forced to defend yourself against.
Just a friendly warning to people throwing out arbitration as the solution to many problems. Sometimes arbitration makes matter worse, because they are legally binding across countries. In my case an idiot client went broke, and when he stopped paying I stopped working. The contract had an arbitration clause in it, which would be handled under US law. My client had various issues and excuses for late payments, and eventually I stopped working. I was willing to take a loss of a hundred thousand USD, but my idiot client had another agenda; he wanted me to work for free, until he managed to make money off my product. So despite the fact that he had stopped paying and breached the contract, he said the only settlement he was willing to enter into to avoid suing me in the arbitration courts was if I was willing to work for free until the product made enough money that he could pay me according to our contract. He was in the US, I was in Norway, and the arbitration clause in the contract was under US law (big mistake). I got a legal opinion in Norway about just ignoring the case (it was ridiculous after all), and then defend me when/if he won a claim and came to collect in the Norway. Well, the legal opinion was "you should win the case in the US". Under arbitration law, if I lost in the US, they could collect in Norway. Even worse, in Norway, the goverment actually go a really long way of enforcing such collections, so I could stand to lose my house, car etc. So risking a default judgement (for not showing up) in the US was out of the question. The idiot client sued me, initially for a million USD, although this was later adjusted down. To have any hope of collecting anything in return, I had to counter sue. After spending $150000 in legal fees, I won and was awarded just below $600000 for his breach of contract. But differently from Norway, the US will not help me collect what I won, so I would have to sue him again in his state to collect. And since my claim is against his company, and the fact that he is a fraud, the odds are he would bankrupt his company, stealing any and all assets, and continue as before. So I would have to sue him again personally (with stricter burdens of proof) to demonstrate actual fraud from his side, and hope he has personal assets I could collect. The fraudsters name is Gregory Spear, and his prime vehicles of fraud are companies named Independent Investor, Spear Financial, Spear Publications and more.
If you want to read the whole sad story, I've put it up on http://aboutspearreport.wordpress.com/ .
If you're looking for a commercial hosted solution with limited storage, Dropbox is probably the best product there is right now. Unison also syncs great both ways against a central "master" copy (if you delete a file from _one_ child copy, it will get deleted from the master and other children as well), although I have no personal experience with Unison on Windows. It also doesn't come with a fancy UI AFAIK.
Great article. Let me tell you a different, yet somehow possibly related story about how things may progress in the future. In Norway we have lots of hydroelectric power (power from water running downhill through turbines). Some years back our goverments finally figured out that it would be a good idea to open up the powergrid and markets so people could buy power from whoever they wanted, not just their local supplier. Worked great for a while. Unfortunately, at the same time the local suppliers were given a monopoly over their own grids, i.e. the lines carrying the power into your house.
Guess what happened next? The price of power remained low and but the transportation fee started rising significantly. Today a lot of people in Norway pay more for getting the power transported to their house than for the actual power itself, and the cost of transportation keeps increasing every year while the cost of the actual power remains low.
Something to think about when the power companies / grid owners really start worrying about not being able to generated their profits from the power itself.
Depending on what kind of software you want to write, and for which platform, you might want to factor in whether you are going to develop client-side or server-side software. My personal opinion is that very few Java based client application feel native to any environment. A java client application looks "java" like. So if you are aiming for Windows client side applications, C# is probably a better choice for the future. If you're aiming server side, and you are already "invested" in Linux/Unix server systems, Java is probably a better choice right now.
It's java (which may be less than ideal), but it works just fine with linux. They also have the most datafeeds for an affordable price, if you want to look at futures and/or currencies in addition to stocks.
The question is a bit generic, as others have already commented. I will share some of my findings however.
.NET framework, low-level C api's, emulator and more).
Symbian is mature and used on lots of phones (Nokia, Sony Ericsson and more). However, if you look at which models actually runs Symbian and allow the owner of the phone to actually put more Symbian stuff on it, those are usually limited to the very expensive high-end phones. I can only speculate why this is so, but it does not seem unlikely that the phone network operators have little or no interest in phones that would allow users to download applications (and I'm not talking about java toys, but apps that would actually make your phone more useful) which would enable data-rate messaging and similar, potentially killing the SMS based revenues really fast.
Developer support for Symbian is poor as well. Yes, search for "linux" and "Symbian" and you will find some tools (GnuPoc). Good luck - those leave a lot to be desired. If Nokia/Sony Ericsson really wanted independent developers supporting their platform, make sure developers get the tools they need easily, and at low or no cost (and that includes the compiler, not only the API).
Based on my experience, Microsoft currently supports developers nicely and most of the Microsoft phones have not been locked down (meaning users are allowed to download and install "native OS" applications). I know some operators (in the UK I believe) have locked down their Microsoft based phones, but this is the exception rather than the rule as far as I know. Microsoft make the developer tools easily available at no cost (including the compiler,
As for Linux based phones, I have not seen any in my part of the world (Northern Europe), but I've read about them.
So for now, if you want to develop and distribute applications independently (meaning being possible for a customer to download and install the application on his phone), your best bet would probably be to bet on Microsoft. Yes, there might be more Symbian-based phones out there, but in my experience very few of those actually allow users to install applications (high-end only, not the consumer models).
My $.02 anyway.
Based on my experience, the challenge is not the software but getting access to updated, correct and historical data. Mechanical Investing is a disipline that seeks to make investment decisions based on objective rules rather than subjective measures (typically "chart reading"), and attempt to measure the success of a strategy with extensive backtesting using historical data. Currently, the most common data sources are ValueLine reports, Stock Investor PRO (from aaii.com) or IBD (investor.com). Getting access to historical data, keeping the data clean and current and "normalize" it for any changes the providers do over time (and they DO change their formats every few years) is the big challenge, not making the software that uses that data to simulate strategies.
And if you want intra-day data, the data problems become even bigger. I guess quite a few of the Technical Analysis services have historical data for testing TA models, but from what I have found there are few cheap and good sources for fundamental company data which also offer historical data.
I believe they are doing this the wrong way. Instead of focus on the "top end", they should try to make it easier for "hardcore" developers to start developing on their phone in the first place. The first step would be a good emulator/simulator which run the same binary code as the phone itself (not some specially compiled "java" stuff). At the same time making sure that the most popular development environments are supported would be a good idea. This would mean supporting the *ixes with development tools. Supporting gcc and the similar set of tools would also make it easier to get started developing for Symbian, as it would be possible for developers to get access to complete development environments for the platform. If they do this, perl, python and most other useful stuff will come virtually "by itself". It would also mean that the most popular toolsets would be available even when Nokia decides their "perl porting team" does not serve its core business.
Not to mention the fact that the software on the Zen _really_ suck. At least on my Zen, there is no "play a random song from my whole collection" function. Managing playlists on the device itself is a pain in the ass. And finally, as somebody else already mentioned, the Zen and the protocols it use for communication are proprietary, so good luck in making it work easily from your nice default linux desktop (yes, there is at least one project for developing software that is able to grok the Zen protocols...).
And you would figure Creative would release some firmware upgrades to take care of missing basic functionality? Dream on.
Next time I'll buy an iPod or one of it's descendants.
Any chance anybody knows the product name or the company that produce these devices?
Can anybody with a clue comment on whether this latest relase would be able to run fanless (e.g. using a hustechnologies.net case), and would the linux/XFree drivers be able to support widescreen resolutions (the review at mini-itx.com says only traditional resolutions are supported, but this might be different in the linux/XFree world)?
Exactly what would you recommend to get decent video capture and real-time encoding, if possible? I built my linux based PVR and even upgraded to a brand new motherboard and processor (1.5 GHz AMD) to see if that would improve video capture. I still only got 15-20 frames per second (because it was captured uncompressed I guess), and capturing sound worked poorly or not at all. Encoding "off-line" (after capture) is fine, but as long as capture was both poor quality and with serious frame dropping, building a linux-based PVR using off-the-shelf components is not something I would recommend.
I also had issues with LIRC. I used the remote control that came with my TV card (a BT based card) and set it up with LIRC. Worked fine - mostly. Unfortunately, LIRC also picked up signals from the other remote controls, and *sometimes* those signals lead to LIRC simply freezing. Restarting the LIRC client was the only solution to get it working again.
Don't get me wrong - it is not that I would not like a "do-it-myself-PVR" running linux, but without proper capture and with the problems with LIRC/remote controls interference, it was very hard to make it easy to use. I set it up so that my girlfriend could use it to play music (mp3/CDs) and watch videos and had to teach her to reboot the box when things froze up and I was not around.
And before people tell me to buy a Tivo - they are not available where I live (Norway), so that is not an option (and the program guide would probably not be supported either, which means it would not be very useful).
So please tell me I am wrong and that everybody else is getting 25-30 frames captured with nice video and sound (preferrably with real-time encoding or an embedded encoding unit before data is streamed to disk to avoid frame skipping) and I might consider giving it another try.
If not, I will wait for more hardware. Either a box that works in my country (Norway), or one that can be hacked to work (scraping programming from web sites), or better hardware to roll my own (a quite mini-itx board with embedded mpeg encoding would be a very nice start).
Most often the false return value will be undef and not 0...
Luckily, the Gentoo 1.4RC version includes pppoe. It worked out of the box for me by issuing the command "adsl-start" before starting installation (try to ping a well known site to confirm you are online before continuing).
But yes, it was not document. I was just about to install it myself from a floppy when I noticed it was already there.
I'm not picky about destinations, but prefer somewhere warm (I'm based in northern Europe). As for the suggestions mentioned so far the no-brainers that I'm already using include internet cafes and cheapo/dial-up links, but these are not sufficient for long time work (and I do check source code into CVS repositories, log in and sync web sites using ssh/rsync and more). And I fear the answers I would get if I dial up the local tourist office and ask for hotels with internet access ("yes, all the hotels have phones.."). So far I have received 0 suggestions, which indicate to me that there are few resorts offering _real_ internet access.
I've developed several applications using linux, gcc and qt and recompiling under windows (using Microsoft Visual C++) right before final delivery, and this works mostly great.
Be aware to do some ifdefs if you use "advanced C++" though. The libraries provided with Microsoft Visual C++ really suck (iostreams and STL), and be prepared if your clients try to work with your source code. Microsoft has a tendency to call different releases of the various "6.0" compilers the same (even after different servicepacks have been applied), and this will lead to some really wierd error messages when you use things like iostreams and STL and will cost you and your clients quite a few hours of work unless you are able to make sure that everybody is using the EXACT same version of VC++.
I have been able to compile the Qt examples under windows using the excellent mingw32 ("complete gcc development environment under windows"), but mingw32 is not as far as I know a supported platform from Troll (the developers of Qt) which means you will need to do some tweaking yourself.
But all in all, using Qt, gcc, and Microsoft Visual C++ I am able to develop and test under linux and then reboot and recompile (with some tweaks for iostreams and possibly STL) for Windows.
Assuming ming32/gcc becomes a supported platform from Troll Tech, cross development should be REALLY REALLY easy, and give you access to a more complete iostreams library and STL.
Good luck,
Marius Kjeldahl