The question is can anything be secure in the long term if an attacker can monitor the conversation between alice and bob 24/7?
Yes. It's a basic assumption in communication security that your communication medium is insecure and can be monitored or modified at will by an attacker.
You can design an authentication/key exchange protocol so that the only way to access the data is to break the encryption algorithm, or via social engineering.
You can design an encryption algorithm so that it cannot be broken except by a brute force attack in an infeasible amount of time, meaning like 1000 years assuming Moore's Law continues unabated the whole time and major world governments want your data.
It's just a tricky thing to get right. And sometimes (WEP) it seems like they weren't even trying.
Every time someone brings up the olympics I go off on a rant like this, which may be why I have so few friends:)
I can understand why that would happen. The question I have is, do you drive them away with your rants? Or would it be like if I were your friend, and I'd drive you away by always saying "Olympics!" at random times just to inspire your rants?
Yeah, I still remember the first time I realized someone was using the phrase "open minded" to mean "holding a specific set of 'open mind'-approved beliefs". It was no different than religious dogmatism but less honest about the fact.
Warlords are the type of government that you get when what you thought you were getting was Anarchy. Anarchy is the least stable political state (as in state of being not nation-state), and the most stupid to endorse, because as a natural consequence it ensures that you get the kind of government that is least like what you wanted.
So 'an RTS' is correct unless you pronounce 'RTS' as a word (arrrt-ssss?).
Even then 'an' would be correct, because it's the presence or absence of a vowel sound that matters.
For 'a RTS' to be the correct version would be if you pronounced it "Rits". Which I guess has a certain ring to it. "What were you doing last night?" "Oh, puttin on the ritz."
It's certainly debatable, and I would say that a and an are both correct, but I wouldn't be pedantic and "correct" someone for not using the word I would prefer...
How is it debatable?
The whole "a vs an" thing comes from the spoken language. You use "an" before words that start with a vowel sound, because the consonant breaks up the vowels and thus the words so it's easier for people listening to distinguish them.
Say "an RTS" out loud, pronouncing each letter. Notice how it rolls off the tongue easily. Now say "a RTS", and you either have to insert an awkward pause between 'a' and 'R', or you risk losing the 'a' while sounding like a pirate. Which is fine on Talk Like a Pirate Day, but even a pirate would say "an aaaaaaarrrr-tee-es." Try it with "a/an artichoke" if the acronym is still messing you up. It's the same principle, though -- it's the sound that matters.
It might be debatable that "a RTS" is a correct alternative in writing. It is not debatable that "an RTS" is correct, because it absolutely is correct.
And, thanks to a misreading on my part, I had a mental image of Archon, where your Sorceress had the ability to go back in time to before your dragon got his ass kicked by a fucking unicorn.
Course you could pretty much already do that, so that didn't make much sense. So I had to read again, oh A-Chron, I get it. Aw, no new Archon game.:(
Translation: People who typed "en." to bring up the last few times they'd visited en.wikipedia.org, "fi" to bring up the last few times they'd visited "finance.google.com", or "fa" for either "fark.com" or "failblog.org", were sick and tired of having to deal with "English, ASCII, and Unicode"
I really don't understand this problem. The first time I typed in "en" to get to wikipedia, sure a ton of other stuff -- in my case all of it being other urls I'd visited that started with en -- comes up, but then I select the one I want, and from then on Firefox immediately goes to the one I wanted.
So basically, restricting the search to urls like you want doesn't solve this "problem" unless you visit very few urls to begin with, and since the software learns what you want it isn't a problem after the first click anyawy. What, you only use url abbreviations once ever, but want firefox to still be able to predict what you wanted?
However if what I wanted was my "English, ASCII, and Unicode" from my bookmarks, then I would have clicked that, and Firefox would have learned that is what I want. Sounds useful for people who work that way.
Software that automatically changes menus or frequently-used options around as a "favor" to the user was bad UI practice five years ago in Windows
It's not moving menu items around. The menu in question is a dynamic history with auto-complete. How could it not change unless you never did anything? And since one of the changes is to figure out what you meant when you type something, how is this a bad thing? What, you want an unsorted undynamic history pulldown? How does that make any sense?
I disagree. Paging is fundamental to memory management. You like having memory mapped to 4KB pages, but call it a hack when those 4KB pages are mapped to different physical memory locations? Why?
What the heck does that bolded part mean? Because I can't see how it has anything to do with PAE specifically. "Paging is fundamental" I 100% agree with, and "4kb pages are mapped to different physical memory locations" is a basic function of paging and thus also something I 100% agree with. Which leads me to believe that I can't be reading what you wrote correctly.
PAE is a hack not because of anything to do with paging, but with what a poor version of paging it is. It extends the physical address space allowing for more memory in a system, but only pretends to extend the virtual space, actually creating "windows" of virtual memory with a table-of-page-tables that is logically equivalent to just having multiple CR3s and swapping them out whenever you want to see a different "window", and has all the happy implications for application design that this implies (like... having to be very, very careful with pointers and simply not being able to use them for a lot of data).
Apparently PAE is even more efficient than 64bit addressing. It's the faster option, although you're 100% correct about the per-process limit being roughly 3GB, which means it'll be obsolete shortly. Games, video editing, and virtual machines will be first to benefit from 64bit > 4GB memory usage.
Um yes it's more efficient than 64 bit, for that narrow range of time and space where people have more than 4GB of RAM in their system, but have no individual applications that would like to use it. Seeing as people had infinitely RAM hungry media apps before they had 4GB in their desktops, that time and space is... never as far as I can tell. But in any case, outside of that narrow range, either 32-bit or 64-bit is better.
What I've always wondered is why Windows uses 4KB pages. Larger pages are far more efficient. The guy who made 7-zip tried hacking in multi-megabyte pages, and had a 15% speedup. O_o
4kb is more efficient from a memory allocation standpoint, so it makes some sense as a default, but yeah a lot of applications can benefit from 2m pages. I'd bet they do use it in places in the kernel, just like Linux does.
Heck, AMD recently added 1GB pages, obviously a bone for the database folks.:)
So, you wouldn't mind having telesurgery on a connection that wasn't protocol aware?
Are you shitting me?
I would never get any kind of telesurgery where the success of the surgery depended on specific latency and reliability promises over the Internet. Protocol-aware QoS isn't magic, it doesn't prevent packets from ever being dropped, or being delayed, or a router crashing and dropping the connection, and so on. You're telling me I'm betting my life on their traffic shaping algorithms? I wouldn't bet my life on that, and a hundred other assumptions that go into the net.
So, no, I would mind. In either case. Either stick to surgeries which don't have critical time constraints on each step so some lag is acceptable, have assistants present for anything that does, or use a communication medium a lot more direct and reliable than the damn internet!
I assume you're British, in which case you should know that over here pissed means a multitude of things, one of which means angry - clearly the intended meaning here.
I'm not British (though I love the word "bloody") though it's true I knew that, but it was funnier if it was "pissed as in drunk".:)
Just because he's British doesn't mean he has to exclusively use the British alternative, my good sirs!
Nonsense. Didn't the UN just pass a resolution about that? If not they should have.
I'm sure it's not in your opinion, but you're sadly oversimplifying or ignoring every use case and ignoring the drivers behind QoS in general. If you want something simplistic and turnkey, there's certainly products out there. Netequalizer springs to mind.
And I'm sure it's not your opinion that you're trying to make what is fundamentally a simple trade-off between latency and bandwdith more complicated than it is. You can make CPU usage cases that sound as complicated as you like too, but in the end they all boil down to the same tradeoff which is why this exact (well more complicated but basically the same) scheduling algorithm works so well there. It's really not any different.
HTTP downloads vs. Flash video streamed over HTTP. One is decidedly interactive (even if buffering certainly helps), the other one is decidedly non-interactive (even if faster = neater, naturally).
Neither of those are interactive. The whole point of buffering is that as long as you maintain a certain level of average bandwidth then you are fine and the jitter of individual packets is irrelevant. Which the latency-vs-bandwidth feedback scheduler provides as long as the network itself can handle it. If either of the two fits the "interactive" usage scenario it's HTML since the user is more likely to want to react to the info displayed. Especially as the web gets more dynamic, the low-bandwidth HTML deserves lower latency than high-bandwidth streaming video.
SIP telephony vs. SIP videoconferencing. Agnosticism per your definition would make the algorithm punish the SIP videocon.
Which is the correct thing to do (especially in the systems I'm familiar with, where audio and video are separate streams). Audio is more susceptible to delayed data. If an audio packet arrives late then it might as well never have because trying to play the audio packet "later" is just going to be a garbled mess. Whereas delayed or partial video frames might look odd but the information is still useful. In any case you're going to have to make some sacrifices in video quality to get good videoconf. You simply can't get both extremely high bandwidth and a guarantee that every packet arrives at top priority without crippling every other service on the net. You can only afford to give high priority to connections that use little bandwidth or you're going to choke everything up defeating the whole purpose. So you have to make some image quality sacrifices to lower your bps, but this also means you're naturally going to be less bandwidth hungry than a bulk transfer or streaming (which still downloads as fast as it can) video.
So, your video conference is "rewarded" relative to file downloads, and "punished" relative to VOIP, but by they very low-bandwidth nature of VOIP this "punishment" is minor. Live video is in between live audio and non-live bulk transfers in priority. Sounds perfect. What's the problem again?
Or, let's take an even simpler example: P2P. Rather than a few very hungry connections, you get a large number of connections pushing less data per connection
Ah, there you got me. The algorithm as I presented it doesn't account for aggregate bandwidth. You could adjust the algorithm to account for aggregate bandwidth -- for example, reducing the priority of all connections from that source based on aggregate bandwidth, however keep the default priority for new connections as "high" (just like in the original algorithm) so that truly minimal and sporadic connections like HTTP requests are unpenalized.
One can always argue that service providers should provide enougb bandwidth so that they won't even have to prioritize data the first place. Nice in theory, hard (or simply uneconomic) in practice.
Yeah, that's why I didn't even come close to arguing that.:P
Take a cable provider - with a limited upstream bandwidth per channel, you need some sort of fairness. Simple per-plug fairness works to some extent, but you don't really
However only if that's the general use case. Otherwise the term 'practical' doesn't seem to apply.
I don't understand what you're getting at. We were talking about the alleged "architectural limitation" of 32-bit microprocessors to access up to 4GB of memory. Either you're using that much memory or not, and thus are either happy with a 32-bit OS or should upgrade to a 64-bit OS. "In all practical cases", treating the 4GB limit like its architectural results in the optimal decision.
(I think I accidentally chopped some of my response - bad tag maybe!) Pretty much what I say above. That you're assuming that > 4GB in a single application is the general use case of having from 4 to 8 GB. For the low end I rather suspect that it's not.
Oh, I see. You're hypothesizing 4 apps that use at most 1.5GB each just as a random example, so there all they really need is the ability to access more than 4GB of physical RAM but have no need of the larger virtual space. Personally even in the "low end" case I suspect that is unlikely. I think it is much more likely that the average user has a number of apps that use a modest amount of memory (100s of MB, games and web browsers), and then one or two apps which will happily chew up as much memory as they have (photoshop, 3dsmax, any other media/content application).
In any case, if their usage ever changes such that an app would like to use all of their RAM (and I do find it hard to imagine apps that use over 1GB but could never make use of more are common), then they will need a 64-bit OS or apps coded for PAE. To make the most flexible use of their RAM, they need a 64-bit OS. To me, "practical" also means "not unnecessarily restricted" because otherwise your "practical" solution is just waiting to become impractical when the limitation bites you in the ass.
Basically, if you have more than 4GB of RAM in your system, a 64-bit OS is imminently more practical than the other option.
If "Net Neutrality"= "treat traffic the same regardless of protocol", then BAD.
Not in my opinion. I see no reason at all to have policies based on protocol. That's a static decision, and static policy decisions can be inaccurate for any particular connection, out of date or simply ignorant of new protocols, and can/will be largely decided by politics not practicality. I.e. bittorent bad, equally bandwidth heavy streaming protocols from ISP-approved media sites good.
You can get QoS while remaining protocol agnostic. You simply base the priority for any connection based on the amount of bandwidth it uses. Lower bandwidth, higher priority. Low-bandwidth latency-sensitive apps like VOIP work perfectly without having their protocol recognized, bulk data transfers are deprioritized but still get plenty of bandwidth (because the higher priority connections are by definition not using much) again without the protocol mattering. If you try to game the system by sending bulk data transfers though VOIP protocols, then you still get downgraded, while a static system would fail.
The only cases it doesn't work for are cases where there's not much you can do anyway -- like live (as in no buffering) streaming video.
What I don't know is if there is any routers out there that do this, or if it's still considered too much memory to keep the connection state info around for packets that are just passing through.
So if I were the South Koreans, I'd be fairly pissed right now. Although this is only a first attempt; anything space-related is bloody hard, and you've got to expect failures on brand new, untested hardware.
Since you used the British term "bloody", I'm going to assume that in the first sentence there you meant that the South Koreans should be moderately drunk. In which case I can only say that if I were the South Koreans, I'd be extremely pissed. And that has nothing to do with rockets.
but what does "for nearly all practical purposes" mean then?
It means "practically speaking, if you need more than 4GB of RAM get a 64 bit cpu/OS and you'll be much better off."
I mean if we really are "in the era of 64-bit budget computers" doesn't that imply that people who are using more memory than 4GB are likely at the lower end
Yes absolutely. But so what? If you want to use more than 4GB in a single application, 64-bit is the way to go even if you're really only using 33 bits. Hell most CPUs don't even implement all 64 address bits, just 40 or 48, because that's still a lot of frickin' memory. But if that changes, newer cpus can just support more bits without having to change the ISA or recompile programs. And it'll be a long time before 64-bits is insufficient.:)
Ha! Yeah I'd forgotten about 286 protected mode and its 20 bit addressing. I even have a book that covers it -- but since at the time the 386 was already out, and its actually good protected modes were also covered by the book, I couldn't imagine anything more useless than the 286 protected mode.:)
32 bit applications will run in 64 bit windows. They do need to be compiled as 64-bit applications if you want to take advantage of having the larger virtual memory space. If the "professional application that costs way too much to just dump and re-buy" is also the one which requires more than 4GB of RAM -- well, the whole app would have to have been programmed around PAE anyway, and if that's the case then you probably would have bought the appropriate version of Windows in the first place (or could save a lot of money by doing so).
Most professional applications with large memory requirements should have 64-bit versions out already (this is more likely than them supporting PAE), and hopefully your support contract includes upgrades so at the next cycle you can get the 64-bit version.
Slashdot Mirror
The question is can anything be secure in the long term if an attacker can monitor the conversation between alice and bob 24/7?
Yes. It's a basic assumption in communication security that your communication medium is insecure and can be monitored or modified at will by an attacker.
You can design an authentication/key exchange protocol so that the only way to access the data is to break the encryption algorithm, or via social engineering.
You can design an encryption algorithm so that it cannot be broken except by a brute force attack in an infeasible amount of time, meaning like 1000 years assuming Moore's Law continues unabated the whole time and major world governments want your data.
It's just a tricky thing to get right. And sometimes (WEP) it seems like they weren't even trying.
Every time someone brings up the olympics I go off on a rant like this, which may be why I have so few friends :)
I can understand why that would happen. The question I have is, do you drive them away with your rants? Or would it be like if I were your friend, and I'd drive you away by always saying "Olympics!" at random times just to inspire your rants?
Why don't you just come out and call it by its real name - a dildo !
LOL. Why don't you just come out and admit that you've either never seen a dildo, or never seen anything Nerf.
Just fyi: foam makes for a really bad dildo, and swinging around a "sword" of latex rubber is a good way to hurt people.
Yeah, I still remember the first time I realized someone was using the phrase "open minded" to mean "holding a specific set of 'open mind'-approved beliefs". It was no different than religious dogmatism but less honest about the fact.
You racist!!! Some of my best friends are Philistines!
Oh please, you can't call a fan club a 'race'. Besides, he's been terrible ever since he left Genesis, so I see no reason to defend them anyway.
*reads this and the previous parallel reply*
Oh my God!
Batman is Barack Obama, sacdelta on /., and HITLER!!!!
Warlords are a type of government.
Warlords are the type of government that you get when what you thought you were getting was Anarchy. Anarchy is the least stable political state (as in state of being not nation-state), and the most stupid to endorse, because as a natural consequence it ensures that you get the kind of government that is least like what you wanted.
Well I'll be honest, it's the Batgonads I'm obsessed with.
*reads the first two posts*
Oh my god! Barack Obama is Batman's secret identity!
This explains why he got to keep his "Blackberry", because it's actually his Batberry! ... I'll let myself out.
Technically, I belive the goal is to make sure your parents still do it...
Sweet Jeebus. I don't even want to think about whether my parents still do it, much less make sure!
So 'an RTS' is correct unless you pronounce 'RTS' as a word (arrrt-ssss?).
Even then 'an' would be correct, because it's the presence or absence of a vowel sound that matters.
For 'a RTS' to be the correct version would be if you pronounced it "Rits". Which I guess has a certain ring to it. "What were you doing last night?" "Oh, puttin on the ritz."
It's certainly debatable, and I would say that a and an are both correct, but I wouldn't be pedantic and "correct" someone for not using the word I would prefer...
How is it debatable?
The whole "a vs an" thing comes from the spoken language. You use "an" before words that start with a vowel sound, because the consonant breaks up the vowels and thus the words so it's easier for people listening to distinguish them.
Say "an RTS" out loud, pronouncing each letter. Notice how it rolls off the tongue easily. Now say "a RTS", and you either have to insert an awkward pause between 'a' and 'R', or you risk losing the 'a' while sounding like a pirate. Which is fine on Talk Like a Pirate Day, but even a pirate would say "an aaaaaaarrrr-tee-es." Try it with "a/an artichoke" if the acronym is still messing you up. It's the same principle, though -- it's the sound that matters.
It might be debatable that "a RTS" is a correct alternative in writing. It is not debatable that "an RTS" is correct, because it absolutely is correct.
Or what if he decides to return the favor by going back in time to become your father as well?
Well, a custody lawyer would get rich, is what, but I mean aside from that!
And, thanks to a misreading on my part, I had a mental image of Archon, where your Sorceress had the ability to go back in time to before your dragon got his ass kicked by a fucking unicorn.
Course you could pretty much already do that, so that didn't make much sense. So I had to read again, oh A-Chron, I get it. Aw, no new Archon game. :(
Translation: People who typed "en." to bring up the last few times they'd visited en.wikipedia.org, "fi" to bring up the last few times they'd visited "finance.google.com", or "fa" for either "fark.com" or "failblog.org", were sick and tired of having to deal with "English, ASCII, and Unicode"
I really don't understand this problem. The first time I typed in "en" to get to wikipedia, sure a ton of other stuff -- in my case all of it being other urls I'd visited that started with en -- comes up, but then I select the one I want, and from then on Firefox immediately goes to the one I wanted.
So basically, restricting the search to urls like you want doesn't solve this "problem" unless you visit very few urls to begin with, and since the software learns what you want it isn't a problem after the first click anyawy. What, you only use url abbreviations once ever, but want firefox to still be able to predict what you wanted?
However if what I wanted was my "English, ASCII, and Unicode" from my bookmarks, then I would have clicked that, and Firefox would have learned that is what I want. Sounds useful for people who work that way.
Software that automatically changes menus or frequently-used options around as a "favor" to the user was bad UI practice five years ago in Windows
It's not moving menu items around. The menu in question is a dynamic history with auto-complete. How could it not change unless you never did anything? And since one of the changes is to figure out what you meant when you type something, how is this a bad thing? What, you want an unsorted undynamic history pulldown? How does that make any sense?
I disagree. Paging is fundamental to memory management. You like having memory mapped to 4KB pages, but call it a hack when those 4KB pages are mapped to different physical memory locations? Why?
What the heck does that bolded part mean? Because I can't see how it has anything to do with PAE specifically. "Paging is fundamental" I 100% agree with, and "4kb pages are mapped to different physical memory locations" is a basic function of paging and thus also something I 100% agree with. Which leads me to believe that I can't be reading what you wrote correctly.
PAE is a hack not because of anything to do with paging, but with what a poor version of paging it is. It extends the physical address space allowing for more memory in a system, but only pretends to extend the virtual space, actually creating "windows" of virtual memory with a table-of-page-tables that is logically equivalent to just having multiple CR3s and swapping them out whenever you want to see a different "window", and has all the happy implications for application design that this implies (like... having to be very, very careful with pointers and simply not being able to use them for a lot of data).
Apparently PAE is even more efficient than 64bit addressing. It's the faster option, although you're 100% correct about the per-process limit being roughly 3GB, which means it'll be obsolete shortly. Games, video editing, and virtual machines will be first to benefit from 64bit > 4GB memory usage.
Um yes it's more efficient than 64 bit, for that narrow range of time and space where people have more than 4GB of RAM in their system, but have no individual applications that would like to use it. Seeing as people had infinitely RAM hungry media apps before they had 4GB in their desktops, that time and space is... never as far as I can tell. But in any case, outside of that narrow range, either 32-bit or 64-bit is better.
What I've always wondered is why Windows uses 4KB pages. Larger pages are far more efficient. The guy who made 7-zip tried hacking in multi-megabyte pages, and had a 15% speedup. O_o
4kb is more efficient from a memory allocation standpoint, so it makes some sense as a default, but yeah a lot of applications can benefit from 2m pages. I'd bet they do use it in places in the kernel, just like Linux does.
Heck, AMD recently added 1GB pages, obviously a bone for the database folks. :)
So, you wouldn't mind having telesurgery on a connection that wasn't protocol aware?
Are you shitting me?
I would never get any kind of telesurgery where the success of the surgery depended on specific latency and reliability promises over the Internet. Protocol-aware QoS isn't magic, it doesn't prevent packets from ever being dropped, or being delayed, or a router crashing and dropping the connection, and so on. You're telling me I'm betting my life on their traffic shaping algorithms? I wouldn't bet my life on that, and a hundred other assumptions that go into the net.
So, no, I would mind. In either case. Either stick to surgeries which don't have critical time constraints on each step so some lag is acceptable, have assistants present for anything that does, or use a communication medium a lot more direct and reliable than the damn internet!
I assume you're British, in which case you should know that over here pissed means a multitude of things, one of which means angry - clearly the intended meaning here.
I'm not British (though I love the word "bloody") though it's true I knew that, but it was funnier if it was "pissed as in drunk". :)
Just because he's British doesn't mean he has to exclusively use the British alternative, my good sirs!
Nonsense. Didn't the UN just pass a resolution about that? If not they should have.
I'm sure it's not in your opinion, but you're sadly oversimplifying or ignoring every use case and ignoring the drivers behind QoS in general. If you want something simplistic and turnkey, there's certainly products out there. Netequalizer springs to mind.
And I'm sure it's not your opinion that you're trying to make what is fundamentally a simple trade-off between latency and bandwdith more complicated than it is. You can make CPU usage cases that sound as complicated as you like too, but in the end they all boil down to the same tradeoff which is why this exact (well more complicated but basically the same) scheduling algorithm works so well there. It's really not any different.
HTTP downloads vs. Flash video streamed over HTTP. One is decidedly interactive (even if buffering certainly helps), the other one is decidedly non-interactive (even if faster = neater, naturally).
Neither of those are interactive. The whole point of buffering is that as long as you maintain a certain level of average bandwidth then you are fine and the jitter of individual packets is irrelevant. Which the latency-vs-bandwidth feedback scheduler provides as long as the network itself can handle it. If either of the two fits the "interactive" usage scenario it's HTML since the user is more likely to want to react to the info displayed. Especially as the web gets more dynamic, the low-bandwidth HTML deserves lower latency than high-bandwidth streaming video.
SIP telephony vs. SIP videoconferencing. Agnosticism per your definition would make the algorithm punish the SIP videocon.
Which is the correct thing to do (especially in the systems I'm familiar with, where audio and video are separate streams). Audio is more susceptible to delayed data. If an audio packet arrives late then it might as well never have because trying to play the audio packet "later" is just going to be a garbled mess. Whereas delayed or partial video frames might look odd but the information is still useful. In any case you're going to have to make some sacrifices in video quality to get good videoconf. You simply can't get both extremely high bandwidth and a guarantee that every packet arrives at top priority without crippling every other service on the net. You can only afford to give high priority to connections that use little bandwidth or you're going to choke everything up defeating the whole purpose. So you have to make some image quality sacrifices to lower your bps, but this also means you're naturally going to be less bandwidth hungry than a bulk transfer or streaming (which still downloads as fast as it can) video.
So, your video conference is "rewarded" relative to file downloads, and "punished" relative to VOIP, but by they very low-bandwidth nature of VOIP this "punishment" is minor. Live video is in between live audio and non-live bulk transfers in priority. Sounds perfect. What's the problem again?
Or, let's take an even simpler example: P2P. Rather than a few very hungry connections, you get a large number of connections pushing less data per connection
Ah, there you got me. The algorithm as I presented it doesn't account for aggregate bandwidth. You could adjust the algorithm to account for aggregate bandwidth -- for example, reducing the priority of all connections from that source based on aggregate bandwidth, however keep the default priority for new connections as "high" (just like in the original algorithm) so that truly minimal and sporadic connections like HTTP requests are unpenalized.
One can always argue that service providers should provide enougb bandwidth so that they won't even have to prioritize data the first place. Nice in theory, hard (or simply uneconomic) in practice.
Yeah, that's why I didn't even come close to arguing that. :P
Take a cable provider - with a limited upstream bandwidth per channel, you need some sort of fairness. Simple per-plug fairness works to some extent, but you don't really
However only if that's the general use case. Otherwise the term 'practical' doesn't seem to apply.
I don't understand what you're getting at. We were talking about the alleged "architectural limitation" of 32-bit microprocessors to access up to 4GB of memory. Either you're using that much memory or not, and thus are either happy with a 32-bit OS or should upgrade to a 64-bit OS. "In all practical cases", treating the 4GB limit like its architectural results in the optimal decision.
(I think I accidentally chopped some of my response - bad tag maybe!) Pretty much what I say above. That you're assuming that > 4GB in a single application is the general use case of having from 4 to 8 GB. For the low end I rather suspect that it's not.
Oh, I see. You're hypothesizing 4 apps that use at most 1.5GB each just as a random example, so there all they really need is the ability to access more than 4GB of physical RAM but have no need of the larger virtual space. Personally even in the "low end" case I suspect that is unlikely. I think it is much more likely that the average user has a number of apps that use a modest amount of memory (100s of MB, games and web browsers), and then one or two apps which will happily chew up as much memory as they have (photoshop, 3dsmax, any other media/content application).
In any case, if their usage ever changes such that an app would like to use all of their RAM (and I do find it hard to imagine apps that use over 1GB but could never make use of more are common), then they will need a 64-bit OS or apps coded for PAE. To make the most flexible use of their RAM, they need a 64-bit OS. To me, "practical" also means "not unnecessarily restricted" because otherwise your "practical" solution is just waiting to become impractical when the limitation bites you in the ass.
Basically, if you have more than 4GB of RAM in your system, a 64-bit OS is imminently more practical than the other option.
If "Net Neutrality"= "treat traffic the same regardless of protocol", then BAD.
Not in my opinion. I see no reason at all to have policies based on protocol. That's a static decision, and static policy decisions can be inaccurate for any particular connection, out of date or simply ignorant of new protocols, and can/will be largely decided by politics not practicality. I.e. bittorent bad, equally bandwidth heavy streaming protocols from ISP-approved media sites good.
You can get QoS while remaining protocol agnostic. You simply base the priority for any connection based on the amount of bandwidth it uses. Lower bandwidth, higher priority. Low-bandwidth latency-sensitive apps like VOIP work perfectly without having their protocol recognized, bulk data transfers are deprioritized but still get plenty of bandwidth (because the higher priority connections are by definition not using much) again without the protocol mattering. If you try to game the system by sending bulk data transfers though VOIP protocols, then you still get downgraded, while a static system would fail.
The only cases it doesn't work for are cases where there's not much you can do anyway -- like live (as in no buffering) streaming video.
What I don't know is if there is any routers out there that do this, or if it's still considered too much memory to keep the connection state info around for packets that are just passing through.
So if I were the South Koreans, I'd be fairly pissed right now. Although this is only a first attempt; anything space-related is bloody hard, and you've got to expect failures on brand new, untested hardware.
Since you used the British term "bloody", I'm going to assume that in the first sentence there you meant that the South Koreans should be moderately drunk. In which case I can only say that if I were the South Koreans, I'd be extremely pissed. And that has nothing to do with rockets.
but what does "for nearly all practical purposes" mean then?
It means "practically speaking, if you need more than 4GB of RAM get a 64 bit cpu/OS and you'll be much better off."
I mean if we really are "in the era of 64-bit budget computers" doesn't that imply that people who are using more memory than 4GB are likely at the lower end
Yes absolutely. But so what? If you want to use more than 4GB in a single application, 64-bit is the way to go even if you're really only using 33 bits. Hell most CPUs don't even implement all 64 address bits, just 40 or 48, because that's still a lot of frickin' memory. But if that changes, newer cpus can just support more bits without having to change the ISA or recompile programs. And it'll be a long time before 64-bits is insufficient. :)
Ha! Yeah I'd forgotten about 286 protected mode and its 20 bit addressing. I even have a book that covers it -- but since at the time the 386 was already out, and its actually good protected modes were also covered by the book, I couldn't imagine anything more useless than the 286 protected mode. :)
32 bit applications will run in 64 bit windows. They do need to be compiled as 64-bit applications if you want to take advantage of having the larger virtual memory space. If the "professional application that costs way too much to just dump and re-buy" is also the one which requires more than 4GB of RAM -- well, the whole app would have to have been programmed around PAE anyway, and if that's the case then you probably would have bought the appropriate version of Windows in the first place (or could save a lot of money by doing so).
Most professional applications with large memory requirements should have 64-bit versions out already (this is more likely than them supporting PAE), and hopefully your support contract includes upgrades so at the next cycle you can get the 64-bit version.