Wow. I thought they'd never do this. Now IE users get to see how brain-damaged most people's CSS link highlighting is, not just us alternative browser users!:)
Right now, the bug I'd like to see fixed most in IE is the one where if you have a div, and put a floating div inside it, followed by <br clear=all>, the outer div ends up being not quite as tall as the inner one...
The owner of the AP is responbile for knowing what the AP is doing. The AP comes with documentation telling you how to set up the way you really intend to. If due to your ignorance/incompetence you completely miscommunicate your intentions and inadvertently advertise that permission to connect is granted to some other person, that's not other person's fault. As far as the other person is concerned, it doesn't really matter what was in your mind if a device you are fully responsible for is going around telling everyone that it is OK to connect.
Let me clarify my point. The device does this by default. There is no way to stop it doing so except by setting it up, then logging in and changing the settings to stop it from doing so. As I have no choice but to run an open network for the time it takes to do so, the fact that I have done so cannot be considered as me having given any random passer-by permission to do so.
By extension, the fact that not all open networks are in a position to authoritatively grant permission to connect means that we must accept that this setting does not ever grant permission BY ITSELF. Otherwise, we would be left in the position that depending on some unknown context the fact that a network allows you to connect either may or may not be permission. In this situation, we cannot make any assumptions about the owners intent and therefore (on the basis that connecting to a network without permission is a substantially worse problem than us being denied access to a network that we should have access to merely because we do not know whether or not we should) we should not use the network.
An entirely automatic function of a network cannot be taken as indicative of its owner's intentions. A person must act to grant permission for another to use some of their resources, inaction is not enough. The consequences otherwise lead to a very unpleasant world, where you always have to watch what you're doing, because if you fail to tell somebody not to use your stuff, they'll take that as permission to use it. I don't want to live in that world... do you?
Here's a scenario which is based on a true story of my own: I walk up to a store on the street in the middle of the afternoon. The door is unlocked, I walk inside and start looking around. Then, the alarm goes off. The shop's new employee left out the back door, set the alarm, and forgot to lock the front door. Should I be booked for attempted burglarly or something? The shop keeper intended for the store to be closed, but they made a mistake and left the store in such a state that says "We're open".
There is a substantial difference between this analogy and the actual practice of using somebody else's unsecured network. For an incredibly substantial majority of times, when a shop advertises that it is open, this is because they want people to come in. However, I'm pretty sure that a substantial majority of open wireless networks are open not because their owners want other people to use them, but rather they do so because they are too ignorant or lazy to secure them properly. In the case of a shop, we can safely assume that the owner wants us to enter. In the case of a wireless network, we can't, because that isn't what most people operating them want.
2. Who gave the AP permission to grant that permission?
The owner - the only person with legitimate authority to control that permission. I suppose an AP could be hacked by someone to become open, but this guy didn't do that. The open AP was put there in the open state by the owner.
Hmmm. When I first installed my AP, it was open.; that was the way the manufacturer supplied it. I had to secure it afterwards. But I certainly never gave it permission to let just anyone come along and use my network. It was entirely automatic -- and permission cannot be granted entirely automatically. There must be some process of informing a person that they are granting permission, and then some action that confirms that they want to do so. This is the simple basic fact of what consent is.
Yes, I'm perfectly aware of how DHCP works. But the fact remains that it does not grant authorisation -- it merely provides information that is necessary to make the network work.
From the same RFC you quoted, paraphrasing slightly for simplification, and adding emphasis:
[A] network administrator, to retain stringent control over the hosts attached to the network, MAY choose to configure DHCP servers to respond only to [authorised clients].
Note the use of the word "may" -- this is a clear indication that it is possible for DHCP servers to respond to unauthorised clients.
An analogy: Me: I'd like to use your car. Can I have the keys? You: Sure. Here's a key I made just for your use. Some time later... You: Officer, he hijacked my car! Officer: What do you mean, "hijacked"? You: He told me that he'd like to use my car, so I had a key made just for him. Then, later, I discovered that he had been using my car! Officer: Are you on any medications?
A more accurate analogy.
A: I've just got this brilliant new piece of kit. You see I lend my car to so many people, and it always takes me ages to find out who's got the keys and where they left them, so I've got this key cutting machine. All you have to do is press a button and it cuts a new key.
[Exit A]
B: Hmmm. I want to borrow A's car. I know, I'll just get a copy of the keys from this key cutting machine he's left outside his front door.
[Exit B with A's car; A returns]
A: Where's my car...? D'oh! I should have put the key cutting machine locked away inside like the instruction manual told me to.
OK, so A is incredibly stupid. But that doesn't mean that B has a right to "borrow" his car like that.
Now, we're not asking about females who are the second of a pairing, just about females and their sibs.
You misread my argument. I'll clarify it here:
The 1/4 of the overall set that are MM will never be asked anything. That leaves FM, MF and FF. Hmmm . . . whaddya know? There's twice as many brothers as sisters out there!
No, there aren't. Let's break those three pairs down:
Pair 1 (FM) has person 1a(F) and person 1b(M). We will ask person 1a, who is F, and the response will be M.
Pair 2 (MF) has person 2a(M) and person 2b(F). We will ask person 2b, who is F, and the response will be M. That's 2xM, 0xF.
Pair 3 (FF) has person 3a(F) and person 3b(F). We will ask person 3a, who is F, and the response will be F. 2xM, 1xF. Then we ask person 3b (which you seemed to forget to do in your survey, which is a little strange, seeing as you're supposed to be asking all the girls), and the response will be F, so the totals are 2 male and 2 female. Still no problem.
Remember -- we are only interviewing girls about their siblings (it was an all-girl school, remember?), not a random sampling from the overall sample set. In effect, we're not getting a truly representative sample set.
Yes, but if gender of sibling is independent of gender of subject (which we would normally assume it to be, in absence of any known cause of bias), then it doesn't matter: for the purpose of finding sibling's genders, asking only female subjects is equivalent to taking a random sample.
Now there are biases that might exist: parents might be more likely to have an abortion if both their children would be the same gender (which would bias the result towards male), and I believe some people have medical conditions that cause them to only have children of a particular gender (which would bias the result towards female), but I'm guessing that both of these are fairly insignificant, and probably cancel each other fairly well anyway.
Err... no. Giving a DHCP response is not authorisation to use a network. DHCP is a means to gather technical information about how to connect to a network, not a way of getting permission to use it.
But the Wifi login *is* the electronic proxy for the person. It *is* where the person gets to say whether its OK to come in or not.
There is no login to an unsecured wireless network -- you just start using it, that's the beginning and the end of it. There's no login to a WEP secured network either, but you need to get hold of the key.
WPA supports network login (except when using WPA-PSK, which is equivalent to WEP except it uses better encryption and authentication), but no older protocol does.
His computer said to the AP, "Hi, can I connect?" and the AP said "Sure, hook right on up.".
1. I don't believe that's how unsecured wireless networks work: basically, you just start using them. You might want to use DHCP to get config information, but that's not the same thing at all.
2. Who gave the AP permission to grant that permission?
If i leave a plate of biscuits (cookies) just inside the open gate to my garden with a sign saying "take one please", is it a crime for someone to take one?
No. But the situation being discussed is more akin to leaving a plate of biscuits just inside your open biscuit without a sign saying "keep your hands off my biscuits."
You can't take absence of dissent to imply consent. The world breaks down if you do that.
My laptop auto-connected until SP2. Now, it behaves as you say.
Whereas my desktop didn't at any point. Neither did it do so under Win2K. To get auto connections you have to either check the relevant box in Network Connections/Wireless Connection/Properties/Wireless/Advanced (which has existed since the very beginning of wireless support in windows), or install a 3rd party network connection utility. My experience with these has suggested that most don't connect automatically: I've used utilities supplied by Belkin, LinkSys and D-Link, and none have autoconnected.
It might be that your card's installer is setting the option for you, in order to help you install it more easily, and the SP2 install deselected it.
Probably. But nobody actually suggested anybody hijack a network... the original poster who used the word was using it in reference to people who assume open network => authorisation to use the network are "hijacking the meaning" of the network being unsecured (which is just that... it means there's no encryption).
Yet his computer asked for concent and was told it was OK.
Err.. no, it didn't. To connect to an unsecured wireless network, you just start sending packets. No request for consent to join the network is involved.
The only time a request for consent is involved is if you're joining a network that's protected via some kind of login system (i.e. a secure network that isn't using "shared key" security).
They are all HFS+, but if you install the PC software before connecting the iPod it will prompt you to restore it to be FAT32. If you connect the iPod before installing the software, things get all confused, the OS will prompt you to reformat it, and it'll cease to play music until you restore it.
That's not true of all of them. A friend of mine has an iPod Shuffle, for instance, and tried to make it work without the software before he installed the software (he was used to other models that simply play whatever files you store on them). He put files on there, got annoyed that they wouldn't play, and then installed the software (which he's constantly annoyed about, because it never seems to do quite what he wants... I thought Apple were supposed to be masters of UI design?). I'm pretty sure he didn't reformat it. There certainly wasn't a restore step to make it work afterwards.
The Shuffle, though, is a Flash-based model. That may be the difference.
A millisecond is a very long time compared to a nanosecond, which is where CPUs are running.
Not running device drivers in ring 0 typically involves two additional context switches per operation (kernel with user program address space -> driver and driver -> kernel with user address space).
Context switches typically require fetching of large amounts of memory, which is often not in cache (because they violate locality), so it's memory bus speed that is the primary determinant of context switch speed. It would not be out of the ordinary for a context switch to require several hundred memory cycles, which would put it into the approximate range of a hundredth of a millisecond, as I was talking about.
I agree that it is a small difference, but it is a noticeable one in some circumstances. The main loss would be in application startup times, and in performance when the system is low on memory.
I'm suggesting that the CPU should be able to regain control of the system within something less than a freakin' MINUTE OR MORE if the driver or hardware hoses up. The retry counts an OS uses are ridiculous. If the damn thing isn't working in five tries, give it up.
I'll give you that one -- that *is* ridiculous. I've only seen it myself when caused by the disk with the paging file on it crashing, but I can imagine it might be a problem in other circumstances too.
It's simply not acceptable for a third party piece of software written by some unknown moron can drag down the whole system. I think not going kaput is more important to a server than even the throughput
True. But, I've found that if you use quality components, Windows servers are generally as reliable as the hardware they run on. You just have to make sure that the parts you're buying are up to professional quality. If they have unsigned drivers, take them back to the vendor and complain. Driver signing happens for a reason, and all too often I've found cards that ship with unsigned drivers are buggy and unreliable. (I'm thinking of Belkin PCI WLAN cards here, specifically...) Better yet, only buy hardware that has drivers in the base Windows distribution. It's what we do with Linux, why not take the same approach when building a Windows machine?
If exactly half of all children are male and the other half female and you ask only the females what sex their sibs (if any) are, you're gonna get an overwhelmingly biased response.
Do the math.
OK. Assuming that each family examined contains 2 siblings, there are four possible and equally likely pairings: MM, MF, FM and FF.
So, for any sample of (say) 100 such families, we expect there to be 25 girls who are the second of an MF pair, 25 who are the first of an FM pair, 25 who are the first of an FF pair, and 25 who are the second of an FF pair. Of these 100 girls, the first 50 have male siblings, and the last 50 have female siblings.
Yeah, if you drop IE in a vat of hydrochloric acid, all the bits will get dissociated and float to the surface, then you fish them out and centrifuge them, and expose them to UV to make the 1s stand out you can tell that it's broken.
Re:Evolution of the user's response to poor design
on
IE7 Bugs and Reviews
·
· Score: 1
If I designed a car and drivers trained themselves to kill the engine in drive every time, that would be some shoddy design on my part.
I have a friend who has perfected the art of bump-starting a car when it stalls while he decelerates for a junction without having to get out and push.
You're right. People learn ways to work around broken technology.
But don't go arround suggesting that Firefox should drop the very things that make up its core. I mean, drop XUL and you lose the extensions and the whole modularity.
You wouldn't drop XUL; you'd just move the implementations of some of the pieces of code that are currently written in js onto the native side of the equation. For instance, most of the functions in browser.js could be very easily ported to C code, and a method added to allow that C code to be referenced from the browser.xul where it currently references the functions in browser.js. My guess is that memory usage would drop and responsiveness would improve, and no functionality would be lost.
This makes sense until you realize that the sample set was all girls. Once you factor that in, it's hardly surprising to find that 66% of their siblings were male.
Why? Is there a tendency to select a second child to be the opposite gender of the first (presumably via abortion)?
Slashdot Mirror
Fix :hover on all elements
:)
Wow. I thought they'd never do this. Now IE users get to see how brain-damaged most people's CSS link highlighting is, not just us alternative browser users!
Right now, the bug I'd like to see fixed most in IE is the one where if you have a div, and put a floating div inside it, followed by <br clear=all>, the outer div ends up being not quite as tall as the inner one...
Wifi has that, but it asks permission at that level, also. Basically 'Can I plug into this network'. This is the level that WEP and WPA work at.
If this is true, why does my AP switch the link light on and apparently grant access to a machine that has an incorrect WEP key?
The owner of the AP is responbile for knowing what the AP is doing. The AP comes with documentation telling you how to set up the way you really intend to. If due to your ignorance/incompetence you completely miscommunicate your intentions and inadvertently advertise that permission to connect is granted to some other person, that's not other person's fault. As far as the other person is concerned, it doesn't really matter what was in your mind if a device you are fully responsible for is going around telling everyone that it is OK to connect.
Let me clarify my point. The device does this by default. There is no way to stop it doing so except by setting it up, then logging in and changing the settings to stop it from doing so. As I have no choice but to run an open network for the time it takes to do so, the fact that I have done so cannot be considered as me having given any random passer-by permission to do so.
By extension, the fact that not all open networks are in a position to authoritatively grant permission to connect means that we must accept that this setting does not ever grant permission BY ITSELF. Otherwise, we would be left in the position that depending on some unknown context the fact that a network allows you to connect either may or may not be permission. In this situation, we cannot make any assumptions about the owners intent and therefore (on the basis that connecting to a network without permission is a substantially worse problem than us being denied access to a network that we should have access to merely because we do not know whether or not we should) we should not use the network.
An entirely automatic function of a network cannot be taken as indicative of its owner's intentions. A person must act to grant permission for another to use some of their resources, inaction is not enough. The consequences otherwise lead to a very unpleasant world, where you always have to watch what you're doing, because if you fail to tell somebody not to use your stuff, they'll take that as permission to use it. I don't want to live in that world... do you?
Here's a scenario which is based on a true story of my own: I walk up to a store on the street in the middle of the afternoon. The door is unlocked, I walk inside and start looking around. Then, the alarm goes off. The shop's new employee left out the back door, set the alarm, and forgot to lock the front door. Should I be booked for attempted burglarly or something? The shop keeper intended for the store to be closed, but they made a mistake and left the store in such a state that says "We're open".
There is a substantial difference between this analogy and the actual practice of using somebody else's unsecured network. For an incredibly substantial majority of times, when a shop advertises that it is open, this is because they want people to come in. However, I'm pretty sure that a substantial majority of open wireless networks are open not because their owners want other people to use them, but rather they do so because they are too ignorant or lazy to secure them properly. In the case of a shop, we can safely assume that the owner wants us to enter. In the case of a wireless network, we can't, because that isn't what most people operating them want.
The router is only your agent if you have given the router permission to act as your agent. This would have to be explicit somewhere.
2. Who gave the AP permission to grant that permission?
The owner - the only person with legitimate authority to control that permission. I suppose an AP could be hacked by someone to become open, but this guy didn't do that. The open AP was put there in the open state by the owner.
Hmmm. When I first installed my AP, it was open.; that was the way the manufacturer supplied it. I had to secure it afterwards. But I certainly never gave it permission to let just anyone come along and use my network. It was entirely automatic -- and permission cannot be granted entirely automatically. There must be some process of informing a person that they are granting permission, and then some action that confirms that they want to do so. This is the simple basic fact of what consent is.
Yes, I'm perfectly aware of how DHCP works. But the fact remains that it does not grant authorisation -- it merely provides information that is necessary to make the network work.
From the same RFC you quoted, paraphrasing slightly for simplification, and adding emphasis:
[A] network administrator, to retain stringent control over the hosts attached to the network, MAY choose to configure DHCP servers to respond only to [authorised clients].
Note the use of the word "may" -- this is a clear indication that it is possible for DHCP servers to respond to unauthorised clients.
An analogy:
Me: I'd like to use your car. Can I have the keys?
You: Sure. Here's a key I made just for your use.
Some time later...
You: Officer, he hijacked my car!
Officer: What do you mean, "hijacked"?
You: He told me that he'd like to use my car, so I had a key made just for him. Then, later, I discovered that he had been using my car!
Officer: Are you on any medications?
A more accurate analogy.
A: I've just got this brilliant new piece of kit. You see I lend my car to so many people, and it always takes me ages to find out who's got the keys and where they left them, so I've got this key cutting machine. All you have to do is press a button and it cuts a new key.
[Exit A]
B: Hmmm. I want to borrow A's car. I know, I'll just get a copy of the keys from this key cutting machine he's left outside his front door.
[Exit B with A's car; A returns]
A: Where's my car...? D'oh! I should have put the key cutting machine locked away inside like the instruction manual told me to.
OK, so A is incredibly stupid. But that doesn't mean that B has a right to "borrow" his car like that.
Now, we're not asking about females who are the second of a pairing, just about females and their sibs.
You misread my argument. I'll clarify it here:
The 1/4 of the overall set that are MM will never be asked anything. That leaves FM, MF and FF. Hmmm . . . whaddya know? There's twice as many brothers as sisters out there!
No, there aren't. Let's break those three pairs down:
Pair 1 (FM) has person 1a(F) and person 1b(M). We will ask person 1a, who is F, and the response will be M.
Pair 2 (MF) has person 2a(M) and person 2b(F). We will ask person 2b, who is F, and the response will be M. That's 2xM, 0xF.
Pair 3 (FF) has person 3a(F) and person 3b(F). We will ask person 3a, who is F, and the response will be F. 2xM, 1xF. Then we ask person 3b (which you seemed to forget to do in your survey, which is a little strange, seeing as you're supposed to be asking all the girls), and the response will be F, so the totals are 2 male and 2 female. Still no problem.
Remember -- we are only interviewing girls about their siblings (it was an all-girl school, remember?), not a random sampling from the overall sample set. In effect, we're not getting a truly representative sample set.
Yes, but if gender of sibling is independent of gender of subject (which we would normally assume it to be, in absence of any known cause of bias), then it doesn't matter: for the purpose of finding sibling's genders, asking only female subjects is equivalent to taking a random sample.
Now there are biases that might exist: parents might be more likely to have an abortion if both their children would be the same gender (which would bias the result towards male), and I believe some people have medical conditions that cause them to only have children of a particular gender (which would bias the result towards female), but I'm guessing that both of these are fairly insignificant, and probably cancel each other fairly well anyway.
Err... no. Giving a DHCP response is not authorisation to use a network. DHCP is a means to gather technical information about how to connect to a network, not a way of getting permission to use it.
But the Wifi login *is* the electronic proxy for the person. It *is* where the person gets to say whether its OK to come in or not.
There is no login to an unsecured wireless network -- you just start using it, that's the beginning and the end of it. There's no login to a WEP secured network either, but you need to get hold of the key.
WPA supports network login (except when using WPA-PSK, which is equivalent to WEP except it uses better encryption and authentication), but no older protocol does.
His computer said to the AP, "Hi, can I connect?" and the AP said "Sure, hook right on up.".
1. I don't believe that's how unsecured wireless networks work: basically, you just start using them. You might want to use DHCP to get config information, but that's not the same thing at all.
2. Who gave the AP permission to grant that permission?
If i leave a plate of biscuits (cookies) just inside the open gate to my garden with a sign saying "take one please", is it a crime for someone to take one?
No. But the situation being discussed is more akin to leaving a plate of biscuits just inside your open biscuit without a sign saying "keep your hands off my biscuits."
You can't take absence of dissent to imply consent. The world breaks down if you do that.
My laptop auto-connected until SP2. Now, it behaves as you say.
Whereas my desktop didn't at any point. Neither did it do so under Win2K. To get auto connections you have to either check the relevant box in Network Connections/Wireless Connection/Properties/Wireless/Advanced (which has existed since the very beginning of wireless support in windows), or install a 3rd party network connection utility. My experience with these has suggested that most don't connect automatically: I've used utilities supplied by Belkin, LinkSys and D-Link, and none have autoconnected.
It might be that your card's installer is setting the option for you, in order to help you install it more easily, and the SP2 install deselected it.
Probably. But nobody actually suggested anybody hijack a network... the original poster who used the word was using it in reference to people who assume open network => authorisation to use the network are "hijacking the meaning" of the network being unsecured (which is just that... it means there's no encryption).
Yet his computer asked for concent and was told it was OK.
Err.. no, it didn't. To connect to an unsecured wireless network, you just start sending packets. No request for consent to join the network is involved.
The only time a request for consent is involved is if you're joining a network that's protected via some kind of login system (i.e. a secure network that isn't using "shared key" security).
If they thought he had a bomb, why did they let him board the bus when they were following him?
Never ascribe to malice what can be adequately explained by incompetence.
They are all HFS+, but if you install the PC software before connecting the iPod it will prompt you to restore it to be FAT32. If you connect the iPod before installing the software, things get all confused, the OS will prompt you to reformat it, and it'll cease to play music until you restore it.
That's not true of all of them. A friend of mine has an iPod Shuffle, for instance, and tried to make it work without the software before he installed the software (he was used to other models that simply play whatever files you store on them). He put files on there, got annoyed that they wouldn't play, and then installed the software (which he's constantly annoyed about, because it never seems to do quite what he wants... I thought Apple were supposed to be masters of UI design?). I'm pretty sure he didn't reformat it. There certainly wasn't a restore step to make it work afterwards.
The Shuffle, though, is a Flash-based model. That may be the difference.
"Partner with another computer to fill the void?"
Does nobody edit these submissions?
A millisecond is a very long time compared to a nanosecond, which is where CPUs are running.
Not running device drivers in ring 0 typically involves two additional context switches per operation (kernel with user program address space -> driver and driver -> kernel with user address space).
Context switches typically require fetching of large amounts of memory, which is often not in cache (because they violate locality), so it's memory bus speed that is the primary determinant of context switch speed. It would not be out of the ordinary for a context switch to require several hundred memory cycles, which would put it into the approximate range of a hundredth of a millisecond, as I was talking about.
I agree that it is a small difference, but it is a noticeable one in some circumstances. The main loss would be in application startup times, and in performance when the system is low on memory.
I'm suggesting that the CPU should be able to regain control of the system within something less than a freakin' MINUTE OR MORE if the driver or hardware hoses up. The retry counts an OS uses are ridiculous. If the damn thing isn't working in five tries, give it up.
I'll give you that one -- that *is* ridiculous. I've only seen it myself when caused by the disk with the paging file on it crashing, but I can imagine it might be a problem in other circumstances too.
It's simply not acceptable for a third party piece of software written by some unknown moron can drag down the whole system. I think not going kaput is more important to a server than even the throughput
True. But, I've found that if you use quality components, Windows servers are generally as reliable as the hardware they run on. You just have to make sure that the parts you're buying are up to professional quality. If they have unsigned drivers, take them back to the vendor and complain. Driver signing happens for a reason, and all too often I've found cards that ship with unsigned drivers are buggy and unreliable. (I'm thinking of Belkin PCI WLAN cards here, specifically...) Better yet, only buy hardware that has drivers in the base Windows distribution. It's what we do with Linux, why not take the same approach when building a Windows machine?
Nope. Statistical bias.
If exactly half of all children are male and the other half female and you ask only the females what sex their sibs (if any) are, you're gonna get an overwhelmingly biased response.
Do the math.
OK. Assuming that each family examined contains 2 siblings, there are four possible and equally likely pairings: MM, MF, FM and FF.
So, for any sample of (say) 100 such families, we expect there to be 25 girls who are the second of an MF pair, 25 who are the first of an FM pair, 25 who are the first of an FF pair, and 25 who are the second of an FF pair. Of these 100 girls, the first 50 have male siblings, and the last 50 have female siblings.
I don't see the problem.
Oh wait, you're talking about a different Acid.
Yeah, if you drop IE in a vat of hydrochloric acid, all the bits will get dissociated and float to the surface, then you fish them out and centrifuge them, and expose them to UV to make the 1s stand out you can tell that it's broken.
If I designed a car and drivers trained themselves to kill the engine in drive every time, that would be some shoddy design on my part.
I have a friend who has perfected the art of bump-starting a car when it stalls while he decelerates for a junction without having to get out and push.
You're right. People learn ways to work around broken technology.
But don't go arround suggesting that Firefox should drop the very things that make up its core. I mean, drop XUL and you lose the extensions and the whole modularity.
You wouldn't drop XUL; you'd just move the implementations of some of the pieces of code that are currently written in js onto the native side of the equation. For instance, most of the functions in browser.js could be very easily ported to C code, and a method added to allow that C code to be referenced from the browser.xul where it currently references the functions in browser.js. My guess is that memory usage would drop and responsiveness would improve, and no functionality would be lost.
This makes sense until you realize that the sample set was all girls. Once you factor that in, it's hardly surprising to find that 66% of their siblings were male.
Why? Is there a tendency to select a second child to be the opposite gender of the first (presumably via abortion)?
There is only one true standard editor.
So true. EDLIN, where are you now?
so, two koreans walk into a pc bang...
What's a pc bang? Is that like a gang bang with all the words changed around so nobody gets offended?