Maybe they will dump fixed 128-bit addresses, and make them variable length instead, so that new addresses may be allocated where they are needed...
This is really a terrific idea... Picture higher-level routers that only recognize the first IPv4 part of the address and pass packets on to the leaf routers. Such a protocol would require only minimal and thus cheap upgrade of firmware for most hardware on the Internet, not to mention that their 32-bit CPU's would still perfectly do the job.
And so the whole address space would become a tree, just like the domain name system.
(After all, for simplicity of the user-end routing devices, each node's MAC address can be appended to the 4-byte IP address, for example, which will turn IPv4 into the forgotten IPX... The first 2-3 bytes of the MAC address can be changed in each node to reflect the local tree structure in your LAN/WAN. Something like NAT, but with a bit more complicated IPX-like structure in your private network... TCPX?)
As for other "benefits" of IPv6... Autoconfiguration is dangerous since it can be spoofed in large and weakly controlled LAN's. I never really trust DHCP, UPnP and other "smart" guys and try to avoid them whenever possible.
As a consequence of cellular phones, nobody knows anyone else's number any more.
Hmm... And if someone asks for someone else's phone number you tell them 'Greg', like your cell phone shows it to you?:)
Seriously... You not always refer to the DNS system since lookups take time. For one, you are analyzing huge logs with raw IP numbers and you don't have the time to run lookups.
Besides, I can't imagine programming/maintaining complex routers without messing with numeric addresses. So, short and memorable numbers are practical. I'm really sceptical about IPv6 and I encourage everyone (especially great hackers) to re-think before we accept it.
So instead of having to remember ff:ab:3a:53:5a:f1:20:1b you just use "www.example.com"
That's you, not me. Any sysadmin will have to deal with numeric IPs despite the promised IPv6 automation tools. It's [almost] like saying alphabetical phone numbers for the 60-digit system (in my example) would solve it all. Some things must be readable/maintainable by humans, too.
(They must be hating IPv6 as well:) To all great hackers: please stop this IPv6 hysteria! It's like replacing the 10-digit phone numbers with 60-digit ones. Would you remember your friends phone number that looks like
Today we all deal with more or less programmable devices such like TV or CD/DVD/MP3 or whatever players, cameras, and even cars (that have full-blown onboard computers). Everyone learns to program to some extent, be it via remote or by plugging a notebook to a device.
Generally speaking, every user interface is also a programming interface. Today you just drive your car or change the channels on your TV, tomorrow you will somehow program it to find your favorite movie or you will program your car to automatically park the way you want it to park in the backyard. Would you share your parking sequence with friends? No doubt about it.
Now consider in just 100 years everyone in this world becomes a programmer as long as interfaces become more usable, intelligent and simple at the same time. Finally, you will program your robot nurse by simply telling what to do. (Now go ahead and improvise:)
We'll be able program every thing that surrounds us, like we humans are talking to each other now. Do we charge those who listen for just speaking out? Or do we copyright everything we say at lunch with a mouthful of pasta? (Well, sometimes...)
And since interaction with devices and robots will become as simple and as natural as with humans, we'll simply share our 'programs', or sequence of commands or whatever, like we share stories and opinions now.
Finally, there will be no fundamental distinction between speaking and programming. Proprietary programming will exist as long as proprietary speech exists nowadays (lectures, books and shit like that) - no more than 1% of everything that's said.
Nice perspective. Now go program your closed-source commercial app. Or tomorrow will be too late to make money out of it.
When exactly it's not possible? You program destruction notification yourself, so why it shouldn't be possible? The only difficulty here is extra coding in both objects, the reference holder and the target. They should be somehow `aware' of this functionality, and most likely it means that it should be built into the very basic class of your hierarchy, like Gtk and VCL do.
From my experience, this technique combined with 'smart' pointers even in huge and complex applications do quite well.
And then there's the problem of circular references, which will never be reclaimed. Of course, it's not that hard to avoid those situations most of the time, but with GC you don't have to care.
Ref-counting can be safe if used in conjunction with other methods. Its flaw is not only in that circular references between objects can't be tracked down but also in the general assumption that you should stay alive in memory while at least someone holds a reference to you. Semantically that's not always fair, since you may have done your job already and there's no need for someone to refer to you any longer.
A mechanism that allows to invalidate a reference when an object dies of its own will complements reference counting. Afaik such thing is present in Gtk, in Delphi VCL and some other generic libs.
Actually I'd leave MI but without virtual bases, which cause this "MI bloat". I do use MI sometimes and I can't convince myself that I could have avoided it.
I'd also leave templates, they are useful and potentially powerful, but should be used with great care - that's it.
He-he, so your circumcised compiler gets back to life, almost.
Just don't use STL, and leave the compiler alone:)
Ok, agreed, I missed multimedia. Actually what I mean is textual data, which is the most important part of our heritage. Knowledge mainly resides in texts, not on sound tracks or photos.
Multimedia can be somehat informative, but basically it's for emotions and curiosity. It'd be funny, for instance, to see digital photos of Rome back in II century, but it's only an illustration to the heritage of Rome. Still, knowledge and experience are in texts.
In fact, Internet is the archive of our knowledge (though not everything is free, but that's a technical question). And that's why generally I don't care about archiving, simply because I already have it - the Internet itself.
Worthy things will survive after 500 years by copying to new medium every, say, 10 years. You don't have to worry about them. Let's get back to 50 years, which is much more interesting (see my post "Why CD's? Internet!").
...and not all compilers are optimized to remove redundant code, but such compilers are becoming available.
This reminds me the situation with Java: Sun promised to its army of Java fans that there would be hardware Java VM by 2000. Sun failed to implement Java processor but the trick worked and Java is still popular.
I'm afraid STL is responsible for discrediting the C++ language and for the fact that C is still in wide use novadays, whereas it should have been replaced with its successor, C++. In C vs C++ wars people usually argue just around efficiency. It is obvious (to me at least) that the C++ language itself with good OO design can produce sound code. Only when it comes to STL and templates in general you easily loose control over code generation and also source code portability.
So my point is that even if STL is an elegant and consistent tool, still the outcome falls short of today's requirements. Nobody would allow you to write OS kernels, DB servers or other time/size critical stuff with STL. Likewise, you would never write such things with Perl or Python.
Just wanted to bring your kind attention to this amazing fact: everyone tries to handle STL code bloat, is looking for a (inexistent) STL debugging tool, suggests to completely re-design compiling principles just to make STL compile a bit better, writes books about good STL coding (how to make your binary 3 times smaller), rends the air by saying "do you know what 'S' means in STL????" (one of slashdot postings)...
So why use it at all? Just because it is standard? Then go program with Fortran or Ada, they are pretty standardized, yet almost completely useless/impractical. And so STL.
Slashdot Mirror
It's not Microsoft that's dead, it's we all became more alive.
Maybe they will dump fixed 128-bit addresses, and make them variable length instead, so that new addresses may be allocated where they are needed...
This is really a terrific idea... Picture higher-level routers that only recognize the first IPv4 part of the address and pass packets on to the leaf routers. Such a protocol would require only minimal and thus cheap upgrade of firmware for most hardware on the Internet, not to mention that their 32-bit CPU's would still perfectly do the job.
And so the whole address space would become a tree, just like the domain name system.
(After all, for simplicity of the user-end routing devices, each node's MAC address can be appended to the 4-byte IP address, for example, which will turn IPv4 into the forgotten IPX... The first 2-3 bytes of the MAC address can be changed in each node to reflect the local tree structure in your LAN/WAN. Something like NAT, but with a bit more complicated IPX-like structure in your private network... TCPX?)
As for other "benefits" of IPv6... Autoconfiguration is dangerous since it can be spoofed in large and weakly controlled LAN's. I never really trust DHCP, UPnP and other "smart" guys and try to avoid them whenever possible.
As a consequence of cellular phones, nobody knows anyone else's number any more.
:)
Hmm... And if someone asks for someone else's phone number you tell them 'Greg', like your cell phone shows it to you?
Seriously... You not always refer to the DNS system since lookups take time. For one, you are analyzing huge logs with raw IP numbers and you don't have the time to run lookups.
Besides, I can't imagine programming/maintaining complex routers without messing with numeric addresses. So, short and memorable numbers are practical. I'm really sceptical about IPv6 and I encourage everyone (especially great hackers) to re-think before we accept it.
So instead of having to remember ff:ab:3a:53:5a:f1:20:1b you just use "www.example.com"
That's you, not me. Any sysadmin will have to deal with numeric IPs despite the promised IPv6 automation tools. It's [almost] like saying alphabetical phone numbers for the 60-digit system (in my example) would solve it all. Some things must be readable/maintainable by humans, too.
One more point: great hackers are against IP...
:) To all great hackers: please stop this IPv6 hysteria! It's like replacing the 10-digit phone numbers with 60-digit ones. Would you remember your friends phone number that looks like
8 -03928-77261-78910
(They must be hating IPv6 as well
GREG (CELL): (578) 567-7292-91123-89202-83939-19381-82727-10384-9383
IPv6 sucks just because it's not practical. I'm against it.)
--
"Programs must be written for people to read, and only incidentally for machines to execute."
You wanna know why?
:)
Today we all deal with more or less programmable devices such like TV or CD/DVD/MP3 or whatever players, cameras, and even cars (that have full-blown onboard computers). Everyone learns to program to some extent, be it via remote or by plugging a notebook to a device.
Generally speaking, every user interface is also a programming interface. Today you just drive your car or change the channels on your TV, tomorrow you will somehow program it to find your favorite movie or you will program your car to automatically park the way you want it to park in the backyard. Would you share your parking sequence with friends? No doubt about it.
Now consider in just 100 years everyone in this world becomes a programmer as long as interfaces become more usable, intelligent and simple at the same time. Finally, you will program your robot nurse by simply telling what to do. (Now go ahead and improvise
We'll be able program every thing that surrounds us, like we humans are talking to each other now. Do we charge those who listen for just speaking out? Or do we copyright everything we say at lunch with a mouthful of pasta? (Well, sometimes...)
And since interaction with devices and robots will become as simple and as natural as with humans, we'll simply share our 'programs', or sequence of commands or whatever, like we share stories and opinions now.
Finally, there will be no fundamental distinction between speaking and programming. Proprietary programming will exist as long as proprietary speech exists nowadays (lectures, books and shit like that) - no more than 1% of everything that's said.
Nice perspective. Now go program your closed-source commercial app. Or tomorrow will be too late to make money out of it.
When exactly it's not possible? You program destruction notification yourself, so why it shouldn't be possible? The only difficulty here is extra coding in both objects, the reference holder and the target. They should be somehow `aware' of this functionality, and most likely it means that it should be built into the very basic class of your hierarchy, like Gtk and VCL do.
From my experience, this technique combined with 'smart' pointers even in huge and complex applications do quite well.
And then there's the problem of circular references, which will never be reclaimed. Of course, it's not that hard to avoid those situations most of the time, but with GC you don't have to care.
Ref-counting can be safe if used in conjunction with other methods. Its flaw is not only in that circular references between objects can't be tracked down but also in the general assumption that you should stay alive in memory while at least someone holds a reference to you. Semantically that's not always fair, since you may have done your job already and there's no need for someone to refer to you any longer.
A mechanism that allows to invalidate a reference when an object dies of its own will complements reference counting. Afaik such thing is present in Gtk, in Delphi VCL and some other generic libs.
Actually I'd leave MI but without virtual bases, which cause this "MI bloat". I do use MI sometimes and I can't convince myself that I could have avoided it.
:)
I'd also leave templates, they are useful and potentially powerful, but should be used with great care - that's it.
He-he, so your circumcised compiler gets back to life, almost.
Just don't use STL, and leave the compiler alone
Ok, agreed, I missed multimedia. Actually what I mean is textual data, which is the most important part of our heritage. Knowledge mainly resides in texts, not on sound tracks or photos.
Multimedia can be somehat informative, but basically it's for emotions and curiosity. It'd be funny, for instance, to see digital photos of Rome back in II century, but it's only an illustration to the heritage of Rome. Still, knowledge and experience are in texts.
In fact, Internet is the archive of our knowledge (though not everything is free, but that's a technical question). And that's why generally I don't care about archiving, simply because I already have it - the Internet itself.
Worthy things will survive after 500 years by copying to new medium every, say, 10 years. You don't have to worry about them. Let's get back to 50 years, which is much more interesting (see my post "Why CD's? Internet!").
Hey, we have this great archiving medium - the Internet itself! Plenty of cheap hosting plans around...
(1) It would help the humanity to filter out worthy things, because if your archive is not worthy you will stop paying for hosting one day.
(2) Hosting companies will take care of integrity of your data, because its their job.
(3) Your data will be publicly available and you will see if anyone in the world, besides you, is interested in it.
Huh? Why not?
--
int i = 0;
This reminds me the situation with Java: Sun promised to its army of Java fans that there would be hardware Java VM by 2000. Sun failed to implement Java processor but the trick worked and Java is still popular.
So where are those compilers?
I'm definitely not that kind of person :)
I'm afraid STL is responsible for discrediting the C++ language and for the fact that C is still in wide use novadays, whereas it should have been replaced with its successor, C++. In C vs C++ wars people usually argue just around efficiency. It is obvious (to me at least) that the C++ language itself with good OO design can produce sound code. Only when it comes to STL and templates in general you easily loose control over code generation and also source code portability.
So my point is that even if STL is an elegant and consistent tool, still the outcome falls short of today's requirements. Nobody would allow you to write OS kernels, DB servers or other time/size critical stuff with STL. Likewise, you would never write such things with Perl or Python.
Just wanted to bring your kind attention to this amazing fact: everyone tries to handle STL code bloat, is looking for a (inexistent) STL debugging tool, suggests to completely re-design compiling principles just to make STL compile a bit better, writes books about good STL coding (how to make your binary 3 times smaller), rends the air by saying "do you know what 'S' means in STL????" (one of slashdot postings)...
So why use it at all? Just because it is standard? Then go program with Fortran or Ada, they are pretty standardized, yet almost completely useless/impractical. And so STL.
(Ah... forgot this: IMO, IMO, IMHO, IMVHO, IMVVHO)
Huh? No?