In 1940s-1960s the USA did well - lots of top German and other scientists. Later there was still some discipline, unity and other good stuff leftover from the war. This era you had the Manhattan Project, 747, Apollo project, Douglas Engelbart's Mother of all Demos. Plenty of great things done.
1970s onwards the USA had the petrodollar. Basically the US Gov could create money, transfer a fair bit to the citizens (directly or indirectly via large projects like the continuing interstate highway project) and everyone else around the world with US dollars gets relatively poorer. Repeat as necessary.
2000+ onwards the petrodollar started weakening. Some "rogue" countries started selling oil in Euros. The US Gov created money but arguably didn't help the citizens as much with it. Go look where the created money went instead.
Things may have been great in the past, but the future doesn't look so bright. Not going to change unless the voters change things. But the voters prefer to keep voting for evil or lesser evil, and then complain that they still get evil.
1) Also invaluable are useful logging, logging messages and exception handling.
Those fancy algos, data structures you can find built-in or on google- usually a better programmer has done the work already and using their code/ideas may improve the average quality of your program;). But decent log messages for your own programs? You usually have to write those yourself.
Example of bad error messages: "NullReferenceException: Object reference not set to an instance of an object" Why is that bad? It doesn't tell you which was the offending object. It's like saying "Doctor it hurts!" without saying where or what hurts. In contrast something like this is far more useful: E121: Undefined variable: g:pymode_updatetime
Similar for "file not found/accessible" errors, don't just log that a file was not found/accessible, log the path of the file too.
What I do when performance isn't a big issue is to log all messages including debug level messages to a circular buffer of configurable size. Then when a log message of ERROR or worse level is logged, the contents of the buffer are prepended before the log error message as context log messages.
This way you don't get your logs cluttered with debug level logs all the time, but you get to see debug level messages just before each error.
It's not any fancy datastructure or programming concept. I don't see many top coders doing this so perhaps it's a bad idea (definitely a bad idea for high performance code sections). But so far it works for the stuff I do.
2) Then there's input validation/filtering and output escaping/encoding. It's good to code as if someone is out to pwn your program. If you don't, you end up with hundreds or even thousands of holes that one unfortunate day need to be fixed, verified and retested.
My problem so far is I tend to inherit code like that... Full of bugs and security holes. Oh well...
Perhaps we should first work out how these things do what they do. Then go to neurons then scale up. After all can we honestly say we know for sure that a white blood cell is much stupider than a worm, insect or fish?
Thinking you understand how neurons or single celled creatures work just by statistics and averages of their outputs is like thinking you understand how humans think just by statistics of their outputs. You might be able to guess what a human might do on a daily basis most of the time but that's not true understanding.
If you don't really know what you're doing you might create something that seems like a human 95+% of the time, but the crucial 5% or 1% of the time it doesn't actually think like a human. After all most humans don't really think much most of the time;).
Yeah his own link stated that only one human has won that Welsh race so far.
My personal hypothesis is humans may (or may not) have started running to hunt animals, but they really got better at it (and got better fast) because of War not because of hunting. Yes some tribal people chase down food animals for hours. But most don't. We use our brains. We prefer to spend our time doing other things instead of running around. Traps, ambushes, chasing animals over a cliff or into a dead end. The other land predators don't chase prey for hours either. It's usually all over within 5 minutes.
But in War the predator and prey are both the same species. Doesn't matter how fast one or the other gets, within a few generations the predator and prey will still be about the same speed - same species after all. And in a war, the predator often doesn't stop after catching/killing one prey.
So endurance matters more - the prey better be able to keep running till it can hide safely or till the sun goes down, and then be prepared to run for hours again the next day.
I argue that the selective pressure from this would be much higher than from endurance hunting. You don't get food one day, you might still survive to reproduce some other day. Whereas in a war if you don't get away today, your genes die.
We've already got grey goo around us - fungi, bacteria etc.
We're nowhere close to building something on a nanoscale that can outcompete fungi or bacteria in digesting our world. We can't build anything like a housefly either (flies reasonably fast for much longer than many tiny toy helis, navigates, handles some suboptimal weather conditions, feeds itself, avoids enemies, finds mates and creates copies).
One might say someone will come up with a grey goo that eats steel (which most fungi and bacteria can't). But what would the thermodynamics and chemical reactions be? To convert the steel to copies of itself it would need additional nutrients (an all steel nanobot seems unlikely) and it would either need suitable catalysts (trace nutrients) or a significant power source. To do it quickly would require even more power.
So I'm not worried about grey goo. I'd be more worried about someone creating a deadly germ (virus, etc).
1) If the caching was better so I got SSD speeds and latencies (low latency is important to me) for almost anything that fits in cache (small copies and compiles) and full 7200RPM speeds for the real world large copies then I'd definitely buy just the SSHD. But that's not the case unfortunately.
2) If Seagate's SSHD never performed worse than normal desktop drives I'd be tempted to buy the SSHD AND an SSD. However for some reason it's actually slower in many cases (look at the real world copy speeds for example).
So overall it's a bit disappointing and a harder "buy" decision.
Seagate's offering is decent but not good enough to make their offering the obvious solution for people like you and me. We both know the manually moving files around takes time. But I want at least mid level SSD performance for stuff that clearly fits in cache.
As it is, with the high performance a real SSD gives me, I could play a game on the SSD while running a large copy to/from a cheaper fast conventional desktop drive and probably not notice a big difference (the latency is the big issue for the noticing part - and the article seems to indicate that Seagate's SSHD is rather bad at that). Doesn't matter if total throughput is a bit less, but if the game pauses for even 200ms it's noticeable.
Lastly if you're using Linux you could try linux's ssd caching in software. Not sure if it's better than Seagate's.
There's another thing I'm curious about. Do all those beloved Constitutional amendments and acts (e.g. FOIA) apply in company towns?
After all I see many people here saying stuff like freedom of speech does not apply on company property (websites, bulletin boards etc), since it's private property.
If this stuff doesn't apply then the US people who keep asking for a small government are rather stupid, since many powerful corporations will be all too happy to take over. Once they own most of anything and anywhere worth owning, good luck with freedom of speech, right to bear arms etc.
Deadweights don't do much. So they're not that responsible for stuff like Windows 8 or Surface RT. Therefore they're not the main problem with Microsoft.
It's those steering and moving the ship who are responsible, not really the deadweights.
Oh I see it's "lighting strikes" and not lightning strikes. I suppose it could protect your system from someone shining a not too bright light at it.
In contrast I'm not aware of many smallish _electronic_ devices that can take direct lightning hits with zero or minimal damage.
I've seen a modem that probably took a lightning induced surge[1]. Basically some of the copper tracks vaporized and were deposited as small little copper balls on the inside of the modem case. Even the mouse attached to the PC attached to the modem was dead.
Anyone who makes claims about small electronic devices protecting your system from direct lightning is lying or doesn't know anything about lightning.
[1] e.g. lightning hits nearby causes a powerful electrical surge along the phone lines. If it was a direct hit the modem wouldn't be in one piece.
Another thing to consider: it may take 6 seconds to clean your teeth well, but how long does it take to clean the brush properly after it cleans your teeth?
Not exactly traditional science but I suspect my comment may have influenced the "bufferbloat" and network people barking up the wrong tree to instead make something like codel.
In my opinion the actual solution to latency is not a reduction in buffer sizes. Because the real problem isn't actually large buffers. The problem is devices holding on to packets longer than they should. Given the wide variations in bandwidth, it is easier to define "too high a delay" than it is to define "too large a buffer".
Not long after that the Taht guy who replied to me implemented codel.
Because while they were definitely complaining about the problem for a long time it still looked up till then like they were missing a key factor for the solution - time spent in queue by packets.
With your adjustments: 1) If you're in between two vehicles (front-rear) and a truck is behind and close to you, you can't change lanes safely since you can't see much behind using the side mirrors, and the middle mirror just shows the truck behind you. This can happen if the front car has stalled and a big truck is behind you. Or you need to change lanes for other reasons.
2) you won't be able to spot motorcycles in the resulting blind spots and where I drive they end up more often in those areas than the usual blind spots.
What you need are mirrors that are curved at the edge so that you see the side of your car AND still cars near to the side of your car.
Even so it's usually good to look at the direction you are going before you change lanes. Someone else from another lane could be changing into the same lane you're trying to change to.
Yeah and it's quite strange/stupid for Microsoft to change the behaviour from reboot to login[1].
Linux and FreeBSD kept the ctrl-alt-del for reboot concept.
This conflict in behaviour can be a problem in a mixed KVM environment where you have Windows and Linux/FreeBSD systems.
When a windows administrator sees a blank screen and tries to log in they may press ctrl-alt-del. Which by default on some Windows configurations/versions brings up the login screen. BUT on most Linux/FreeBSD default installs reboots the machine...
And so in some cases I've configured FreeBSD or Linux to not reboot on ctrl-alt-del.
[1] Disable it sure, but ctrl-alt-del to login has probably caused more problems than it solved in real-life.
Don't believe me? Lets test it. I will delete a picture from facebook in the next ten minutes. Try and recover it.
Sure just give me it's old URL. I think you'll find it's still accessible. In fact I suspect all you need is the photo's unique facebook filename e.g. 11855_1269540174526_6600783_n.jpg
Login to facebook copy the URL of a random uploaded photo, replace the photo filename in the URL with the unique facebook filename of a deleted photo. Visit the resulting URL, voila deleted photo is accessible.
For many cloud services the static files aren't deleted - it's just too much trouble.
On a related note, I'm fine with people texting while they drive as long as they pass a very difficult simulator test to prove they can repeatedly do so safely under difficult driving conditions and scenarios. e.g. answering difficult questions correctly while driving in varying difficult traffic and road conditions (including people/animals dashing across the street) to get from point to point within time limits.
If any driver can pass such tests, it's more likely that crappy drivers like me would kill them than they kill us even while they are texting. So I'd be fine with them on the road texting away;).
The real problem is everyone has been coming up with "Go buttons" but there was no decent "Stop button". So to stop some stuff but not others you have to make sure ALL the unwanted Go buttons" are not pressed. And that is not easy to do. Some people say "Use a library" the problem is how do you make sure future "Go buttons" that haven't been invented yet are not pressed either? And how about different browsers behaving differently?
at a certain size the station would pull itself apart unless it was made of some sort of super strong exotic metal.
Attach space station to counterweight with a bunch of long tethers. Spin to taste. We've got cables holding up rather heavy stuff down on Earth. No need to spin at high speeds, no need for big space stations.
In 1940s-1960s the USA did well - lots of top German and other scientists. Later there was still some discipline, unity and other good stuff leftover from the war. This era you had the Manhattan Project, 747, Apollo project, Douglas Engelbart's Mother of all Demos. Plenty of great things done.
1970s onwards the USA had the petrodollar. Basically the US Gov could create money, transfer a fair bit to the citizens (directly or indirectly via large projects like the continuing interstate highway project) and everyone else around the world with US dollars gets relatively poorer. Repeat as necessary.
2000+ onwards the petrodollar started weakening. Some "rogue" countries started selling oil in Euros. The US Gov created money but arguably didn't help the citizens as much with it. Go look where the created money went instead.
Things may have been great in the past, but the future doesn't look so bright. Not going to change unless the voters change things. But the voters prefer to keep voting for evil or lesser evil, and then complain that they still get evil.
I wonder if it's possible to get lost in reorganizations and end up collecting a salary but not have to work.
Paying and not allowing you to work is not the same thing: http://www.huffingtonpost.com/2009/06/22/new-york-teachers-paid-to_n_219336.html
you are charged based on how much current you're using at any point in time, as the meter measures amperage across it, not voltage drop
That only applies if you are charged by the kVAh, should not apply if you are charged by kWh (unless you're being cheated).
Industrial rates are usually kVAh. Domestic/residential rates are usually kWh.
1) Also invaluable are useful logging, logging messages and exception handling.
;). But decent log messages for your own programs? You usually have to write those yourself.
Those fancy algos, data structures you can find built-in or on google- usually a better programmer has done the work already and using their code/ideas may improve the average quality of your program
Example of bad error messages: "NullReferenceException: Object reference not set to an instance of an object"
Why is that bad? It doesn't tell you which was the offending object. It's like saying "Doctor it hurts!" without saying where or what hurts.
In contrast something like this is far more useful:
E121: Undefined variable: g:pymode_updatetime
Similar for "file not found/accessible" errors, don't just log that a file was not found/accessible, log the path of the file too.
What I do when performance isn't a big issue is to log all messages including debug level messages to a circular buffer of configurable size. Then when a log message of ERROR or worse level is logged, the contents of the buffer are prepended before the log error message as context log messages.
This way you don't get your logs cluttered with debug level logs all the time, but you get to see debug level messages just before each error.
It's not any fancy datastructure or programming concept. I don't see many top coders doing this so perhaps it's a bad idea (definitely a bad idea for high performance code sections). But so far it works for the stuff I do.
2) Then there's input validation/filtering and output escaping/encoding.
It's good to code as if someone is out to pwn your program. If you don't, you end up with hundreds or even thousands of holes that one unfortunate day need to be fixed, verified and retested.
My problem so far is I tend to inherit code like that... Full of bugs and security holes. Oh well...
So far I'm not sure they can even simulate a paramecium, amoeba or white blood cells 100%. These single celled creatures do quite fancy stuff given their limited senses and physical abilities. Watch these: https://www.youtube.com/watch?v=JnlULOjUhSQ
http://www3.imperial.ac.uk/newsandeventspggrp/imperialcollege/newssummary/news_14-9-2011-8-51-31
Perhaps we should first work out how these things do what they do. Then go to neurons then scale up. After all can we honestly say we know for sure that a white blood cell is much stupider than a worm, insect or fish?
Thinking you understand how neurons or single celled creatures work just by statistics and averages of their outputs is like thinking you understand how humans think just by statistics of their outputs. You might be able to guess what a human might do on a daily basis most of the time but that's not true understanding.
If you don't really know what you're doing you might create something that seems like a human 95+% of the time, but the crucial 5% or 1% of the time it doesn't actually think like a human. After all most humans don't really think much most of the time ;).
Yeah his own link stated that only one human has won that Welsh race so far.
My personal hypothesis is humans may (or may not) have started running to hunt animals, but they really got better at it (and got better fast) because of War not because of hunting. Yes some tribal people chase down food animals for hours. But most don't. We use our brains. We prefer to spend our time doing other things instead of running around. Traps, ambushes, chasing animals over a cliff or into a dead end. The other land predators don't chase prey for hours either. It's usually all over within 5 minutes.
But in War the predator and prey are both the same species. Doesn't matter how fast one or the other gets, within a few generations the predator and prey will still be about the same speed - same species after all. And in a war, the predator often doesn't stop after catching/killing one prey.
So endurance matters more - the prey better be able to keep running till it can hide safely or till the sun goes down, and then be prepared to run for hours again the next day.
I argue that the selective pressure from this would be much higher than from endurance hunting. You don't get food one day, you might still survive to reproduce some other day. Whereas in a war if you don't get away today, your genes die.
We've already got grey goo around us - fungi, bacteria etc.
We're nowhere close to building something on a nanoscale that can outcompete fungi or bacteria in digesting our world. We can't build anything like a housefly either (flies reasonably fast for much longer than many tiny toy helis, navigates, handles some suboptimal weather conditions, feeds itself, avoids enemies, finds mates and creates copies).
One might say someone will come up with a grey goo that eats steel (which most fungi and bacteria can't). But what would the thermodynamics and chemical reactions be? To convert the steel to copies of itself it would need additional nutrients (an all steel nanobot seems unlikely) and it would either need suitable catalysts (trace nutrients) or a significant power source. To do it quickly would require even more power.
So I'm not worried about grey goo. I'd be more worried about someone creating a deadly germ (virus, etc).
1) If the caching was better so I got SSD speeds and latencies (low latency is important to me) for almost anything that fits in cache (small copies and compiles) and full 7200RPM speeds for the real world large copies then I'd definitely buy just the SSHD. But that's not the case unfortunately.
2) If Seagate's SSHD never performed worse than normal desktop drives I'd be tempted to buy the SSHD AND an SSD. However for some reason it's actually slower in many cases (look at the real world copy speeds for example).
So overall it's a bit disappointing and a harder "buy" decision.
Seagate's offering is decent but not good enough to make their offering the obvious solution for people like you and me. We both know the manually moving files around takes time. But I want at least mid level SSD performance for stuff that clearly fits in cache.
As it is, with the high performance a real SSD gives me, I could play a game on the SSD while running a large copy to/from a cheaper fast conventional desktop drive and probably not notice a big difference (the latency is the big issue for the noticing part - and the article seems to indicate that Seagate's SSHD is rather bad at that). Doesn't matter if total throughput is a bit less, but if the game pauses for even 200ms it's noticeable.
Lastly if you're using Linux you could try linux's ssd caching in software. Not sure if it's better than Seagate's.
There's another thing I'm curious about. Do all those beloved Constitutional amendments and acts (e.g. FOIA) apply in company towns?
After all I see many people here saying stuff like freedom of speech does not apply on company property (websites, bulletin boards etc), since it's private property.
If this stuff doesn't apply then the US people who keep asking for a small government are rather stupid, since many powerful corporations will be all too happy to take over. Once they own most of anything and anywhere worth owning, good luck with freedom of speech, right to bear arms etc.
Deadweights don't do much. So they're not that responsible for stuff like Windows 8 or Surface RT. Therefore they're not the main problem with Microsoft.
It's those steering and moving the ship who are responsible, not really the deadweights.
I used to say Jobs was an asshole with taste, but that didn't go down too well ;).
Badabing Rimshot!
Oh I see it's "lighting strikes" and not lightning strikes. I suppose it could protect your system from someone shining a not too bright light at it.
In contrast I'm not aware of many smallish _electronic_ devices that can take direct lightning hits with zero or minimal damage.
I've seen a modem that probably took a lightning induced surge[1]. Basically some of the copper tracks vaporized and were deposited as small little copper balls on the inside of the modem case. Even the mouse attached to the PC attached to the modem was dead.
Anyone who makes claims about small electronic devices protecting your system from direct lightning is lying or doesn't know anything about lightning.
[1] e.g. lightning hits nearby causes a powerful electrical surge along the phone lines. If it was a direct hit the modem wouldn't be in one piece.
Another thing to consider: it may take 6 seconds to clean your teeth well, but how long does it take to clean the brush properly after it cleans your teeth?
Not exactly traditional science but I suspect my comment may have influenced the "bufferbloat" and network people barking up the wrong tree to instead make something like codel.
They were saying oversized buffers were the problem:
http://queue.acm.org/detail.cfm?id=2071893
So I commented there (excerpt of full comment):
In my opinion the actual solution to latency is not a reduction in buffer sizes. Because the real problem isn't actually large buffers. The problem is devices holding on to packets longer than they should. Given the wide variations in bandwidth, it is easier to define "too high a delay" than it is to define "too large a buffer".
Not long after that the Taht guy who replied to me implemented codel.
Perhaps they were already working on it, but it's not even obvious that they were from Van Jacobsen's 2006 rant on queues: http://www.pollere.net/Pdfdocs/QrantJul06.pdf
Because while they were definitely complaining about the problem for a long time it still looked up till then like they were missing a key factor for the solution - time spent in queue by packets.
The food industry also found out that asking people what they want doesn't work well:
https://www.youtube.com/watch?v=iIiAAhUeR6Y#t=9m50s
The difference was Jobs was an asshole with a sense of taste.
Lots of CEOs can do the asshole part easily, but they just don't have taste.
With your adjustments:
1) If you're in between two vehicles (front-rear) and a truck is behind and close to you, you can't change lanes safely since you can't see much behind using the side mirrors, and the middle mirror just shows the truck behind you. This can happen if the front car has stalled and a big truck is behind you. Or you need to change lanes for other reasons.
2) you won't be able to spot motorcycles in the resulting blind spots and where I drive they end up more often in those areas than the usual blind spots.
What you need are mirrors that are curved at the edge so that you see the side of your car AND still cars near to the side of your car.
Even so it's usually good to look at the direction you are going before you change lanes. Someone else from another lane could be changing into the same lane you're trying to change to.
Yeah and it's quite strange/stupid for Microsoft to change the behaviour from reboot to login[1].
Linux and FreeBSD kept the ctrl-alt-del for reboot concept.
This conflict in behaviour can be a problem in a mixed KVM environment where you have Windows and Linux/FreeBSD systems.
When a windows administrator sees a blank screen and tries to log in they may press ctrl-alt-del. Which by default on some Windows configurations/versions brings up the login screen. BUT on most Linux/FreeBSD default installs reboots the machine...
And so in some cases I've configured FreeBSD or Linux to not reboot on ctrl-alt-del.
[1] Disable it sure, but ctrl-alt-del to login has probably caused more problems than it solved in real-life.
Don't believe me? Lets test it. I will delete a picture from facebook in the next ten minutes. Try and recover it.
Sure just give me it's old URL. I think you'll find it's still accessible. In fact I suspect all you need is the photo's unique facebook filename e.g. 11855_1269540174526_6600783_n.jpg
Login to facebook copy the URL of a random uploaded photo, replace the photo filename in the URL with the unique facebook filename of a deleted photo. Visit the resulting URL, voila deleted photo is accessible.
For many cloud services the static files aren't deleted - it's just too much trouble.
Check out how this cop does it: https://www.youtube.com/watch?v=ErASUGL00gQ
On a related note, I'm fine with people texting while they drive as long as they pass a very difficult simulator test to prove they can repeatedly do so safely under difficult driving conditions and scenarios. e.g. answering difficult questions correctly while driving in varying difficult traffic and road conditions (including people/animals dashing across the street) to get from point to point within time limits.
If any driver can pass such tests, it's more likely that crappy drivers like me would kill them than they kill us even while they are texting. So I'd be fine with them on the road texting away ;).
The real problem is everyone has been coming up with "Go buttons" but there was no decent "Stop button". So to stop some stuff but not others you have to make sure ALL the unwanted Go buttons" are not pressed. And that is not easy to do. Some people say "Use a library" the problem is how do you make sure future "Go buttons" that haven't been invented yet are not pressed either? And how about different browsers behaving differently?
So more than 10 years ago I proposed that a "Stop" "button" be created: http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html
But there was no interest in such a thing till recent years with CSP: https://developer.mozilla.org/en/docs/Security/CSP
If the major browsers had implemented my simple suggestion years ago it would have been harder for the Yahoo, MySpace and other worms.
at a certain size the station would pull itself apart unless it was made of some sort of super strong exotic metal.
Attach space station to counterweight with a bunch of long tethers.
Spin to taste.
We've got cables holding up rather heavy stuff down on Earth.
No need to spin at high speeds, no need for big space stations.
and guess what happened with Facebook, Twitter, LinkedIn?
It's still much easier for Brazilian citizens to pick a Brazilian Government they prefer than for them to pick a US Government they prefer.
If they keep voting in governments that spy on them then perhaps that's what most of them want and deserve.