By knowing the IP address of the problem, you know the precise location of the problem from a network point of view.
With IPv4, you don't. It's classless with arbitrary subnetting.
With IPv6, the 16 bits before identify the precise location on the network of the feed going in. No hunting up GeoIP maps. Don't need em.
The 16 bits that change at the break, and ONLY 16 bits will have changed at a time, that is guaranteed, you know the precise location on the network of the specific fault. Remember, an interface has an address, not a machine, and addresses are based on upstream prefixes.
The prefix always comes from upstream.
And that means you know the direction of the link, where each side is located, even what manufacture each router is if the MAC is physical not altered or logical.
What else do you know? IPv6 is self-healing. It'll fix breaks if it can, without losing any connections and with renumbering the doenstream network if necessary.
So if there's a problem, you can afford to be more aggressive. It won't hurt, unlike IPv4 which can't cope.
Real IPv6, the original specification, had one mode, autoconfigure. No DHCP, no static, just autoconfigure. There was no need for anything else.
(By the eay, IPv4 has RARP, BOOTP as well as static and DHCP, where DHCP may be static or dynamic. And unlike IPv6, you can't mix.)
It's the barbarians who refused the elegant simplicity and demanded to bring over IPv4 detrius that ruined that simplicity.
Real IPv6, original specification, had no fragmentation, no NAT, no forwarding boxes for mobility. Multihoming was one address on one virtual interface.
The format is: (type):(network prefix):(computer suffix)
How, exactly, is that hard?
There are dead people who can understand that.
As noted by others, you can never have::::
Since the prefix describes a path, it will typically have no long sequences of zeroes. You get those between the prefix and suffix.
So it's more likely you'll get: (type):(prefix)::(suffix)
What if you want to use your IPv4 address as your suffix? That's fine.::(ipv4) is a perfectly valid suffix.
5f0b:1700:c047:1400::800:200d:1cfe
Would refer to the test network (5f0b), with a network address of 1700:c047:1400 and a computer address of 800:200d:1cfe
This is not rocket science.
With DDNS servers, you can have the name be assigned an IP address by construction at time of connection. Everyone else will.
As a result, your computer will be fed live DDNS updates as the Internet changes, for computers you care about and no others.
When querying the nameserver heirarchy for an address, you get the current address. That information will be guaranteed fresh because state information for MobileIP traverses the Internet. It has to. And it contains the instruction that whatever went to one prefix now goes to another. Your DDNS will adjust accordingly.
A five year old can master the idea that if you've gone for a walk, a different road will lead to the same endpoint (the car).
I have no sympathy for those who lack the navigational skills of a five year old.
The original design stated that the design of the IP addresses was guaranteed heirarchical (so machines only ever looked at a 16-bit value at a time, so using less time and less hardware) and that DDNS made this largely irrelevant except to engineers.
Who would naturally prefer a telescopic address where they need only look at 16 bits.
It's why the original specification mandated encryption. Not at endpoints, but at tunnels. So neither your MAC address nor your data was ever visible.
Since you could set your MAC address, it wouldn't have mattered much anyway. You didn't own an IP address, you owned access to a router, or as many routers as you liked. Your IP was generated from the path and what you advertised.
The alarmists are the ones claiming nothing is wrong other than the scientists. The alarmists are the ones who believe that by killing opponents will change the world.
When you've 10 gigabits to the home, 6 gigabits isn't so bad.
Interlaced degrades resolution, but nobody needs the full resolution.
You make the assumption that lossy compression and lossless compression are the same.
Efficient representation is not compression. OpenEXR doesn't use image compression but supports a much wider dynamic range than the bit count suggests.
There's no need for compression in a movie. You're not transmitting over slow data links unless it's a broadcast. Lossless compression is tolerable but what's the point?
I agree on colour. OpenEXR is good and is used by ILM. Who also invented it. Any 48-bit format should work, but to get movie-level dynamic range, you need a mantissa-exponent format for your three colours.
Modern stuff is filmed on digital devices no better in quality than the images are designed to be shown at.
Old film stock, particularly if it was good quality, doubly if it was also medium, supported a very high dynamic range and a reasonably impressive resolution. You need an 80 megapixel camera to match the very best film camera.
So it depends on how good 2001's film stock was.
You must also consider audience. Those likely to have the money will be the richer end of the arthouse types, and 2001 is an arthouse movie.
Let's take a hypothetical. For all scenes not involving people, they build every single model in a computer and use photon tracing plus photon mapping for each and every frame, so you've as good a render as we've the science to produce.
From there, they've a few options.
They can transfer shading onto the digitized frames, to bring the dynamic range up to whatever they like. That won't alter the content but will restore colours and intensities to something nearer the original.
They can repair film defects without eliminating real detail because they'll know what's supposed to be there.
They can replace defective backdrop with a photorealistic simulation of what the backdrop shows.
This won't work if you have people who can alter the scene, because you can't (yet) render models of people and the only way to make this work is if you duplicate every scene precisely, so have a photorealistic virtual movie with all the physical objects present. That way, reflections, refractions, edge effects and shadows are all correct. CGI fails because these are ignored most of the time.
This won't work if you don't use both raytracing and radiosity, because the former can't handle diffuse reflections and the latter can't handle direct. Basic forms of these won't work, you get artefacts that'll look gnarly. That's why studio CGI uses Renderman-style shading. It's crude, primitive and ugly, but doesn't hit uncanny valley.
You're now talking serious compute power. If you thought Titanic took a lot, this proposal would require 480 times as many compute nodes, even allowing for the faster computers these days.
But it could be done. The software exists, the number of machines is finite if large, the models would be incredibly difficult to create but certainly not impossible.
The catch is that you're computer generating the model shots, simulating identical materials and identical colour schemes, under identical conditions. The results should be identical. Which is the entire point, but also the catch. It's a lot of money, time and effort to fix the subtlest of production errors.
And, on a more realistic note, you can do scaled down versions for a lot less money, time and effort.
A star backdrop isn't affected by the foreground, so you can render that from multiple camera angles and paste over. As long as the stars were in the correct positions, the start and end should differ only in the fact that backdrops will be reflecting light, rendered stars won't.
The moon scenes may be doable, because everyone is suited up. But you absolutely can't be even one subpixel out. Again, starts adding expense.
No, I think CGI, good, really good CGI could be used to fix star backdrops but I think it's going to have to be limited to that unless someone has a lot of money for vanity projects.
Slashdot Mirror
Easy, with IPv6.
By knowing the IP address of the problem, you know the precise location of the problem from a network point of view.
With IPv4, you don't. It's classless with arbitrary subnetting.
With IPv6, the 16 bits before identify the precise location on the network of the feed going in. No hunting up GeoIP maps. Don't need em.
The 16 bits that change at the break, and ONLY 16 bits will have changed at a time, that is guaranteed, you know the precise location on the network of the specific fault. Remember, an interface has an address, not a machine, and addresses are based on upstream prefixes.
The prefix always comes from upstream.
And that means you know the direction of the link, where each side is located, even what manufacture each router is if the MAC is physical not altered or logical.
What else do you know? IPv6 is self-healing. It'll fix breaks if it can, without losing any connections and with renumbering the doenstream network if necessary.
So if there's a problem, you can afford to be more aggressive. It won't hurt, unlike IPv4 which can't cope.
Most of that was to placate the unwashed hordes.
Real IPv6, the original specification, had one mode, autoconfigure. No DHCP, no static, just autoconfigure. There was no need for anything else.
(By the eay, IPv4 has RARP, BOOTP as well as static and DHCP, where DHCP may be static or dynamic. And unlike IPv6, you can't mix.)
It's the barbarians who refused the elegant simplicity and demanded to bring over IPv4 detrius that ruined that simplicity.
Real IPv6, original specification, had no fragmentation, no NAT, no forwarding boxes for mobility. Multihoming was one address on one virtual interface.
How much simpler can you get??!
Those addresses aren't possible, so irrelevant.
The format is: (type):(network prefix):(computer suffix)
How, exactly, is that hard?
There are dead people who can understand that.
As noted by others, you can never have ::::
Since the prefix describes a path, it will typically have no long sequences of zeroes. You get those between the prefix and suffix.
So it's more likely you'll get: (type):(prefix)::(suffix)
What if you want to use your IPv4 address as your suffix? That's fine. ::(ipv4) is a perfectly valid suffix.
5f0b:1700:c047:1400::800:200d:1cfe
Would refer to the test network (5f0b), with a network address of 1700:c047:1400 and a computer address of 800:200d:1cfe
This is not rocket science.
With DDNS servers, you can have the name be assigned an IP address by construction at time of connection. Everyone else will.
As a result, your computer will be fed live DDNS updates as the Internet changes, for computers you care about and no others.
When querying the nameserver heirarchy for an address, you get the current address. That information will be guaranteed fresh because state information for MobileIP traverses the Internet. It has to. And it contains the instruction that whatever went to one prefix now goes to another. Your DDNS will adjust accordingly.
A five year old can master the idea that if you've gone for a walk, a different road will lead to the same endpoint (the car).
I have no sympathy for those who lack the navigational skills of a five year old.
The original design stated that the design of the IP addresses was guaranteed heirarchical (so machines only ever looked at a 16-bit value at a time, so using less time and less hardware) and that DDNS made this largely irrelevant except to engineers.
Who would naturally prefer a telescopic address where they need only look at 16 bits.
Everyone else should exclusively use names.
With IPv6, your computer generates a universally unique ID that allows connections to be sent to your current hotspot.
Radvd allows the prefix to be attacged to your computer's suffix to make a unique IP address.
Dynamic DNS ensures that if your computer is named, the name is usable for your current hotspot endpoint.
MTU discovery ensures that there is zero fragmentation, so no problems with stateless firewalls.
That could claim infinite end points is TUBA, one of the other IPng contenders.
The only history that matters is IPng and IPv6 draft, prior to RFC status and then when IPSec is ratified.
But, then, you don't want history. You much prefer your pram.
It's why the original specification mandated encryption. Not at endpoints, but at tunnels. So neither your MAC address nor your data was ever visible.
Since you could set your MAC address, it wouldn't have mattered much anyway. You didn't own an IP address, you owned access to a router, or as many routers as you liked. Your IP was generated from the path and what you advertised.
Total anonymity and total privacy.
No, that's the view of the right.
The left doesn't dominate. That is how it is defined.
The alarmists are the ones claiming nothing is wrong other than the scientists. The alarmists are the ones who believe that by killing opponents will change the world.
Coal is subsidized to the tune of 22 trillion a year.
You are armed because you are a moron. Not all armed people are morons, it just happens you're one.
When you've 10 gigabits to the home, 6 gigabits isn't so bad.
Interlaced degrades resolution, but nobody needs the full resolution.
You make the assumption that lossy compression and lossless compression are the same.
Efficient representation is not compression. OpenEXR doesn't use image compression but supports a much wider dynamic range than the bit count suggests.
Path tracing is different from any other form of raytacing how? Sill has the same limitation because light doesn't reflect in lines. There is no path.
https://tools.ietf.org/html/rf...
https://tools.ietf.org/html/rf...
This protocol was assigned v8 by the IANA.
It's old, antiquated technology the libertarians and conservatives killed in the 90s.
Already defined.
Those are not new addresses, they're cohabited old addresses. Same way a block of flats is one building, not a hundred.
Easy.
The top two bytes identify packet type.
The next two bytes are the ID of a router.
The next two bytes are the ID of a router on a given connection.
And so on, until you reach 48 bits that identify the computer on a router.
From any given point, you care about the two bytes above and either the two bytes below or the 6 bytes below if they're the last 6.
It's the equivalent of being given directions. Take a left at the third roundabout, then take a right at the second traffic light.
There's no nine year old outside of vegetative state that can't understand that. V4 is far more complex.
Uh, no it wasn't. Indeed, IPv6 was intended to prevent any monitoring at all.
Linux is the kernel. For OSS, you want GNU or BSD userspace over a Linux kernelspace, GNU/Linux and BSD/Linux respectively.
Japan has gigabit and ten gigabit links to the home.
8K at 24bpp at 60 fps would be 47,775,744,000 gigabits per second.
Ok, not doing to be able to do that on a 10 gig link.
But you only need to compress it to a fifth that.
No problem, even with lossless compression, you can reduce the frames substantially, and an old movie can be shown at a far lower frame rate.
And not a compression artefact in sight.
There's no need for compression in a movie. You're not transmitting over slow data links unless it's a broadcast. Lossless compression is tolerable but what's the point?
I agree on colour. OpenEXR is good and is used by ILM. Who also invented it. Any 48-bit format should work, but to get movie-level dynamic range, you need a mantissa-exponent format for your three colours.
Modern stuff is filmed on digital devices no better in quality than the images are designed to be shown at.
Old film stock, particularly if it was good quality, doubly if it was also medium, supported a very high dynamic range and a reasonably impressive resolution. You need an 80 megapixel camera to match the very best film camera.
So it depends on how good 2001's film stock was.
You must also consider audience. Those likely to have the money will be the richer end of the arthouse types, and 2001 is an arthouse movie.
You understand your website has more errors than an Enron accounts book?
Let's take a hypothetical. For all scenes not involving people, they build every single model in a computer and use photon tracing plus photon mapping for each and every frame, so you've as good a render as we've the science to produce.
From there, they've a few options.
They can transfer shading onto the digitized frames, to bring the dynamic range up to whatever they like. That won't alter the content but will restore colours and intensities to something nearer the original.
They can repair film defects without eliminating real detail because they'll know what's supposed to be there.
They can replace defective backdrop with a photorealistic simulation of what the backdrop shows.
This won't work if you have people who can alter the scene, because you can't (yet) render models of people and the only way to make this work is if you duplicate every scene precisely, so have a photorealistic virtual movie with all the physical objects present. That way, reflections, refractions, edge effects and shadows are all correct. CGI fails because these are ignored most of the time.
This won't work if you don't use both raytracing and radiosity, because the former can't handle diffuse reflections and the latter can't handle direct. Basic forms of these won't work, you get artefacts that'll look gnarly. That's why studio CGI uses Renderman-style shading. It's crude, primitive and ugly, but doesn't hit uncanny valley.
You're now talking serious compute power. If you thought Titanic took a lot, this proposal would require 480 times as many compute nodes, even allowing for the faster computers these days.
But it could be done. The software exists, the number of machines is finite if large, the models would be incredibly difficult to create but certainly not impossible.
The catch is that you're computer generating the model shots, simulating identical materials and identical colour schemes, under identical conditions. The results should be identical. Which is the entire point, but also the catch. It's a lot of money, time and effort to fix the subtlest of production errors.
And, on a more realistic note, you can do scaled down versions for a lot less money, time and effort.
A star backdrop isn't affected by the foreground, so you can render that from multiple camera angles and paste over. As long as the stars were in the correct positions, the start and end should differ only in the fact that backdrops will be reflecting light, rendered stars won't.
The moon scenes may be doable, because everyone is suited up. But you absolutely can't be even one subpixel out. Again, starts adding expense.
No, I think CGI, good, really good CGI could be used to fix star backdrops but I think it's going to have to be limited to that unless someone has a lot of money for vanity projects.