Mod parent up. I've seen this pattern so many times, it's ridiculous. I've walked friends through the process of finding places to work, but they feel it's undignified to be paid less than the guy who's been there for a while.
The best thing a government can do for an economy is get out of the way. Even outside of extreme regulation, taxation and foot-dragging bureaucracies, a government that doesn't change is better than a government that changes every six months, and whose leadership announces sweeping new initiatives almost as frequently.
Nobody in their right mind wants Romney to "fix" the economy, they just want him to get out of the way.
It also allows the exception handler to make a decision about whether or not the stack should be destroyed i.e. allowing the program to continue execution from the point where the exception was thrown.
Personally, I make that decision by choosing where I put my try...catch blocks.
Here's pseudocode for a common idiom where I work for opening and parsing internal binary-format files:
Of there's a failure between those try and catch blocks, I don't give a crap about the rest of the content of the file, or even of any temporary variables I may have created for conditional processing. ReadValue() will throw an exception, no more calls to ReadValue will be made, the catch block will do its own thing, and we'll all be very happy. Well, the user might be pissed his file is corrupt...
Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.
So do it. You wouldn't be the first person to create a language more to his liking, believe me. I've seen dozens, if not hundreds, of programming languages which originate from a developer liking some features of another language, but disliking others.
You clearly have strong opinions; stop writing essays and start writing code! (Or write essays to form a spec, and then code. I see that, too.)
Tons of people love to have something to hate. It might be because they don't like something about it...but I think it's mostly because people like to set up communities held together by rhetoric against a tool or technology perceived and portrayed as an enemy.
"C++ sucks. We are at war with C++. We have always been at war with C++.[1]"
Swap out "C++" for whatever language you like.
Certainly there are going to be cases and scenarios where C is preferable over C++, where C++ is preferable over C, or where Brainfuck is preferable over either. Use the right tool for the right job,[2] and the right tool is whichever allows you to most effectively achieve your goals.
[1] Or, at least since its inception. Or since [insert arbitrary date here].[3] [2] For whoever asks "what's the right job for Brainfuck?"... just wait. Someone will eventually come along and get modded +2 Funny when they reply to you. [3] I see what you'll do there, Mr. Connor.
So I did a little digging. It looks like the first WYSIWYG functionality in personal computer appeared with the Apple Lisa in 1983, and WYSIWYG quickly made its way into the GUI releases of Word and WordPerfect around 1985. Still, this is 1985 we're talking about. You're lamenting the lack of consumer-oriented open-source desktop applications back at a time when any commercial enterprise trying to build and sell such a product was taking a huge risk. The reason Microsoft's mission statement was "a computer on every desktop" wasn't because the hardware was already there! Even Scott Adams mocked Microsoft for their motto in his 1995 book "The Dilbert Principle"; the concept was still seen as far-fetched even then.
KPlayer, KMPlayer, Kaffeine, Dragon Player.
Incidentally, VLC was just one example - there are plenty of others like I listed above, and then Totem and MPlayer.
Reference as many different projects as you like, they sit on the shoulders of the same group of people who've gone to monumental efforts collecting samples, reverse engineering, documenting and reimplementing a massive variety of codecs. It doesn't matter what skin you put on the thing when the hardest part is the compression and decompression of undocumented multimedia formats.
GNUCash is admittedly there, but I doubt that they're so much into working w/ institutions like banks or brokerages than in just being a personal finance manager, which I guess is fine. However, I was thinking not so much about tax software, but rather, something like QuickBooks, which has nothing like it in Linux or BSD environments.
This is exactly what I thought you meant.
I agree that those monumental efforts would not have been easy. However, my argument in my previous post has been that instead of spinning a gazillion different Linux and somewhat fewer BSD distros, people would have done better in pooling their efforts towards making liberated applicaitons software.
Open source and free software isn't powered by some top-down, collaborative idea saying "hey, we need to all work together to do $x", it's powered by a bunch of people doing what interests them, for the reasons they're interested. There's no one, two or even three people who could say "everybody, pull in this direction" and get more than a few hundred people rallying behind them, and certainly not more than for a very limited period of time.
Also, look at the reason the various distros exist. They're iterative technological improvements on previous packaging methodologies (Slackware in response to linux-from-scratch, RPMs in response to Slackware's tarballs, Apt in response to pre-yum RPMs, Portage in response to unoptimized and inflexible binary distributions), philosophical differences (Debian's DFSG as opposed to RH's more lenient policies, Ubuntu's pragmatism vs Debian's strict policies), role/niche-specific distros (FreeNAS, pfSense, netbook-targeted) or political (such as how OpenBSD split off from NetBSD because some of the core devs didn't get along with Theo, and he didn't want to jump through hoops to get work done. (If I read the historical conversations right))
The core distros seem to continue on inertia and contributions from derivatives. Derivatives come and go as they experiment with basing themselves on different software...such as Mint's using Debian to build a rolling-release system.
This is how competition, invention and improvement work; you have to allow for things to break into many overlapping pieces if you want to see which ones work, which ones don't, and which ones beat the pants off of everything that came before.
I expect we're going to have to agree to disagree on this, because all of the solid intellectual reference on this is based in command economies vs free markets, an
Had the FOSS movements (not talking about just the FSF, but everybody involved in having source code automatically available w/ binaries) actually started w/ useful apps and making those liberated or open-sourced - things like Office Suites,
emacs, vi, vim, latex
Image & video editing software
Ok, GIMP lagged Photoshop to market by six years. However, it's worth noting Photoshop was the first in its class.
Video editing? PCs really weren't up to snuff. I remember having to run an MPEG decoder in grayscale mode under Windows 3.1 just because decoding chroma made it run too slow.
Publishing software
LaTeX...which was (and is) a WYSIWYM editor similar in some respects to WordPerfect for DOS (remember that?), but was really a user-friendlier means of working with TeX, the standard bearer for publishing at the time.
financial software
Admittedly terribly lacking, currently. Discussion of this comes up again every year around tax season...
VLC
Go ask the VLC guys how easy it is to reverse-engineer codecs written at a time when everyone who needed FMV (so, game devs) built their own in-house, and where each revision of a game had changes to the codecs, and nobody wanted to use MPEG (too expensive). The precursors to Vorbis and Theora either weren't around, or hadn't caught on. (In fact, it wasn't until within the last decade when I spotted ogg files in a commercial game's media pack)
Once that was out there, it would have been relatively easier to migrate them to FOSS OSs, be it Linux, BSD, osFree, ReactOS, et al. The initial port may have been a bitch - all those API translations and so on - but once that was done & out of the way
So once you've completed one monumental effort of inventing products which hadn't been invented yet (or which were very new), on personal computers (which weren't yet widespread), and once you've completed another monumental effort (porting from DOS, DOS/Win32 and NT/Win32 coding styles and APIs to POSIX), then everything's easy. Except you want these monumental efforts to have occurred 20-25 years ago. And even if it had happened, it still wouldn't be easy.
(incidentally, while on that subject, such software should not have to be re-written b/w different versions of glibc or GCC or GTK or Qt - once it's written in each library, it should automatically be supported by its successors)
First, that, right there, is why Windows is incredibly bloated. It has an incredible amount of layered-in support for older model APIs.
Second, most programs don't need to be modified to support newer versions of glibc, GCC, Gtk or Qt, except possibly in response to bumps in the major revision number. There hasn't just been a Gtk+, Gtk2 and Gtk3, there've been dozens of revisions of each. Programs that compile (or even link!) against revisions within the same major version set don't normally notice a difference.
Third, understand that computer science and engineering knowledge is continually marching on. We're constantly learning and implementing new ways to do things better (R/W locks instead of simple mutexes, PIC, thread-local storage, RAII and garbage collection, embedding of domain specific languages, new ways to compute, new ways to communicate, new ways to interact with the user...), and enforcing backwards-compatibility constrains how efficient your product can be; can we keep the thing small? Can we keep the thing fast? Must we not use scalar floating-point operations because they want to use MMX, and our ABI's calling convention didn't guarantee the sanctity of that register over there?
What about when hardware changes out from under you? With the introduction of SSE, Intel changed another CPU instruction (I don't remember which one...but I think it had to do with manipulating MMX like a
The simple masking pattern that I used was only as an example. Use any pattern you like for masking. And yeah, it's static - that's what EUI-64 is as well, and I was proposing an alternative to that which doesn't just leak the MAC address. But if you want a dynamic address, just take EUI-64, add it to a selected function of the date-time stamp, and then run it. Whenever it needs to expire, or get updated, repeat the process.
Sure. I was discussing the particulars (particularly in case anyone else comes along and and decides to implement that mask concept). I wasn't trying to be combative.
Incidentally, all that can be done statefully as well, in a dhcp6 server. Also, you can assign a pool of addresses - however large you like - to act as dynamic address.
Again, I really don't like adding more moving parts to a system. It might work fine for a wired Ethernet link with few clients, but it falls over quickly in wireless environments like apartment buildings and hotels. (It's ugly, but perhaps one in twenty DNS queries fail for me on my laptop at home, with the packets apparently lost between my laptop and my AP twenty feet away.)
Yes, I know about DHCP-PD. Using it to specify a pool of addresses to source from is an interesting idea. And, yes, if you use DHCP, you can push all kinds of configuration into a client.
But, again, I like SLAAC, because it's more reliable and generates less network traffic for me.
That private company (or their ISP) needed a special transit or tunnel setup between their AS and the AS their customers sit on so that intermediate networks didn't simply drop the packets. I expect the fan-out happened at the ISP in Australia; Australia doesn't have a very good connection to the rest of the Internet.
I suspect you don't have all the details. I know you haven't done anything in-depth with IPv6, based on your previous comments.
FYI, your SLAAC still is static (if you're not using Win7 or Vista...and their quirk there can be configured out of them, too), even in the case of privacy extensions. Privacy extensions use a combination of a static IP and continually-changing temporary IPs.
Otherwise, I like most of what you describe. Still, you shouldn't use a simple masking pattern. At one end of the MAC address, entropy is reduced because of the presence of manufacturer ID information. At the other end of the MAC address, entropy is reduced because of the serial nature of their generation; when I see motherboards with two NICs, those NICs typically have adjacent numbers for MAC addresses. I've seen similar patterns with MAC addresses assigned to virtual machines.
That's why I suggested SHA1; every bit in the input data gets spread across every bit in the output data. Generate the SHA1, and then take however many of the bits you need off of one end or the other. Deterministic, yet sufficiently unlikely to result in a collision.
First, using a centralized box to continually shuffle client IP addresses adds a significant degree of complexity; you're either adding moving parts to an otherwise static system, or you're forcing existing moving parts to move much faster.
Neither is a good idea.
Second, IPv6 privacy extensions work by generating a permanent IP, as well as one or more temporary addresses that are used for outbound connections, and those temporary addresses are deprecated, expired and generated by the host itself...but it still keeps a permanent address. (Windows Vista and 7 use a full random permanent address, but other stacks use deterministically-generated permanent addresses.)
Third, the 'type' information I was referring to discusses how the IPs are generated. You can tell a SLAAC IP from a privacy-extension IP just by looking at them. That's different from keying on subnet.
First off, you're really not guaranteed that there's going to be a decent source of random numbers[1]. And there's not a need for truly random numbers; you don't want to consume them if you don't need to. Besides...I like deterministic addresses I can see traffic on my network and immediately know which machine it corresponds to, without having to use something stateful like DHCP. If your network has fewer than ten nodes on it, it doesn't long at all to get to know it.
So instead take the SHA1 hash of the MAC address (or perhaps the MAC address appended to the prefix), and use the first N bits. Then, at least, you have a deterministic method to generate the IP address.
[1] Believe me, this is a problem I'm trying to provide solutions for. My etools/entmesh package has been stagnant for a while, but that's because I've been getting prepping for getting married, getting married, doing the honeymoon thing, and dealing with other life surprises. Happens.
OK, I follow you now. The only gripe I still have is with dependence on privacy extensions; I like that my machines have deterministic addresses, and I like the diagnostic details from seeing the MAC addresses. You're advocating complete randomization. That, I don't like.
Reasonable points, though I think it was more about easing hardware implementations of the stack than about dealing specifically with memory-constraints. That said, I would still protest anything that breaks SLAAC; SLAAC is very useful. If you want to describe how SLAAC would operate in a completely classless system, I wouldn't mind discussing it.
What are these incorrect assumptions you describe, and can you point to some of the examples of them coming up? (Just honestly curious)
You are aware that all major IPv6 stacks have IPSec support? Forget that the standard doesn't explicitly require it...Linux, *BSD and Windows have long shipped with working versions.
You still haven't given any technical reason why "prefix-length === 64" should be dropped; you've called it stupid and unnecessary, and the best you've done is indicate you don't care that doing so would break SLAAC. I like and use SLAAC, which depends on that 64-bit minimum subnet size; your 'unnecessary' argument doesn't hold in that context.
To begin with, DHCPv6 runs counter to privacy extensions. That rather sucks. Also, I recommend actually reading RFC 4941. There's more to privacy extensions than it appears you realize.
It's also worth noting that those 16 bits between your MAC address and the width of a/64 are used for encoding type information. That makes it a useful diagnostic, and not something to be discarded lightly.
Slashdot Mirror
That's been fixed with TLS+SNI, which has broad support. SSL (as opposed to TLS) should be effectively dead as a support requirement by now.
Thank you. You had all the links and citations I never bothered to save links for. Bookmarking your comment.
Mod parent up. I've seen this pattern so many times, it's ridiculous. I've walked friends through the process of finding places to work, but they feel it's undignified to be paid less than the guy who's been there for a while.
The best thing a government can do for an economy is get out of the way. Even outside of extreme regulation, taxation and foot-dragging bureaucracies, a government that doesn't change is better than a government that changes every six months, and whose leadership announces sweeping new initiatives almost as frequently.
Nobody in their right mind wants Romney to "fix" the economy, they just want him to get out of the way.
It also allows the exception handler to make a decision about whether or not the stack should be destroyed i.e. allowing the program to continue execution from the point where the exception was thrown.
Personally, I make that decision by choosing where I put my try...catch blocks.
Here's pseudocode for a common idiom where I work for opening and parsing internal binary-format files:
bool ParseFile(fh file_handle) // try // catch // Log an error
{
bool bRet = false;
m_SomeMember = ReadValue(file_handle);
m_SomeOtherMember = ReadValue(file_handle);
m_YetAnotherMember = ReadValue(file_handle);
m_AndStillAnotherMember = ReadValue(file_handle);
bRet = true;
{
}
return bRet;
}
Of there's a failure between those try and catch blocks, I don't give a crap about the rest of the content of the file, or even of any temporary variables I may have created for conditional processing. ReadValue() will throw an exception, no more calls to ReadValue will be made, the catch block will do its own thing, and we'll all be very happy. Well, the user might be pissed his file is corrupt...
It might be worth trying recompiling the standard library optimized for size, and see if that helps. There are also C++-to-C compilers which may work.
Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.
So do it. You wouldn't be the first person to create a language more to his liking, believe me. I've seen dozens, if not hundreds, of programming languages which originate from a developer liking some features of another language, but disliking others.
You clearly have strong opinions; stop writing essays and start writing code! (Or write essays to form a spec, and then code. I see that, too.)
I am not claiming it is a language without warts, but I challenge any one who modded the parent post up to provide...
And lose their mod points? Dude!
assert(C == C++);
Beautiful. Someone needs to prep an April Fools joke for next year for renaming C++ to ++C.
Tons of people love to have something to hate. It might be because they don't like something about it...but I think it's mostly because people like to set up communities held together by rhetoric against a tool or technology perceived and portrayed as an enemy.
"C++ sucks. We are at war with C++. We have always been at war with C++.[1]"
Swap out "C++" for whatever language you like.
Certainly there are going to be cases and scenarios where C is preferable over C++, where C++ is preferable over C, or where Brainfuck is preferable over either. Use the right tool for the right job,[2] and the right tool is whichever allows you to most effectively achieve your goals.
[1] Or, at least since its inception. Or since [insert arbitrary date here].[3] ... just wait. Someone will eventually come along and get modded +2 Funny when they reply to you.
[2] For whoever asks "what's the right job for Brainfuck?"
[3] I see what you'll do there, Mr. Connor.
I was talking about things like Libre-Office
So I did a little digging. It looks like the first WYSIWYG functionality in personal computer appeared with the Apple Lisa in 1983, and WYSIWYG quickly made its way into the GUI releases of Word and WordPerfect around 1985. Still, this is 1985 we're talking about. You're lamenting the lack of consumer-oriented open-source desktop applications back at a time when any commercial enterprise trying to build and sell such a product was taking a huge risk. The reason Microsoft's mission statement was "a computer on every desktop" wasn't because the hardware was already there! Even Scott Adams mocked Microsoft for their motto in his 1995 book "The Dilbert Principle"; the concept was still seen as far-fetched even then.
KPlayer, KMPlayer, Kaffeine, Dragon Player.
Incidentally, VLC was just one example - there are plenty of others like I listed above, and then Totem and MPlayer.
Reference as many different projects as you like, they sit on the shoulders of the same group of people who've gone to monumental efforts collecting samples, reverse engineering, documenting and reimplementing a massive variety of codecs. It doesn't matter what skin you put on the thing when the hardest part is the compression and decompression of undocumented multimedia formats.
GNUCash is admittedly there, but I doubt that they're so much into working w/ institutions like banks or brokerages than in just being a personal finance manager, which I guess is fine. However, I was thinking not so much about tax software, but rather, something like QuickBooks, which has nothing like it in Linux or BSD environments.
This is exactly what I thought you meant.
I agree that those monumental efforts would not have been easy. However, my argument in my previous post has been that instead of spinning a gazillion different Linux and somewhat fewer BSD distros, people would have done better in pooling their efforts towards making liberated applicaitons software.
Open source and free software isn't powered by some top-down, collaborative idea saying "hey, we need to all work together to do $x", it's powered by a bunch of people doing what interests them, for the reasons they're interested. There's no one, two or even three people who could say "everybody, pull in this direction" and get more than a few hundred people rallying behind them, and certainly not more than for a very limited period of time.
Also, look at the reason the various distros exist. They're iterative technological improvements on previous packaging methodologies (Slackware in response to linux-from-scratch, RPMs in response to Slackware's tarballs, Apt in response to pre-yum RPMs, Portage in response to unoptimized and inflexible binary distributions), philosophical differences (Debian's DFSG as opposed to RH's more lenient policies, Ubuntu's pragmatism vs Debian's strict policies), role/niche-specific distros (FreeNAS, pfSense, netbook-targeted) or political (such as how OpenBSD split off from NetBSD because some of the core devs didn't get along with Theo, and he didn't want to jump through hoops to get work done. (If I read the historical conversations right))
The core distros seem to continue on inertia and contributions from derivatives. Derivatives come and go as they experiment with basing themselves on different software...such as Mint's using Debian to build a rolling-release system.
This is how competition, invention and improvement work; you have to allow for things to break into many overlapping pieces if you want to see which ones work, which ones don't, and which ones beat the pants off of everything that came before.
I expect we're going to have to agree to disagree on this, because all of the solid intellectual reference on this is based in command economies vs free markets, an
Had the FOSS movements (not talking about just the FSF, but everybody involved in having source code automatically available w/ binaries) actually started w/ useful apps and making those liberated or open-sourced - things like Office Suites,
emacs, vi, vim, latex
Image & video editing software
Ok, GIMP lagged Photoshop to market by six years. However, it's worth noting Photoshop was the first in its class.
Video editing? PCs really weren't up to snuff. I remember having to run an MPEG decoder in grayscale mode under Windows 3.1 just because decoding chroma made it run too slow.
Publishing software
LaTeX...which was (and is) a WYSIWYM editor similar in some respects to WordPerfect for DOS (remember that?), but was really a user-friendlier means of working with TeX, the standard bearer for publishing at the time.
financial software
Admittedly terribly lacking, currently. Discussion of this comes up again every year around tax season...
VLC
Go ask the VLC guys how easy it is to reverse-engineer codecs written at a time when everyone who needed FMV (so, game devs) built their own in-house, and where each revision of a game had changes to the codecs, and nobody wanted to use MPEG (too expensive). The precursors to Vorbis and Theora either weren't around, or hadn't caught on. (In fact, it wasn't until within the last decade when I spotted ogg files in a commercial game's media pack)
Once that was out there, it would have been relatively easier to migrate them to FOSS OSs, be it Linux, BSD, osFree, ReactOS, et al. The initial port may have been a bitch - all those API translations and so on - but once that was done & out of the way
So once you've completed one monumental effort of inventing products which hadn't been invented yet (or which were very new), on personal computers (which weren't yet widespread), and once you've completed another monumental effort (porting from DOS, DOS/Win32 and NT/Win32 coding styles and APIs to POSIX), then everything's easy. Except you want these monumental efforts to have occurred 20-25 years ago. And even if it had happened, it still wouldn't be easy.
(incidentally, while on that subject, such software should not have to be re-written b/w different versions of glibc or GCC or GTK or Qt - once it's written in each library, it should automatically be supported by its successors)
First, that, right there, is why Windows is incredibly bloated. It has an incredible amount of layered-in support for older model APIs.
Second, most programs don't need to be modified to support newer versions of glibc, GCC, Gtk or Qt, except possibly in response to bumps in the major revision number. There hasn't just been a Gtk+, Gtk2 and Gtk3, there've been dozens of revisions of each. Programs that compile (or even link!) against revisions within the same major version set don't normally notice a difference.
Third, understand that computer science and engineering knowledge is continually marching on. We're constantly learning and implementing new ways to do things better (R/W locks instead of simple mutexes, PIC, thread-local storage, RAII and garbage collection, embedding of domain specific languages, new ways to compute, new ways to communicate, new ways to interact with the user...), and enforcing backwards-compatibility constrains how efficient your product can be; can we keep the thing small? Can we keep the thing fast? Must we not use scalar floating-point operations because they want to use MMX, and our ABI's calling convention didn't guarantee the sanctity of that register over there?
What about when hardware changes out from under you? With the introduction of SSE, Intel changed another CPU instruction (I don't remember which one...but I think it had to do with manipulating MMX like a
Get hip-deep in heavy networking knowledge. Use the grants to get Cisco certs; that's a hard thing to get into, otherwise.
The simple masking pattern that I used was only as an example. Use any pattern you like for masking. And yeah, it's static - that's what EUI-64 is as well, and I was proposing an alternative to that which doesn't just leak the MAC address. But if you want a dynamic address, just take EUI-64, add it to a selected function of the date-time stamp, and then run it. Whenever it needs to expire, or get updated, repeat the process.
Sure. I was discussing the particulars (particularly in case anyone else comes along and and decides to implement that mask concept). I wasn't trying to be combative.
Incidentally, all that can be done statefully as well, in a dhcp6 server. Also, you can assign a pool of addresses - however large you like - to act as dynamic address.
Again, I really don't like adding more moving parts to a system. It might work fine for a wired Ethernet link with few clients, but it falls over quickly in wireless environments like apartment buildings and hotels. (It's ugly, but perhaps one in twenty DNS queries fail for me on my laptop at home, with the packets apparently lost between my laptop and my AP twenty feet away.)
Yes, I know about DHCP-PD. Using it to specify a pool of addresses to source from is an interesting idea. And, yes, if you use DHCP, you can push all kinds of configuration into a client.
But, again, I like SLAAC, because it's more reliable and generates less network traffic for me.
That private company (or their ISP) needed a special transit or tunnel setup between their AS and the AS their customers sit on so that intermediate networks didn't simply drop the packets. I expect the fan-out happened at the ISP in Australia; Australia doesn't have a very good connection to the rest of the Internet.
I suspect you don't have all the details. I know you haven't done anything in-depth with IPv6, based on your previous comments.
(most of this, I respond to in comment #40244507)
I shouldn't think it necessary to point out that the reason for /48s was to reduce the size of a full routing view.
FYI, your SLAAC still is static (if you're not using Win7 or Vista...and their quirk there can be configured out of them, too), even in the case of privacy extensions. Privacy extensions use a combination of a static IP and continually-changing temporary IPs.
Otherwise, I like most of what you describe. Still, you shouldn't use a simple masking pattern. At one end of the MAC address, entropy is reduced because of the presence of manufacturer ID information. At the other end of the MAC address, entropy is reduced because of the serial nature of their generation; when I see motherboards with two NICs, those NICs typically have adjacent numbers for MAC addresses. I've seen similar patterns with MAC addresses assigned to virtual machines.
That's why I suggested SHA1; every bit in the input data gets spread across every bit in the output data. Generate the SHA1, and then take however many of the bits you need off of one end or the other. Deterministic, yet sufficiently unlikely to result in a collision.
First, using a centralized box to continually shuffle client IP addresses adds a significant degree of complexity; you're either adding moving parts to an otherwise static system, or you're forcing existing moving parts to move much faster.
Neither is a good idea.
Second, IPv6 privacy extensions work by generating a permanent IP, as well as one or more temporary addresses that are used for outbound connections, and those temporary addresses are deprecated, expired and generated by the host itself...but it still keeps a permanent address. (Windows Vista and 7 use a full random permanent address, but other stacks use deterministically-generated permanent addresses.)
Third, the 'type' information I was referring to discusses how the IPs are generated. You can tell a SLAAC IP from a privacy-extension IP just by looking at them. That's different from keying on subnet.
OK, now that doesn't make sense.
First off, you're really not guaranteed that there's going to be a decent source of random numbers[1]. And there's not a need for truly random numbers; you don't want to consume them if you don't need to. Besides...I like deterministic addresses I can see traffic on my network and immediately know which machine it corresponds to, without having to use something stateful like DHCP. If your network has fewer than ten nodes on it, it doesn't long at all to get to know it.
So instead take the SHA1 hash of the MAC address (or perhaps the MAC address appended to the prefix), and use the first N bits. Then, at least, you have a deterministic method to generate the IP address.
[1] Believe me, this is a problem I'm trying to provide solutions for. My etools/entmesh package has been stagnant for a while, but that's because I've been getting prepping for getting married, getting married, doing the honeymoon thing, and dealing with other life surprises. Happens.
OK, I follow you now. The only gripe I still have is with dependence on privacy extensions; I like that my machines have deterministic addresses, and I like the diagnostic details from seeing the MAC addresses. You're advocating complete randomization. That, I don't like.
Reasonable points, though I think it was more about easing hardware implementations of the stack than about dealing specifically with memory-constraints. That said, I would still protest anything that breaks SLAAC; SLAAC is very useful. If you want to describe how SLAAC would operate in a completely classless system, I wouldn't mind discussing it.
What are these incorrect assumptions you describe, and can you point to some of the examples of them coming up? (Just honestly curious)
You are aware that all major IPv6 stacks have IPSec support? Forget that the standard doesn't explicitly require it...Linux, *BSD and Windows have long shipped with working versions.
You still haven't given any technical reason why "prefix-length === 64" should be dropped; you've called it stupid and unnecessary, and the best you've done is indicate you don't care that doing so would break SLAAC. I like and use SLAAC, which depends on that 64-bit minimum subnet size; your 'unnecessary' argument doesn't hold in that context.
Why?
To begin with, DHCPv6 runs counter to privacy extensions. That rather sucks. Also, I recommend actually reading RFC 4941. There's more to privacy extensions than it appears you realize.
It's also worth noting that those 16 bits between your MAC address and the width of a /64 are used for encoding type information. That makes it a useful diagnostic, and not something to be discarded lightly.
You do realize that breaks SLAAC, right?