Isaac Asimov (the creator of the three laws of robotics) actually added a fourth, which took precedence over the other three -- and that law is the scary one that basically allows anything to happen:
0. A robot may not harm humanity, or, by inaction, allow humanity to come to harm.
Think about it: If, as the "robots" see it (i.e. are programmed), NOT killing a few gazillion people would harm humanity -- well, then we'd better kill them! No?
The morale of this: You cannot program morals! (At least not easily.)
My experience from a similar situation is that the most expensive part of a cloud-based solution is the data traffic cost. I had to choose a hosted solution with unlimited Internet bandwidth, which came out much cheaper than a cloud-based solution. I must say, though, that the system had a constant high level of traffic independent on the number of users.
If you virtualise from get go, you should be able to choose whatever solution is the cheapest at any time by moving your image around.
OK, I am going to kill whatever goodwill (and karma) I may have had with these statements:
* I actually liked Jar Jar Binks -- he was the not so bright, but well-meaning, comic sidekick
* I think Jake Lloyd performed much better than Hayden Christensen
* I think the chemistry between Natalie Portman and Hayden Christensen was as hot as the chemistry between gold and nitrogen at 0 Kelvin
* I do not think that Anakin's shift from good to evil is very convincing
But no matter what, the movies are not worth another ticket to me, 3D or not.
Following Sony's rise and fall is rather interesting, I think.
They started off by making tape recorders and became famous by producing small, transistorised radio receivers that were affordable but rather poor quality. I remember my first one that after a few months developed the most scratchy volume control (metal wiper on a carbon path -- I took it apart in the end).
After WWII (not, I'm not that old:-) the Americans introduced the quality movement in Japan and in 1968, Kaoru Ishikawa outlined the tenets of TQC (Total Quality Control) management:
* quality comes first, not short-term profits
* the customer comes first, not the producer
* customers are the next process with no organizational barriers
* decisions are based on facts and data
* management is participatory and respectful of all employees
* management is driven by cross-functional committees covering product planning, product design, production planning, purchasing, manufacturing, sales, and distribution
Akio Morita, the founder of Sony, was a proponent of this quality movement and worked hard to make Sony products fairly affordable and good quality, which was the hallmark of their products for many years.
After Morita's brain hemorrhage in 1993, he was unable to lead the company and stepped down as chairman in 1994, at the height of the company's glory. After that time, Sony seemed to slide slowly downwards in its respect of customers with a marked disregard for the second tenet of the TQC "laws".
Sony has been -- and still is -- very innovative, but they have gone down the slope quite a bit since Akio Morita's time with regards to affordability and respect for customers.
I think Slashcode should auto-detect these idiotic URL shorteners and either just refuse to accept them like it does for "all caps" posts and the like or preemptively down-mod the post by 2 points at least...
... or follow them and display the final addresses instead?
Whatever I need to keep hidden (passwords, PIN codes,...) in KeePass.
Meetings, birthdays, days to put the rubbish out and whatever else time related in my calendar(s). I actually have a few calendars on computers and phones that I keep synchronised.
Names, addresses, telephone numbers, E-mail addresses, etc. in my contact list on my phone. I synchronise this with my other systems too.
Everything else goes in a hierarchy on the file server: Anything trade related, for example, in a trade folder organised by date, provider and type (receipts, contracts, proposals, warranties, policies, terms & conditions,...). Anything related to my children's schools in a school folder. Recipies, downloaded literature, programs, photos... And so on.
I find this system works well for me and I can always find things (sometimes to my wife's surprise;-) even several years later.
Many years ago I worked at a mainframe installation (IBM S/360 to give you an idea of my age;-). The computer was installed at the back of a huge room with plenty of space for expansion. For some incomprehensible reason BRBs (Big Red Buttons) were placed along the skirting board every ten feet or so, which had hitherto not been a problem -- with all the space nobody came near during daily (and nightly) operations.
Every morning at around two AM a guy came with a load of cassettes containing cheques from the banks for clearing. He usually just opened the door to the room and shoved each cassette in to slide, like curling stones, across the floor to the cheque sorter.
And one morning, well... A cassette decided to slide all the way across the room and unerringly triggered one of the BRBs square on. Half a night's work to be redone.
I would have thought the studios would consider this a "trade secret";-)
On a more serious note: I hope the studios will not reduce their games to cater only for the 90% as most gamers love the possibilities in a game and would probably not buy a "limited" game. (Just like I love a good tool, despite using it only once or twice.)
It is about time that somebody (hopefully some of the commercial vendors AND the open source community too) get wise to the problems of digital storage.
I always create files with unique headers and consistent version numbering to allow for minor as well as major file format changes. For storage/exchange purposes, I make the format expandable where each subfield/record has an individual header with a field type and a length indicator. Each field is terminated with a unique marker (two NULL bytes) to make the format resilient to errors in the headers with possible resynchronisationthrough the markers. The format is in most situations backward compatible to a certain extent as an old program can always ignore fields/subfields it does not understand in a newer format file. If that is not an option, the major version number is incremented. This means that a version 2.11 program can read a version 2.34 file with only minor problems. It will not be able to write to that format, though. The same version 2.11 program would not be able to correctly read a version 3.01 file either.
I have not implemented ECC in the formats yet, but maybe the next time I do an overhaul... I will have to ponder that. Maybe not, my programs seem to ephemeral for that... Then again, so did people think about their 1960es COBOL programs.
Well, not the author in person, but his book, The Street Lawyer. Paperback version.
I would have been rather more reluctant to do the same with a Kindle (or equivalent) edition, as I am pretty sure a dip in the water would render it beyond repair.
I cannot be the only one who occasionally loses a paperback to whatever unfortunate events that pass me by. (Temporary insanity and such.) I have provided Dublin Airport with one (I got my camera back, which had been impounded by security guards), an assortment of hotels, planes and trains have got their share and for some odd reason I have never found my lost PDA. (The interesting stuff was encrypted, thank you very much.)
The thing for me (and quite a few other people, I am sure) is that the loss of a paperback may be unfortunate but not a major setback, whereas the loss of an eBook reader is more than just annoying.
It seems that the p-System -- the underlying OS for UCSD Pascal -- is no more.
It had a number of features like direct feed-back from the compiler to the editor, highlighting lines in error, which was a major step forward, especially for me, as I had done most of my programming on my Apple ][ in 6502 assembler. (Digression: Steve Wozniak is a genius in my humble opinion.)
UCSD Pascal was unique in the way that it compiled to pseudo-code (p-code, why does that make me think of Java?) and was mostly written in p-code itself, apart from machine-dependent parts.
Other "features" made the system a bit quirky, like contiguous files only, which meant you had to pre-allocate space for files if you wanted to write to more than one on a disk.
But hey, I could exercise my theoretical knowledge, gleaned from Niklaus Wirth's Pascal book (red and white and from Springer Verlag) on my Apple!
Has anybody actually checked their calculations????
I just eyed the numbers and it seems to be off by three orders of magnitude; they estimate the energy collection to be about 9.19 Billion Kilowatts -- am I wrong or does the calculation actually give 9.19 Trillion Kilowatts????
And they say they calculate ((25,000 mi^2) x (5280 ft / mi)^2) / (200W/15.16 ft^2) but do in fact calculate ((25,000 mi^2) x (5280 ft / mi)^2) x (200W/15.16 ft^2) -- which they should.
Not very assuring, is it?... Or rather, WOW!, with only an efficiency of 0.015% we can still supply USA three times over... Or, with 15% efficiency, a fifteenth of the world consumption (2005 numbers, total world energy consumption 500 exajoules = 5 x 10^20 J or about 139 x 10^12 kWh divide into output, 9.19 x 10^12 kWh, and voila roughly 1/15).
This is probably a rehash (pun intended:-) of other people's answers, but all the same, I cannot help myself...
My best programming work is done in a drawing application like Inkscape or Visio.
Long before the first line of code is committed to the harddisk, I have (bar for the simplest of programs) made one or more drawings depicting the interrelations between the modules of the program I am making. Not only does this ensure a modular approach to the problem solving, but it also gives a nice documentation to present to other people. With a bit of verbal grease (knowing me, people would probably say: verbiage), it often makes it possible for me to explain to non-technical people, how the program is supposed to work and that I have ensured scalability, usability... or whatever other -ability the customer wants.
The selection of the actual program language for implementation comes later and is often based on other parameters, like Perl for quick (and often "dirty") solutions that need pattern matching, associative arrays and object orientation, PHP if the solution is not too heavy on pattern matching and associative arrays but is web-oriented, C (or C++ or C#) if I need a fast and efficient solution without (too much) pattern matching and associative arrays, COBOL for one of my customers, who uses no other language (oh yes, they DO exist!)...
Sometimes the language is given by the customer, based on whatever capability the customer's organisation has. I honestly do not care. I can program in most major languages like {patting my shoulder} ALGOL, FORTRAN, COBOL, RPG, APL, Ada, COMAL, Simula, BASIC (that covered most of my teenage years and early twenties), assembler (IBM, x86, 6502, M6800, M68000, RCA1802,... -- that covered some of my first grey hairs), Pascal, C, C++, C#, Java, JavaScript, Perl, PHP, Ruby, Python, and whatever languages I have forgotten (like FORTH, LISP and Prolog). Most of these languages (being functional) are basically the same with slightly different syntax and semantics. Some of the languages are radically different like FORTH (reverse Polish notation made into a programming language), LISP (List processing) and Prolog, where you basically tell the computer what you want, not how you want it done. (I cannot wait until quantum computers gives Prolog or a similar derivative a new lease of life.)
So (at long last) the conclusion is: The method is much more important than the programming language. The more you know the better prepared you are for whatever an employer (or customer) may throw at you. And I cannot count the number of times I have created a quick proof of concept in Perl, only to have it programmed in some other language for actual implementation.
Remember, programming languages can be taught, programming can not. (OK, do not flame me! I do know, some programming can be taught, but the most elegant and efficient programming is more akin to creating mathematical proofs or composing beautiful poems or painting stunning pictures, an art, not a craft!)
The Many Layers of Complexity
on
IT and Health Care
·
· Score: 5, Insightful
As always this is a relatively simple problem wrapped in layers of -- to a certain extent unnecessary -- complexity.
The simple idea is to have a system that records the patients history of illnesses and treatment (including medication, obviously) and which is easily communicated across different places of diagnose and treatment (GP, specialists, consultants, hospitals,...).
This specific problem could easily be solved with standard software like Lotus Notes, Microsoft SharePoint and similar systems, but that is where the simplicity stops and the layers of complexity start.
Sorry if I am going down a well-travelled trail here.
Firstly, it is very difficult to get people and organisations to standardise on a single system for good and for bad reasons. (Like "We've already got Lotus Notes, why should we get a Microsoft product?" -- plug in whatever conflicting product/system names you can think of.) This means that a single system probably is out of the question, which leaves us with a standardised interchange format instead.
OK, now we have a gazillion systems happily exchanging information in a standardised format, so everybody is happy, right?
Wrong!
Because secondly, who is responsible for the safekeeping of the data? This is two-fold: Who is responsible for storing the data and who is responsible for who has access to the data?
So 2a, Responsibility for storing the data: If every place of diagnose and treatment is responsible for storing own data, how can a patient be sure that any specific institution treating her has access to all the information? This needs some centralised storage or at least "mediating" (much like peer-to-peer systems, e.g. torrents, need a "meeting place", like The Pirate Bay, where they can find the trackers so they know where to find the peers). Either system suffers from the problem of connectivity dependence, i.e. if they cannot get access to either the storage, the "mediator" or the peers, information cannot be retrieved. This is still better than paper-based systems, if you are treated in different places, geographically.
This leads to 2b, Responsibility for who has access to the data: I would obviously like for my GP to send information directly to the hospital and for the nurses, doctors, consultants and surgeons treating me to see my records, but -- being the famous person, I am... not -- I would be quite weary if just about anyone could look at my records. How is this problem solved?
Thirdly, who would be responsible for correcting errors and mistakes in the records? This problem is not really an issue relating only to electronic records, but is a general issue, which crops up all the time. Should you, as the patient, be allowed to correct mistakes you know about? If that is the case, how do the professionals make sure that you are not trying to tamper with the system for some ulterior motive (everything from trying to cover medical problems for insurance purposes to hypochondria)? If you are not allowed to correct mistakes, how do you tell them that you did not receive a certain medication two years ago and, in fact, is allergic to it?
Fourthly, a system relying on doctors, specialists and consultants to type would probably be doomed, at least for now. It seems that doctors, etc. at all the hospitals I have seen, rely on dictation, having a pool of secretaries typing it in and updating the records, which introduces unnecessary delays and adds an extra risk of introducing errors.
These are some of the many problems facing such a system and I am sure I have left out many, just as relevant. I honestly do not believe that the fear of transparency regarding the treatment is the major stumbling block for the introduction of electronic medical records, but rather the diverse types of problems facing the system.
I was not trying to imply anything about the cause(s) of the tragic crash of A447, rather about the complexity of the system and what that means.
Many years ago (before GPS) i developed a navigation system for a customer, based on the at that time available positioning systems (like Pulse/8, Syledis, and active and passive Decca). The system was used in a surveillance ship and had to plot a route to follow and to show the position of the centre of mass of the ship in relation to the desired position, which meant that I had to get input about pitch, yaw and roll as well as the positions from the different positioning systems.
Due to a number of factors, it was far from straightforward as the sensor readings could be noisy (I once had a nightlong discussion with the First Officer about a problem with the gyro, which the FO claimed couldn't be malfunctioning as it was a Robinson Gyro -- but it was, malfunctioning, that is), the readings from each navigation system would vary from the actual position and the ship would roll up to 45 degrees to each side due to severe weather.
My job then was a difficult task and what I am trying to say is that it is probably orders of magnitude more difficult for a system like the Airbus and thus much more prone to errors, human as well as technical.
The computers may be multiple redundant with graceful degrading of performance in case of failures and may try to guard the plane from the pilots (like preventing the pilot from decreasing speed to below stall-level or performing manoeuvres that would jeopardize the plane or its passengers), but the system is dependent on input from sensors and, if I remember correctly, Airbus has had a number of problems with sensors and I just read that Air France are going to replace all airspeed sensors and that pilots should refuse to fly unless two of the three airspeed sensors have been replaced.
Multiple redundant systems do not change the GIGO (Garbage In, Garbage Out) principle.
When does the policymakers (and the public) realise that death from terrorism is negligible compared to other (more or less) avoidable causes.
How many lives could be saved in the USA alone by free flu vaccines? How many are killed from gun-related shootings? Traffic deaths?... Come on, terrorism is hardly noticeable in the big scheme of deaths.
We do not need much airport security, really. Just think about the time, when you could board a plane without being checked, double checked and then frisked. Do not just take my word for it, Bruce Schneier has mentioned it several times, including here.
"Microsoft was accused of preying on Borland's staff and hiring them away"
I do not know if Microsoft preyed on Borland's staff, but it is a fact that the creator of Turbo Pascal (a fellow Dane) Anders Hejlsberg is now employed by Microsoft and is lead architect of C#.
You are so absolutely right... only I spend too much time in airplanes, and so far no one have allowed me to drag out my 3G-based network card and use it on board.
To boot, some of the companies I work for have not got a proper VPN setup either, thus preventing that approach! (Bummer, that.)
Regarding loss of data, I carry a copy of all essential files (encrypted, naturally) on a diminutive USB-drive, which I keep on me at all times. (Please don't tell the people at the airport security control!) Furthermore I unload data to my clients' servers, whenever I can (at least I am not responsible for their security:-). To facilitate the backup to the USB drive, I have some homegrown scripts (did I hear somebody groan?) that automatise everything, apart from entering a password now and again.
Oh and I have not lost any data yet (apart from computer or software breakdowns while entering data before backup like when Windows does a BSOD after I have composed a masterpiece of a report) in my almost forty years of working with computers.
All of this does not change the fact that you are right: Whenever possible keep your data in a secure environment and access it remotely through a VPN tunnel.
I work as a contractor for a number of companies and need to take sensitive data home (like their customer contracts, proposals, etc.) on my laptop.
To make sure I do my best to keep their data away from others (especially since I travel a lot), I encrypt twice. First I encrypt the hard drive (before booting the OS) and then I encrypt the individual customer's files in separate "containers".
Truecrypt has a nice feature for its encryption of containers (I use files with uninformative names like turbo.dat, haiku.wav, just for the fun of it) that it will automatically unmount the containers when the computer is put into sleep mode or hibernation, which means that no customer data is accessible when I am travelling.
And regarding common sense: I do not keep any unecessary data on my laptop. I do not copy unneeded data to it and I remove all unneeded data immediately. I keep the different customer's data in separate cointainers and do not open different customer's containers at the same time to reduce the exposure, should somebody steal the laptop from my hands. I keep it locked to a big object whenever I work at a fixed place for some time and always before I leave it out of sight. I lock the screen every time I leave it.
And guess what? It doesn't take too much time either.
As much as I love government bashing, this seems to be an overreaction to a small section of the letter that DHS employee
Paul S. Ruwaldt (PDF) sent.
Basically, he says that this bracelet is a good idea for the temporary detention of suspected illegal aliens and/or criminal elements and expands on this as well as other similar uses.
The only mention of use in planes is "... it is conceivable to envision a use to improve air security, on passenger planes."
No mention of "collaring" the whole plane -- and, well, no mention on how it could improve air security either.
Slashdot Mirror
Does not mean you must.
This goes for about anything you can think of, not just the invasion of privacy.
Isaac Asimov (the creator of the three laws of robotics) actually added a fourth, which took precedence over the other three -- and that law is the scary one that basically allows anything to happen:
0. A robot may not harm humanity, or, by inaction, allow humanity to come to harm.
Think about it: If, as the "robots" see it (i.e. are programmed), NOT killing a few gazillion people would harm humanity -- well, then we'd better kill them! No?
The morale of this: You cannot program morals! (At least not easily.)
What's more to say?
My experience from a similar situation is that the most expensive part of a cloud-based solution is the data traffic cost. I had to choose a hosted solution with unlimited Internet bandwidth, which came out much cheaper than a cloud-based solution. I must say, though, that the system had a constant high level of traffic independent on the number of users.
If you virtualise from get go, you should be able to choose whatever solution is the cheapest at any time by moving your image around.
OK, I am going to kill whatever goodwill (and karma) I may have had with these statements:
* I actually liked Jar Jar Binks -- he was the not so bright, but well-meaning, comic sidekick
* I think Jake Lloyd performed much better than Hayden Christensen
* I think the chemistry between Natalie Portman and Hayden Christensen was as hot as the chemistry between gold and nitrogen at 0 Kelvin
* I do not think that Anakin's shift from good to evil is very convincing
But no matter what, the movies are not worth another ticket to me, 3D or not.
Following Sony's rise and fall is rather interesting, I think.
:-) the Americans introduced the quality movement in Japan and in 1968, Kaoru Ishikawa outlined the tenets of TQC (Total Quality Control) management:
They started off by making tape recorders and became famous by producing small, transistorised radio receivers that were affordable but rather poor quality. I remember my first one that after a few months developed the most scratchy volume control (metal wiper on a carbon path -- I took it apart in the end).
After WWII (not, I'm not that old
* quality comes first, not short-term profits
* the customer comes first, not the producer
* customers are the next process with no organizational barriers
* decisions are based on facts and data
* management is participatory and respectful of all employees
* management is driven by cross-functional committees covering product planning, product design, production planning, purchasing, manufacturing, sales, and distribution
Akio Morita, the founder of Sony, was a proponent of this quality movement and worked hard to make Sony products fairly affordable and good quality, which was the hallmark of their products for many years.
After Morita's brain hemorrhage in 1993, he was unable to lead the company and stepped down as chairman in 1994, at the height of the company's glory. After that time, Sony seemed to slide slowly downwards in its respect of customers with a marked disregard for the second tenet of the TQC "laws".
Sony has been -- and still is -- very innovative, but they have gone down the slope quite a bit since Akio Morita's time with regards to affordability and respect for customers.
I think Slashcode should auto-detect these idiotic URL shorteners and either just refuse to accept them like it does for "all caps" posts and the like or preemptively down-mod the post by 2 points at least...
I organise my information in four ways:
...) in KeePass.
...). Anything related to my children's schools in a school folder. Recipies, downloaded literature, programs, photos ... And so on.
;-) even several years later.
Whatever I need to keep hidden (passwords, PIN codes,
Meetings, birthdays, days to put the rubbish out and whatever else time related in my calendar(s). I actually have a few calendars on computers and phones that I keep synchronised.
Names, addresses, telephone numbers, E-mail addresses, etc. in my contact list on my phone. I synchronise this with my other systems too.
Everything else goes in a hierarchy on the file server: Anything trade related, for example, in a trade folder organised by date, provider and type (receipts, contracts, proposals, warranties, policies, terms & conditions,
I find this system works well for me and I can always find things (sometimes to my wife's surprise
Many years ago I worked at a mainframe installation (IBM S/360 to give you an idea of my age ;-). The computer was installed at the back of a huge room with plenty of space for expansion. For some incomprehensible reason BRBs (Big Red Buttons) were placed along the skirting board every ten feet or so, which had hitherto not been a problem -- with all the space nobody came near during daily (and nightly) operations.
... A cassette decided to slide all the way across the room and unerringly triggered one of the BRBs square on. Half a night's work to be redone.
Every morning at around two AM a guy came with a load of cassettes containing cheques from the banks for clearing. He usually just opened the door to the room and shoved each cassette in to slide, like curling stones, across the floor to the cheque sorter.
And one morning, well
I would have thought the studios would consider this a "trade secret" ;-)
On a more serious note: I hope the studios will not reduce their games to cater only for the 90% as most gamers love the possibilities in a game and would probably not buy a "limited" game. (Just like I love a good tool, despite using it only once or twice.)
It is about time that somebody (hopefully some of the commercial vendors AND the open source community too) get wise to the problems of digital storage.
... I will have to ponder that. Maybe not, my programs seem to ephemeral for that ... Then again, so did people think about their 1960es COBOL programs.
I always create files with unique headers and consistent version numbering to allow for minor as well as major file format changes. For storage/exchange purposes, I make the format expandable where each subfield/record has an individual header with a field type and a length indicator. Each field is terminated with a unique marker (two NULL bytes) to make the format resilient to errors in the headers with possible resynchronisationthrough the markers. The format is in most situations backward compatible to a certain extent as an old program can always ignore fields/subfields it does not understand in a newer format file. If that is not an option, the major version number is incremented. This means that a version 2.11 program can read a version 2.34 file with only minor problems. It will not be able to write to that format, though. The same version 2.11 program would not be able to correctly read a version 3.01 file either.
I have not implemented ECC in the formats yet, but maybe the next time I do an overhaul
Today I had a nice, long bath with John Grisham.
Well, not the author in person, but his book, The Street Lawyer. Paperback version.
I would have been rather more reluctant to do the same with a Kindle (or equivalent) edition, as I am pretty sure a dip in the water would render it beyond repair.
I cannot be the only one who occasionally loses a paperback to whatever unfortunate events that pass me by. (Temporary insanity and such.) I have provided Dublin Airport with one (I got my camera back, which had been impounded by security guards), an assortment of hotels, planes and trains have got their share and for some odd reason I have never found my lost PDA. (The interesting stuff was encrypted, thank you very much.)
The thing for me (and quite a few other people, I am sure) is that the loss of a paperback may be unfortunate but not a major setback, whereas the loss of an eBook reader is more than just annoying.
It seems that the p-System -- the underlying OS for UCSD Pascal -- is no more.
It had a number of features like direct feed-back from the compiler to the editor, highlighting lines in error, which was a major step forward, especially for me, as I had done most of my programming on my Apple ][ in 6502 assembler. (Digression: Steve Wozniak is a genius in my humble opinion.)
UCSD Pascal was unique in the way that it compiled to pseudo-code (p-code, why does that make me think of Java?) and was mostly written in p-code itself, apart from machine-dependent parts.
Other "features" made the system a bit quirky, like contiguous files only, which meant you had to pre-allocate space for files if you wanted to write to more than one on a disk.
But hey, I could exercise my theoretical knowledge, gleaned from Niklaus Wirth's Pascal book (red and white and from Springer Verlag) on my Apple!
Drat!
:-(
I caught one error only to trip up later
Has anybody actually checked their calculations????
... Or rather, WOW!, with only an efficiency of 0.015% we can still supply USA three times over ... Or, with 15% efficiency, a fifteenth of the world consumption (2005 numbers, total world energy consumption 500 exajoules = 5 x 10^20 J or about 139 x 10^12 kWh divide into output, 9.19 x 10^12 kWh, and voila roughly 1/15).
I just eyed the numbers and it seems to be off by three orders of magnitude; they estimate the energy collection to be about 9.19 Billion Kilowatts -- am I wrong or does the calculation actually give 9.19 Trillion Kilowatts????
And they say they calculate ((25,000 mi^2) x (5280 ft / mi)^2) / (200W/15.16 ft^2) but do in fact calculate ((25,000 mi^2) x (5280 ft / mi)^2) x (200W/15.16 ft^2) -- which they should.
Not very assuring, is it?
This is probably a rehash (pun intended :-) of other people's answers, but all the same, I cannot help myself ...
... or whatever other -ability the customer wants.
...
... -- that covered some of my first grey hairs), Pascal, C, C++, C#, Java, JavaScript, Perl, PHP, Ruby, Python, and whatever languages I have forgotten (like FORTH, LISP and Prolog). Most of these languages (being functional) are basically the same with slightly different syntax and semantics. Some of the languages are radically different like FORTH (reverse Polish notation made into a programming language), LISP (List processing) and Prolog, where you basically tell the computer what you want, not how you want it done. (I cannot wait until quantum computers gives Prolog or a similar derivative a new lease of life.)
My best programming work is done in a drawing application like Inkscape or Visio.
Long before the first line of code is committed to the harddisk, I have (bar for the simplest of programs) made one or more drawings depicting the interrelations between the modules of the program I am making. Not only does this ensure a modular approach to the problem solving, but it also gives a nice documentation to present to other people. With a bit of verbal grease (knowing me, people would probably say: verbiage), it often makes it possible for me to explain to non-technical people, how the program is supposed to work and that I have ensured scalability, usability
The selection of the actual program language for implementation comes later and is often based on other parameters, like Perl for quick (and often "dirty") solutions that need pattern matching, associative arrays and object orientation, PHP if the solution is not too heavy on pattern matching and associative arrays but is web-oriented, C (or C++ or C#) if I need a fast and efficient solution without (too much) pattern matching and associative arrays, COBOL for one of my customers, who uses no other language (oh yes, they DO exist!)
Sometimes the language is given by the customer, based on whatever capability the customer's organisation has. I honestly do not care. I can program in most major languages like {patting my shoulder} ALGOL, FORTRAN, COBOL, RPG, APL, Ada, COMAL, Simula, BASIC (that covered most of my teenage years and early twenties), assembler (IBM, x86, 6502, M6800, M68000, RCA1802,
So (at long last) the conclusion is: The method is much more important than the programming language. The more you know the better prepared you are for whatever an employer (or customer) may throw at you. And I cannot count the number of times I have created a quick proof of concept in Perl, only to have it programmed in some other language for actual implementation.
Remember, programming languages can be taught, programming can not. (OK, do not flame me! I do know, some programming can be taught, but the most elegant and efficient programming is more akin to creating mathematical proofs or composing beautiful poems or painting stunning pictures, an art, not a craft!)
As always this is a relatively simple problem wrapped in layers of -- to a certain extent unnecessary -- complexity.
...).
... not -- I would be quite weary if just about anyone could look at my records. How is this problem solved?
The simple idea is to have a system that records the patients history of illnesses and treatment (including medication, obviously) and which is easily communicated across different places of diagnose and treatment (GP, specialists, consultants, hospitals,
This specific problem could easily be solved with standard software like Lotus Notes, Microsoft SharePoint and similar systems, but that is where the simplicity stops and the layers of complexity start.
Sorry if I am going down a well-travelled trail here.
Firstly, it is very difficult to get people and organisations to standardise on a single system for good and for bad reasons. (Like "We've already got Lotus Notes, why should we get a Microsoft product?" -- plug in whatever conflicting product/system names you can think of.) This means that a single system probably is out of the question, which leaves us with a standardised interchange format instead.
OK, now we have a gazillion systems happily exchanging information in a standardised format, so everybody is happy, right?
Wrong!
Because secondly, who is responsible for the safekeeping of the data? This is two-fold: Who is responsible for storing the data and who is responsible for who has access to the data?
So 2a, Responsibility for storing the data: If every place of diagnose and treatment is responsible for storing own data, how can a patient be sure that any specific institution treating her has access to all the information? This needs some centralised storage or at least "mediating" (much like peer-to-peer systems, e.g. torrents, need a "meeting place", like The Pirate Bay, where they can find the trackers so they know where to find the peers). Either system suffers from the problem of connectivity dependence, i.e. if they cannot get access to either the storage, the "mediator" or the peers, information cannot be retrieved. This is still better than paper-based systems, if you are treated in different places, geographically.
This leads to 2b, Responsibility for who has access to the data: I would obviously like for my GP to send information directly to the hospital and for the nurses, doctors, consultants and surgeons treating me to see my records, but -- being the famous person, I am
Thirdly, who would be responsible for correcting errors and mistakes in the records? This problem is not really an issue relating only to electronic records, but is a general issue, which crops up all the time. Should you, as the patient, be allowed to correct mistakes you know about? If that is the case, how do the professionals make sure that you are not trying to tamper with the system for some ulterior motive (everything from trying to cover medical problems for insurance purposes to hypochondria)? If you are not allowed to correct mistakes, how do you tell them that you did not receive a certain medication two years ago and, in fact, is allergic to it?
Fourthly, a system relying on doctors, specialists and consultants to type would probably be doomed, at least for now. It seems that doctors, etc. at all the hospitals I have seen, rely on dictation, having a pool of secretaries typing it in and updating the records, which introduces unnecessary delays and adds an extra risk of introducing errors.
These are some of the many problems facing such a system and I am sure I have left out many, just as relevant. I honestly do not believe that the fear of transparency regarding the treatment is the major stumbling block for the introduction of electronic medical records, but rather the diverse types of problems facing the system.
I was not trying to imply anything about the cause(s) of the tragic crash of A447, rather about the complexity of the system and what that means.
Many years ago (before GPS) i developed a navigation system for a customer, based on the at that time available positioning systems (like Pulse/8, Syledis, and active and passive Decca). The system was used in a surveillance ship and had to plot a route to follow and to show the position of the centre of mass of the ship in relation to the desired position, which meant that I had to get input about pitch, yaw and roll as well as the positions from the different positioning systems.
Due to a number of factors, it was far from straightforward as the sensor readings could be noisy (I once had a nightlong discussion with the First Officer about a problem with the gyro, which the FO claimed couldn't be malfunctioning as it was a Robinson Gyro -- but it was, malfunctioning, that is), the readings from each navigation system would vary from the actual position and the ship would roll up to 45 degrees to each side due to severe weather.
My job then was a difficult task and what I am trying to say is that it is probably orders of magnitude more difficult for a system like the Airbus and thus much more prone to errors, human as well as technical.
The computers may be multiple redundant with graceful degrading of performance in case of failures and may try to guard the plane from the pilots (like preventing the pilot from decreasing speed to below stall-level or performing manoeuvres that would jeopardize the plane or its passengers), but the system is dependent on input from sensors and, if I remember correctly, Airbus has had a number of problems with sensors and I just read that Air France are going to replace all airspeed sensors and that pilots should refuse to fly unless two of the three airspeed sensors have been replaced.
Multiple redundant systems do not change the GIGO (Garbage In, Garbage Out) principle.
... and where?
... Come on, terrorism is hardly noticeable in the big scheme of deaths.
It has to stop somewhere.
When does the policymakers (and the public) realise that death from terrorism is negligible compared to other (more or less) avoidable causes.
How many lives could be saved in the USA alone by free flu vaccines? How many are killed from gun-related shootings? Traffic deaths?
We do not need much airport security, really. Just think about the time, when you could board a plane without being checked, double checked and then frisked. Do not just take my word for it, Bruce Schneier has mentioned it several times, including here.
"Microsoft was accused of preying on Borland's staff and hiring them away"
I do not know if Microsoft preyed on Borland's staff, but it is a fact that the creator of Turbo Pascal (a fellow Dane) Anders Hejlsberg is now employed by Microsoft and is lead architect of C#.
Sorry Sir, but it seems that a transistor has gone in the controller circuit and your data cannot be retrieved!
You are so absolutely right ... only I spend too much time in airplanes, and so far no one have allowed me to drag out my 3G-based network card and use it on board.
:-). To facilitate the backup to the USB drive, I have some homegrown scripts (did I hear somebody groan?) that automatise everything, apart from entering a password now and again.
To boot, some of the companies I work for have not got a proper VPN setup either, thus preventing that approach! (Bummer, that.)
Regarding loss of data, I carry a copy of all essential files (encrypted, naturally) on a diminutive USB-drive, which I keep on me at all times. (Please don't tell the people at the airport security control!) Furthermore I unload data to my clients' servers, whenever I can (at least I am not responsible for their security
Oh and I have not lost any data yet (apart from computer or software breakdowns while entering data before backup like when Windows does a BSOD after I have composed a masterpiece of a report) in my almost forty years of working with computers.
All of this does not change the fact that you are right: Whenever possible keep your data in a secure environment and access it remotely through a VPN tunnel.
I work as a contractor for a number of companies and need to take sensitive data home (like their customer contracts, proposals, etc.) on my laptop.
To make sure I do my best to keep their data away from others (especially since I travel a lot), I encrypt twice. First I encrypt the hard drive (before booting the OS) and then I encrypt the individual customer's files in separate "containers".
Truecrypt has a nice feature for its encryption of containers (I use files with uninformative names like turbo.dat, haiku.wav, just for the fun of it) that it will automatically unmount the containers when the computer is put into sleep mode or hibernation, which means that no customer data is accessible when I am travelling.
And regarding common sense: I do not keep any unecessary data on my laptop. I do not copy unneeded data to it and I remove all unneeded data immediately. I keep the different customer's data in separate cointainers and do not open different customer's containers at the same time to reduce the exposure, should somebody steal the laptop from my hands. I keep it locked to a big object whenever I work at a fixed place for some time and always before I leave it out of sight. I lock the screen every time I leave it.
And guess what? It doesn't take too much time either.
As much as I love government bashing, this seems to be an overreaction to a small section of the letter that DHS employee Paul S. Ruwaldt (PDF) sent.
Basically, he says that this bracelet is a good idea for the temporary detention of suspected illegal aliens and/or criminal elements and expands on this as well as other similar uses.
The only mention of use in planes is "... it is conceivable to envision a use to improve air security, on passenger planes."
No mention of "collaring" the whole plane -- and, well, no mention on how it could improve air security either.