More importantly: the moment the mirror surface warps or burns, it stops reflecting. So after the initial laser hit, there's a sudden spike in energy adsorption as the reflective material fails.
Any practical reflective material is also going to be polished metal, so this would happen pretty quickly.
It's not a backup while it's on the same disk, but a backup without version information is very close to useless anyway - unless you're positive you'll catch problems between now and the last backup, you need version information - and that part is the slow clumsy bit which makes most of these problems complicated.
ZFS is very nice in that regard, because if the filesystem is holding version information for you, transparently (and - by virtue of the layer, very efficiently - since it literally only stores changed blocks) then you can backup by just doing a "zfs send" and boom - you've got all your version information and the complete filesystem ready to go.
Trying to do this with other things becomes very annoying very quickly - for example, I do want to keep at least 1 backup of my music collection, and if it got completely scrambled I might not notice it for a while...but if I change ID3 information, then rsync and other solutions will store a full extra copy of the track. How many should I store? How do I prevent "track scrambled" if I only store 1 copy, then update ID3 info later?
All of these kinds of ideas are good, but they all implode dramatically when you're dealing with a tens of thousands of files, and hundreds of gigs of whatever. They just take too long to run - and, in many ways, are an awkward layer over the top of something which needs to be handled transparently and continuously.
Between 3 active computers I use, there's enough redundancy since they're rarely in the same place. SpiderOak manages absolutely, completely vital stuff (currently my thesis drafts).
But there's no real, constructive and useful pattern to it yet. The problem is less backups and more change management. Keeping copy-on-write sane on Windows is difficult, and migrating my servers XFS partition to ZFS is problematic since I need just tons of storage to do it which I presently can't afford.
The issue is far less "backups" and more "making them meaningful". Backing up is useless if I overwrite the media with the important changes, or it takes forever to dissect a working copy of the data.
A good backup strategy has to include a verification step. It's the whole reason "the cloud" makes any sort of sense to begin with - your essentially continually checking and rechecking your data.
Or that they do explore but they slow down their rate reproduction as longevity increases?
If you take current trends, we're going to evolve into having a very nearly static population long before interstellar spacetravel becomes accessible. That's a social and cultural change, and it's likely to also accompany some big increases in our longevity. Given these factors, is it actually particularly likely that mankind will ever populate, in an exponential fashion, the galaxy? Or just explore it.
It's possible you only ever end up with a few billion sentients of any given species engaging in large scale space travel, and the galaxy/universe is very big.
I've always presumed that some amount of heavier elements must have been formed immediately after the big bang, if only because the cooling plasma would've still been dense and energetic enough to cause incidental fusion.
Series hybrids pay for that in long-range performance, since you go engine -> generator -> motor continuously. The whole point of the Prius and other parallel designs is to eliminate that engine -> generator loss when you can.
The basic problem with what you (and indeed others) want is that it's not really possible to make appreciable weight-savings on the type of engine you'd need to make the series system practical, and you need more batteries to make the efficiency over the short-haul worth it.
What we really need is a practical, portable solid-oxide fuel cell that can use regular petrol - since then you're looking at 80% direct electrical efficiency, and a greatly reduced number of moving parts (and avoiding the need for a generator at all).
Double edged blade. If you have tenure then you can hold off on publishing to make sure you're really, truly correct. If you don't, then you have no choice.
To my mind the real issue is that the notion of "debate in the literature" is being rapidly killed by the increase in complexity and cost of some experiments, and to a greater extent the very terse manner in which journals like to have their experimental methods published: I'd much rather read a rambling journal or logbook then someone's - effectively "opinion" - on what they think their important experimental variables are, since accusing someone of publishing false information is ridiculously difficult (and not to be taken lightly) whereas people simply missing things is common and to be expected.
It's almost criminal the HPN-SSH patches haven't been rolled into mainline SSH yet. On modern LAN's, SSH is incredibly slow at data transfer yet tons of guides out there on the internet (and systems) propose using it for things like disc imaging and the like - where it's completely unsuited.
The average user ends up with either a disappointing experience, or just turns off encryption / uses no authentication whatsoever.
The HPN-SSH patches more or less fix all these problems: SSH gets faster, they've added a multi-threaded AES cipher, and the "none" cipher let's you retain secure authentication and HMAC digests without the transfer overhead of encryption (which is incredibly useful when you want to move basically unsecure items like log files, media etc.) but retaining secure log in and authentication.
FYI: storing hard disks in a fire-proof safe is not a good idea. Fire-proof safes are generally rated for their ability to protect paper documents from burning up - but paper is very robust, and stable to very high temperatures provided it isn't actually exposed to a source of ignition.
This isn't really true of a hard disk - you can heat paper to 150 degrees C no problems, but as far as I know most hard disks when in storage may not actually survive prolonged exposure to those sorts of temperatures.
Not really: radiative emission is the only type of cooling you can get in space. Depending how much power you're bleeding off elsewhere on your ship, it could be quite difficult to keep things suitably cool. Especially considering that any part of your ship facing the sun is going to be picking up quite a high thermal load.
Let's not turn this into some weird racial thing. There are very good reasons to be skeptical of letting non-allied governments, or indeed any external governments, near major national communications hardware - especially if it's likely to find use for defense or other strategic purposes.
One of the single biggest problems with things like this is the hardware side of things: how do you make sure that the black-box hardware you're buying (and any silicon chip is exactly that, at least until you open it up and follow the traces and even then - see the Underhanded C Contest - for why "source code" is a poor metric for determining security in a lot of cases.
Letting a Chinese company install large orders of hardware into a national network is just idiotic. It may not be that much wiser letting a US company do it, but Australia is allied with the US whereas we still define national security policy by notionally assuming China to be a foe in some capacity.
Google pulled out of China precisely because they experience demands for surveillance and repeated efforts by suspect government sponsored hackers to invade the privacy of accounts. Letting companies from the same area install network hardware is madness.
I seriously disagree with this notion. It's not that I think you're necessarily wrong, but I think that being too open about the idea of simply dropping support for older protocols and ideas, far too easily leads to cutting useful things and trying to justify it by pushing untested ideas that someone is too enthusiastic about.
Currently, everything about GUIs in the computer world is suffering this problem - Windows 8 Metro, Ubuntu Unity, Gnome Shell - all these things are currently abandoning well-tested, well-understood user interface concepts in the ridiculous mad rush that everyone's suddenly decided they need to cram a tablet interface onto everything. And all of them are characterized by it being done in a very non-optional, non-incremental way - which in the case of Ubuntu at least is simply costing them users, but it's absurd that the lesson is being learnt by failure rather then critical thinking or careful design and iteration. See things like the MS Office "ribbon" - pretty much forced on users by corporate upgrade inertia, yet the actual underlying ribbon infrastructure can easily support old-style MS Office menus. So why doesn't it? Why, after discussing all their careful iteration to come up with the ribbon, did the people who designed it not think "we should put these features side-by-side and gather data on how people use it, and at what point they switch back, or how many do switch back?"
Apple - ironically - are currently the only ones being vaguely sensible about their desktop interfaces. How long they resist iOS'ing Mac OS will be interesting to see.
When you talk about "bloat" it's very unclear what you mean. What bloat, and do we care about it? If we're talking about my OS wanting 5 gb's of disk space - well who cares? That's not a problem except in some special case environments, and most of the time what I want (and the reason I still use Windows) is that bloat and long-chain of backwards compatibility. To date, Microsoft has done a very good job on this, since usually by the time something straight up stops working, we're at the point it's either been gradually replaced or can be fully emulated by modern hardware (there's nothing so joyous as finding out DosBox runs an old game you struggled to play a decade ago perfectly). It is a very dangerous path to consider dropping support for things as universally a good idea, and currently too many developers are buying into the idea that we should exactly that.
Postscript: (I suspect the current trend is at least in part a foolish reaction to the web - which experienced a lot of added functionality in recent years to "bring it up" to being able to do what desktop apps do, but which gets implemented by dramatic overhauls of the experience. I think the issue is everyone's missed the big issue there: we already knew from the desktop most of what types of UI interfaces and elements work and should be implemented - which is very different from inventing brand new ones and then dumping them onto users, the the rise of client-side CSS editors should be considered as evidence).
I really doubt we're going to get there. My appraisal of the future would be that high-resolution high-DPI screens will start to win out (which we're seeing thanks to smart phones to some degree) and then someone will make a consumer-priced, lightweight VR-headset and that'll be the end of the laptop.
If you can track head-position/eye-gaze then you can after-all get away with using just the 1 screen and bringing content to the eyes as required.
The new Sony HMD isn't quite there yet, but it's a big step in the right direction.
More to life yes, but I suspect in marketing to the general consumer "1080" is now a secret codeword. Hollywood in reference to HDTV and Blu-Ray throws the term "1080p" around as the thing you want. Hell, it "feels" nice when I think about it. So for the average consumer it certainly sounds good.
It's just you, and other posters are right: for general purpose computing, it's not really so good because in working with documents, web-pages etc. everything we do is much more orientated towards "tall" resolutions (i.e. we work with portrait documents, not landscape).
One of my brothers runs 3 monitors and he has 1 24" screen configured specifically in a portrait configuration for this very reason.
Linux - essentially - desperately needs a good compatibility interface for DirectX and the gaming-relevant APIs.
It's called OpenGL and it's better than DirectX. Linux already has all the gaming APIs it needs, what it needs is more games and I don't know about you, but I don't want to get my games from the tired old publishers any more. How many ways are there to spell "yet another tired shooter".
This is the same logic that leads to Linux not having a decent implementation of useful features MS might put into their operating system -- for example the new Start menu.
It's chicken and egg -- no one's going to make games for Linux till there's a market, there won't be a market till you can play most games on Linux without needing to boot into Windows.
Dealing with that situation as an end-user though is still a pain. Even if I can figure it out, it's one more thing I have to figure out.
Information like that needs to presented in an easy to digest manner straight to the user, and the relevant actions made available at a few clicks - not command line functions.
Gaming is a great big tether to keep my on Windows. I mean, I use it for other things, run other programs, do work on it etc. but since I'm going to keep it around for gaming anyway there's no real incentive to ever make the push since I know I'll always keep coming back to it.
Linux - essentially - desperately needs a good compatibility interface for DirectX and the gaming-relevant APIs. Or a way to get say, 90% of my graphics card's performance out of virtualized box of Windows for gaming without me having to boot away from Windows.
If something like that could be accomplished, we'd be in a much better position.
Complaining about Metro UI as a reason Windows sucks these days is idiotic in a world where Gnome 3 was created and Ubuntu lost it's damn mind and made Unity.
The whole world of computer interfaces has gone to hell very quickly because of tablets and people taking away all the exact wrong lessons from them.
The problem with DKMS is that it works fine up until the kernel guys change an interface. Then it breaks horribly.
Linux needs way more ABI stability then it currently has - ideally some very clear guidelines on when ABI's will change (which should be, between major version releases). It's not really acceptable to have device drivers get taken out by minor version kernel updates, and it's pretty absurd to religiously apply FOSS to hardware in the first place since I'm never not going to be buying hardware.
On Windows and OSX, every application is (a) bloated because they have to ship all the dependencies and (b) has to either run some stupid auto-updater or be manually updated to get security fixes.
On (a): nobody cares. This isn't 1990. My laptop has a 750 gb hard drive. By far the biggest user of resources on my computer is graphics assets for applications. Not code libraries. Nobody - and I mean nobody - cares about 5 extra megabytes of libraries installed with every application. In fact in the vast majority of cases they want that feature, since it chokes out the risk of an upgrade introducing new bugs (and Win 7 went to considerable effort to provide that and undo the legacy "shared library" model). Let deduplicating filesystems or whatever take care of "app bloat"
Slashdot Mirror
More importantly: the moment the mirror surface warps or burns, it stops reflecting. So after the initial laser hit, there's a sudden spike in energy adsorption as the reflective material fails.
Any practical reflective material is also going to be polished metal, so this would happen pretty quickly.
It's not a backup while it's on the same disk, but a backup without version information is very close to useless anyway - unless you're positive you'll catch problems between now and the last backup, you need version information - and that part is the slow clumsy bit which makes most of these problems complicated.
ZFS is very nice in that regard, because if the filesystem is holding version information for you, transparently (and - by virtue of the layer, very efficiently - since it literally only stores changed blocks) then you can backup by just doing a "zfs send" and boom - you've got all your version information and the complete filesystem ready to go.
Trying to do this with other things becomes very annoying very quickly - for example, I do want to keep at least 1 backup of my music collection, and if it got completely scrambled I might not notice it for a while...but if I change ID3 information, then rsync and other solutions will store a full extra copy of the track. How many should I store? How do I prevent "track scrambled" if I only store 1 copy, then update ID3 info later?
rdiff-backup is slow.
All of these kinds of ideas are good, but they all implode dramatically when you're dealing with a tens of thousands of files, and hundreds of gigs of whatever. They just take too long to run - and, in many ways, are an awkward layer over the top of something which needs to be handled transparently and continuously.
Between 3 active computers I use, there's enough redundancy since they're rarely in the same place. SpiderOak manages absolutely, completely vital stuff (currently my thesis drafts).
But there's no real, constructive and useful pattern to it yet. The problem is less backups and more change management. Keeping copy-on-write sane on Windows is difficult, and migrating my servers XFS partition to ZFS is problematic since I need just tons of storage to do it which I presently can't afford.
The issue is far less "backups" and more "making them meaningful". Backing up is useless if I overwrite the media with the important changes, or it takes forever to dissect a working copy of the data.
Everything here.
A good backup strategy has to include a verification step. It's the whole reason "the cloud" makes any sort of sense to begin with - your essentially continually checking and rechecking your data.
Or that they do explore but they slow down their rate reproduction as longevity increases?
If you take current trends, we're going to evolve into having a very nearly static population long before interstellar spacetravel becomes accessible. That's a social and cultural change, and it's likely to also accompany some big increases in our longevity. Given these factors, is it actually particularly likely that mankind will ever populate, in an exponential fashion, the galaxy? Or just explore it.
It's possible you only ever end up with a few billion sentients of any given species engaging in large scale space travel, and the galaxy/universe is very big.
Is that strictly true?
I've always presumed that some amount of heavier elements must have been formed immediately after the big bang, if only because the cooling plasma would've still been dense and energetic enough to cause incidental fusion.
Series hybrids pay for that in long-range performance, since you go engine -> generator -> motor continuously. The whole point of the Prius and other parallel designs is to eliminate that engine -> generator loss when you can.
The basic problem with what you (and indeed others) want is that it's not really possible to make appreciable weight-savings on the type of engine you'd need to make the series system practical, and you need more batteries to make the efficiency over the short-haul worth it.
What we really need is a practical, portable solid-oxide fuel cell that can use regular petrol - since then you're looking at 80% direct electrical efficiency, and a greatly reduced number of moving parts (and avoiding the need for a generator at all).
Double edged blade. If you have tenure then you can hold off on publishing to make sure you're really, truly correct. If you don't, then you have no choice.
To my mind the real issue is that the notion of "debate in the literature" is being rapidly killed by the increase in complexity and cost of some experiments, and to a greater extent the very terse manner in which journals like to have their experimental methods published: I'd much rather read a rambling journal or logbook then someone's - effectively "opinion" - on what they think their important experimental variables are, since accusing someone of publishing false information is ridiculously difficult (and not to be taken lightly) whereas people simply missing things is common and to be expected.
It's almost criminal the HPN-SSH patches haven't been rolled into mainline SSH yet. On modern LAN's, SSH is incredibly slow at data transfer yet tons of guides out there on the internet (and systems) propose using it for things like disc imaging and the like - where it's completely unsuited.
The average user ends up with either a disappointing experience, or just turns off encryption / uses no authentication whatsoever.
The HPN-SSH patches more or less fix all these problems: SSH gets faster, they've added a multi-threaded AES cipher, and the "none" cipher let's you retain secure authentication and HMAC digests without the transfer overhead of encryption (which is incredibly useful when you want to move basically unsecure items like log files, media etc.) but retaining secure log in and authentication.
Yeah but in that case you can't actually get back to the console session, which is principally what screen is good for.
FYI: storing hard disks in a fire-proof safe is not a good idea. Fire-proof safes are generally rated for their ability to protect paper documents from burning up - but paper is very robust, and stable to very high temperatures provided it isn't actually exposed to a source of ignition.
This isn't really true of a hard disk - you can heat paper to 150 degrees C no problems, but as far as I know most hard disks when in storage may not actually survive prolonged exposure to those sorts of temperatures.
Not really: radiative emission is the only type of cooling you can get in space. Depending how much power you're bleeding off elsewhere on your ship, it could be quite difficult to keep things suitably cool. Especially considering that any part of your ship facing the sun is going to be picking up quite a high thermal load.
Let's not turn this into some weird racial thing. There are very good reasons to be skeptical of letting non-allied governments, or indeed any external governments, near major national communications hardware - especially if it's likely to find use for defense or other strategic purposes.
One of the single biggest problems with things like this is the hardware side of things: how do you make sure that the black-box hardware you're buying (and any silicon chip is exactly that, at least until you open it up and follow the traces and even then - see the Underhanded C Contest - for why "source code" is a poor metric for determining security in a lot of cases.
Letting a Chinese company install large orders of hardware into a national network is just idiotic. It may not be that much wiser letting a US company do it, but Australia is allied with the US whereas we still define national security policy by notionally assuming China to be a foe in some capacity.
Google pulled out of China precisely because they experience demands for surveillance and repeated efforts by suspect government sponsored hackers to invade the privacy of accounts. Letting companies from the same area install network hardware is madness.
I seriously disagree with this notion. It's not that I think you're necessarily wrong, but I think that being too open about the idea of simply dropping support for older protocols and ideas, far too easily leads to cutting useful things and trying to justify it by pushing untested ideas that someone is too enthusiastic about.
Currently, everything about GUIs in the computer world is suffering this problem - Windows 8 Metro, Ubuntu Unity, Gnome Shell - all these things are currently abandoning well-tested, well-understood user interface concepts in the ridiculous mad rush that everyone's suddenly decided they need to cram a tablet interface onto everything. And all of them are characterized by it being done in a very non-optional, non-incremental way - which in the case of Ubuntu at least is simply costing them users, but it's absurd that the lesson is being learnt by failure rather then critical thinking or careful design and iteration. See things like the MS Office "ribbon" - pretty much forced on users by corporate upgrade inertia, yet the actual underlying ribbon infrastructure can easily support old-style MS Office menus. So why doesn't it? Why, after discussing all their careful iteration to come up with the ribbon, did the people who designed it not think "we should put these features side-by-side and gather data on how people use it, and at what point they switch back, or how many do switch back?"
Apple - ironically - are currently the only ones being vaguely sensible about their desktop interfaces. How long they resist iOS'ing Mac OS will be interesting to see.
When you talk about "bloat" it's very unclear what you mean. What bloat, and do we care about it? If we're talking about my OS wanting 5 gb's of disk space - well who cares? That's not a problem except in some special case environments, and most of the time what I want (and the reason I still use Windows) is that bloat and long-chain of backwards compatibility. To date, Microsoft has done a very good job on this, since usually by the time something straight up stops working, we're at the point it's either been gradually replaced or can be fully emulated by modern hardware (there's nothing so joyous as finding out DosBox runs an old game you struggled to play a decade ago perfectly). It is a very dangerous path to consider dropping support for things as universally a good idea, and currently too many developers are buying into the idea that we should exactly that.
Postscript:
(I suspect the current trend is at least in part a foolish reaction to the web - which experienced a lot of added functionality in recent years to "bring it up" to being able to do what desktop apps do, but which gets implemented by dramatic overhauls of the experience. I think the issue is everyone's missed the big issue there: we already knew from the desktop most of what types of UI interfaces and elements work and should be implemented - which is very different from inventing brand new ones and then dumping them onto users, the the rise of client-side CSS editors should be considered as evidence).
I really doubt we're going to get there. My appraisal of the future would be that high-resolution high-DPI screens will start to win out (which we're seeing thanks to smart phones to some degree) and then someone will make a consumer-priced, lightweight VR-headset and that'll be the end of the laptop.
If you can track head-position/eye-gaze then you can after-all get away with using just the 1 screen and bringing content to the eyes as required.
The new Sony HMD isn't quite there yet, but it's a big step in the right direction.
More to life yes, but I suspect in marketing to the general consumer "1080" is now a secret codeword. Hollywood in reference to HDTV and Blu-Ray throws the term "1080p" around as the thing you want. Hell, it "feels" nice when I think about it. So for the average consumer it certainly sounds good.
It's just you, and other posters are right: for general purpose computing, it's not really so good because in working with documents, web-pages etc. everything we do is much more orientated towards "tall" resolutions (i.e. we work with portrait documents, not landscape).
One of my brothers runs 3 monitors and he has 1 24" screen configured specifically in a portrait configuration for this very reason.
Linux - essentially - desperately needs a good compatibility interface for DirectX and the gaming-relevant APIs.
It's called OpenGL and it's better than DirectX. Linux already has all the gaming APIs it needs, what it needs is more games and I don't know about you, but I don't want to get my games from the tired old publishers any more. How many ways are there to spell "yet another tired shooter".
This is the same logic that leads to Linux not having a decent implementation of useful features MS might put into their operating system -- for example the new Start menu.
It's chicken and egg -- no one's going to make games for Linux till there's a market, there won't be a market till you can play most games on Linux without needing to boot into Windows.
That means you need a compatibility layer.
Dealing with that situation as an end-user though is still a pain. Even if I can figure it out, it's one more thing I have to figure out.
Information like that needs to presented in an easy to digest manner straight to the user, and the relevant actions made available at a few clicks - not command line functions.
Agreed.
Gaming is a great big tether to keep my on Windows. I mean, I use it for other things, run other programs, do work on it etc. but since I'm going to keep it around for gaming anyway there's no real incentive to ever make the push since I know I'll always keep coming back to it.
Linux - essentially - desperately needs a good compatibility interface for DirectX and the gaming-relevant APIs. Or a way to get say, 90% of my graphics card's performance out of virtualized box of Windows for gaming without me having to boot away from Windows.
If something like that could be accomplished, we'd be in a much better position.
Complaining about Metro UI as a reason Windows sucks these days is idiotic in a world where Gnome 3 was created and Ubuntu lost it's damn mind and made Unity.
The whole world of computer interfaces has gone to hell very quickly because of tablets and people taking away all the exact wrong lessons from them.
This is the wrong answer - www.x2go.org
It is literally everything NX should have been (and uses SSH keys and authentication correctly).
The problem with DKMS is that it works fine up until the kernel guys change an interface. Then it breaks horribly.
Linux needs way more ABI stability then it currently has - ideally some very clear guidelines on when ABI's will change (which should be, between major version releases). It's not really acceptable to have device drivers get taken out by minor version kernel updates, and it's pretty absurd to religiously apply FOSS to hardware in the first place since I'm never not going to be buying hardware.
Does someone really need to post a list of SSH exploits which have been fixed?
On Windows and OSX, every application is (a) bloated because they have to ship all the dependencies and (b) has to either run some stupid auto-updater or be manually updated to get security fixes.
On (a): nobody cares. This isn't 1990. My laptop has a 750 gb hard drive. By far the biggest user of resources on my computer is graphics assets for applications. Not code libraries. Nobody - and I mean nobody - cares about 5 extra megabytes of libraries installed with every application. In fact in the vast majority of cases they want that feature, since it chokes out the risk of an upgrade introducing new bugs (and Win 7 went to considerable effort to provide that and undo the legacy "shared library" model). Let deduplicating filesystems or whatever take care of "app bloat"