A more pertinent issue with Perspectives, as I see it, is that if someone MITM's very close to you
Ditto on the other side. It's impossible to distinguish a valid key change from an invalid one. Since the people attesting to the authenticity of a certificate have zero 'special' interaction, it remains feasible to fool them. It basically throws the baby out with the bathwater. The problem by and large is any singular CA can attest for any thing it feels like. A better approach would be: -DNSSEC secured results enumerating the CAs the site selected to secure the domain. If DigiNotar signs yourdomain.com and your DNSSEC says 'Thawte', then there is an issue. -Multiple CAs signing a certificate. If you have 3 or so CAs (all listed in your DNSSEC record of course), then compromising all three would be required to compromise your security. -A positive OSCP response should be required. Currently, even when OSCP is checked, if some return indicates 'general error' or 'try again later', that's taken as good enough. -Having a reputation system as an extra measure makes sense. Perhaps https without a 'padlock' given a positive reputation based read in absence of anything else, and if reputation and CA both check out, grant the visual indication of secure.
/dev/random is about as random as you'll get. I presume your issue is that the pool is exhausted for the given desire./dev/urandom is your endless of supply of 'good-enough' random for something like this. If your criticism is that it isn't really 'random', it's no less random than your pcap stream. Besides, given the application 'true' randomness will not be distinguishable from good pseudo-random.
If you wanted to be random and artistic, then maybe point a webcam at a fireplace or something as an entropy source.
I was thinking less about email and more about things like 'google reader', where I can share all day long on my own domain but my content will not be interleaved with others. email/jabber are nicely distributed, but some things do have an inherent network effect that is difficult to overcome.
I always go with local applications rather than webapps when possible. The issue is that with the google products I used, the critical aspect was how to get data to and from other people. Google reader takes away the only feature that made me use that instead of something else, but something else simply cannot realistically replace the 'sharing' capability without relying on some service that can be shut down at the whim of the provider.
Incidentally, why the hell did everyone start going with 'SaaS' instead of 'webapps'? The concept is nearly as old as the web itself.
The challenge is the risk of 'older' applications not being able to even *cope* with '/lib32'. It was easier to have newer apps change than break exisiting apps and hope for the best.
Incidently, you still have brand new MIPS, POWER, and Itanium in the world, though Itanium I think is going to stop 'any day now', but MIPS and POWER seem to be plateaued in share.
Yes, exactly my point. If you want to have it clean, you better avoid the/bin/lib mess.
The thing is the *nix philosophy for CLI apps has always been mostly small single-purposed utilities brought together on the fly to do more complex things. If *every* application has it's own bin dir, your path is an unmanageable mess *or* you have to fully qualify invoking applications. I for one do not savor the thought of '/opt/fileutils/bin/ls|/opt/gawk/bin/awk '{stuff}'|/opt/grep/bin/grep foo'.
This effort is fairly silly anyway. It only *really* has any impact in package-managed content which *already* is isolated at a layer other than the filesystem.
Keep in mind that many systems have many *terabytes* of data per compute node on local spindles. Boot volumes/partitions and many little apps may barely be a blip on the big drives of today, but a whole lot of stuff has a lot more data than you realize, *particularly* if they have a meaningful application of a distributed filesystem..
Ignoring virtualization overhead (which is a factor), if the storage is underutilized, yes a massive amount of cache/number of spindles a FC hop away in certain scenarios can blow away one or two local spindles. The problem is when you up utilization, the equation slips the other way. If you have low utilization or insane number of disks behind an FC compared to number of hosts in the SAN, the SAN can do better. Most places I see are heavily utilized on a relatively small amount of storage relative to number of systems due to pricing, and IO to dedicated disks reigns supreme.
I would say the 'hadoop-like' use case is the likely set of customers ready to entertain something as exotic as an ARM server anyway, so local disk very appropriate.
FC/FCoE/iSCSI all deliver much much lower aggregate I/O performance than coordinated use of direct attached storage. Google, Hadoop, GPFS, Lustre all facilitate that sort of usage. You will in any of those remote disk architecture have an I/O bottleneck along the line.
That said, I would presume netboot at least would be there, and from there you can do iSCSI in software certainly. FCoE tends to be a bit pickier, so they may not be able to do that in the network fabric provided.
On the whole, I'm skeptical still yet. So far ARM has proved itself when low power is critical and performance. I'm not sure if performance per watt is going to be impressive (e.g. if it hypothetically takes 10% of the power of a competitor and gave 9% of the performance, that can work well for places like cell phones but perhaps not so much for a datacenter). ARMv8 may make things very interesting though...
The issue is much of the 'metadata' that is externalized is meaningless outside of a specific context. For example, a song has some informational data that inarguably persists with the file (vintage, artist, cover art, etc) and some data that varies depending on the context (the rating the current listener ascribes to it, order in a playlist, or other data that has special meaning only in relation to something else like 'this is "our" song' isn't a universal attribute of a song.
Sadly, aside from the executable bit, Linux desktops are largely afflicted by this as well, as all the desktop environments have pretty much embraced extension based file typing.
Those filesystems are not designed primarily with your scenario in mind. If you want a hardware agnostic support, use software RAID or a non-cluster filesystem like ZFS.
Distributing your storage will probably not enhance your ability to survive a mishap. In fact, the complexity of the situation probably increases your risk of messing up your data (I have heard more than a couple of instances of someone accidentally destroying all the contents of a distributed filesystem, but in those professional contexts they have a real backup strategy. You'll be pissing away money on power to drive multiple computers that you really don't need to power.
If you care about catastrophic recovery, you need a real backup solution. This may mean identifying what's "important" from a practical home situation. If you don't mind downtime so long as your data is accessible in a day or two (e.g. time to get replacement parts) without going to your backup media and without suffering the loss of non-critical data, then also having a software raid or ZFS is the way to go. If you want to avoid downtime (within reason), get yourself a box with basic redundancy designed into it like a tower server from Dell/HP/IBM. If Intel, you would sadly want to go Xeon to get ECC, on AMD you can get ECC cheaper. In terms of drive count, I'd dial it back to 4 3TB drives in a RAID5 (or 5 in RAID6 if you wanted), safe on power and reduce risk in the system.
The problem is not that the interface is accessible to people with no training and therefore not 'exclusive' enough for power users. The problem is a lack of capability that can be found in more complex UIs. Considering those are pre-unity compiz and KDE, they aren't particularly complex at the surface, just complex when you dig into it.
Anybody can tie a bunch of processors together and connect them to a thousand hard drives
You really have no idea whatsoever what is involved in these configurations. Network topologies to actually have those work *efficiently* together is not as simple as 'slap a bunch of ethernet switches together'.
Show me a screaming fast processor that breaks the 3 GHz ceiling (I hear AMD is working on 5GHz...) and I'll be impressed.
First off, what 3 Ghz ceiling? AMD and Intel both have processors that exceed that per-core. Second, GHz isn't everything (I thought most of the world learned that with Pentium 4's ludicrous clockspeeds yet crappy performance).
In this scenario, IPv6 would alleviate the need to so aggressively reuse IP addresses in that scenario.
Of course, one wonders given the high amount of traffic if amazon is needlessly changing addresses. They probably should make more effort to have a tendency to be more persistent even beyond the 'promise' of the ttl. Sort of how in most DHCP servers, even when your lease expires you'll still often get the last address you had because the DHCP server retained it anyway unless pool exhaustion forces a change.
It seems every day an ugly wart of public 'cloud' hosting crops up. People with remotely interesting workloads should be wary.
Secure boot will be enabled by the likes of Dell, IBM, and HP, *but* their respective service processors would allow install of new platform keys given authentication. It's the only way they could get Windows 8 logo (which *will* continue to matter greatly) and the *only* way they can sell into half the market (large-scale, auto-deployed non-Windows systems). They would have to be careful not to do something like allow keys to be manipulated via in-band IPMI.
Indeed. vim is impossible for a first-time user. That does not mean it is a terrible editor. Over-emphasizing day 1 productivity is a bad thing when most of your days will not be 'day 1'.
To be fair, the prius has some heavy batteries to contend with. Though yeah, a DeLorean with an electric drive would be easily in the weight area of the big name electric vehicles, though probably not nearly as safe in the event of an accident.
Mobile just means more legs to potentially call about. If I'm at home, I have to (rarely) call my internet provider. Not because I'm inept, but to report/get status on an outage.
If my work VPN disables my account for one reason or another, I have to call to get it restored.
If my mail server is out (actually hasn't happened to me in the last 8 years), then I'd have to call.
It's not always about what you know/don't know how to do, sometimes you need something done that you can't actually do yourself.
Not to mention the likelihood of the arrival of Sandy Bridge systems, Kepler and Southern Islands GPUs providing competitors that aren't big in the news at the moment.
By the end of 2012, even the optimistic end of the scale at 20 petaflops probably won't be #1. If #1 is a BlueGene, it will probably use less electricity than Titan while still getting higher numbers, though either way programmers will have a bit of a struggle vs. big traditional CPU based systems.
Stuffing paper money into a mattress into a bank would have approximately the same effect, with about the same amount of safety in the face of your house burning down.
Bitcoin is heralded as taking back control of your money and just keeping everything in your 'wallet'. People got worried; the 'wallet' can't be trivially backed up/restored, if you lose your one copy of the 'wallet', it's gone for good, etc. Then people started setting up 'banks' so that your 'wallet' would be stored in an institution with presumably better data reliability practices. Congratulations, you've gotten to step one, putting control of the money back in the hands of financial institutions.
The other point trotted out is appealing to gold standard fanatics as being resistant to market manipulation due to the inherent fixed 'amount' of bitcoin in the world, not subject to being 'printed' to devalue. Now you have bitcoin exchanges where the value of a bitcoin relative to 'real' money is assessed. You have bitcoin value speculation on the exchanges and there have been bitcoin bubbles and busts in terms of value. In fact, it's had more volatility in value than the US Dollar.
Bitcoin is a failed experiment. For all the noise about it being a fixed amount of value, liberating people from banks, and so on and so forth, it has gone right back to the status quo in its (limited) application.
With CD, there wasn't a real good 'legacy' technology to transition from that had a strong competitor to CD.
This would be more like Intel releasing a new x86 processor that is *almost* as good as a hypothetical ARM chip that beats the x86 offering on price, performance, and electricity usage. The market may fail the ARM chips because x86 can at least run N-1 things. USB 3.0 is a single connector that services tons of 'legacy' usage, is technically worse than Thunderbolt *but* not so much so that anyone will notice. It's actually very reminiscent of USB v. Firewire.
Slashdot Mirror
A more pertinent issue with Perspectives, as I see it, is that if someone MITM's very close to you
Ditto on the other side. It's impossible to distinguish a valid key change from an invalid one. Since the people attesting to the authenticity of a certificate have zero 'special' interaction, it remains feasible to fool them. It basically throws the baby out with the bathwater. The problem by and large is any singular CA can attest for any thing it feels like. A better approach would be:
-DNSSEC secured results enumerating the CAs the site selected to secure the domain. If DigiNotar signs yourdomain.com and your DNSSEC says 'Thawte', then there is an issue.
-Multiple CAs signing a certificate. If you have 3 or so CAs (all listed in your DNSSEC record of course), then compromising all three would be required to compromise your security.
-A positive OSCP response should be required. Currently, even when OSCP is checked, if some return indicates 'general error' or 'try again later', that's taken as good enough.
-Having a reputation system as an extra measure makes sense. Perhaps https without a 'padlock' given a positive reputation based read in absence of anything else, and if reputation and CA both check out, grant the visual indication of secure.
/dev/random is about as random as you'll get. I presume your issue is that the pool is exhausted for the given desire. /dev/urandom is your endless of supply of 'good-enough' random for something like this. If your criticism is that it isn't really 'random', it's no less random than your pcap stream. Besides, given the application 'true' randomness will not be distinguishable from good pseudo-random.
If you wanted to be random and artistic, then maybe point a webcam at a fireplace or something as an entropy source.
I was thinking less about email and more about things like 'google reader', where I can share all day long on my own domain but my content will not be interleaved with others. email/jabber are nicely distributed, but some things do have an inherent network effect that is difficult to overcome.
I always go with local applications rather than webapps when possible. The issue is that with the google products I used, the critical aspect was how to get data to and from other people. Google reader takes away the only feature that made me use that instead of something else, but something else simply cannot realistically replace the 'sharing' capability without relying on some service that can be shut down at the whim of the provider.
Incidentally, why the hell did everyone start going with 'SaaS' instead of 'webapps'? The concept is nearly as old as the web itself.
The challenge is the risk of 'older' applications not being able to even *cope* with '/lib32'. It was easier to have newer apps change than break exisiting apps and hope for the best.
Incidently, you still have brand new MIPS, POWER, and Itanium in the world, though Itanium I think is going to stop 'any day now', but MIPS and POWER seem to be plateaued in share.
Yes, exactly my point. If you want to have it clean, you better avoid the /bin /lib mess.
The thing is the *nix philosophy for CLI apps has always been mostly small single-purposed utilities brought together on the fly to do more complex things. If *every* application has it's own bin dir, your path is an unmanageable mess *or* you have to fully qualify invoking applications. I for one do not savor the thought of '/opt/fileutils/bin/ls|/opt/gawk/bin/awk '{stuff}'|/opt/grep/bin/grep foo'.
This effort is fairly silly anyway. It only *really* has any impact in package-managed content which *already* is isolated at a layer other than the filesystem.
Keep in mind that many systems have many *terabytes* of data per compute node on local spindles. Boot volumes/partitions and many little apps may barely be a blip on the big drives of today, but a whole lot of stuff has a lot more data than you realize, *particularly* if they have a meaningful application of a distributed filesystem..
Ignoring virtualization overhead (which is a factor), if the storage is underutilized, yes a massive amount of cache/number of spindles a FC hop away in certain scenarios can blow away one or two local spindles. The problem is when you up utilization, the equation slips the other way. If you have low utilization or insane number of disks behind an FC compared to number of hosts in the SAN, the SAN can do better. Most places I see are heavily utilized on a relatively small amount of storage relative to number of systems due to pricing, and IO to dedicated disks reigns supreme.
I would say the 'hadoop-like' use case is the likely set of customers ready to entertain something as exotic as an ARM server anyway, so local disk very appropriate.
FC/FCoE/iSCSI all deliver much much lower aggregate I/O performance than coordinated use of direct attached storage. Google, Hadoop, GPFS, Lustre all facilitate that sort of usage. You will in any of those remote disk architecture have an I/O bottleneck along the line.
That said, I would presume netboot at least would be there, and from there you can do iSCSI in software certainly. FCoE tends to be a bit pickier, so they may not be able to do that in the network fabric provided.
On the whole, I'm skeptical still yet. So far ARM has proved itself when low power is critical and performance. I'm not sure if performance per watt is going to be impressive (e.g. if it hypothetically takes 10% of the power of a competitor and gave 9% of the performance, that can work well for places like cell phones but perhaps not so much for a datacenter). ARMv8 may make things very interesting though...
The issue is much of the 'metadata' that is externalized is meaningless outside of a specific context. For example, a song has some informational data that inarguably persists with the file (vintage, artist, cover art, etc) and some data that varies depending on the context (the rating the current listener ascribes to it, order in a playlist, or other data that has special meaning only in relation to something else like 'this is "our" song' isn't a universal attribute of a song.
, mostly confined to Windows and OS X today.
Sadly, aside from the executable bit, Linux desktops are largely afflicted by this as well, as all the desktop environments have pretty much embraced extension based file typing.
Those filesystems are not designed primarily with your scenario in mind. If you want a hardware agnostic support, use software RAID or a non-cluster filesystem like ZFS.
Distributing your storage will probably not enhance your ability to survive a mishap. In fact, the complexity of the situation probably increases your risk of messing up your data (I have heard more than a couple of instances of someone accidentally destroying all the contents of a distributed filesystem, but in those professional contexts they have a real backup strategy. You'll be pissing away money on power to drive multiple computers that you really don't need to power.
If you care about catastrophic recovery, you need a real backup solution. This may mean identifying what's "important" from a practical home situation. If you don't mind downtime so long as your data is accessible in a day or two (e.g. time to get replacement parts) without going to your backup media and without suffering the loss of non-critical data, then also having a software raid or ZFS is the way to go. If you want to avoid downtime (within reason), get yourself a box with basic redundancy designed into it like a tower server from Dell/HP/IBM. If Intel, you would sadly want to go Xeon to get ECC, on AMD you can get ECC cheaper. In terms of drive count, I'd dial it back to 4 3TB drives in a RAID5 (or 5 in RAID6 if you wanted), safe on power and reduce risk in the system.
The problem is not that the interface is accessible to people with no training and therefore not 'exclusive' enough for power users. The problem is a lack of capability that can be found in more complex UIs. Considering those are pre-unity compiz and KDE, they aren't particularly complex at the surface, just complex when you dig into it.
Anybody can tie a bunch of processors together and connect them to a thousand hard drives
You really have no idea whatsoever what is involved in these configurations. Network topologies to actually have those work *efficiently* together is not as simple as 'slap a bunch of ethernet switches together'.
Show me a screaming fast processor that breaks the 3 GHz ceiling (I hear AMD is working on 5GHz...) and I'll be impressed.
First off, what 3 Ghz ceiling? AMD and Intel both have processors that exceed that per-core. Second, GHz isn't everything (I thought most of the world learned that with Pentium 4's ludicrous clockspeeds yet crappy performance).
Maybe he was a big fan of Chrismas Eve?
(Oct 30 = Dec24)
In this scenario, IPv6 would alleviate the need to so aggressively reuse IP addresses in that scenario.
Of course, one wonders given the high amount of traffic if amazon is needlessly changing addresses. They probably should make more effort to have a tendency to be more persistent even beyond the 'promise' of the ttl. Sort of how in most DHCP servers, even when your lease expires you'll still often get the last address you had because the DHCP server retained it anyway unless pool exhaustion forces a change.
It seems every day an ugly wart of public 'cloud' hosting crops up. People with remotely interesting workloads should be wary.
Secure boot will be enabled by the likes of Dell, IBM, and HP, *but* their respective service processors would allow install of new platform keys given authentication. It's the only way they could get Windows 8 logo (which *will* continue to matter greatly) and the *only* way they can sell into half the market (large-scale, auto-deployed non-Windows systems). They would have to be careful not to do something like allow keys to be manipulated via in-band IPMI.
Indeed. vim is impossible for a first-time user. That does not mean it is a terrible editor. Over-emphasizing day 1 productivity is a bad thing when most of your days will not be 'day 1'.
To be fair, the prius has some heavy batteries to contend with. Though yeah, a DeLorean with an electric drive would be easily in the weight area of the big name electric vehicles, though probably not nearly as safe in the event of an accident.
Mobile just means more legs to potentially call about. If I'm at home, I have to (rarely) call my internet provider. Not because I'm inept, but to report/get status on an outage.
If my work VPN disables my account for one reason or another, I have to call to get it restored.
If my mail server is out (actually hasn't happened to me in the last 8 years), then I'd have to call.
It's not always about what you know/don't know how to do, sometimes you need something done that you can't actually do yourself.
Not to mention the likelihood of the arrival of Sandy Bridge systems, Kepler and Southern Islands GPUs providing competitors that aren't big in the news at the moment.
By the end of 2012, even the optimistic end of the scale at 20 petaflops probably won't be #1. If #1 is a BlueGene, it will probably use less electricity than Titan while still getting higher numbers, though either way programmers will have a bit of a struggle vs. big traditional CPU based systems.
But what about per-page advertising? Think of the advertisers!
The key here is I'm willing to believe Dart can be 'much better', because really, being 'much better' than Javascript is a pretty low bar.
Stuffing paper money into a mattress into a bank would have approximately the same effect, with about the same amount of safety in the face of your house burning down.
Bitcoin is heralded as taking back control of your money and just keeping everything in your 'wallet'. People got worried; the 'wallet' can't be trivially backed up/restored, if you lose your one copy of the 'wallet', it's gone for good, etc. Then people started setting up 'banks' so that your 'wallet' would be stored in an institution with presumably better data reliability practices. Congratulations, you've gotten to step one, putting control of the money back in the hands of financial institutions.
The other point trotted out is appealing to gold standard fanatics as being resistant to market manipulation due to the inherent fixed 'amount' of bitcoin in the world, not subject to being 'printed' to devalue. Now you have bitcoin exchanges where the value of a bitcoin relative to 'real' money is assessed. You have bitcoin value speculation on the exchanges and there have been bitcoin bubbles and busts in terms of value. In fact, it's had more volatility in value than the US Dollar.
Bitcoin is a failed experiment. For all the noise about it being a fixed amount of value, liberating people from banks, and so on and so forth, it has gone right back to the status quo in its (limited) application.
With CD, there wasn't a real good 'legacy' technology to transition from that had a strong competitor to CD.
This would be more like Intel releasing a new x86 processor that is *almost* as good as a hypothetical ARM chip that beats the x86 offering on price, performance, and electricity usage. The market may fail the ARM chips because x86 can at least run N-1 things. USB 3.0 is a single connector that services tons of 'legacy' usage, is technically worse than Thunderbolt *but* not so much so that anyone will notice. It's actually very reminiscent of USB v. Firewire.