3.3Wh/gram sounds a lot but usability evaporates when taking the half-life of Ni63->Cu63 decay into account: 3.3Wh / 24/365 / 100 / 3.3V == 1.141e-6A == 1.14 (insert UTF8 greek micro)A. The 3.3V is just an example.
I think this is incorrect and EPR does allow instantaneous (i.e. FTL) communications except that the entangled particles have to travel first and this is bound by the speed of light. So EPR seems to use bandwidth in the past. However, there are some conflicts with other theories so science came up with the "no-communication theorem" to fix the breakage as far as I understand it.
Disks are pretty much safe, it's the ECC-less transfer to new disks which is risky.
It is very very unlikely for bitrot on disk to go unnoticed thanks to ECC but when you migrate your data to bigger disks, new filesystems then an occasional bitflip due to critical timings (SDRAM, busses, chips, clocks), old PATA cables (no data checksum) or caused by EMI, radiation etc. increases with the size of the dataset.
The solution is checksumming before- and after the copy. Even deprecated algorithms (MD5, SHA1) will do.
...the init process needs to be really minimalistic and offload everything else with a simple and well documented (better: obvious) interface.
"systemd" should have been named "borgd" a long time ago and by now it has gone completely wild assimilating a lot of things it thinks a problem needs to be solved. http://boycottsystemd.org/ summarizes the issues very well.
Document your pet projects (which reflect what you really like to do) on your own website with a distinctive name (sort of personal branding). It may take years to find but at some point you might find a job description which is a perfect match. When applying for the job refer to your own website to substantiate your skills.
For the same reason why there's still no massive MS-windows PC destruction: to control them has more value than to destroy them. And how would you brag about such an act of vandalism without getting into trouble?
They would be stupid to not take advantage of any such scheme. Just like any other government organization which has "secret" spelled over its name. And they've been accused of a lot of things but stupidity...
Fact is there's a lot of software involved in the wiretapping. And it''s from Israeli firms. We don't have the source and we don't know how it works (I live in NL). Go figure.
I think the compiler is correct. If tun is null, then tun->sk is undefined and the compiler can do what even optimization it want.
So when the compiler see tun->sk it can assume that tun is not null, and do the optimization, because IF tun is null, then the program is invoked undefined behavier, which the compiler don't have to preserve/handle. (How do you keep the semantic of an undefined program??)
The compiler is a complete asshole for deliberately optimizing a too late NULL check away instead of screaming "possibly dereferencing NULL" or something.
People don't realise that global warming never meant that the whole world turns into the tropics but that weather patterns shift (ie cold places get warmer but other areas could very well get colder) and that it's still a negative thing because everything in those environments depend on certain temperatures.
There are large seasonal temperature variations. A small change may be bad for some but will also be good for others. I hate this pessimistic view that every change is bad.
Not that it really matters. it's fact that pollution has a very negative impact on human beings so we should care even if there is no negative effects on the environment.
It is rather shifting to "climate change". And "well established" != "proven".
Adapting is probably a lot cheaper than trying to reverse or to compensate any supposed effect, let alone the dangers due to lack of understanding. And change means opportunity! not disaster: some changes are good, some are bad.
The key thing is to keep it on-line with good enough redundancy (e.g. raid1 + off-site backup). Actively keeping it on-line (replacing harddisks by bigger and more modern ones) solves the technology drift problem and adds space faster than can be filled with meaningful data (for most of us). Once the data hits the (raid1) disk it is reasonably safe because of ECC. The off-site backup is insurance against rm/fire et.al. Caveat: software, firmware, hardware all have bugs so _independent_ verification is important: tar/cpio/rsync bugs, SDRAM bit flips once every 20G, I've seen them. That's why I wrote this simple tool: http://www.frankvm.com/fsindex .
Everything stored off-line is inaccessible and just waiting to become permanently lost.
I'm not going to mod you as troll. But maybe others do me.
Computer science and all what goes with is is an exact science. Until MS came around. MS destroyed it. Welcome to the dark ages of MS.
rPath is quite interesting because what's the main hassle to get portability? Interfaces! Have a look at POSIX, glibc, M$.* and realize that those interfaces are big & fat.
So, the easiest way to run an application might just be to contain it in its own virtual OS instance.
And of course Cleversave is interesting (IMHO) because there is a practically infinite amount of storage out there and GByte prices are declining ever since harddisks were invented...
This most certainly is not a user issue. You can't put such a complex machine as todays PC on a desk and expect the user to understand. Elderly people were sometimes even afraid to break their VCR when pressing buttons on their RC. In the current PC era one actually can break something by pressing buttons. Not good. Let's face it: the whole IT industry is still in its infancy and Microsofts dominance is not exactly helping here. Actually, I believe that in a few decades (100 years?) one will look back and refer to this era as something as the "dark ages" of IT.
All DVI, SATA, SCSI, USB, FireWire and now this new display interface standard in the works share the need for bandwith, preferably cheap cables, occasionally long cables without repeaters (goodbye USB and FireWire) and it all exists already. It is called Ethernet. CopperTen will fill the bandwith need for displays. Not necessarily using IP based protocols: see ATA over Ethernet (AoE). Mass production of cables and MAC chips will make it affordable.
I don't dismiss the OS: M$ is crap and smart people just don't use it. The
guy who picks a crappy OS to start with is a deep cause. Incompetent
programmers, operators, whatever are a deep cause as well: they don't
have enough clue and will fsck up some day even when they use linux. Are
we then going to blame linux?
Another example:
If you can't view a web page because it is written for IE, blaming M$ is
one thing but it is more effective to educate the world about the stupid
webdesign company which did that lousy job. By now, only the really
stupid people are not aware of M$ crappyness.
It's not the OS, it's the people behind who's to blame. Yes, stupidity and MSW often go together but in a few years one will probably occasionally see a massive linux outage due to... similarly stupid people.
Slashdot Mirror
Subject says it all. If you can't stand the heat stay out of the kitchen.
3.3Wh/gram sounds a lot but usability evaporates when taking the half-life of Ni63->Cu63 decay into account: 3.3Wh / 24 /365 / 100 / 3.3V == 1.141e-6A == 1.14 (insert UTF8 greek micro)A. The 3.3V is just an example.
I think this is incorrect and EPR does allow instantaneous (i.e. FTL) communications except that the entangled particles have to travel first and this is bound by the speed of light. So EPR seems to use bandwidth in the past. However, there are some conflicts with other theories so science came up with the "no-communication theorem" to fix the breakage as far as I understand it.
Subject says it all. Even if virus writers just go for the largest market instead of the least secure OS then it's just another argument to use Linux.
Disks are pretty much safe, it's the ECC-less transfer to new disks which is risky. It is very very unlikely for bitrot on disk to go unnoticed thanks to ECC but when you migrate your data to bigger disks, new filesystems then an occasional bitflip due to critical timings (SDRAM, busses, chips, clocks), old PATA cables (no data checksum) or caused by EMI, radiation etc. increases with the size of the dataset. The solution is checksumming before- and after the copy. Even deprecated algorithms (MD5, SHA1) will do.
... it is not the best solution. A leap second table to make it a time representation issue would probably be better.
The Carambola 2 has the same SoC and runs OpenWrt out of the box.
...the init process needs to be really minimalistic and offload everything else with a simple and well documented (better: obvious) interface. "systemd" should have been named "borgd" a long time ago and by now it has gone completely wild assimilating a lot of things it thinks a problem needs to be solved. http://boycottsystemd.org/ summarizes the issues very well.
Document your pet projects (which reflect what you really like to do) on your own website with a distinctive name (sort of personal branding). It may take years to find but at some point you might find a job description which is a perfect match. When applying for the job refer to your own website to substantiate your skills.
Open source is freedom. freedom is not the same as democracy. And science is no democracy either.
For the same reason why there's still no massive MS-windows PC destruction: to control them has more value than to destroy them. And how would you brag about such an act of vandalism without getting into trouble?
They would be stupid to not take advantage of any such scheme. Just like any other government organization which has "secret" spelled over its name. And they've been accused of a lot of things but stupidity... Fact is there's a lot of software involved in the wiretapping. And it''s from Israeli firms. We don't have the source and we don't know how it works (I live in NL). Go figure.
I think the compiler is correct. If tun is null, then tun->sk is undefined and the compiler can do what even optimization it want.
So when the compiler see tun->sk it can assume that tun is not null, and do the optimization, because IF tun is null, then the program is invoked undefined behavier, which the compiler don't have to preserve/handle. (How do you keep the semantic of an undefined program??)
The compiler is a complete asshole for deliberately optimizing a too late NULL check away instead of screaming "possibly dereferencing NULL" or something.
Can't suppress remembering Star Trek Next Generation episode "The Inner Light". http://en.wikipedia.org/wiki/The_Inner_Light_(TNG_episode)
People don't realise that global warming never meant that the whole world turns into the tropics but that weather patterns shift (ie cold places get warmer but other areas could very well get colder) and that it's still a negative thing because everything in those environments depend on certain temperatures.
There are large seasonal temperature variations. A small change may be bad for some but will also be good for others. I hate this pessimistic view that every change is bad.
Not that it really matters. it's fact that pollution has a very negative impact on human beings so we should care even if there is no negative effects on the environment.
CO2 is not a pollutant.
We do not have to , global warming is not proven.
It's rather well established by now.
It is rather shifting to "climate change". And "well established" != "proven". Adapting is probably a lot cheaper than trying to reverse or to compensate any supposed effect, let alone the dangers due to lack of understanding. And change means opportunity! not disaster: some changes are good, some are bad.
There is a workable solution.
The key thing is to keep it on-line with good enough redundancy (e.g. raid1 + off-site backup). Actively keeping it on-line (replacing harddisks by bigger and more modern ones) solves the technology drift problem and adds space faster than can be filled with meaningful data (for most of us). Once the data hits the (raid1) disk it is reasonably safe because of ECC. The off-site backup is insurance against rm/fire et.al. Caveat: software, firmware, hardware all have bugs so _independent_ verification is important: tar/cpio/rsync bugs, SDRAM bit flips once every 20G, I've seen them. That's why I wrote this simple tool: http://www.frankvm.com/fsindex .
Everything stored off-line is inaccessible and just waiting to become permanently lost.
I'm not going to mod you as troll. But maybe others do me. Computer science and all what goes with is is an exact science. Until MS came around. MS destroyed it. Welcome to the dark ages of MS.
rPath is quite interesting because what's the main hassle to get portability? Interfaces! Have a look at POSIX, glibc, M$.* and realize that those interfaces are big & fat. So, the easiest way to run an application might just be to contain it in its own virtual OS instance. And of course Cleversave is interesting (IMHO) because there is a practically infinite amount of storage out there and GByte prices are declining ever since harddisks were invented...
This most certainly is not a user issue. You can't put such a complex machine as todays PC on a desk and expect the user to understand. Elderly people were sometimes even afraid to break their VCR when pressing buttons on their RC. In the current PC era one actually can break something by pressing buttons. Not good. Let's face it: the whole IT industry is still in its infancy and Microsofts dominance is not exactly helping here. Actually, I believe that in a few decades (100 years?) one will look back and refer to this era as something as the "dark ages" of IT.
Everything is interim. Wireless is an option when TeraHz Wifi is there.
All DVI, SATA, SCSI, USB, FireWire and now this new display interface standard in the works share the need for bandwith, preferably cheap cables, occasionally long cables without repeaters (goodbye USB and FireWire) and it all exists already. It is called Ethernet. CopperTen will fill the bandwith need for displays. Not necessarily using IP based protocols: see ATA over Ethernet (AoE). Mass production of cables and MAC chips will make it affordable.
This might help "wine" and similar projects. Think marketing: buy this mac and run your M$W apps too.
I don't dismiss the OS: M$ is crap and smart people just don't use it. The guy who picks a crappy OS to start with is a deep cause. Incompetent programmers, operators, whatever are a deep cause as well: they don't have enough clue and will fsck up some day even when they use linux. Are we then going to blame linux?
Another example:
If you can't view a web page because it is written for IE, blaming M$ is one thing but it is more effective to educate the world about the stupid webdesign company which did that lousy job. By now, only the really stupid people are not aware of M$ crappyness.
It's not the OS, it's the people behind who's to blame. Yes, stupidity and MSW often go together but in a few years one will probably occasionally see a massive linux outage due to... similarly stupid people.