I had to point out that forking ENTIRE processes is much "heavier" & resource intensive, than it is using threadwork instead, for 1 example here.
And you have never been able to show that I wasn't already aware of that. Here, let me adopt your tactic for a moment:
OMG! I had to point out what a forkbomb is! You must not have known!!!111!!!one. Now let me reiterate for the next ten posts: I know what a forkbomb is and you don't. A forkbomb is a process which forks itself over and over. A forkbomb is a PROCESS which FORKS ITESLF over and over! Oh, and by the way, I know what a forkbomb is and you don't.
Is this all you've got? If so, this discussion is over -- you're clearly not willing to discuss the real issue here.
probably never will, as long as you waste time on/.
Look who's talking.
For that matter, from how rarely you even grammatically make sense here, I'm surprised you were published at all, even in PC World.
Well, that ONLY TAKES PLACE IF TWO OR MORE APPS ARE SHARING DATA
Like, I don't know, executable code? Or, yes, a document!
Like, maybe, the same things that would be shared with threads!
And if you're not sharing data with threads, the performance improvement is not significant. It's the kind of thing which might easily be sacrificed for stability or security. By the time you've got enough overhead from running separate processes, it might be time to look at partitioned green threads (Erlang-style) anyway.
Can't you admit where you are wrong/off
It would help if you showed me where. I say "not significant", and you hear "not at all". Let's find my original quote:
Forking processes is a LOT heavier than threadwork. When you do a *NIX "fork", you are spawning a completely NEW process,
It's also done copy-on-write, so it's very fast when your forked process doesn't change much compared to the original. Threads are faster, though.
This was as a reaction to your capslock emphasis on spawning a completely NEW process -- which is incorrect, by the way, as I've shown repeatedly; copy-on-write means that the new process is not entirely new, as it shares some memory with its parent.
I have never once said that processes are exactly as fast to spawn, or use exactly as much RAM, as threads. In fact, I'm not sure why you mentioned this, originally -- you were replying to:
I have never seen my Linux system have 1500 processes except when I was playing with forkbombs. And I don't see either happening in the near future -- again, unless I'm playing with forkbombs.
Perhaps you don't understand what a forkbomb is? Hint: It's not intended to be efficient. It's intended to be the opposite of efficient.
I have -- I haven't actually gone and bought it right away, but I have followed banner ads when I saw something interesting.
That said, these were at least somewhat relevant/contextual, and I absolutely do block the more obnoxious ones. Anything with an animation is GONE, Flash doubly so.
In sports, we know what's going on. We know why the pass was made, we know who made it, we can generally tell how helpful a particular "assist" was. For that matter, we know that this pass directly resulted in a score being made.
Here, it's all statistics, and we don't really have a clue. And, you don't seem to be addressing the points the GP made -- this doesn't necessarily make it "more fair" at all.
Be careful that you are not against a good idea merely because it was from Microsoft, if Google had suggested this would you have had the same reactions?
Well, first, Google wouldn't have suggested it. They'd have simply started doing it.
But ask yourself the same question -- are you ignoring the counterargument simply because you think the person is an MS-basher?
Disclaimer: I'm no longer answering your off-topic comments. Your attempt to turn a discussion on threading into Linux vs Windows is neither welcome nor appreciated. And that's ignoring that the original discussion was not about threading.
And, this changes WHAT, exactly? Your "pervasive message passing" is NOT a design paradigm for multiply threaded apps, period.
Where did I say it was?
you are now omitting the fact that forking ENTIRE PROCESSES is not only SLOWER, but also is heavier in RAM as well!
By a few bytes, yes. Does the concept of "copy-on-write pages" still elude you?
and, when that one program eats up your CPU, bug or not? When you compound its load with other apps you run (background daemons/services OR otherwise like trayicon apps)?
I'm sorry, was there a question in there?
If the question was "what do you do", you already know the answer, if you would read before replying, which you never seem to be able to do.
Which was my point, to a tee - to extoll diff. methodologies used... simple. You went 'off track' basically...
YOU replied to ME. I like to think that I was on track with my original comment.
Beg to differ: I have caught you saying things that are blatant errors, using your OWN words no less (I close this post on that very note in fact)...
So the best you've got is nitpicks. Nitpicks in which you are wrong. Your reading comprehension is as low as ever.
BUT, they are NOT THE SAME THING...
I did not say they were. They are treated the same way by the Linux scheduler, is all.
Oh, and this also ignores the part where the performance difference is irrelevant. Oh noes, it takes one millisecond instead of 0.3 to start a new process. Guess I better leave them in threads... Or maybe I can split tasks into separate processes and users, gain some security and stability (one process can completely blow up, and be restarted by another)...
Uhm, didn't you state this "amarok" program did that to you here, earlier?
As a bug, meaning when it does this, I kill it...
And since when does one program constitute "more than one app"?
Well, imo? Not really - how does "pervasive message passing" function as a COMPLETE OPPOSITE, in terms of design
It doesn't. I will give this one more try...
"Pervasive message passing" is a feature of language, or the framework. It's like object-orientedness, or garbage collection. It's a property of the tool.
"Coarse multithreading", as you've explained it, is a methodology. So is "fine-grained multithreading". These are like, oh, model-view-controller. You can implement model-view-controller with an object-oriented language, or, if you really want, you can implement it in a purely-functional language (like Haskell), or in a language without even a concept of a subroutine (BASIC with GOTOs), etc... you can do it in a language with garbage collection or without...
What's more, "coarse" and "fine-grained" are relative and a matter of opinion. How do you define a "task"? And keep in mind that while having thousands of threads sounds like "fine-grained", they are not sharing data, except by passing messages back and forth...
This is all & again: IF NO CHANGES ARE MADE? This NEVER happens, period.
Exactly.
Threads additionally (again), are much "lighter" to instance, than an entire process (as forking does, vs. spawning extra threads).
The overhead of using processes instead of threads is pretty much irrelevant, especially if you were going to use message-passing in the threads, even moreso if you're intentionally doing "coarse multithreading". Of course, you could also use shared memory between processes.
And yes, all of this is Linux-specific. Forking a process on Windows is much slower.
A few - but, the point is NOT so much about them
No, the point is that, originally, I said that I would not see any real improvement if I had a quad-core system instead of dual-core.
it's more about what happens when you have a "CPU Hog" of an app...
You seem to be operating in a fantasy world where:
I have more than one app that wants to saturate a core
I do not have the ability to set the priority of these apps lower
I absolutely need my one app to run at 100% of that one core, rather than 90% of it. (Especially ludicrous as you keep bringing up Amarok -- if Amarok is using 100% CPU because of a bug, forcing it to use 90% isn't going to cause problems.)
I was saying that dual-core is actually useless to me -- it's not. It just means I don't have to do item #2, above.
I never said or implied that multicore would never be usable, or that it was useless to everyone. I was merely speculating that most people are probably in the same situation I am.
Furthermore, most of the points you bring up, I knew, but didn't think they were relevant to the discussion. Had you been paying attention, you might have noticed that I was specifically making a statement about how completely irrelevant the deep technical details are to the point of whether dual-core is useful to the general population -- most people I know would never notice a machine they were using was dual-core until you pointed it out to them.
Or you can simply copy the files off the DVD and point VLC at the VIDEO_TS folder.
The reason I would use other tools is, mplayer -dumpstream, in particular, is a quick and dirty hack to grab just the movie and nothing else. Remember, we're still dealing with a 64-gig hard drive.
which is another manipulation in order to gain marketshare.
Right, and those manipulations can go away as soon as the war is over. Had it continued, would they have raised prices much? I suspect they'd have tried to keep prices stable as the technology got cheaper, until they eventually made a profit.
When you have to buy extra parts for your widget to work, and when parts for competing widgets are incompatible, you end up with what are essentially mini-monopolies.
What you're missing is that they are still essentially mini-monopolies. Competing formats are nowhere near as good as a single, open format, but they are better than a single closed format. (Among closed formats, a less-DRM'd, region-free version is better, too.)
Point about some studios doing both was, had the war gone on much longer, other studios might've been forced to follow suit. What you'd eventually end up with is, consumers buy the player and disc format they like best, and in another year or two, we'd have players that play both formats anyway. Of course, all that is pure speculation...
I didn't buy one, but most of them do have a better upscaler than the upscaling DVD players, for less money.
So that is actually a legitimate reason for buying one, although it doesn't make it suck any less for those of us who were invested in the losing side.
This would only hurt MS in the event that their lastest windows version isn't worth upgrading to....
It isn't.
I realise this doesn't prevent people just rebranding their own home brew windows, but how is this worse then all the pirated copies out there now?
The pirated copies are not sanctioned, have no support, could get you sued, won't auto-update, etc etc.
A GPL'd version would be just as good as the real thing, maybe minus support, but most support is by third-parties like Dell anyhow -- and I'm sure Dell could compile their own and support it (and not Windows).
this would at the very least give MS a home brew community which it could pluck useful idea's from.
Which would be GPL'd themselves, most likely, meaning they couldn't be included in the (proprietary) new Windows.
That's not to say I wouldn't like a GPL'd Windows, but it ain't gonna happen.
SSL cannot be done with name-based virtual servers, or really, anything else that depends on the Host: header.
The reason is, all headers are encrypted, including the Host header. In order for the encryption to be setup, you need to know which SSL certificate should be sent. In order to know that, you need to know which hostname the client expects -- which means you need the Host header.
In short, separate SSL domains need separate IP addresses, or, at the very least, separate ports. I'm not sure how browsers would react to separate ports, but then the ISP needs to allocate one port on its NAT gateway for everyone behind it running SSL.
The problem is, the cost may not be measured in dollars.
Right now, although my ISP only gives me one IP address per subscription, I control it. I can run a private web server, mailserver, etc. I can basically run a website on $10/year (the cost of registering a domain) unless I suddenly get popular. ($30/year if I pay for an SSL cert.)
If we stick with IPv4, this will no longer be possible. IPv6 would bring plenty of improvements on the current scheme, but sticking with IPv4 till it runs out means more NAT, and at the ISP level. And that means a higher barrier of entry to being a web server. It means the Myspaces and Livejournals of the world get to control everything anyone wants to publish.
This is not a cost that we can measure in dollars, though. It's a cost to society.
Trust is different than trustworthiness. Trustworthiness is a quality, and trust is an action.
Trusting someone always makes you less secure, no matter how trustworthy they are. It is certainly better to trust someone who is trustworthy, but it is still a decrease in security.
Consider the case where you don't have commit access, which means that not only is someone else committing for you, but they're probably committing it all in one big patch, rather than lots of little increments.
I know that at work, where I have commit access, I tend to commit all the time -- if I need to not break things for everyone else, I make a branch. But for open source projects, I might do a weekend's worth of coding before sending it in, and even then, someone else gets commit credit.
You're sort of right, though -- it's pretty impossible to find a good metric by which to measure productivity.
That doesn't answer the question I asked: Does "pervasive message passing" function as an example of an exact opposite of "coarse multithreading" as do mine for "fine grained multithreading"?
Read the paragraph below the one you quoted! I did answer your question.
Forking processes is a LOT heavier than threadwork. When you do a *NIX "fork", you are spawning a completely NEW process,
It's also done copy-on-write, so it's very fast when your forked process doesn't change much compared to the original. Threads are faster, though.
And none of this is relevant to the current discussion.
I have 37 backgrounded trayicon & services running... of those, 27 bear 2-N threads.
How many of those are actually using a significant chunk of CPU?
(That is over 78% worth of my processes that run backgrounded that gain because of OS process scheduler subsystems sending threads, as needed (usually in the case of cpu cycles starvation on the main CPU core), to 2-N cpu cores/cpus available).
And if they are, collectively, using less than 5% of one core, then your performance gain for those processes being threaded is:
0 with no CPU-intensive tasks running (unloaded is unloaded, period).
One CPU-intensive thread will run 5% faster on a dual-core system than on a single-core.
Two CPU-intensive threads will each run 2.5% faster if a third core is available.
my laptop MUST have a built in DVD drive as I use it as an entertainment station for the kids while we're away, and having a separate drive hanging off on a usb cable is a big NO NO.
For this one, I'd rip a few discs worth, then pack away the DVD drive until I'm done watching them. If you're not re-encoding, it's fairly easy to rip just the movie (not the special features), and even with the 64 gig solid-state, that's still a good 4-5 movies. Figure, also, that it's a lot less wear on the discs (if you're bringing originals) to rip them in some stationary place, then put them away for the car (or plane) ride.
You say "Whooptee doo." Again... um... higher resolution is a BIG plus for many people, yet you just discount it... well done.
True, but the same applies to this as to OS choice. The Baby Boomers hate it when I turn their resolution up, because it makes everything smaller and harder to read, and they don't know how to set resolution or font size in most places. This is less relevant for OS X -- if they can figure out how to use the awesome zooming feature.
This SO doesn't apply to most people...
I think it does apply to a lot of people -- I'd imagine there are far fewer people who don't have a preference than people who prefer one to the other. But unless you really don't care about OS X, it makes sense to have the option, and Parallels if you need XP programs.
But Adobe shouldn't restrict its users from fixing and helping others fix Adobe programs.
I don't agree with RMS; I think that's entirely their right. As a user, it means I'm much more likely to use KPDF, but at no time do I think they "shouldn't do that".
I'm not sure if this is still the case when a monopoly is in effect -- for instance, I do consider it a bit unethical the way the Flash specs are presented, especially when it seems to be wanting to replace the Web. (Entirely -- Flash itself has a plugin called AIR which embeds Webkit, an HTML engine.) But this is mainly because Flash has no real competitors, and is not interoperable. Adobe Reader has plenty of competitors, and is using a standard format (PDF).
this poses a real practical problem for ordinary computer users.
Not really. At least, unless you have a reason to not want the latest version (and there are sometimes valid reasons), Adobe's interests are aligned with the customers' -- they have every reason to provide a security patch in a timely fashion.
leading you instead to think that the heart of this issue is what you're asking about
That may be true, but it doesn't make what I just said about the practical implications any less true.
Again: I love free software. As a user, I love the freedoms it gives me. As a developer, I usually don't mind giving those same freedoms to my users. But I neither use nor develop exclusively free software, and I see nothing wrong with that.
And I have read many of the gnu.org philosophy papers. I understand and respect your philosophy, and I do not share it. I'm not sure there's much you can say to change my mind. I hope, at least, that when I do develop free software, you find it useful.
I did that , to show 'extremes', this is all. Does YOUR 'pervasive messagepassing'
Erlang's, but thanks for the compliment.
(sounds like a normal Win32 message queue passing & scrubbing/reading messages system basically) fit the bill as a complete opposite, as does "fine grained" multithreading (vs. "coarse" multithreading)?
They are orthogonal. It does, however, make it easier to do fine-grained stuff.
And no, it's not a new idea -- Win32 didn't invent it either. But do me a favor, run a "ring benchmark".
Write a function that spawns N threads in a ring. That is, thread A connects to thread B, which connects to thread C, and eventually comes back around to thread A.
Now, send M messages around the ring.
How big can N get before you run out of RAM, or your system slows to a crawl? What's the relationship between M and the time it takes to execute?
On Erlang, I just had it spawn 100,000 processes and send 1,000 messages, and it took just under 14 seconds. Reversed those numbers -- spawned 1,000 processes, sent 100,000 messages -- and it took 26.7 seconds. Neither way used more than about 20 megs of RAM.
Understand, I'm not including this as a proof of raw performance, just as proof of the paradigm -- the language itself makes it easy to spawn ridiculous numbers of threads, and the runtime can handle it. They are green threads, but with SMP enabled, Erlang spawns exactly as many real OS threads as you have processors, and schedules green threads between them. Which means you get the best of both worlds: You can spawn literally one thread per function if you want, with minimal overhead, but you'll also automatically scale to the number of physical cores in use.
Now, if your Windows threads are anything like my POSIX threads, it's not going to take anywhere near a hundred thousand threads (around a thousand of which are actively vying for CPU time) to slow your benchmark to a crawl, and quite possibly overwhelm your OS scheduler.
Then, why did I have to mention it for you then??
You didn't. Read the paragraph after the one you're quoting.
You don't get it, do you? If you have enough of them running
But you see, I don't. Most people don't. This is the point you are missing.
By having another CPU/core to use, you could run more programs, more smoothly
Right now, I'm running email, IM, an MMO (under Wine), an IRC client, a web browser, and a povray instance. I simply don't have more programs that I want to run right now. That's not to say that I couldn't max out an eight-core system, if I just wanted to prove a point.
give me enough 4%-5% cpu using apps, even trayicon'd ones? The other core will HAVE to be used @ some point).
Yeah, at 4-5%, that's, what, 25 of them? Keep in mind, I have less than 5% used, total, among my seven system tray icons and 151 processes, not including povray. That means, depending on how you count, they are using on average a little less than 1%, or a little more than 0.03% each, meaning it would take either 120 system tray icons, or over 3000 processes, before it hits that other CPU. Let's pretend that I'm way off and the OS will spend 50% of the time scheduling -- I still don't have 60 system tray apps, and I have never seen my Linux system have 1500 processes except when I was playing with forkbombs. And I don't see either happening in the near future -- again, unless I'm playing with forkbombs.
Now, for this next part: You've just basically told me that Windows behaves the same way as Linux, in this regard. Maybe you don't know the terminology I was using. Or maybe you do, and were just pointing out what I'm about to:
Applications (run under Windows @ least) run under the context of the user logged on, & with his rights + abilities (down
Slashdot Mirror
We already do.
And you have never been able to show that I wasn't already aware of that. Here, let me adopt your tactic for a moment:
OMG! I had to point out what a forkbomb is! You must not have known!!!111!!!one. Now let me reiterate for the next ten posts: I know what a forkbomb is and you don't. A forkbomb is a process which forks itself over and over. A forkbomb is a PROCESS which FORKS ITESLF over and over! Oh, and by the way, I know what a forkbomb is and you don't.
Is this all you've got? If so, this discussion is over -- you're clearly not willing to discuss the real issue here.
Look who's talking.
For that matter, from how rarely you even grammatically make sense here, I'm surprised you were published at all, even in PC World.
Like, I don't know, executable code? Or, yes, a document!
Like, maybe, the same things that would be shared with threads!
And if you're not sharing data with threads, the performance improvement is not significant. It's the kind of thing which might easily be sacrificed for stability or security. By the time you've got enough overhead from running separate processes, it might be time to look at partitioned green threads (Erlang-style) anyway.
It would help if you showed me where. I say "not significant", and you hear "not at all". Let's find my original quote:
This was as a reaction to your capslock emphasis on spawning a completely NEW process -- which is incorrect, by the way, as I've shown repeatedly; copy-on-write means that the new process is not entirely new, as it shares some memory with its parent.
I have never once said that processes are exactly as fast to spawn, or use exactly as much RAM, as threads. In fact, I'm not sure why you mentioned this, originally -- you were replying to:
Perhaps you don't understand what a forkbomb is? Hint: It's not intended to be efficient. It's intended to be the opposite of efficient.
I have -- I haven't actually gone and bought it right away, but I have followed banner ads when I saw something interesting.
That said, these were at least somewhat relevant/contextual, and I absolutely do block the more obnoxious ones. Anything with an animation is GONE, Flash doubly so.
In sports, we know what's going on. We know why the pass was made, we know who made it, we can generally tell how helpful a particular "assist" was. For that matter, we know that this pass directly resulted in a score being made.
Here, it's all statistics, and we don't really have a clue. And, you don't seem to be addressing the points the GP made -- this doesn't necessarily make it "more fair" at all.
Well, first, Google wouldn't have suggested it. They'd have simply started doing it.
But ask yourself the same question -- are you ignoring the counterargument simply because you think the person is an MS-basher?
Disclaimer: I'm no longer answering your off-topic comments. Your attempt to turn a discussion on threading into Linux vs Windows is neither welcome nor appreciated. And that's ignoring that the original discussion was not about threading.
Where did I say it was?
By a few bytes, yes. Does the concept of "copy-on-write pages" still elude you?
I'm sorry, was there a question in there?
If the question was "what do you do", you already know the answer, if you would read before replying, which you never seem to be able to do.
YOU replied to ME. I like to think that I was on track with my original comment.
So the best you've got is nitpicks. Nitpicks in which you are wrong. Your reading comprehension is as low as ever.
I did not say they were. They are treated the same way by the Linux scheduler, is all.
Oh, and this also ignores the part where the performance difference is irrelevant. Oh noes, it takes one millisecond instead of 0.3 to start a new process. Guess I better leave them in threads... Or maybe I can split tasks into separate processes and users, gain some security and stability (one process can completely blow up, and be restarted by another)...
As a bug, meaning when it does this, I kill it...
And since when does one program constitute "more than one app"?
It doesn't. I will give this one more try...
"Pervasive message passing" is a feature of language, or the framework. It's like object-orientedness, or garbage collection. It's a property of the tool.
"Coarse multithreading", as you've explained it, is a methodology. So is "fine-grained multithreading". These are like, oh, model-view-controller. You can implement model-view-controller with an object-oriented language, or, if you really want, you can implement it in a purely-functional language (like Haskell), or in a language without even a concept of a subroutine (BASIC with GOTOs), etc... you can do it in a language with garbage collection or without...
What's more, "coarse" and "fine-grained" are relative and a matter of opinion. How do you define a "task"? And keep in mind that while having thousands of threads sounds like "fine-grained", they are not sharing data, except by passing messages back and forth...
Exactly.
Sigh...
Apparently, you still don't get it, even though you just tried to explain copy-on-write to me. fork() on Linux is implemented as copy-on-write, and has very little overhead. Linux sees threads and processes as essentially the same thing.
The overhead of using processes instead of threads is pretty much irrelevant, especially if you were going to use message-passing in the threads, even moreso if you're intentionally doing "coarse multithreading". Of course, you could also use shared memory between processes.
And yes, all of this is Linux-specific. Forking a process on Windows is much slower.
No, the point is that, originally, I said that I would not see any real improvement if I had a quad-core system instead of dual-core.
You seem to be operating in a fantasy world where:
I never said or implied that multicore would never be usable, or that it was useless to everyone. I was merely speculating that most people are probably in the same situation I am.
Furthermore, most of the points you bring up, I knew, but didn't think they were relevant to the discussion. Had you been paying attention, you might have noticed that I was specifically making a statement about how completely irrelevant the deep technical details are to the point of whether dual-core is useful to the general population -- most people I know would never notice a machine they were using was dual-core until you pointed it out to them.
Or you can simply copy the files off the DVD and point VLC at the VIDEO_TS folder.
The reason I would use other tools is, mplayer -dumpstream, in particular, is a quick and dirty hack to grab just the movie and nothing else. Remember, we're still dealing with a 64-gig hard drive.
It did happen.
Right, and those manipulations can go away as soon as the war is over. Had it continued, would they have raised prices much? I suspect they'd have tried to keep prices stable as the technology got cheaper, until they eventually made a profit.
What you're missing is that they are still essentially mini-monopolies. Competing formats are nowhere near as good as a single, open format, but they are better than a single closed format. (Among closed formats, a less-DRM'd, region-free version is better, too.)
Point about some studios doing both was, had the war gone on much longer, other studios might've been forced to follow suit. What you'd eventually end up with is, consumers buy the player and disc format they like best, and in another year or two, we'd have players that play both formats anyway. Of course, all that is pure speculation...
I don't see a way they could do it and make more cash than they do now. Or even as much.
I didn't buy one, but most of them do have a better upscaler than the upscaling DVD players, for less money.
So that is actually a legitimate reason for buying one, although it doesn't make it suck any less for those of us who were invested in the losing side.
In three seconds, they appear, and in two more, they're either dead or acquired. Remember, nothing's stopping this Microsoft from hiring hitmen.
I actually preferred the days when a player might go down to $99 at Wal-Mart.
Competition is good.
Standards are good too, but only when they are open standards, not controlled by those with a vested interest in one particular implementor.
Also, at least some studios were doing both.
The rest of your argument is pretty much sheer speculation.
As long as you're nitpicking, HTML isn't a programming language.
It isn't.
The pirated copies are not sanctioned, have no support, could get you sued, won't auto-update, etc etc.
A GPL'd version would be just as good as the real thing, maybe minus support, but most support is by third-parties like Dell anyhow -- and I'm sure Dell could compile their own and support it (and not Windows).
Which would be GPL'd themselves, most likely, meaning they couldn't be included in the (proprietary) new Windows.
That's not to say I wouldn't like a GPL'd Windows, but it ain't gonna happen.
SSL cannot be done with name-based virtual servers, or really, anything else that depends on the Host: header.
The reason is, all headers are encrypted, including the Host header. In order for the encryption to be setup, you need to know which SSL certificate should be sent. In order to know that, you need to know which hostname the client expects -- which means you need the Host header.
In short, separate SSL domains need separate IP addresses, or, at the very least, separate ports. I'm not sure how browsers would react to separate ports, but then the ISP needs to allocate one port on its NAT gateway for everyone behind it running SSL.
The problem is, the cost may not be measured in dollars.
Right now, although my ISP only gives me one IP address per subscription, I control it. I can run a private web server, mailserver, etc. I can basically run a website on $10/year (the cost of registering a domain) unless I suddenly get popular. ($30/year if I pay for an SSL cert.)
If we stick with IPv4, this will no longer be possible. IPv6 would bring plenty of improvements on the current scheme, but sticking with IPv4 till it runs out means more NAT, and at the ISP level. And that means a higher barrier of entry to being a web server. It means the Myspaces and Livejournals of the world get to control everything anyone wants to publish.
This is not a cost that we can measure in dollars, though. It's a cost to society.
No, better the sister learns this lesson early:
Trust is different than trustworthiness. Trustworthiness is a quality, and trust is an action.
Trusting someone always makes you less secure, no matter how trustworthy they are. It is certainly better to trust someone who is trustworthy, but it is still a decrease in security.
If you have commit access, maybe.
Consider the case where you don't have commit access, which means that not only is someone else committing for you, but they're probably committing it all in one big patch, rather than lots of little increments.
I know that at work, where I have commit access, I tend to commit all the time -- if I need to not break things for everyone else, I make a branch. But for open source projects, I might do a weekend's worth of coding before sending it in, and even then, someone else gets commit credit.
You're sort of right, though -- it's pretty impossible to find a good metric by which to measure productivity.
Read the paragraph below the one you quoted! I did answer your question.
It's also done copy-on-write, so it's very fast when your forked process doesn't change much compared to the original. Threads are faster, though.
And none of this is relevant to the current discussion.
How many of those are actually using a significant chunk of CPU?
And if they are, collectively, using less than 5% of one core, then your performance gain for those processes being threaded is:
For this one, I'd rip a few discs worth, then pack away the DVD drive until I'm done watching them. If you're not re-encoding, it's fairly easy to rip just the movie (not the special features), and even with the 64 gig solid-state, that's still a good 4-5 movies. Figure, also, that it's a lot less wear on the discs (if you're bringing originals) to rip them in some stationary place, then put them away for the car (or plane) ride.
True, but the same applies to this as to OS choice. The Baby Boomers hate it when I turn their resolution up, because it makes everything smaller and harder to read, and they don't know how to set resolution or font size in most places. This is less relevant for OS X -- if they can figure out how to use the awesome zooming feature.
I think it does apply to a lot of people -- I'd imagine there are far fewer people who don't have a preference than people who prefer one to the other. But unless you really don't care about OS X, it makes sense to have the option, and Parallels if you need XP programs.
Otherwise, good points.
The officially supported, legal one from Apple.
I don't agree with RMS; I think that's entirely their right. As a user, it means I'm much more likely to use KPDF, but at no time do I think they "shouldn't do that".
I'm not sure if this is still the case when a monopoly is in effect -- for instance, I do consider it a bit unethical the way the Flash specs are presented, especially when it seems to be wanting to replace the Web. (Entirely -- Flash itself has a plugin called AIR which embeds Webkit, an HTML engine.) But this is mainly because Flash has no real competitors, and is not interoperable. Adobe Reader has plenty of competitors, and is using a standard format (PDF).
Not really. At least, unless you have a reason to not want the latest version (and there are sometimes valid reasons), Adobe's interests are aligned with the customers' -- they have every reason to provide a security patch in a timely fashion.
That may be true, but it doesn't make what I just said about the practical implications any less true.
Again: I love free software. As a user, I love the freedoms it gives me. As a developer, I usually don't mind giving those same freedoms to my users. But I neither use nor develop exclusively free software, and I see nothing wrong with that.
And I have read many of the gnu.org philosophy papers. I understand and respect your philosophy, and I do not share it. I'm not sure there's much you can say to change my mind. I hope, at least, that when I do develop free software, you find it useful.
Erlang's, but thanks for the compliment.
They are orthogonal. It does, however, make it easier to do fine-grained stuff.
And no, it's not a new idea -- Win32 didn't invent it either. But do me a favor, run a "ring benchmark".
Write a function that spawns N threads in a ring. That is, thread A connects to thread B, which connects to thread C, and eventually comes back around to thread A.
Now, send M messages around the ring.
How big can N get before you run out of RAM, or your system slows to a crawl? What's the relationship between M and the time it takes to execute?
On Erlang, I just had it spawn 100,000 processes and send 1,000 messages, and it took just under 14 seconds. Reversed those numbers -- spawned 1,000 processes, sent 100,000 messages -- and it took 26.7 seconds. Neither way used more than about 20 megs of RAM.
Understand, I'm not including this as a proof of raw performance, just as proof of the paradigm -- the language itself makes it easy to spawn ridiculous numbers of threads, and the runtime can handle it. They are green threads, but with SMP enabled, Erlang spawns exactly as many real OS threads as you have processors, and schedules green threads between them. Which means you get the best of both worlds: You can spawn literally one thread per function if you want, with minimal overhead, but you'll also automatically scale to the number of physical cores in use.
Now, if your Windows threads are anything like my POSIX threads, it's not going to take anywhere near a hundred thousand threads (around a thousand of which are actively vying for CPU time) to slow your benchmark to a crawl, and quite possibly overwhelm your OS scheduler.
You didn't. Read the paragraph after the one you're quoting.
But you see, I don't. Most people don't. This is the point you are missing.
Right now, I'm running email, IM, an MMO (under Wine), an IRC client, a web browser, and a povray instance. I simply don't have more programs that I want to run right now. That's not to say that I couldn't max out an eight-core system, if I just wanted to prove a point.
Yeah, at 4-5%, that's, what, 25 of them? Keep in mind, I have less than 5% used, total, among my seven system tray icons and 151 processes, not including povray. That means, depending on how you count, they are using on average a little less than 1%, or a little more than 0.03% each, meaning it would take either 120 system tray icons, or over 3000 processes, before it hits that other CPU. Let's pretend that I'm way off and the OS will spend 50% of the time scheduling -- I still don't have 60 system tray apps, and I have never seen my Linux system have 1500 processes except when I was playing with forkbombs. And I don't see either happening in the near future -- again, unless I'm playing with forkbombs.
Now, for this next part: You've just basically told me that Windows behaves the same way as Linux, in this regard. Maybe you don't know the terminology I was using. Or maybe you do, and were just pointing out what I'm about to: