SVN works well with a single up to date master, but that model eventually breaks if you want to have experimental features. At some point that will become a need -- trying something outside the main branch that is actively being deployed. Git is a bit of a pain at first but you simply can't do the things git does in svn.
I use SVN at work and for a small number of developers it works decently well. SVN is quick to set up and to learn -- it somehow feels easy. I agree with the TortoiseSVN as a client -- all of that works quite well.
However. Doing merges in SVN is an absolute nightmare. The "cherry picking" model of implementing features and merging them back in, one by one, as code gets ripe is painful in SVN. There is a learning curve for git, but not much more so that for SVN, and the habit of using a feature branch and merging back feels logical and the right thing to do.
Try Cambridge, with companies like ARM, Cambridge Silicon Radio/CSR (several billion chips sold) Cambridge University. Plenty of money in London, Europe's financial centre. Plenty of talent around, or attractable due to English being the universal language and European borders being open -- or old colonial ties.
Or try Berlin for "frontier living".
Normally a lookup table would be the way to go. There's always a why -- in this case it was a slow microcontroller with 16KByte of codespace, which was already cramped. Table won't fit.
I live in the UK, about an hour away from London. I have been to New York, but only once.
London has existed for over a thousand years. It has just grown organically. All recent services (such luxuries as underground, trains, ringroads, mains water, electricity, sewers, communication lines) have been retrofitted on that base -- and it shows. The roads are the wrong size for the amount of traffic -- trains clash and are overfull, high rise offices are planned but foundations have to carefully avoid all the tunneling below.
New York, in it's current form, is a lot younger than that. A lot of the concepts "we might want sewers" / electricity / rail, to some extend, could be taken into account when the city grid was being laid out. It's a lot easier to build sewers / underground trains before high rise buildings have gone up on top.
Back to the software world -- if you've got code that was pre-Web / pre-Internet but needs to be brought into the 21st century, inevitably things won't fit. I've worked on some banking code which had punchcard assumptions shine through. Some of that code is 40 years old. You could call it crufty, some would call it rock-solid.
I've written code that computes a CRC. It's been done before. The naive/reference implementation works but isn't fast. The optimized version, and how the heck that came about from the naive implementation to those magic few lines of code, looks nothing like it. Now rather than you glazing over "what the?", I figure that *if* you have to overhaul this code, you'd like to know *why* this code looks like it does. So I explained why. In the code. In a full page of comments.
Interesting code, serves a real purpose, solves a real problem.
A lot of "real world" code out there has not been designed, it has grown, and that's part of the problem. Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?) and major reengineering exercises need to be undertaken (in the case of London, as one example, sewage pipes were fitted in underneath). Inevitably there's some shortcuts taken or real reasons that you could not quite do the best job.
Codewise, the oldest running code probably lives in the banking system or the telephony system. Typically code that has grown over time and can't just be shut down for an upgrade -- "what do you mean close the bank for a week?". Now whatever code runs there has been kept running (bodged?) for decades, but pretty it probably isn't.
I'd say that that works in favour.
As bitcoin get more valuable / scarce the tendency to protect them increases. So as more of them get lost the rate of them getting lost will decrease.
Note that "gold" also has a finite amount available that gets progressively harder/more expensive to mine.
If I asked my customers what they wanted, they'd say they wanted a faster horse. Innovation comes from thinking out of the box.
I worked on some mobile e-mail product some 8 years ago. Call it a Blackberry competitor -- it ran on phones like the Palm Treo, Nokia E61 and various Windows Mobile devices. There was rumours of Apple making a phone -- and when it came out, it had no keys... I remember thinking -- how are you ever going to type a message without keys? Well...
Dear o dear you're getting fleeced over in the US. I paid for my phone outright. One off cost. A humble Galaxy S3 mini. £180 / US$ 280 including all sales tax, new, unlocked. Add a SIM-only deal. I pay £8 / US$12.50 for 500 minutes, unlimited messages and 1GB of data. there. Oh, and I don't pay for incoming calls.
Looks like prices in the UK are around 25% of the prices you quote...
I'll mark you points if you can open a telnet or ssh connection to a Unix shell account somewhere.
Packet drivers and NCSA Telnet would get you there, and you could run a commandline webclient from there.
Slashdot Mirror
Yeah. I'm that guy that just orders a double espresso. I'd be happy with fresh black filter coffee too.
SVN works well with a single up to date master, but that model eventually breaks if you want to have experimental features. At some point that will become a need -- trying something outside the main branch that is actively being deployed. Git is a bit of a pain at first but you simply can't do the things git does in svn.
I use SVN at work and for a small number of developers it works decently well. SVN is quick to set up and to learn -- it somehow feels easy. I agree with the TortoiseSVN as a client -- all of that works quite well. However. Doing merges in SVN is an absolute nightmare. The "cherry picking" model of implementing features and merging them back in, one by one, as code gets ripe is painful in SVN. There is a learning curve for git, but not much more so that for SVN, and the habit of using a feature branch and merging back feels logical and the right thing to do.
Peugeot makes them: http://www.peugeot.co.uk/hybri...
Are you sure? http://www.telegraph.co.uk/new...
Try Cambridge, with companies like ARM, Cambridge Silicon Radio/CSR (several billion chips sold) Cambridge University. Plenty of money in London, Europe's financial centre. Plenty of talent around, or attractable due to English being the universal language and European borders being open -- or old colonial ties. Or try Berlin for "frontier living".
Is it an African or a European gyrocopter?
In Berlin, after the war, trams were used to haul freight.
Irish / English law are often alike: https://www.gov.uk/right-of-wa...
Buy low, sell high.
Normally a lookup table would be the way to go. There's always a why -- in this case it was a slow microcontroller with 16KByte of codespace, which was already cramped. Table won't fit.
London has existed for over a thousand years. It has just grown organically. All recent services (such luxuries as underground, trains, ringroads, mains water, electricity, sewers, communication lines) have been retrofitted on that base -- and it shows. The roads are the wrong size for the amount of traffic -- trains clash and are overfull, high rise offices are planned but foundations have to carefully avoid all the tunneling below.
New York, in it's current form, is a lot younger than that. A lot of the concepts "we might want sewers" / electricity / rail, to some extend, could be taken into account when the city grid was being laid out. It's a lot easier to build sewers / underground trains before high rise buildings have gone up on top.
Back to the software world -- if you've got code that was pre-Web / pre-Internet but needs to be brought into the 21st century, inevitably things won't fit. I've worked on some banking code which had punchcard assumptions shine through. Some of that code is 40 years old. You could call it crufty, some would call it rock-solid.
I've written code that computes a CRC. It's been done before. The naive/reference implementation works but isn't fast. The optimized version, and how the heck that came about from the naive implementation to those magic few lines of code, looks nothing like it. Now rather than you glazing over "what the?", I figure that *if* you have to overhaul this code, you'd like to know *why* this code looks like it does. So I explained why. In the code. In a full page of comments.
A lot of "real world" code out there has not been designed, it has grown, and that's part of the problem. Think of cities that have grown (London?) rather than be designed according to some grand master plan (New York?) and major reengineering exercises need to be undertaken (in the case of London, as one example, sewage pipes were fitted in underneath). Inevitably there's some shortcuts taken or real reasons that you could not quite do the best job.
Codewise, the oldest running code probably lives in the banking system or the telephony system. Typically code that has grown over time and can't just be shut down for an upgrade -- "what do you mean close the bank for a week?". Now whatever code runs there has been kept running (bodged?) for decades, but pretty it probably isn't.
http://www.reuters.com/article...
Build your Walmart store with the back facing the railtracks.
I'd say that that works in favour. As bitcoin get more valuable / scarce the tendency to protect them increases. So as more of them get lost the rate of them getting lost will decrease. Note that "gold" also has a finite amount available that gets progressively harder/more expensive to mine.
For a man perhaps not yet -- but you did see this one right? http://www.bbc.co.uk/news/science-environment-25178299
shl ax,2
would be slightly faster and use less memory :)
I worked on some mobile e-mail product some 8 years ago. Call it a Blackberry competitor -- it ran on phones like the Palm Treo, Nokia E61 and various Windows Mobile devices. There was rumours of Apple making a phone -- and when it came out, it had no keys... I remember thinking -- how are you ever going to type a message without keys? Well...
Looks like prices in the UK are around 25% of the prices you quote...
And acidity. Nothing wrong with Robusta beans, but you can't sell the resulting product as "Arabica coffee".
Not seen the place, not been there, but I can't see a reason a restaurant won't take cards.
For another starting point look on http://users.ohiohills.com/fmacall/ or http://sshdos.sourceforge.net/index.html
Your next challenge: do it on an 8088.
This one: http://en.wikipedia.org/wiki/Am5x86