I'm not the original poster, but I agree with him wholeheartedly. In my experience, tasks that can be easily parallelized work well in Solaris (web servers, polling servers, etc). However, tasks that are serial in nature (dealing with a stream of events like IDS or syslog) work *horribly* on Solaris.
When we moved some of our log parsing from Solaris/SPARC hardware to similarly priced Debian/x86 hardware, we expected a 3x improvement in performance just due to the CPU...we actually saw a 10x improvement in performance. We attributed this largely to Solaris' aggressive reservation of CPU cycles for other threads...even when we only had one.
Close, but not quite. By default, the MAC address of the interface is used for part of the address, but there's a possibility of collisions, still, so there is a whole system designed to make sure that two hosts don't use the same address, and what to choose if you do collide. If you're curious, Look up IPv6 Duplicate Address Detection.
Also, due to privacy concerns, there's talk of having systems automatically rotate their IPv6 address (the host part, anyway) every few minutes, to prevent tracking by sites like double-click. (there's also talk of having systems generate their address cryptographically...if you're curious about that one, have a look at CGA: cryptographically generated addresses...no, I'm not kidding.)
What if you want (as many enterprises do) to have some record of which MAC address was assigned to a given IP? Then you have to go to stateful DHCP6.
I'm going to bet almost every large network will end up running stateful DHCP6 for precisely this reason. Record-keeping and forensics are important...stateless autoconf makes that not work.
Then how do you deal with the intentionally ignorant? (Ie, those who might be able to tell that they're being used to launder money, but refuse to look?) Is willful ignorance also illegal? At what point does that line get crossed where you "should have known?"
It only seems to be a problem of scale because we haven't tried anything even remotely like it. Dyson spheres are a pipe dream because we have absolutely no idea what the practical issues are with building them.
In comparison, we are beginning to at least get a feel for what the problem space is for long-term longevity. Whether those problems are surmountable is still an open question, but we are at least starting to define the problem space.
I'm not entirely convinced that our future is in space at all. We may never build a Dyson sphere, because that may be a direction we never choose to go with our technology. We may never leave Earth, 'cause we may never feel the need. I don't know, but I do know that everyone who's tried to predict the future has been wrong.
1) My understanding of de Grey's aims are that he isn't trying for a Kurzweil-style upload. Instead, I think de Grey is aiming for standard biological longevity. This makes the upload kinda beside the point.
2) There are plenty of things that are theoretically possible, but practically infeasible for us to cause to happen: Large scale changes to the orbit of a planet, for example. What I'm wondering about is his view of the dividing line between the theoretically possible & the practically infeasible. What would it take to convince him that a 1000-year lifespan is on the other side of the "infeasible" line?
(On a side-note, the upload may also sit on the wrong side of the "technically infeasible" line. I've seen nothing to convince me to the contrary yet.)
Solar cells are still made from industrial chemical processes, so they're not necessarily very land-fill friendly (obviously, this depends on the chemical makeup of the cell)....and yes, the cells will wear out and require replacement.
Also, as a joker pointed out earlier, since they don't work at night, you need batteries...our battery technology is also fairly heavy on the heavy metals right now. These also wear out, often faster than the cells do.
In the case that the BLM are talking about, there are a number of interesting possibilities:
* How to bees/other insects react to light reflected back off large banks of cells? Does it mess with their navigation?
* Do any of the plans to get cables out to the banks of cells mess with the wildlife they're trying to protect?
* Do the cells have any (potentially) toxic runoff when hit with heavy rains/hail/etc?
* will any residual heat from the cells mess with the local flora/fauna? (if it's an area that's normally snow-covered in winter, what happens if the heat from the cells keeps it snow-free? Does that mess with any of the local plants cycles?)
If you really believe that anything that doesn't support IPv6 at this point is "legacy" you clearly haven't tried to implement it. A few things off the top of my head:
* Cisco IOS will route IPv6, but it does doesn't do it in hardware (it forces the packet up to the totally underpowered CPU of the router), so the packet rates are pathetic compared to IPv4.
* Until fairly recently, the Cisco PIX and ASA would route IPv6, but several major features (like failover) weren't available.
* Running NAC? I have yet to talk to a NAC vendor who supports IPv6.
* Many of the Security Information Manager products don't do IPv6, either (or they didn't the last time I checked).
* Heck, let's talk Windows XP. It theoretically supports IPv6, but it will only do DNS over IPv4.
The thing they're not talking about here is that to meet the mandate, the gov't networks have to be *capable* of passing IPv6, and have tested that they can. Turning IPv6 back off as soon as they confirm that test is totally within the bounds of compliance (and many agencies are doing exactly that).
In short, don't expect this to actually drive IPv6 adoption...this was a paperwork exercise.
Close. They will become the registRY. The registRAR must be one of the ICANN-approved ones (you can't require a non-ICANN registrar). It isn't clear from what I've read whether you can refuse to work with any registrar and make it a closed TLD. I would assume you can, though.
I'd love to say that you're right, but you know what? Compared to x86, SPARC performance still sucks for some tasks...especially serial (non-threaded) ones.
Example: we had a perl script processing high-volume syslog data & inserting it into a database. On sparc hardware, we had trouble getting the script to read any faster than about 600 messages per second. Switching to a similarly-priced x86 box, we max out somewhere around 4,000 messages per second.
Sun's heavy emphasis on threading makes *some* tasks work better. But, if your task is very serial (like reading & parsing syslog), SPARC just doesn't compete.
There needs to be some way to send something to someone without sending it to the world. I don't care what that technique is, just tell me what it is. Some way for me to send my recording to you, without giving you the right to profit from it, or to publicize it. There is such a way: it's called a contract.
In lieu of a contract, anything you send someone unsolicited is a gift.
The assumption is that R might be, say, Verisign's key that they use to generate SSL certificates, and that this is all an elaborate bluff to get us to break Verisign's key for them.
If that's the case, then the ransomers could never actually deliver on their promise to decrypt your files (barring some elaborate double-bluff, like always using the same encryption key, K).
It should be easy to determine if the ransomer's public key, R, belongs to one of the well-known certificate authorities, as they're both public knowledge...so, we should be able to just compare them. However, there is still the possibility that this is a very elaborate targeted attack against a non-public encryption key.
Why do you, the freedom-loving Americans, deny the people the basic right of moving anywhere they want to?
If you have no control over the membership of a group, you are subject to all sorts of problems when people join your group that intend to undermine it...and no, I'm not talking about terrorists. If you allow completely free movement, how do you deal with spies and competing country's saboteurs? Free movement of peoples leaves you completely open to active attack by hostile nations.
It'd be nice for there to be completely free movement. Until people stop being tribal jerks to one another, it's not going to happen.
Slashdot Mirror
I'm not the original poster, but I agree with him wholeheartedly. In my experience, tasks that can be easily parallelized work well in Solaris (web servers, polling servers, etc). However, tasks that are serial in nature (dealing with a stream of events like IDS or syslog) work *horribly* on Solaris.
When we moved some of our log parsing from Solaris/SPARC hardware to similarly priced Debian/x86 hardware, we expected a 3x improvement in performance just due to the CPU...we actually saw a 10x improvement in performance. We attributed this largely to Solaris' aggressive reservation of CPU cycles for other threads...even when we only had one.
And how many clients support that? None.
Close, but not quite. By default, the MAC address of the interface is used for part of the address, but there's a possibility of collisions, still, so there is a whole system designed to make sure that two hosts don't use the same address, and what to choose if you do collide. If you're curious, Look up IPv6 Duplicate Address Detection.
Also, due to privacy concerns, there's talk of having systems automatically rotate their IPv6 address (the host part, anyway) every few minutes, to prevent tracking by sites like double-click. (there's also talk of having systems generate their address cryptographically...if you're curious about that one, have a look at CGA: cryptographically generated addresses...no, I'm not kidding.)
What if you want (as many enterprises do) to have some record of which MAC address was assigned to a given IP? Then you have to go to stateful DHCP6.
I'm going to bet almost every large network will end up running stateful DHCP6 for precisely this reason. Record-keeping and forensics are important...stateless autoconf makes that not work.
Unless you want to use DNS...then your network admins need to set up a DHCP6 server. (yes, I think this is stupid.)
Admins will have to get used to trusting DNS
Except that we just got finished convincing the admins that DNS wasn't trustable, due to Dan Kaminsky.
Then how do you deal with the intentionally ignorant? (Ie, those who might be able to tell that they're being used to launder money, but refuse to look?) Is willful ignorance also illegal? At what point does that line get crossed where you "should have known?"
Change your profile picture to goatse...they should take card of the rest.
It only seems to be a problem of scale because we haven't tried anything even remotely like it. Dyson spheres are a pipe dream because we have absolutely no idea what the practical issues are with building them.
In comparison, we are beginning to at least get a feel for what the problem space is for long-term longevity. Whether those problems are surmountable is still an open question, but we are at least starting to define the problem space.
I'm not entirely convinced that our future is in space at all. We may never build a Dyson sphere, because that may be a direction we never choose to go with our technology. We may never leave Earth, 'cause we may never feel the need. I don't know, but I do know that everyone who's tried to predict the future has been wrong.
No, I don't consider Dyson spheres more feasible. There's a neat idea, but they're a pipe dream.
No, I really do mean ever. For two reasons:
1) My understanding of de Grey's aims are that he isn't trying for a Kurzweil-style upload. Instead, I think de Grey is aiming for standard biological longevity. This makes the upload kinda beside the point.
2) There are plenty of things that are theoretically possible, but practically infeasible for us to cause to happen: Large scale changes to the orbit of a planet, for example. What I'm wondering about is his view of the dividing line between the theoretically possible & the practically infeasible. What would it take to convince him that a 1000-year lifespan is on the other side of the "infeasible" line?
(On a side-note, the upload may also sit on the wrong side of the "technically infeasible" line. I've seen nothing to convince me to the contrary yet.)
Others have listed potential problems, I'm interested in the follow-up question to those: what do you look for to say "this won't work"?
Simply stating "I believe it can" is the realm of religion. What evidence would it take to convince you that it isn't possible after all?
Solar cells are still made from industrial chemical processes, so they're not necessarily very land-fill friendly (obviously, this depends on the chemical makeup of the cell)....and yes, the cells will wear out and require replacement.
Also, as a joker pointed out earlier, since they don't work at night, you need batteries...our battery technology is also fairly heavy on the heavy metals right now. These also wear out, often faster than the cells do.
In the case that the BLM are talking about, there are a number of interesting possibilities:
* How to bees/other insects react to light reflected back off large banks of cells? Does it mess with their navigation?
* Do any of the plans to get cables out to the banks of cells mess with the wildlife they're trying to protect?
* Do the cells have any (potentially) toxic runoff when hit with heavy rains/hail/etc?
* will any residual heat from the cells mess with the local flora/fauna? (if it's an area that's normally snow-covered in winter, what happens if the heat from the cells keeps it snow-free? Does that mess with any of the local plants cycles?)
So, it'll give me light, heat, *and* dinner? Tell me again why this is bad...
If you really believe that anything that doesn't support IPv6 at this point is "legacy" you clearly haven't tried to implement it. A few things off the top of my head:
* Cisco IOS will route IPv6, but it does doesn't do it in hardware (it forces the packet up to the totally underpowered CPU of the router), so the packet rates are pathetic compared to IPv4.
* Until fairly recently, the Cisco PIX and ASA would route IPv6, but several major features (like failover) weren't available.
* Running NAC? I have yet to talk to a NAC vendor who supports IPv6.
* Many of the Security Information Manager products don't do IPv6, either (or they didn't the last time I checked).
* Heck, let's talk Windows XP. It theoretically supports IPv6, but it will only do DNS over IPv4.
Vendor support for IPv6 has been pathetic.
The thing they're not talking about here is that to meet the mandate, the gov't networks have to be *capable* of passing IPv6, and have tested that they can. Turning IPv6 back off as soon as they confirm that test is totally within the bounds of compliance (and many agencies are doing exactly that).
In short, don't expect this to actually drive IPv6 adoption...this was a paperwork exercise.
Close. They will become the registRY. The registRAR must be one of the ICANN-approved ones (you can't require a non-ICANN registrar). It isn't clear from what I've read whether you can refuse to work with any registrar and make it a closed TLD. I would assume you can, though.
I'd love to say that you're right, but you know what? Compared to x86, SPARC performance still sucks for some tasks...especially serial (non-threaded) ones.
Example: we had a perl script processing high-volume syslog data & inserting it into a database. On sparc hardware, we had trouble getting the script to read any faster than about 600 messages per second. Switching to a similarly-priced x86 box, we max out somewhere around 4,000 messages per second.
Sun's heavy emphasis on threading makes *some* tasks work better. But, if your task is very serial (like reading & parsing syslog), SPARC just doesn't compete.
Or maybe we just like playing with language.
For example:
tits.tits tits.
tits tits tits tits.
titstitstitstitstitstitstitstitstitstits
It's such a wonderful word, isn't it? It's not a bad word...It sounds more like a snack. (yeah, yeah, I know...it is!)
(PS: Thank you George for making me giggle during one of my early make-out sessions....the above bit came into my head & totally ruined the moment.)postman hoc, propter hoc?
In lieu of a contract, anything you send someone unsolicited is a gift.
The assumption is that R might be, say, Verisign's key that they use to generate SSL certificates, and that this is all an elaborate bluff to get us to break Verisign's key for them.
If that's the case, then the ransomers could never actually deliver on their promise to decrypt your files (barring some elaborate double-bluff, like always using the same encryption key, K).
It should be easy to determine if the ransomer's public key, R, belongs to one of the well-known certificate authorities, as they're both public knowledge...so, we should be able to just compare them. However, there is still the possibility that this is a very elaborate targeted attack against a non-public encryption key.
Can we please have a moderation option for "missed the joke"?
If you have no control over the membership of a group, you are subject to all sorts of problems when people join your group that intend to undermine it...and no, I'm not talking about terrorists. If you allow completely free movement, how do you deal with spies and competing country's saboteurs? Free movement of peoples leaves you completely open to active attack by hostile nations.
It'd be nice for there to be completely free movement. Until people stop being tribal jerks to one another, it's not going to happen.