I have had 3G data in the UK, DE and NL, all on Vodafone 3G networks. Initial roll-out was slow with poor coverage even in London. The first time I used 3G in the UK was in the city and it was so bad, I was losing calls unless I restricted myself to 2G. I was visiting the vicinity of Angel last year and the 3G service was heavily overloaded and not cheap.
Yes, since last year it was a lot cheaper, but again there is an attempt to segment the market according to protocol, i.e., services like Web 'n Walk from T-mobile which restricts you to web ports. Understandably the vendors were scared of Skype, a service which I successfully used evenings when I was in London last (VF's problems were clearly linked to daytime users).
At the moment my base is Germany. Vodafone charge me 48/mo (+Mwst) for their 4GB plan on a datacard. There are various plans offered for telephone only but my phone doesn't do HDSP or whatever and it is restricted to web type services.
Yes, the 3G auctions in the end did neither the operators nor the subscribers much good. The operators find that they are so burdened with debt that they have to press high charges on fragile business models. Mobile data is very, very useful but access is too expensive in many places for applications to be established. In fact although 3G has been around in Europe for several years now using it has been too expensive for most people.
At the time of the battery scare, many sites gave the direct link, i.e. dellbatteryprogram.com, even some dead tree articles in newspapers and magazines. The moment anyone manually types in a URL, there is a possibility of a typo. If the rate is just 1 in a 100, then you will still get enough traffic to your malware page to make it very profitable.
If you are really clever, you can frame Dell's original page and then put stuff up like those annoying "Your computer is running slow ads" which are much more likely to be clicked if they are apparently being hosted by a vendor. The people I support (my family) have been carefully trained not to click anything unless it is a genuine web site from someone reputable, but typosquatting can make this difficult.
If you are sorting out PVCs (effectively leased circuits with guaranteed bandwidth), you normally get some kind of fall back option where they switch you somewhere else and maybe trim your bandwidth. If you really care about connectivity (i.e., connectivity between market participants and markets) you will go to different providers and make sure they liase so as to route via different cables (I guess that's where that $350 map comes in handy).
Some bigger companies will have connectivity but those hanging off smaller ISPs don't. My Wife's company has an office in India and they have lost data completely outside India but not voice.
Of course, one would think there would be two types of redundancy: The software would be N-version programmed and there would be separate systems for each engine.
Normally, it would be all three systems delivering data to voting logic that would allow the data through to both engines. Each processor has identical input but one of the two that correlate is permitted to deliver control instructions.
The chances of two independent N-version-programmed programs failing at the same instant seems particularly low.
That is if they have been well tested. I think any teacher of programming can talk about students independently developing software with the same mistakes (off-by-ones).
It's easy to jump to the it-must-be-the-computers conclusion because PCs are unreliable in everyday use compared to washing machines, cars or compact disk players.
Apart from the plague of duff capacitors or occasional loose connections after relocation, PC hardware tends to be extremely reliable. The software isn't. If it was, we would have laboriously tested code costing a fortune and everyone would have configuration management so that only tested configurations are deployed. Interestingly enough, in the examples you gave all have processors these days. Those on the car can be said to be safety critical (particularly if your car has stability control or whatever). In all cases, what the processor does is rigidly defined and on the car, the lesser defined tasks such as entertainment or navigation are offloaded to a separate system.
First, that was a 777-300. Where did the 772 come from?
Sorry, it isn't in people's nature to shut up and trust the experts. Particularly if you every fly in one of those things (I haven't flown in a 777 for six weeks now), but if I am expected to fly in one again, I would like to be able to second guess any issues with the plane and perhaps choose differently. What is even more relevant is that many of us work in IT and although I haven't touched avionics development for some 17 years now, I maintain an interest in reliable systems design.
There is serious redundancy on all FBW aircraft. Also, since the DC10, manufacturers try to ensure that controls and power is routed separately so that damage in one area will not remove all controls.
I think we will find that there was a coding error that caused the engines not to respond to controls with this one.
Flight systems (hydraulics, power and controls) are triplicated to give the appropriate security for fly-by-wire. Airbus Industrie on the 320 used two different processor architectures and three separate teams working on flight software to ensure that the same problem would not occur on two out of three computers. Does anyone know if Boeing used the same practice for their flight systems?
I used a Dell Latitude in the UK and it came with a three wire AC adapter. Still two wires to the machine though. I tried one in Germany and like the US it came with a two wire AC connection, and yes, I sometimes get a tingle (alloy case and so on).
If one looks at the average military procurement program the prime concern is not whether it works, just that there are enough retired senior military officers on the company's payroll. Note that PDAs have been used for some time by people like surveyors, construction workers and so on. These ruggedised versions are best to use for comparison purposes. Yes, they do cost more than a regular PDA, but that much?
The model you mention looks a bit too flimsy, but they also do this one which really does look a lot more something that you could easily carry around and use on the move.
Go to one of the largest all-electronic markets in the world: www.deutche-boerse.com and www.eurexchange.com. They use VMS and are still waiting for other systems to catch up!!!!
Re:It would make MySQL easier to deploy...
on
Sun Buys MySQL
·
· Score: 1
No, technical deployment is usually the the least of my worries. The problem with deployment from the management perspective is whether we believe that the company can support as needed for the lifetime of the system. We do get a lot of small systems in for the business but then the business manager signs-off on the waiver. In the case of infrastructure technology, it becomes down to the responsibility of the CTO and if it isn't mainstream, he (he usually is a 'he') won't like the risk when he is halled over the coals for the failure of a major system. With the big databases, Oracale, SyBase or even MS SQL, you can simply say that 'I chose a system already widely deployed in banking'. Having Sun there doesn't mean they bring anything technical to the table, but just there name amkes it a whole lot more acceptable.
Re:It would make MySQL easier to deploy...
on
Sun Buys MySQL
·
· Score: 2, Insightful
The banks are really allergic to deploying stuff from smaller vendors. The CTO in a bank tends to be really risk averse (yes, strange whilst his colleagues are pissing the bank's money away on dodgy loans and derivatives). It has been very difficult to deploy Linux but it has sort-of become possible over the years (typically RHEL or sometimes SUSE). Personally, I can see the benefit of major databases, but they get expensive when what you are looking for is a light-weight data store and you really don't want the overhead of an enterprise database. Sun is still big and they still sell a lot of backend servers in banks.
It would make MySQL easier to deploy...
on
Sun Buys MySQL
·
· Score: 5, Insightful
I have worked at a lot of big banks. Open Source has been slowly finding its way in, but it is incredibly difficult to deploy an open source database like MySQL or Postgres. The banks says they want safety and security - and you answer that your database isn't enterprise critical so why pay for Oracle? Management then says, ah well, how about MS SQL Server....
Most corporates buy their Microsoft software through volume agreements. This means that license fees are a recurring cost rather than one-time. The only place where MS really does seem to have the upperhand is slightly better management/rollout and more functionality (which 70% of users don't use anyway).
PG's eBook of Peter Pan is public domain in the US and most other places, but not in the UK.
This is an interesting and very special case because the copyright was due to expire in 2007 but because Barrie had deeded all royalties to Great Ormand Street Childrens Hospital, the copyright was extended in perpuity by a special ammendment in the British House of Lords in 1987 (the original copyright was life of author plus fifty years). The rest of the EU sees the copyright on the book expiring this year (life of author plus 70 years), so the only place left generating royalties for the hospital is the UK. Disney will be happy!!!
Yes, Java has some good points and the class libraries can be a real time saver but I still don't particularly like it for high computational or processing volumes. I would certainly agree that Java is more flexible and delivers sooner but when your problem domain is well defined then C/C++ is still a valid solution. Java can be quite fast now, but particularly across multiple processors a language that gives you more control can be better.
Must be said that my first reaction is to throw hardware at such problems.
I can't quite remember the size of their Grid but it was B I G. I/O was a problem though because once you calculated it at book level, the books could be formed into multiple hierarchies, i.e., business line, legal entity, etc. That was very much a hash and remash of the original data. Yes, they were overdoing the cursors and locking as that is the most obvious way to handle a database.
As different business desks were responsible for fixing different data sets, each could take a snapshot of the data nodes and recalculate their data without having dependencies on anyone else. Unfortunately it was still one database and the relational model isn't that well suited to the problem. If the different risk desks reran their snapshots at the same time, there would still be contention both for processors and the database.
Frankly, under very high load conditions, I would have kicked out the database management software (as is done at some exchanges such as Eurex). Matching takes place using a database of flat files (either memory or disk based depending on expected trading volume) with journalling where needed.
The thing is that even with shaving 50% off their run times, it didn't save them from that fact that if North America delivered data late because of timezone issues and their FO/MO systems consistently screwed up the batches that produced the source positions then perhaps it is better to worry about how data is produced and then to look at beefing up performance. The problem was that FO IT and Risk IT were seperate departments so it was politically different for one to place requirements on the other.
From an administrative perspective, a much smaller bank had taken over a large UK bank a few years back and the fault-lines were still quite visible, particularly when their UK office is telling an office originally part of the larger bank several thousand km away. The funny thing is they have now taken on another European bank, even if they manage the quick integration of their desks, the bank they acquired has many more books to run. It shouldn't be an IT problem, but one of the reasons for the acquisition is the rationalisation of trading infrastructure.
Obviously I don't know your setup well enough to know if my ideas are crap or not, but I think a useful bit of a CS course ought to be that sort of hack.
I had the 'pleasure' of starting on some very slow machines at University. It was all we had, but it did make you think about performance. We may not have studied much on performance but when you had a CPU clocked in KHz and batch jobs were CPU limited (Yes, I guess I'm a bit older than you) then you learned to think about performance. I guess the best training now are the students doing robotics such as the DARPA challenge people in the states where you have a problem to solve and the speed of your vehicle depends on how quickly you can do that.
I was working on a little project up at angel (you probably know the client) where they were having problems calculating their VaR in a timely manner. From a technical viewpoint, they could have junked Java and their Sybase database, but that would have cost a lot of effort. They had some good developers but no defect or release management and since people had little outside experience, nobody saw this as wrong.
Interesting idea. It could also save on parking. Why have so many parking spaces when a car doesn't spend all day parked outside the office? One of the problems though is that many people regard a car as a private thing.
I remember being forced to learn how to use logarithm tables (printed booklets with rows and columns of logs, sine, cosine values etc) long after electronic scientific calculators were commonplace and cheap. It was a total waste of time. I'd never dream of introducing people to programming using C or C++.
Interestingly enough, lookup tables made a comeback for fast transcendental functions for real-time work. I saw them in use for missile guidance systems in the day when microprocessors started knocking around and also for early 3D graphics. Later, I have used them myself in the 486 era for real-time option pricing models. I would agree that familiarity with the tools in hand is a good first step but at some point you need to be aware of their limitations.
I have had 3G data in the UK, DE and NL, all on Vodafone 3G networks. Initial roll-out was slow with poor coverage even in London. The first time I used 3G in the UK was in the city and it was so bad, I was losing calls unless I restricted myself to 2G. I was visiting the vicinity of Angel last year and the 3G service was heavily overloaded and not cheap.
Yes, since last year it was a lot cheaper, but again there is an attempt to segment the market according to protocol, i.e., services like Web 'n Walk from T-mobile which restricts you to web ports. Understandably the vendors were scared of Skype, a service which I successfully used evenings when I was in London last (VF's problems were clearly linked to daytime users).
At the moment my base is Germany. Vodafone charge me 48/mo (+Mwst) for their 4GB plan on a datacard. There are various plans offered for telephone only but my phone doesn't do HDSP or whatever and it is restricted to web type services.
Yes, now. Remember 3G has been around for about 4-5 years. Initial uptake was sloooow.
Yes, the 3G auctions in the end did neither the operators nor the subscribers much good. The operators find that they are so burdened with debt that they have to press high charges on fragile business models. Mobile data is very, very useful but access is too expensive in many places for applications to be established. In fact although 3G has been around in Europe for several years now using it has been too expensive for most people.
At the time of the battery scare, many sites gave the direct link, i.e. dellbatteryprogram.com, even some dead tree articles in newspapers and magazines. The moment anyone manually types in a URL, there is a possibility of a typo. If the rate is just 1 in a 100, then you will still get enough traffic to your malware page to make it very profitable.
If you are really clever, you can frame Dell's original page and then put stuff up like those annoying "Your computer is running slow ads" which are much more likely to be clicked if they are apparently being hosted by a vendor. The people I support (my family) have been carefully trained not to click anything unless it is a genuine web site from someone reputable, but typosquatting can make this difficult.
If you are sorting out PVCs (effectively leased circuits with guaranteed bandwidth), you normally get some kind of fall back option where they switch you somewhere else and maybe trim your bandwidth. If you really care about connectivity (i.e., connectivity between market participants and markets) you will go to different providers and make sure they liase so as to route via different cables (I guess that's where that $350 map comes in handy).
Some bigger companies will have connectivity but those hanging off smaller ISPs don't. My Wife's company has an office in India and they have lost data completely outside India but not voice.
Sorry, you are correct, it was the 777-200ER model.
First, that was a 777-300. Where did the 772 come from?
Sorry, it isn't in people's nature to shut up and trust the experts. Particularly if you every fly in one of those things (I haven't flown in a 777 for six weeks now), but if I am expected to fly in one again, I would like to be able to second guess any issues with the plane and perhaps choose differently. What is even more relevant is that many of us work in IT and although I haven't touched avionics development for some 17 years now, I maintain an interest in reliable systems design.
There is serious redundancy on all FBW aircraft. Also, since the DC10, manufacturers try to ensure that controls and power is routed separately so that damage in one area will not remove all controls.
I used a Dell Latitude in the UK and it came with a three wire AC adapter. Still two wires to the machine though. I tried one in Germany and like the US it came with a two wire AC connection, and yes, I sometimes get a tingle (alloy case and so on).
If one looks at the average military procurement program the prime concern is not whether it works, just that there are enough retired senior military officers on the company's payroll. Note that PDAs have been used for some time by people like surveyors, construction workers and so on. These ruggedised versions are best to use for comparison purposes. Yes, they do cost more than a regular PDA, but that much?
The model you mention looks a bit too flimsy, but they also do this one which really does look a lot more something that you could easily carry around and use on the move.
Go to one of the largest all-electronic markets in the world: www.deutche-boerse.com and www.eurexchange.com. They use VMS and are still waiting for other systems to catch up!!!!
No, technical deployment is usually the the least of my worries. The problem with deployment from the management perspective is whether we believe that the company can support as needed for the lifetime of the system. We do get a lot of small systems in for the business but then the business manager signs-off on the waiver. In the case of infrastructure technology, it becomes down to the responsibility of the CTO and if it isn't mainstream, he (he usually is a 'he') won't like the risk when he is halled over the coals for the failure of a major system. With the big databases, Oracale, SyBase or even MS SQL, you can simply say that 'I chose a system already widely deployed in banking'. Having Sun there doesn't mean they bring anything technical to the table, but just there name amkes it a whole lot more acceptable.
The banks are really allergic to deploying stuff from smaller vendors. The CTO in a bank tends to be really risk averse (yes, strange whilst his colleagues are pissing the bank's money away on dodgy loans and derivatives). It has been very difficult to deploy Linux but it has sort-of become possible over the years (typically RHEL or sometimes SUSE). Personally, I can see the benefit of major databases, but they get expensive when what you are looking for is a light-weight data store and you really don't want the overhead of an enterprise database. Sun is still big and they still sell a lot of backend servers in banks.
I have worked at a lot of big banks. Open Source has been slowly finding its way in, but it is incredibly difficult to deploy an open source database like MySQL or Postgres. The banks says they want safety and security - and you answer that your database isn't enterprise critical so why pay for Oracle? Management then says, ah well, how about MS SQL Server....
Most corporates buy their Microsoft software through volume agreements. This means that license fees are a recurring cost rather than one-time. The only place where MS really does seem to have the upperhand is slightly better management/rollout and more functionality (which 70% of users don't use anyway).
Yes, Java has some good points and the class libraries can be a real time saver but I still don't particularly like it for high computational or processing volumes. I would certainly agree that Java is more flexible and delivers sooner but when your problem domain is well defined then C/C++ is still a valid solution. Java can be quite fast now, but particularly across multiple processors a language that gives you more control can be better.
I can't quite remember the size of their Grid but it was B I G. I/O was a problem though because once you calculated it at book level, the books could be formed into multiple hierarchies, i.e., business line, legal entity, etc. That was very much a hash and remash of the original data. Yes, they were overdoing the cursors and locking as that is the most obvious way to handle a database.
As different business desks were responsible for fixing different data sets, each could take a snapshot of the data nodes and recalculate their data without having dependencies on anyone else. Unfortunately it was still one database and the relational model isn't that well suited to the problem. If the different risk desks reran their snapshots at the same time, there would still be contention both for processors and the database.
Frankly, under very high load conditions, I would have kicked out the database management software (as is done at some exchanges such as Eurex). Matching takes place using a database of flat files (either memory or disk based depending on expected trading volume) with journalling where needed.
The thing is that even with shaving 50% off their run times, it didn't save them from that fact that if North America delivered data late because of timezone issues and their FO/MO systems consistently screwed up the batches that produced the source positions then perhaps it is better to worry about how data is produced and then to look at beefing up performance. The problem was that FO IT and Risk IT were seperate departments so it was politically different for one to place requirements on the other.
From an administrative perspective, a much smaller bank had taken over a large UK bank a few years back and the fault-lines were still quite visible, particularly when their UK office is telling an office originally part of the larger bank several thousand km away. The funny thing is they have now taken on another European bank, even if they manage the quick integration of their desks, the bank they acquired has many more books to run. It shouldn't be an IT problem, but one of the reasons for the acquisition is the rationalisation of trading infrastructure.
I had the 'pleasure' of starting on some very slow machines at University. It was all we had, but it did make you think about performance. We may not have studied much on performance but when you had a CPU clocked in KHz and batch jobs were CPU limited (Yes, I guess I'm a bit older than you) then you learned to think about performance. I guess the best training now are the students doing robotics such as the DARPA challenge people in the states where you have a problem to solve and the speed of your vehicle depends on how quickly you can do that.
I was working on a little project up at angel (you probably know the client) where they were having problems calculating their VaR in a timely manner. From a technical viewpoint, they could have junked Java and their Sybase database, but that would have cost a lot of effort. They had some good developers but no defect or release management and since people had little outside experience, nobody saw this as wrong.
Interesting idea. It could also save on parking. Why have so many parking spaces when a car doesn't spend all day parked outside the office? One of the problems though is that many people regard a car as a private thing.
Yes, but I don't minds so much when my MP3 player crashes (Microsoft do not do safety-related systems other than GPS).