... Uhh, durr, how would you like it if your neighbor just built a tall treehouse in his yard and stared at your house all day! These treehouses have to be regulated!
Not quite a proper analogy. There is a natural restriction on the number of neighbours you have, which reduces the risk of somebody watching you and makes it difficult for non-neighbours to peep into your garden. With drones you can do your peeping from a public road or maybe even from home. The laws in many (most?) countries make it illegal for people to look into your property and outlaws publication of pictures of your property and people there taken without your consent. If a neighbour invades your privacy and you see it, you know who to pursue, whereas a drone could be impossible to trace.
Think about the consequences if drones become ubiquitous, cheap and long range: Lindsay Lohan (replace name with any suitable celebrity) would not be able to get a tan in her back yard with the drones flitting around and covering the sun.
Either place may lack a proper, always-on Internet connection, but why should that stop the people from enjoying a game on their console?
For a number of reasons, my next "laptop" will be a 10-inch-ish tablet with high density display:
* It is easier to transport.
* It is lighter.
* It is better suited to read E-books on (and I have quite a few I would like to read in PDF format, like Linux Journal).
* It can be used to watch videos on.
* It can be used for VoIP (SIP, Skype, you-name-it,
* It can be used for E-mail.
* It can be used for smaller, business-related jobs like editing a document or creating a spreadsheet.
* It will be able to hold about a week's worth of multimedia consumption (i.e. videos, music and books).
* It will hopefully have a very long battery life. (12+ hours would be ideal!)
So, in order of preference:
* Better battery life.
* Higher density display.
* High capacity storage.
* Sunlight-readable display.
For the occasions where I need a keyboard, a good quality, lightweight Bluetooth keyboard would suffice and I could live with the point and tap interface.
I back up to my friend's server abroad via rsync. This server (which is also my main mail server) backs up to my brother's server (the backup mail server) with a Time Machine-like perl script so I have generations of backup available on my brother's system. (It is a deliberate choice not to have generations of data available on my friend's system.) My brother backs this server up to a NAS appliance, which makes my historical data slightly more vulnerable than my active data, being in one location only.
I have a local backup on an external harddisk, to make any immediate recovery quicker — I am going to upgrade this soon with more capacity and implement my Time Machine-like functionality on it.
My brother's own data and my friend's are similarly distributed to each other and to me.
In this, somewhat convoluted system, I have a pretty robust backup-scheme — and I cannot wait until my ISP runs fibre optics to my house, promising speeds well above 50Mbps down and 15Mbps up.
I never got any of the late payment penalty invoices paid though - they never pay late payment fees as a corporate policy, I was told.
Thank you so much!
Programming is a mix of skills ranging from "language" skills, where the programmer needs to understand:
- The syntax of the programming language
- The semantics of the programming language
The programmer also needs to know how to "interface" and thus understand:
- The interaction with the OS
- The interaction with storage systems
- The interaction with networking systems
- The interaction with the presentation layer (this includes communicating with the user)
- The limitations of each subsystem
And lastly the programmer has to solve the problem and therefore needs to understand:
- The problem
- The solution
- The different ways of achieving the solution and select the best in the circumstances
- What can go wrong at every step and catch each possible error in a meaningful way that does not break the functionality
On top of this, any seasoned programmer knows a number of "tricks", methods and algorithms, and can select the best for the current job. The list is probably not even complete, but the best I could do at short notice.
Many of the above skills can be learned, but some are just beyond many, if not most, people like understanding the semantics of the programming language (Perl is notorious in this respect) and the intricacies of the interaction with the subsystems (like how a program can fail miserably when ported from *NIX-type systems where filenames are case sensitive to Windows where they are not), to name two. And coming up with a solution to even simple problems is impossible for many -- believe me, I have seen quite a few failing. What can go wrong and how to catch it is a challenge for even the most seasoned programmer -- it is near-impossible to learn this if you do not have the "gift".
Best practice is to encrypt each record with a unique key. This key could be generated by some unique identifiers per user like Visible User ID (maybe E-mail address) and Password and Hidden User ID (different from the visible and generated independently from it) and Android ID.
To create the database entry:
1. Collect the information to store
2. Key = Hash(Visible User ID, Password, Hidden User ID, Android ID)
3. Send Visible User ID and Key to a receive-only system with as little an Internet Surface as possible (i.e. one that is next to impossible to hack into, if done correctly) -- This information is used retrieve the user data for analysis and such
4. Store the information in the more accessible database encrypted with the key
To retrieve the data from a user's application:
1. Collect Visible User ID, Password, Hidden User ID and Android ID
2. Key = Hash(Visible User ID, Password, Hidden User ID, Android ID)
3. Use the key to retrieve the necessary data
To retrieve the data from the inside:
1. Use the User ID to Key data to decrypt the data
What I really wanted to say was commercial Space Travel with Space Hotels, but that was not an option, so Underwater City got my vote, which is not too bad either as I have always been fascinated with living under water.
That said, I worked for a short while as a consultant on a survey ship in connection with oil exploration. As you were confined to the ship for as long as you were on-board (obviously), they had made it twelve hour shifts, 8 to 8. That worked quite well as they had two weeks on-board and two weeks off. Two weeks at home with the family. So not only was the pay good, but the compensation for the family "deprivation" was sufficient to actually keep people interested.
I had an experience with really long working hours when another customer of mine had a problem: An employee had made a circuit board as an extension to their office computer and the company had a commitment to install this board before the end of the week, only it did not work! I worked for more than 40 hours straight to make the board work and presented the working board and updated software in the morning to a manager, who just said, "OK, drive out to the customer and install it." I politely declined, telling him that I was not driving anywhere in my condition. In the end the manager chauffeured me there and back, and the installation was a success.
There were times during the nights where I was doubting I would ever get through and it was not top productivity all the time, that is for sure -- but on the other hand, the company was generally extremely supportive and still on my top-five list of companies I have had as customers.
I know that computers today are magnitudes faster than the early days and that most western households have more computing power in their house than was available in the whole world some fifty years ago, but the problems we try to solve have grown even further and yet we expect the response times to be reasonable for everything we want to do.
One problem that just came to mind is navigation: That little box on the windscreen is actually searching through millions of roads to find the optimum route between two points and still we expect it to take less than a minute.
I am afraid that the boxes of punched cards have been lost some years back and I am working (very slowly) on a new version using a more recent programming language, Perl.