When did I ever say the O.S. didn't use reference counting with the DLLs? For one thing, that's what mmap() does anyway. However, I was responding to you saying that not the entire library is mapped into the process, as in:
<quote> AGAIN: The OS memmgt. subsystems may load a libs/dll's ENTIRE BODY, globally, for sharing amongst apps (as far as libs/dlls are concerned), but, only the parts you NEED map into the calling application's private memory space (when it uses a lib/dll for its own uses). </quote>
Your words, not mine. As I said, I already understood how this worked beforehand. However, you didn't have it right, and your original post was way off. The only one "spouting outrageous b.s." here is you.
And just so you don't try to say I'm wrong again, there might very well be counters specifically for library references (rather than just all mmap'd objects), seems like an implementation-dependent thing.
I think this pretty well shows your level of intelligence:
In response to me: mmap is pretty much free, in any case mmap a bigger segment vs. a small segment has approx the same cost. No efficiency loss there.
You said: <quote>
Ok... A QUESTION:
ARE YOU TRYING TO SAY THAT IF I LOADED MORE FUNCTIONS FROM A LIB/DLL, THAT IT WOULD TAKE UP LESS MEMORY THAN ONLY LOADING A SINGLE FUNCTION SECTION FROM SAID LIB/DLL?
(You're wrong if you do, & that is the efficiency gain (I mentioned it earlier anyhow - less ram taken!)) </quote>
You think that mmap takes more memory for a larger segment, the difference is miniscule. There's also almost 0 extra CPU time. Further you seem to have lost your caps lock key while writing that. Please do to digg or somewhere and leave the people who actually work for a living alone.
AGAIN: The OS memmgt. subsystems may load a libs/dll's ENTIRE BODY, globally, for sharing amongst apps (as far as libs/dlls are concerned), but, only the parts you NEED map into the calling application's private memory space (when it uses a lib/dll for its own uses). </quote>
No, the entire library is mapped into the process's memory space. In order to only map parts of the library, the dynamic linker would have to know every function the referenced functions depend on.
I know how shared libraries work, it is you that does not. Also note that I was talking about mmap-ing the "code" sections to share between processes. The "data" sections are not shared, which is what I said from the beginning.
IPC (interprocess communication) has nothing to do with this, you were the only one that though message passing was related.
Alright, this is how I believe it works, keep in mind that "loading" and mmap-ing are similar in some ways (address space is used either way, and to the processit appears to be in memory).
Here is where you are wrong:
<quote> I did, because IF you're not calling a lib "in process", then you have "out of process" loads, & THIS (the latter) incurs messagepassing overheads... you aren't leaving me with any choice here, but to mention that, to inform you of it. </quote>
Memory mapped sections are shared between processes, and do not exist in any one process. Therefore the library itself is "shared" (not in-process) but not out of process. The entire library is mapped into your address space, and may or may not be in RAM. Entire pages of this library (page = 4K by default) are loaded at a time. The OS may therefore load more of your library than it strictly needs. Loading the same library in two processes will not require loading the library twice.
Yes, you deserved to be insulted for thinking that either the library was loaded into a process or it was out-of-process, mmap is very old and if you are going to comment on library loading you should understand it. The way I worded my original response was not entirely clear, and others phrased it better, however my meaning was the same.
Who said anything about inter-process calls? You map the code section of each library into each process. The data section can be per-process (so that global variables are per-process). Do you honestly think it's a good memory v. CPU tradeoff to have the dynamic linker figure out which parts of a library you need?
mmap is pretty much free, in any case mmap a bigger segment vs. a small segment has approx the same cost. No efficiency loss there.
Also, note that I prefaced my comment that I was talking about *nix not Windows. However I really doubt that NT works the way you think it works, like I said having the linker figure out which functions you need (including dependent functions) would be very slow, and most libraries aren't huge. I suppose the compiler could pre-compute dependency trees for each function and throw them in the DLL, but that would increase file size and probably isn't worth it. No, I really doubt any working OS tries to load libraries piece-meal, they can easily mmap the library into the process and let the MMU figure out which pages the process needs. That still leaves the whole library inside the process.
Actually, your comment about IPC to call libraries, exactly what process did you think the library would be running in to call?
My point was that you don't load the lib into the process just for that one, you memory map the library (not the same as loading).
I still can't get over that you were stupid enough to think I was suggesting message passing.
Global variables are always local to the process, please understand mmap() before responding to posts about how OSs work.
To be fair, I'm pretty sure in *nix this is not the case, calling a function in a library requires the entire library to be loaded into memory. Of course I can't think of a good reason to load a library into an app's memory space, isn't it loaded into shared memory and mapped in to each process that needs it? (AFAIK mapping is almost free compared to loading a library). Libraries do have global variables, so just loading the function likely wouldn't work, you need at least the shared variables, and those variables could well contain function pointers. Plus the function you call could well call other functions, it doesn't seem helpful to just load one section of the library, you'll need the rest anyway.
BTW, I'm not a web person, just also not an NT person.
Sometimes it's important to know the simple solution as well. Most (all?) of the algorithms that perform better than O(n^2) have a fairly high constant attached to them, which usually translates to more computing time and a difficult to implement algorithm. If you're really concerned about speed (you may have to sort 5 items from each of 500,000 lists) then you need to know how much data you're dealing with.
However, that's all too complicated for a beginner's course. Teach them about stdin/stdout, teach them I/O basics, teach them about data structures.
The sorts are interesting sure, but treat it more as a way to demonstrate the multiple ways of doing the same thing can be vastly different. It's a mind-opening experience, not an end in and of itself.
A good middle or end-of-term program the might just catch their attention, write a program that can retrieve a single page from an HTTP server. They don't need to know every nook-and-cranny of HTTP to do it, and it's a good way to gain some familiarity with networking. I know it's not the standard beginner's material, but that material was written 20+ years ago, today's students want something that's relevant to them.
Finally, I suggest Java. It's easy to learn, very powerful and (relatively) consistent. Java was the first language I really learned, before the end of the 1st quarter, while the other students were still learning what classes were, I had written my first network server.
You should be able to run Firefox (or almost any other application) from anywhere on the disk, including your home folder, you don't need to put it in Applications to use it. Of course, if your employer has specifically prevented programs from running from your home folder then you're screwed (and you work for paranoid idiots).
Nuclear doesn't release CO2, and the waste is low volume and doesn't need to be filtered. Expecting to get enough power from pure "green" sources within the next 50 years is not reasonable, if you ask for perfection you will get nothing.
Making the source code available, and requiring the derived works be under a similar or identical license. Of course, it's been a while since I reviewed the GPL. In practical terms, any program containing GPL code has to be under the GPL (ALL of the program) and the GPL requires you to make the source available.
That's GPLv2, GPLv3 works the same way I believe, but I'm more familiar with v2.
non-GPL applications can't use or link against code from GPL projects. The BSD license essentially says what you described, the GPL has extra restrictions.
The extra restrictions also prevent non-open source applications from using GPL code.
The biggest advantage would be that a company could query the system for any valid certificates for their domain (so would anyone else) and detect when their records were compromised.
The certificate does need to list *that* domain name, so a man-in-the-middle attack by an ISP would only work if they have a signed certificate for that domain name, not just any certificate. The ISP itself (hopefully) isn't a CA.
On the other hand, I'm sure the government could get verisign to make them whatever cert they wanted.
It would probably work better if there was a single, well-known, trusted entity running a database of the key(s) assigned to particular domain, rather than the key containing the domain. This one entity could then have a well known key that it used to sign all of its messages. Thus if anyone tampered with the valid keys for the domain it would be in public view.
The current system does leave it open to silent tampering.
I'm Not A Cryptography/Security Expert, can anyone poke holes in that idea?
It wouldn't have to be just one machine, multiple mirrors could be run, but there should be a high level of trust between the administrators of the mirrors.
Right, the issue that I have run into is that often the managers looking at the UI have no comprehension of the problem the software is intended to solve. For instance, if you were writing a UI for looking at genetic structures (note: I have no knowledge of this field) then some manager with an MBA and no knowledge of DNA should not look at it and it is too confusing.
The issue isn't quite identity verification, the issue is that without a trusted certificate another server masquerading as yours can connect to your server and retrieve the data the user is requesting without either party noticing. That's what a man-in-the-middle attack (is simple terms). There's simply no way to secure the link without that. There may be other ways to have a signed certificate system, and that is where you should be looking.
My family came over here in the early 20th century from Ireland. I'm not responsible for what the British and others did here in the U.S., in fact they treated the Irish as little for than slaves for hundreds of years and yet *somehow* the Irish have managed to become quite successful in their own right since independence. Don't tell me some sob story and then expect them to get more than they already are, which is a lot more than my great-grandfather got.
The question would be whether it blocks the HTML that causes the applet to be initialized, or whether it can actually prevent Firefox from loading the JRE through plugin loading. Admittedly, I don't know how NoScript works.
Actually, my guess is that this is some sort of automatic file type detection where the browser tries to detect the type of file and use the appropriate plugin (thus causing the JRE Applet Plugin to potentially get selected). If that's the case, NoScript may not recognize it, though disabling Java should fix it.
Off of destroying an entire area to the benefit of no one but themselves, yes. Fine, they can drill there, they have to pay to but it back exactly like it was when they are done. Oh, you mean then they wouldn't make a profit? THEN IT'S NOT PROFITABLE, IT'S A SUBSIDY
Except that it's their job to enforce the law, using undue force on a suspect is assault. It doesn't matter what their upbringing is, they are supposed to enforce the law, and if they fail to do so they themselves should be held accountable for that failure.
I'm pretty sure it would be trivial to set up a PC to PC voice connection, even with just openssh, assuming the microphone and speaker are both "files".
I'd imagine on both sides the command would look like this:
Obviously I don't know the exact device name, and you might have to use some other program to read in from the mic and such. IF the connection is slow/choppy, use speex. You should still even be able to do it from the command line, assuming the speex encoder streams.
The point is, and I'm sure you know this, there are already OSS programs capable of setting up the whole connection, so skype being buggable just makes it easier to spy on people who aren't as concerned about their privacy and/or deal with people who aren't.
On another note, isn't it possible that the official was only talking about skypeOut calls? Surely bugging a call over PSTN coming from skype is no different than any other PSTN call, and they don't need to break skype to do it.
And, as demonstrated above, there are far more secure ways to do PC2PC than skype.
Slashdot Mirror
Stop using my name.
When did I ever say the O.S. didn't use reference counting with the DLLs? For one thing, that's what mmap() does anyway. However, I was responding to you saying that not the entire library is mapped into the process, as in:
<quote>
AGAIN: The OS memmgt. subsystems may load a libs/dll's ENTIRE BODY, globally, for sharing amongst apps (as far as libs/dlls are concerned), but, only the parts you NEED map into the calling application's private memory space (when it uses a lib/dll for its own uses).
</quote>
Your words, not mine. As I said, I already understood how this worked beforehand. However, you didn't have it right, and your original post was way off. The only one "spouting outrageous b.s." here is you.
And just so you don't try to say I'm wrong again, there might very well be counters specifically for library references (rather than just all mmap'd objects), seems like an implementation-dependent thing.
I think this pretty well shows your level of intelligence:
In response to me:
mmap is pretty much free, in any case mmap a bigger segment vs. a small segment has approx the same cost. No efficiency loss there.
You said:
<quote>
Ok... A QUESTION:
ARE YOU TRYING TO SAY THAT IF I LOADED MORE FUNCTIONS FROM A LIB/DLL, THAT IT WOULD TAKE UP LESS MEMORY THAN ONLY LOADING A SINGLE FUNCTION SECTION FROM SAID LIB/DLL?
(You're wrong if you do, & that is the efficiency gain (I mentioned it earlier anyhow - less ram taken!))
</quote>
You think that mmap takes more memory for a larger segment, the difference is miniscule. There's also almost 0 extra CPU time. Further you seem to have lost your caps lock key while writing that. Please do to digg or somewhere and leave the people who actually work for a living alone.
AGAIN: The OS memmgt. subsystems may load a libs/dll's ENTIRE BODY, globally, for sharing amongst apps (as far as libs/dlls are concerned), but, only the parts you NEED map into the calling application's private memory space (when it uses a lib/dll for its own uses).
</quote>
No, the entire library is mapped into the process's memory space. In order to only map parts of the library, the dynamic linker would have to know every function the referenced functions depend on.
I know how shared libraries work, it is you that does not. Also note that I was talking about mmap-ing the "code" sections to share between processes. The "data" sections are not shared, which is what I said from the beginning.
IPC (interprocess communication) has nothing to do with this, you were the only one that though message passing was related.
From the POSIX standard (man page format):
http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
Wikipedia:
http://en.wikipedia.org/wiki/Mmap
Alright, this is how I believe it works, keep in mind that "loading" and mmap-ing are similar in some ways (address space is used either way, and to the processit appears to be in memory).
Here is where you are wrong:
<quote>
I did, because IF you're not calling a lib "in process", then you have "out of process" loads, & THIS (the latter) incurs messagepassing overheads... you aren't leaving me with any choice here, but to mention that, to inform you of it.
</quote>
Memory mapped sections are shared between processes, and do not exist in any one process. Therefore the library itself is "shared" (not in-process) but not out of process. The entire library is mapped into your address space, and may or may not be in RAM. Entire pages of this library (page = 4K by default) are loaded at a time. The OS may therefore load more of your library than it strictly needs. Loading the same library in two processes will not require loading the library twice.
Yes, you deserved to be insulted for thinking that either the library was loaded into a process or it was out-of-process, mmap is very old and if you are going to comment on library loading you should understand it. The way I worded my original response was not entirely clear, and others phrased it better, however my meaning was the same.
Who said anything about inter-process calls? You map the code section of each library into each process. The data section can be per-process (so that global variables are per-process). Do you honestly think it's a good memory v. CPU tradeoff to have the dynamic linker figure out which parts of a library you need?
mmap is pretty much free, in any case mmap a bigger segment vs. a small segment has approx the same cost. No efficiency loss there.
Also, note that I prefaced my comment that I was talking about *nix not Windows. However I really doubt that NT works the way you think it works, like I said having the linker figure out which functions you need (including dependent functions) would be very slow, and most libraries aren't huge. I suppose the compiler could pre-compute dependency trees for each function and throw them in the DLL, but that would increase file size and probably isn't worth it. No, I really doubt any working OS tries to load libraries piece-meal, they can easily mmap the library into the process and let the MMU figure out which pages the process needs. That still leaves the whole library inside the process.
Actually, your comment about IPC to call libraries, exactly what process did you think the library would be running in to call?
My point was that you don't load the lib into the process just for that one, you memory map the library (not the same as loading).
I still can't get over that you were stupid enough to think I was suggesting message passing.
Global variables are always local to the process, please understand mmap() before responding to posts about how OSs work.
To be fair, I'm pretty sure in *nix this is not the case, calling a function in a library requires the entire library to be loaded into memory. Of course I can't think of a good reason to load a library into an app's memory space, isn't it loaded into shared memory and mapped in to each process that needs it? (AFAIK mapping is almost free compared to loading a library). Libraries do have global variables, so just loading the function likely wouldn't work, you need at least the shared variables, and those variables could well contain function pointers. Plus the function you call could well call other functions, it doesn't seem helpful to just load one section of the library, you'll need the rest anyway.
BTW, I'm not a web person, just also not an NT person.
Sometimes it's important to know the simple solution as well. Most (all?) of the algorithms that perform better than O(n^2) have a fairly high constant attached to them, which usually translates to more computing time and a difficult to implement algorithm. If you're really concerned about speed (you may have to sort 5 items from each of 500,000 lists) then you need to know how much data you're dealing with.
However, that's all too complicated for a beginner's course. Teach them about stdin/stdout, teach them I/O basics, teach them about data structures.
The sorts are interesting sure, but treat it more as a way to demonstrate the multiple ways of doing the same thing can be vastly different. It's a mind-opening experience, not an end in and of itself.
A good middle or end-of-term program the might just catch their attention, write a program that can retrieve a single page from an HTTP server. They don't need to know every nook-and-cranny of HTTP to do it, and it's a good way to gain some familiarity with networking. I know it's not the standard beginner's material, but that material was written 20+ years ago, today's students want something that's relevant to them.
Finally, I suggest Java. It's easy to learn, very powerful and (relatively) consistent. Java was the first language I really learned, before the end of the 1st quarter, while the other students were still learning what classes were, I had written my first network server.
You should be able to run Firefox (or almost any other application) from anywhere on the disk, including your home folder, you don't need to put it in Applications to use it. Of course, if your employer has specifically prevented programs from running from your home folder then you're screwed (and you work for paranoid idiots).
They can disclose the invention on a public registry without filing it, thus protecting themselves from someone else patenting it.
Nuclear doesn't release CO2, and the waste is low volume and doesn't need to be filtered. Expecting to get enough power from pure "green" sources within the next 50 years is not reasonable, if you ask for perfection you will get nothing.
Making the source code available, and requiring the derived works be under a similar or identical license. Of course, it's been a while since I reviewed the GPL. In practical terms, any program containing GPL code has to be under the GPL (ALL of the program) and the GPL requires you to make the source available.
That's GPLv2, GPLv3 works the same way I believe, but I'm more familiar with v2.
non-GPL applications can't use or link against code from GPL projects. The BSD license essentially says what you described, the GPL has extra restrictions.
The extra restrictions also prevent non-open source applications from using GPL code.
They weren't a corporation, and they were acquitted as what they did was legal, the media made it look much worse than it was.
The fact that you thought they were a corporation shows that you have done very little to educate yourself about the subject.
The biggest advantage would be that a company could query the system for any valid certificates for their domain (so would anyone else) and detect when their records were compromised.
The certificate does need to list *that* domain name, so a man-in-the-middle attack by an ISP would only work if they have a signed certificate for that domain name, not just any certificate. The ISP itself (hopefully) isn't a CA.
On the other hand, I'm sure the government could get verisign to make them whatever cert they wanted.
It would probably work better if there was a single, well-known, trusted entity running a database of the key(s) assigned to particular domain, rather than the key containing the domain. This one entity could then have a well known key that it used to sign all of its messages. Thus if anyone tampered with the valid keys for the domain it would be in public view.
The current system does leave it open to silent tampering.
I'm Not A Cryptography/Security Expert, can anyone poke holes in that idea?
It wouldn't have to be just one machine, multiple mirrors could be run, but there should be a high level of trust between the administrators of the mirrors.
Right, the issue that I have run into is that often the managers looking at the UI have no comprehension of the problem the software is intended to solve. For instance, if you were writing a UI for looking at genetic structures (note: I have no knowledge of this field) then some manager with an MBA and no knowledge of DNA should not look at it and it is too confusing.
The issue isn't quite identity verification, the issue is that without a trusted certificate another server masquerading as yours can connect to your server and retrieve the data the user is requesting without either party noticing. That's what a man-in-the-middle attack (is simple terms). There's simply no way to secure the link without that. There may be other ways to have a signed certificate system, and that is where you should be looking.
More than likely he's run into far too many people who simply look at something, take no time to understand it, and say it is too confusing.
In this respect, it is standardized, it's the kernel.
My family came over here in the early 20th century from Ireland. I'm not responsible for what the British and others did here in the U.S., in fact they treated the Irish as little for than slaves for hundreds of years and yet *somehow* the Irish have managed to become quite successful in their own right since independence. Don't tell me some sob story and then expect them to get more than they already are, which is a lot more than my great-grandfather got.
The question would be whether it blocks the HTML that causes the applet to be initialized, or whether it can actually prevent Firefox from loading the JRE through plugin loading. Admittedly, I don't know how NoScript works.
Actually, my guess is that this is some sort of automatic file type detection where the browser tries to detect the type of file and use the appropriate plugin (thus causing the JRE Applet Plugin to potentially get selected). If that's the case, NoScript may not recognize it, though disabling Java should fix it.
Off of destroying an entire area to the benefit of no one but themselves, yes. Fine, they can drill there, they have to pay to but it back exactly like it was when they are done. Oh, you mean then they wouldn't make a profit? THEN IT'S NOT PROFITABLE, IT'S A SUBSIDY
Except that it's their job to enforce the law, using undue force on a suspect is assault. It doesn't matter what their upbringing is, they are supposed to enforce the law, and if they fail to do so they themselves should be held accountable for that failure.
I'm pretty sure it would be trivial to set up a PC to PC voice connection, even with just openssh, assuming the microphone and speaker are both "files".
/dev/snd/out' < /dev/snd/mic
I'd imagine on both sides the command would look like this:
ssh joe@someplace.net 'cat >
Obviously I don't know the exact device name, and you might have to use some other program to read in from the mic and such. IF the connection is slow/choppy, use speex. You should still even be able to do it from the command line, assuming the speex encoder streams.
The point is, and I'm sure you know this, there are already OSS programs capable of setting up the whole connection, so skype being buggable just makes it easier to spy on people who aren't as concerned about their privacy and/or deal with people who aren't.
On another note, isn't it possible that the official was only talking about skypeOut calls? Surely bugging a call over PSTN coming from skype is no different than any other PSTN call, and they don't need to break skype to do it.
And, as demonstrated above, there are far more secure ways to do PC2PC than skype.