The bottom line is that if you bring suit against someone else, you should be prepared to get your ass handed to you. You should not be allowed to simply drop the suit once you initiate it. If the defendant is willing to fight it to the end, then they should have that option.
Maybe this would make it harder to bring suit against a well-financed opponent. So be it. A suit brought against a well-financed opponent is just as unjust as one brought against a poorly financed one if the suit itself has little merit.
The problem of bankrupting either side through the lawsuit is a completely separate issue that also needs to be addressed, of course, and as far as I'm concerned the maximum amount of damage should be limited to some large percentage of the total assets of the entity in question (for a corporation, those assets should include the total assets of all direct and indirect owners). That goes for plaintiff and defendant, of course. So if the plaintiff elects to drop the suit after having hit that limit, only then should doing so not require the assent of the defendant.
A process can make use of the same synchronization mechanisms that a thread can here. So the thread gets no advantage in this respect.
This appears to be where I may be wrong. Pthreads has its own mutex mechanism which has direct kernel support in Linux. That mechanism isn't necessarily available across processes.
I would be surprised if they're not usable across processes, though, since in Linux a process and a thread are both simply special cases of the more generic "task".
Even so, the locking overhead likely represents a very small percentage of the overall runtime of most applications. Lower hanging fruit almost certainly exists, so my original point (that one should prefer processes to threads in the general case) stands.
If you need concurrency in your apps, there isn't that much between threads and processes. However, if you need interprocess-communication then you are far better off with threads, they are significantly faster wrt locking than processes as all process-based locks must be done at the OS level, using shared (and finite) system resources. Threads can just use a critical section and have done with it, almost no overhead.
Unfortunately for your argument here, there is no difference between processes and threads in this regard (with one possible exception. See below). A critical section makes use of a synchronization mechanism like a semaphore at entry and exit time to ensure that only one thread of execution (whether that be a process or a thread) is running in the critical section at any one time.
A process can make use of the same synchronization mechanisms that a thread can here. So the thread gets no advantage in this respect.
The only case where that isn't true is when the threading mechanism is strictly user-space (no kernel support), but in that case the process itself is doing its own internal thread switching. And obviously, such a setup can't make use of multiple processors at the same time. There's a version of pthreads that does this, on systems which don't have support for kernel-level threads.
That is, of course, unless the kernel threading interface has an explicit way of denoting critical sections that isn't available to processes. I suppose that's possible, but it's obviously not going to be true on all systems.
Regardless, the amount of overhead in making use of locking mechanisms for accessing shared memory in the process model, and thus the amount of performance that can be gained by using the threaded model, is usually (but not always) trivial in comparison with the total overhead of the application. Apache is something of a special case here, because its purpose is to act as a framework rather than an application in its own right.
Threads are not more efficient at context switching than processes, the same procedure happens whether a thread is switched, or a process is (in fact, a process is really an app with 1 thread). However, as threads can share memory more efficiently, locking is often not needed as much so they appear to be more efficient.
Threads generally use less resources for a context switch than processes, but this depends greatly on the hardware architecture and the OS. In the general case, there is less state to be saved and restored upon a context switch for a thread than there is for a process, and some of that state is expensive to save and restore. The fact that the page tables don't have to be switched out is in some cases a rather large win for threads.
The best argument for threads v processes is Apache. Personally, I agree with the Apache group that Apache 2 with its thread-based model is better. They should know.
It just depends on what's important to you. The process model buys you much better isolation between contexts, so if one thread of execution scribbles on the wrong bit of memory it won't affect any other threads of execution (unless the bit of memory is explicitly shared, which generally won't be the case for Apache processes), but under the multithreaded server it will affect all of them. That is a big, big reliability win for the multiprocess model.
And that's just for Apache. There are definitely some Apache installations that get so much traffic that going with the threaded version instead of the multiprocess version is a big win. But those installations are the exception, not the rule, and by doing so they give up the isolation and protection that the multiprocess model brings to the table. They may get better performance, but unless their code is very well written and debugged, they'll get worse stability as a result. Performance is almost always much easier to buy than stability: just buy more and/or faster hardware.
Sorry, those application servers will have to wait until Apache mpm-worker is done destroying mpm-prefork benchmarks. Sheesh, I guess all those developers working on the most popular, successful Web server ever have a lot of learning to do.
Look, the point wasn't that threads are always a bad idea. The point is that if you're going to write a concurrent application using threads, you should have a really good reason for making use of them instead of processes. Processes should be the default.
In the case of Apache, yes, it benchmarks better (perhaps even significantly better) with a threaded server than with a multiprocess server. That will matter to some people who deploy web servers. But only to some.
To most people, the amount of performance gained by using the threaded Apache server will make no difference whatsoever to them. Those people will be better served by the improved stability and isolation that mpm-prefork brings to the table.
As for the Apache developers, they wrote the multithreaded server in response to demand for improved performance in a high-traffic environment. In other words, in a situation in which the advantages of threads really do matter. Such situations are rare in practice. And on top of that, the preforking server had already been written and tuned so its performance characteristics were already well-known. At the time the multithreaded server was written, it was no longer an either-or choice as to which model to go with.
So I stand by what I said before: you should be using processes unless you can make a convincing argument that you really do need the context-switch performance benefits of threads more than the reliability and isolation that processes give you.
Without native thread support it's hard to take advantage of multiple processor cores. Too bad we don't see more mature native compiled functional languages out there.
What?
Sorry, that's bullshit. If you want to take advantage of multiple processor cores, use multiple processes! Even Windows has fork() these days, thanks to its POSIX subsystem, so creating a clone of your process is very easy.
You should use threads over processes only if you can prove that the context switch savings really does cause a big performance improvement for your application. If you really think about it, you'll find it's very rare indeed that the context switch overhead difference really matters, even on an OS like Windows where it's relatively high.
-- old-style Unix development, because of the 'lightweight process model'. It's a unix-ism that's on the way out but until it disappears we will have some things like Ruby that don't 'get it'.
And it's silly for it to be "on the way out".
Anyone remember the Amiga? It had a preemptive multitasking OS that lacked hardware memory protection because the hardware it was running on couldn't support it. And while the OS itself was very fast and efficient, the overall system was relatively crash-prone, because any memory-related programming error in any running application had a decent chance of taking down the system.
Fast forward to today. Every computer sold has hardware memory protection built-in. Anyone who doesn't know why that's a good thing needs to spend time on an Amiga.
And yet, despite that, threads are all the rage. Why? Because people have this idiotic belief that they're somehow "more efficient" than processes. Such people probably program about as well as they think, which is to say not very well. Threads are indeed more efficient at context switching than processes, but the real question is: does that really matter? In the vast majority of cases, it doesn't, because in the vast majority of cases multiple threads are being used to make the user interface responsive. There's no way a human being can tell the difference between a millisecond-level context switch time and a microsecond-level one.
On top of that, processes bring one critical advantage to the table that threads don't: memory protection. And for the same reason memory protection is important at the OS and hardware level, so too is it important at the process and thread level: it allows clean, protected separation of concern and greater overall application stability.
The vast, vast majority of applications that are multithreaded don't actually need the slight additional context switch performance advantage that threads bring to the table, but they very much need the memory protection facilities that processes bring to the table. Which is another way of saying that if your application needs concurrency, you're a fool if you blindly use threads instead of processes.
Even Windows supports fork() these days, with the POSIX subsystem (available, as far as I know, on any Windows 2000 and later system), so creating a clone of your current process is dirt simple even under Windows. End result: application authors have no good reason to use threads over processes unless they've actually done the math and can prove that their application really needs the slight performance advantage of threads more than the significant reliability advantage of processes.
As to the other reason for using threads, the sharing of memory, there's this really cool new technology out these days. Maybe you've heard of it. It's called "shared memory". It's only been available for 20 years or so. No wonder most people haven't heard of it. Being forced to explicitly declare what's shared and what isn't is a good thing, because it makes you program easier to maintain, easier to debug, and more reliable -- all at the same time.
The bottom line is this: if you need concurrency in your application, you should be using processes, not threads. If you insist on using threads, you'd better have a damned good reason for it, because the reliability implications of threads are hugely negative while the performance implications are modest at best.
What the judge is saying is, the RIAA can't just run up a huge legal bill and walk away. Score one for the little guy.
That should be the case as a matter of law. That it's not is a travesty of justice, and makes it obvious that the U.S. legal system is not designed to serve the people, but to serve the lawyers and moneyed interests.
There should be no option of dropping a case without prejudice unless the defense agrees. If you were stupid enough to bring a case against someone else before the court without significant evidence, you should by law be forced to suffer the consequences, either by losing the case entirely or by being forced to pay for their defense, if your case is weak and the defendant is willing to fight to the finish.
And yes, I realize the consequences regarding suing a well-financed opponent. That's why I think any civil judgment rendered, whether it's against the plaintiff or the defendant, should be limited by law to a maximum of some large percentage of that entity's total assets. That way, if an individual sues a corporation and loses, it'll hurt a lot but it won't completely bankrupt the individual.
AFAIR that's still the law in this country. You're innocent until proven guilty.
It's not clear to me how much truth there is to that in civil cases, though. They're decided on the "preponderance of evidence".
Frankly, I think civil cases and criminal cases should both be decided based on "evidence beyond a reasonable doubt". Why? Because while a civil case doesn't strip an individual of their freedom, it does strip them of their assets. Those assets were usually acquired through a lot of hard work, so in essence taking those assets is the same as forcing that person to do labor for the benefit of the plaintiff. Slavery, in other words. The only difference is that (some of) the work's already been done. In some cases, the amount involved is more than the defendant can pay, which really does make them a slave of the plaintiff.
The bottom line is that in both civil and criminal cases, government coercion is being used to strip someone of something that was once theirs. Government coercion should never be used for that unless the evidence supports it beyond a reasonable doubt.
That only a "preponderance of evidence" is required to invoke that government power is one of the reasons the system in the U.S. is the "legal system" and not the "justice system".
I worked out turning my one work computer off as I leave the office keeps about 1 ton of CO2 per year out of the atmosphere (workings below), plus an amount of mercury and other pollution, assuming the electricity here comes from coal. It takes 100 gallons of gasoline to produce 1 ton of CO2. Please correct me if I'm wrong
Did you figure in the reduction of the useful life of the computer and/or its components as a result of the amount of power cycling you're doing to it?
Electronic components tend not to like power transients, but that's exactly what you're subjecting them to whenever you power cycle your computer. You subject them to thermal transients as well.
I'm not saying that you'll reduce the lifespan of the computer to some ridiculously low number by power cycling it, but it will take its toll. Additionally, there are some components like hard drives that suffer more than others. I keep my computers on 24x7 for this reason, and the end result is that the only failures I've had to date have been in power supply fans (the sleeve bearing types) and a couple of extremely old (10+ years) hard drives.
The longer the computer lasts, the fewer of them need to be manufactured. You'll want to account for that in your energy calculations. This also implies that the longer you keep your computer, the more environmentally friendly you are in the long run.
Most people who sue do so for the maximum amount they can. But you do have a good point.
The real meat of my proposal is that the maximum amount you should be able to sue for should be some percentage of the assets of the target. If you want to sue for a small amount relative to the assets of the target, feel free.:-)
You don't sue for a dollar amount. You sue for a percentage of the target's assets, with a cap at some medium-high percentage (say, 70%).
So if A sues B for 50%, then either:
A loses, so B collects from A 50% of the value of A's assets, plus attorney's fees, plus (if B is an individual) the amount of income that B would have made for the amount of time that B is required to attend (this last bit prevents someone from losing their shirt just because they have to show up in court), with a maximum grand total of some large percentage (say, 80%) of A's assets.
A wins, and collects 50% of B's assets.
And in the case of a corporation, the "assets" are calculated based on the sum of the assets of all corporate owners, directly and indirectly. That way a corporation can't, even indirectly, get away with creating a wholly-owned worthless shell corporation whose purpose is to sue. I suppose similar provisions should be made for individual ownership of said shell corporation. The bottom line is that the entities responsible should not be able to hide behind a shell corporation.
The end result is that if you lose, you may pay big, but you don't wind up bankrupt for the rest of your natural life, either, regardless of whether you started it or not. But you *do* have to pay the defense fees if you started it and lose.
I'm just pointing out that corporations are things, not beings, and they are a part of a system, and behave as they are supposed to within the system.
Not really.
Corporations are supposed to act in the best interests of the society in which they function first and foremost. If that were not the case, then a corporate charter and business license wouldn't be required, now would it?
The problem is that most people have lost sight of that fact. In exchange for limited liability and effective immortality, corporations are supposed to act with restraint. And in a sane, balanced society, such restraint would be enforced by the revocation of corporate charters in the case of misconduct, just like it was done in the (relatively) distant past.
People like you have been brainwashed to believe that it's okay for corporations to act in evil ways (if intentionally harming others for personal gain isn't evil, then I don't know what is) because "they're responsible to their shareholders" or some such bullshit.
But it's not okay. It never has been. Such behaviour is very harmful, and many ills of the world exist because of it. You might say that it's the responsibility of the government to hold corporations accountable for their actions and you would be right about that. But that in no way excuses the behaviour of corporations. That someone might not have been punished for murder doesn't make the act any less wrong.
People like you need to wake up, and fast, because we're almost out of time. The U.S. is pretty much unrecoverable now but there's still time for the rest of the world. But if corporations aren't held to a much higher standard than we hold them to now, it won't be long before they rule the rest of the world the way they rule the U.S.
And trust me, that would be a bad thing for just about everyone. The experience with the British East India Company is one of the things that led to the founding of the United States, after all.
Ultimately your politicians are answerable to you, no?
No.
Politicians in the U.S. are answerable to those who control the media, not to the voters. That's because the media controls the information the voters get that determine who they can vote for. Voters can't vote for someone whose existence they're not aware of, and aren't likely to vote for someone whom they are constantly told is a bad candidate.
And the media is owned by a very small number of very large corporations, who certainly do deals with other large corporations for control over the "message" about their favorite candidates.
Hence, candidates that aren't willing to do the bidding of the large corporations either get no air time at all or are portrayed as bad candidates by the media.
The media in this case includes newspapers, television, and radio, and is now starting to include the internet as well (media corporations own a large percentage of the end-user ISPs). If your suggestion is that people should look someplace else for their information, then where exactly do you suggest they look, and how exactly do you plan on informing them of where to look?
Sorry, but the situation in the U.S. is now irreversible. Can't be fixed. That means it won't be fixed. We're just completely and permanently fucked over here. You're going to have to learn to deal with that.
This tool looks very cool, but today's semi-pro and pro (and even some consumer grade) cameras will store their images in a raw format which preserves 12 bits per color channel at a minimum.
GIMP can't deal with these. Tools such as ufraw can convert them to 8 bits/channel images such as JPEG but don't allow you to actually manipulate the image in its native color resolution.
Linux seriously needs a good image manipulation tool such as the GIMP with 16-bit or even 32-bit per color channel support built-in. This is particularly important for operations like sharpening.
Cinepaint will do it but it's way behind in features compared with GIMP these days.
What's the hold up with GIMP anyway? You'd think its developers would take this kind of issue seriously and would fix the engine to natively do, say, 32 bits per color channel internally.
No, this isn't the moral of the story. The moral is that many companies, and certainly nearly all Fortune 500 companies, have dedicated security staff that is responsible for doing security testing. If security testing isn't your job and you have a concern about something, contact the security staff and voice your concern.
Yeah, and as we all know, corporate systems, particularly those that are externally-facing, never have any significant vulnerabilities, and the ones people report are obviously lies. And those security people! Boy, those guys are on the ball, as evidenced by the fact that the systems they're responsible for never have any vulnerabilities!
Gimme a break. If the "dedicated security staff" were so good, people wouldn't be (stupidly, because it gets them in trouble) reporting security vulnerabilities to management all the time. No, the purpose of the "dedicated security staff" is to give the systems a once-over in order to give the appearance of security. They're like the TSA screeners in airports in that regard -- they may catch the low-hanging fruit but that's all they'll catch. Their real purpose is to make management feel better, not to add any real security.
You're a fool if you trust information you care about to a system whose security you haven't checked out for yourself. If you lack the expertise to perform such a check then you have no choice but to guardedly trust such systems, but you'd be an idiot to trust them any more than the minimum possible. If you have the expertise to perform such a check then you'd be an idiot not to do so as long as you can do so in such a way that there's no way to trace the check back to you.
Ultimately, my point is that the actual security of most systems, even those that are externally-facing, is something the management doesn't give a shit about. They only care about the appearance of security, because that is much easier (read: less expensive) to maintain. The only systems where you'll see real security are the ones where security issues will cost the management real money, like banking systems and such. But external web sites and other such sites that most people use? They're of no real consequence to management types, so they get the "TSA treatment".
No, the real moral of this story, and others like it, is simple:
Don't bother testing the security of a system unless you're forced to use that system to store, in unencrypted form, information you care about.
If you are forced to use such a system (and thus to test its security), perform all your tests in such a way that there's no way they can be traced back to you.
If you find security holes, the only action you should take is to minimize your use of the system. Under no circumstances should you actually tell management about the security holes unless you have, signed and in writing, authorization to perform the security testing. If you have such authorization, make sure you store copies of it in safe places. Even so, with today's fucked up legal environment, it's entirely possible that their lawyers would be able to get said document stricken from the evidence record on some sort of legal technicality, which means that even if you have ironclad proof that you were authorized to perform the security testing in question, you might not be able to use it.
If you absolutely must tell someone, make sure it's someone you can absolutely, positively trust with your life. Because that may be what's on the line (well, at least part of it, because we're talking about jail time here, and inmates love fresh nerd meat).
The bottom line is that corporate management doesn't give a shit about the actual security of their system. They only care about the illusion of security, and they'll bring their full wrath against anyone who dares shatter that illusion.
Let them have their illusion. If they ever get seriously 0wn3d, as is likely (it's only a matter of time), you can laugh your ass off at them, because it'll be evil people getting the shaft from other evil people. But today there is nothing but a whole lot of pain for the good guys in the world. Welcome to the real world, where evil usually wins in the end thanks to the world's inherent tendency towards chaos. You can try to fight it if you want, but you'll probably lose, so why bother? You're probably better off just keeping your own affairs in order and letting the others get fucked up the ass for their stupidity.
The police are there to do the paperwork after you are unable to protect yourself.
Or to clean up the mess after you're able to successfully protect yourself.;)
Where "clean up the mess" == "throw your ass in jail". Remember: it's not legal to really protect yourself in most states. "Minimal force" is impossible to really determine when you're in a life and death situation, but that's what the law generally expects you to adhere to, and you'll have to prove in court that the force you used was necessary after the fact, with little evidence to back you up.
The way things are in the U.S. today (and getting that way elsewhere as well), it looks to me like it's simply not worth revealing security holes to the corporations that have them. All they'll do is either sue you into oblivion or get you criminally prosecuted. They sure as hell won't thank you.
So I think it's time to let these corporations have what they want. Let them have their blissfully naive fantasy that they're invulnerable. They don't want to hear anything to the contrary, so why tell them? Let them and their customers suffer. It sucks that their customers will suffer, but if their customers suffer, then perhaps (unlikely, I know, but still) they will suffer too. And for having such a simultaneously naive and arrogant attitude, they deserve to suffer.
Instead, if the target in question is running open source software, inform the author(s) of said software about the security vulnerability. Include a fix if you can. They'll be far more grateful for your effort than any of these piece of shit corporations will.
The end result? Open source software gets fixed, because vulnerabilities get reported to those who can do something about it, and closed-source software remains vulnerable. That gives open source software even more of an advantage than it already has, thanks to the blind arrogance of the corporate idiots who would prefer to harm the messenger rather than fix their own problems.
Offtopic, huh? Some moderators have no sense of humour at all.:-)
For those moderators that didn't get the intent of the joke, the story is about a sword-wielding robot. So imagine said sword-wielding robot playing the role of the Black Knight in Monty Python's Holy Grail...
ARTHUR: You fight with the strength of many men, Sir Knight. I am Arthur, King of the Britons. I seek the finest and the bravest knights in the land to join me in my court at Camelot. You have proved yourself worthy. Will you join me?
[pause]
ARTHUR: You make me sad. So be it. Come, Patsy. BLACK KNIGHT (in monotone robot voice): None shall pass. ARTHUR: What? BLACK KNIGHT: None shall pass. ARTHUR: I have no quarrel with you, good Sir Knight, but I must cross this bridge. BLACK KNIGHT: Then you shall die. ARTHUR: I command you, as King of the Britons, to stand aside! BLACK KNIGHT: I move for no man. ARTHUR: So be it! ARTHUR and BLACK KNIGHT: Aaah!, hiyaah!, etc.
[ARTHUR chops the BLACK KNIGHT's left arm off] ARTHUR: Now stand aside, worthy adversary. BLACK KNIGHT: 'Tis but a scratch. ARTHUR: A scratch? Your arm's off! BLACK KNIGHT: No, it isn't. ARTHUR: Well, what's that, then? BLACK KNIGHT: I've had worse. ARTHUR: You liar! BLACK KNIGHT: Come on, you pansy!
[clang]
Huyah!
[clang]
Hiyaah!
[clang]
Aaaaaaaah!
[ARTHUR chops the BLACK KNIGHT's right arm off]
ARTHUR: Victory is mine!
[kneeling]
We thank Thee Lord, that in Thy mer-- BLACK KNIGHT: Hah!
[kick]
Come on, then. ARTHUR: What? BLACK KNIGHT: Have at you!
[kick] ARTHUR: Eh. You are indeed brave, Sir Knight, but the fight is mine. BLACK KNIGHT: Oh, had enough, eh? ARTHUR: Look, you stupid bastard. You've got no arms left. BLACK KNIGHT: Yes, I have. ARTHUR: Look! BLACK KNIGHT: Just a surface wound.
[kick]
I'm going to sleep safe tonight knowing that he won't possibly be able to run agian... if he doesn't fall on his sword before the next election (I know I would if I had been that much of a disgrace).
What makes you think he'll have to run in an election?
The Bush administration doesn't obey the will of Congress. It doesn't heed the Constitution in the everyday matters of the executive. What makes you think it'll heed the Constitution when it comes time to let go of the reins?
All it'll take is a conveniently timed, sufficiently bad terrorist attack and the elections can be postponed indefinitely. Historical precedent means nothing here -- this presidency doesn't heed historical precedent any better than it heeds the Constitution.
I know it sounds paranoid and all, and I think the chances of it happening are small, but then the idea of the U.S. actually holding people indefinitely without access to counsel or trial sounded paranoid not too long ago, too. It happened anyway.
I understand the sentiment, but I won't pay much more at this point. I turn over laptops every 18-24 months, and *for my needs* it's just not worth putting too much extra in for a better built unit. Others will of course have different needs. There are things that I miss on the cheaper units (built in keyboard light, touchpad and button mouse, decent speakers) but if the unit is $500 I'll live without.
But do you turn over laptops every 18-24 months because they don't last much longer than that, or for some other reason?
Suppose your laptop were built like and tank (but didn't weigh as much as a tank, of course) and upgradeable so that you could keep up with technology, and each upgrade cost you about $400 (on average), but the initial expense was $2000 instead of $500, with all of that extra money going into the build quality. Would you go for that?
Think hard about that. The extra expense would get you a unit with a really solid keyboard (not the crap keyboards they have today), a rugged chassis, and a touchpad/stick that would never fail. It would also allow you to keep using your software without requiring a reinstall every 12-18 months. You'd be able to upgrade the OS on your schedule. That might be every 12-18 months, but it wouldn't have to be. It'd take you 20 years to break even financially, but during that entire period of time you'd have a machine that was much better built than the one you're using now.
Would that be worth it? In my opinion, it would be, in the long run. But that's how I tend to think about things: long term.
That said, laptops are probably the hardest computing devices to use this strategy on, because of the extra requirements of portability and miniaturization.
Slashdot Mirror
The bottom line is that if you bring suit against someone else, you should be prepared to get your ass handed to you. You should not be allowed to simply drop the suit once you initiate it. If the defendant is willing to fight it to the end, then they should have that option.
Maybe this would make it harder to bring suit against a well-financed opponent. So be it. A suit brought against a well-financed opponent is just as unjust as one brought against a poorly financed one if the suit itself has little merit.
The problem of bankrupting either side through the lawsuit is a completely separate issue that also needs to be addressed, of course, and as far as I'm concerned the maximum amount of damage should be limited to some large percentage of the total assets of the entity in question (for a corporation, those assets should include the total assets of all direct and indirect owners). That goes for plaintiff and defendant, of course. So if the plaintiff elects to drop the suit after having hit that limit, only then should doing so not require the assent of the defendant.
The system as it stands right now is inexcusable.
This appears to be where I may be wrong. Pthreads has its own mutex mechanism which has direct kernel support in Linux. That mechanism isn't necessarily available across processes.
I would be surprised if they're not usable across processes, though, since in Linux a process and a thread are both simply special cases of the more generic "task".
Even so, the locking overhead likely represents a very small percentage of the overall runtime of most applications. Lower hanging fruit almost certainly exists, so my original point (that one should prefer processes to threads in the general case) stands.
Unfortunately for your argument here, there is no difference between processes and threads in this regard (with one possible exception. See below). A critical section makes use of a synchronization mechanism like a semaphore at entry and exit time to ensure that only one thread of execution (whether that be a process or a thread) is running in the critical section at any one time.
A process can make use of the same synchronization mechanisms that a thread can here. So the thread gets no advantage in this respect.
The only case where that isn't true is when the threading mechanism is strictly user-space (no kernel support), but in that case the process itself is doing its own internal thread switching. And obviously, such a setup can't make use of multiple processors at the same time. There's a version of pthreads that does this, on systems which don't have support for kernel-level threads.
That is, of course, unless the kernel threading interface has an explicit way of denoting critical sections that isn't available to processes. I suppose that's possible, but it's obviously not going to be true on all systems.
Regardless, the amount of overhead in making use of locking mechanisms for accessing shared memory in the process model, and thus the amount of performance that can be gained by using the threaded model, is usually (but not always) trivial in comparison with the total overhead of the application. Apache is something of a special case here, because its purpose is to act as a framework rather than an application in its own right.
Threads generally use less resources for a context switch than processes, but this depends greatly on the hardware architecture and the OS. In the general case, there is less state to be saved and restored upon a context switch for a thread than there is for a process, and some of that state is expensive to save and restore. The fact that the page tables don't have to be switched out is in some cases a rather large win for threads.
It just depends on what's important to you. The process model buys you much better isolation between contexts, so if one thread of execution scribbles on the wrong bit of memory it won't affect any other threads of execution (unless the bit of memory is explicitly shared, which generally won't be the case for Apache processes), but under the multithreaded server it will affect all of them. That is a big, big reliability win for the multiprocess model.
And that's just for Apache. There are definitely some Apache installations that get so much traffic that going with the threaded version instead of the multiprocess version is a big win. But those installations are the exception, not the rule, and by doing so they give up the isolation and protection that the multiprocess model brings to the table. They may get better performance, but unless their code is very well written and debugged, they'll get worse stability as a result. Performance is almost always much easier to buy than stability: just buy more and/or faster hardware.
Look, the point wasn't that threads are always a bad idea. The point is that if you're going to write a concurrent application using threads, you should have a really good reason for making use of them instead of processes. Processes should be the default.
In the case of Apache, yes, it benchmarks better (perhaps even significantly better) with a threaded server than with a multiprocess server. That will matter to some people who deploy web servers. But only to some.
To most people, the amount of performance gained by using the threaded Apache server will make no difference whatsoever to them. Those people will be better served by the improved stability and isolation that mpm-prefork brings to the table.
As for the Apache developers, they wrote the multithreaded server in response to demand for improved performance in a high-traffic environment. In other words, in a situation in which the advantages of threads really do matter. Such situations are rare in practice. And on top of that, the preforking server had already been written and tuned so its performance characteristics were already well-known. At the time the multithreaded server was written, it was no longer an either-or choice as to which model to go with.
So I stand by what I said before: you should be using processes unless you can make a convincing argument that you really do need the context-switch performance benefits of threads more than the reliability and isolation that processes give you.
What?
Sorry, that's bullshit. If you want to take advantage of multiple processor cores, use multiple processes! Even Windows has fork() these days, thanks to its POSIX subsystem, so creating a clone of your process is very easy.
You should use threads over processes only if you can prove that the context switch savings really does cause a big performance improvement for your application. If you really think about it, you'll find it's very rare indeed that the context switch overhead difference really matters, even on an OS like Windows where it's relatively high.
And it's silly for it to be "on the way out".
Anyone remember the Amiga? It had a preemptive multitasking OS that lacked hardware memory protection because the hardware it was running on couldn't support it. And while the OS itself was very fast and efficient, the overall system was relatively crash-prone, because any memory-related programming error in any running application had a decent chance of taking down the system.
Fast forward to today. Every computer sold has hardware memory protection built-in. Anyone who doesn't know why that's a good thing needs to spend time on an Amiga.
And yet, despite that, threads are all the rage. Why? Because people have this idiotic belief that they're somehow "more efficient" than processes. Such people probably program about as well as they think, which is to say not very well. Threads are indeed more efficient at context switching than processes, but the real question is: does that really matter? In the vast majority of cases, it doesn't, because in the vast majority of cases multiple threads are being used to make the user interface responsive. There's no way a human being can tell the difference between a millisecond-level context switch time and a microsecond-level one.
On top of that, processes bring one critical advantage to the table that threads don't: memory protection. And for the same reason memory protection is important at the OS and hardware level, so too is it important at the process and thread level: it allows clean, protected separation of concern and greater overall application stability.
The vast, vast majority of applications that are multithreaded don't actually need the slight additional context switch performance advantage that threads bring to the table, but they very much need the memory protection facilities that processes bring to the table. Which is another way of saying that if your application needs concurrency, you're a fool if you blindly use threads instead of processes.
Even Windows supports fork() these days, with the POSIX subsystem (available, as far as I know, on any Windows 2000 and later system), so creating a clone of your current process is dirt simple even under Windows. End result: application authors have no good reason to use threads over processes unless they've actually done the math and can prove that their application really needs the slight performance advantage of threads more than the significant reliability advantage of processes.
As to the other reason for using threads, the sharing of memory, there's this really cool new technology out these days. Maybe you've heard of it. It's called "shared memory". It's only been available for 20 years or so. No wonder most people haven't heard of it. Being forced to explicitly declare what's shared and what isn't is a good thing, because it makes you program easier to maintain, easier to debug, and more reliable -- all at the same time.
The bottom line is this: if you need concurrency in your application, you should be using processes, not threads. If you insist on using threads, you'd better have a damned good reason for it, because the reliability implications of threads are hugely negative while the performance implications are modest at best.
That should be the case as a matter of law. That it's not is a travesty of justice, and makes it obvious that the U.S. legal system is not designed to serve the people, but to serve the lawyers and moneyed interests.
There should be no option of dropping a case without prejudice unless the defense agrees. If you were stupid enough to bring a case against someone else before the court without significant evidence, you should by law be forced to suffer the consequences, either by losing the case entirely or by being forced to pay for their defense, if your case is weak and the defendant is willing to fight to the finish.
And yes, I realize the consequences regarding suing a well-financed opponent. That's why I think any civil judgment rendered, whether it's against the plaintiff or the defendant, should be limited by law to a maximum of some large percentage of that entity's total assets. That way, if an individual sues a corporation and loses, it'll hurt a lot but it won't completely bankrupt the individual.
It's not clear to me how much truth there is to that in civil cases, though. They're decided on the "preponderance of evidence".
Frankly, I think civil cases and criminal cases should both be decided based on "evidence beyond a reasonable doubt". Why? Because while a civil case doesn't strip an individual of their freedom, it does strip them of their assets. Those assets were usually acquired through a lot of hard work, so in essence taking those assets is the same as forcing that person to do labor for the benefit of the plaintiff. Slavery, in other words. The only difference is that (some of) the work's already been done. In some cases, the amount involved is more than the defendant can pay, which really does make them a slave of the plaintiff.
The bottom line is that in both civil and criminal cases, government coercion is being used to strip someone of something that was once theirs. Government coercion should never be used for that unless the evidence supports it beyond a reasonable doubt.
That only a "preponderance of evidence" is required to invoke that government power is one of the reasons the system in the U.S. is the "legal system" and not the "justice system".
Did you figure in the reduction of the useful life of the computer and/or its components as a result of the amount of power cycling you're doing to it?
Electronic components tend not to like power transients, but that's exactly what you're subjecting them to whenever you power cycle your computer. You subject them to thermal transients as well.
I'm not saying that you'll reduce the lifespan of the computer to some ridiculously low number by power cycling it, but it will take its toll. Additionally, there are some components like hard drives that suffer more than others. I keep my computers on 24x7 for this reason, and the end result is that the only failures I've had to date have been in power supply fans (the sleeve bearing types) and a couple of extremely old (10+ years) hard drives.
The longer the computer lasts, the fewer of them need to be manufactured. You'll want to account for that in your energy calculations. This also implies that the longer you keep your computer, the more environmentally friendly you are in the long run.
Most people who sue do so for the maximum amount they can. But you do have a good point.
The real meat of my proposal is that the maximum amount you should be able to sue for should be some percentage of the assets of the target. If you want to sue for a small amount relative to the assets of the target, feel free. :-)
That's why the way I'd do it is this:
You don't sue for a dollar amount. You sue for a percentage of the target's assets, with a cap at some medium-high percentage (say, 70%).
So if A sues B for 50%, then either:
And in the case of a corporation, the "assets" are calculated based on the sum of the assets of all corporate owners, directly and indirectly. That way a corporation can't, even indirectly, get away with creating a wholly-owned worthless shell corporation whose purpose is to sue. I suppose similar provisions should be made for individual ownership of said shell corporation. The bottom line is that the entities responsible should not be able to hide behind a shell corporation.
The end result is that if you lose, you may pay big, but you don't wind up bankrupt for the rest of your natural life, either, regardless of whether you started it or not. But you *do* have to pay the defense fees if you started it and lose.
Not really.
Corporations are supposed to act in the best interests of the society in which they function first and foremost. If that were not the case, then a corporate charter and business license wouldn't be required, now would it?
The problem is that most people have lost sight of that fact. In exchange for limited liability and effective immortality, corporations are supposed to act with restraint. And in a sane, balanced society, such restraint would be enforced by the revocation of corporate charters in the case of misconduct, just like it was done in the (relatively) distant past.
People like you have been brainwashed to believe that it's okay for corporations to act in evil ways (if intentionally harming others for personal gain isn't evil, then I don't know what is) because "they're responsible to their shareholders" or some such bullshit.
But it's not okay. It never has been. Such behaviour is very harmful, and many ills of the world exist because of it. You might say that it's the responsibility of the government to hold corporations accountable for their actions and you would be right about that. But that in no way excuses the behaviour of corporations. That someone might not have been punished for murder doesn't make the act any less wrong.
People like you need to wake up, and fast, because we're almost out of time. The U.S. is pretty much unrecoverable now but there's still time for the rest of the world. But if corporations aren't held to a much higher standard than we hold them to now, it won't be long before they rule the rest of the world the way they rule the U.S.
And trust me, that would be a bad thing for just about everyone. The experience with the British East India Company is one of the things that led to the founding of the United States, after all.
No.
Politicians in the U.S. are answerable to those who control the media, not to the voters. That's because the media controls the information the voters get that determine who they can vote for. Voters can't vote for someone whose existence they're not aware of, and aren't likely to vote for someone whom they are constantly told is a bad candidate.
And the media is owned by a very small number of very large corporations, who certainly do deals with other large corporations for control over the "message" about their favorite candidates.
Hence, candidates that aren't willing to do the bidding of the large corporations either get no air time at all or are portrayed as bad candidates by the media.
The media in this case includes newspapers, television, and radio, and is now starting to include the internet as well (media corporations own a large percentage of the end-user ISPs). If your suggestion is that people should look someplace else for their information, then where exactly do you suggest they look, and how exactly do you plan on informing them of where to look?
Sorry, but the situation in the U.S. is now irreversible. Can't be fixed. That means it won't be fixed. We're just completely and permanently fucked over here. You're going to have to learn to deal with that.
This tool looks very cool, but today's semi-pro and pro (and even some consumer grade) cameras will store their images in a raw format which preserves 12 bits per color channel at a minimum.
GIMP can't deal with these. Tools such as ufraw can convert them to 8 bits/channel images such as JPEG but don't allow you to actually manipulate the image in its native color resolution.
Linux seriously needs a good image manipulation tool such as the GIMP with 16-bit or even 32-bit per color channel support built-in. This is particularly important for operations like sharpening.
Cinepaint will do it but it's way behind in features compared with GIMP these days.
What's the hold up with GIMP anyway? You'd think its developers would take this kind of issue seriously and would fix the engine to natively do, say, 32 bits per color channel internally.
Yeah, and as we all know, corporate systems, particularly those that are externally-facing, never have any significant vulnerabilities, and the ones people report are obviously lies. And those security people! Boy, those guys are on the ball, as evidenced by the fact that the systems they're responsible for never have any vulnerabilities!
Gimme a break. If the "dedicated security staff" were so good, people wouldn't be (stupidly, because it gets them in trouble) reporting security vulnerabilities to management all the time. No, the purpose of the "dedicated security staff" is to give the systems a once-over in order to give the appearance of security. They're like the TSA screeners in airports in that regard -- they may catch the low-hanging fruit but that's all they'll catch. Their real purpose is to make management feel better, not to add any real security.
You're a fool if you trust information you care about to a system whose security you haven't checked out for yourself. If you lack the expertise to perform such a check then you have no choice but to guardedly trust such systems, but you'd be an idiot to trust them any more than the minimum possible. If you have the expertise to perform such a check then you'd be an idiot not to do so as long as you can do so in such a way that there's no way to trace the check back to you.
Ultimately, my point is that the actual security of most systems, even those that are externally-facing, is something the management doesn't give a shit about. They only care about the appearance of security, because that is much easier (read: less expensive) to maintain. The only systems where you'll see real security are the ones where security issues will cost the management real money, like banking systems and such. But external web sites and other such sites that most people use? They're of no real consequence to management types, so they get the "TSA treatment".
No, the real moral of this story, and others like it, is simple:
The bottom line is that corporate management doesn't give a shit about the actual security of their system. They only care about the illusion of security, and they'll bring their full wrath against anyone who dares shatter that illusion.
Let them have their illusion. If they ever get seriously 0wn3d, as is likely (it's only a matter of time), you can laugh your ass off at them, because it'll be evil people getting the shaft from other evil people. But today there is nothing but a whole lot of pain for the good guys in the world. Welcome to the real world, where evil usually wins in the end thanks to the world's inherent tendency towards chaos. You can try to fight it if you want, but you'll probably lose, so why bother? You're probably better off just keeping your own affairs in order and letting the others get fucked up the ass for their stupidity.
Where "clean up the mess" == "throw your ass in jail". Remember: it's not legal to really protect yourself in most states. "Minimal force" is impossible to really determine when you're in a life and death situation, but that's what the law generally expects you to adhere to, and you'll have to prove in court that the force you used was necessary after the fact, with little evidence to back you up.
Good luck with that. You'll need it.
The way things are in the U.S. today (and getting that way elsewhere as well), it looks to me like it's simply not worth revealing security holes to the corporations that have them. All they'll do is either sue you into oblivion or get you criminally prosecuted. They sure as hell won't thank you.
So I think it's time to let these corporations have what they want. Let them have their blissfully naive fantasy that they're invulnerable. They don't want to hear anything to the contrary, so why tell them? Let them and their customers suffer. It sucks that their customers will suffer, but if their customers suffer, then perhaps (unlikely, I know, but still) they will suffer too. And for having such a simultaneously naive and arrogant attitude, they deserve to suffer.
Instead, if the target in question is running open source software, inform the author(s) of said software about the security vulnerability. Include a fix if you can. They'll be far more grateful for your effort than any of these piece of shit corporations will.
The end result? Open source software gets fixed, because vulnerabilities get reported to those who can do something about it, and closed-source software remains vulnerable. That gives open source software even more of an advantage than it already has, thanks to the blind arrogance of the corporate idiots who would prefer to harm the messenger rather than fix their own problems.
Sounds like a win-win deal to me!
Offtopic, huh? Some moderators have no sense of humour at all. :-)
For those moderators that didn't get the intent of the joke, the story is about a sword-wielding robot. So imagine said sword-wielding robot playing the role of the Black Knight in Monty Python's Holy Grail...
(with apologies to Monty Python)
ARTHUR: You fight with the strength of many men, Sir Knight. I am Arthur, King of the Britons. I seek the finest and the bravest knights in the land to join me in my court at Camelot. You have proved yourself worthy. Will you join me?
[pause]
ARTHUR: You make me sad. So be it. Come, Patsy.
BLACK KNIGHT (in monotone robot voice): None shall pass.
ARTHUR: What?
BLACK KNIGHT: None shall pass.
ARTHUR: I have no quarrel with you, good Sir Knight, but I must cross this bridge.
BLACK KNIGHT: Then you shall die.
ARTHUR: I command you, as King of the Britons, to stand aside!
BLACK KNIGHT: I move for no man.
ARTHUR: So be it!
ARTHUR and BLACK KNIGHT: Aaah!, hiyaah!, etc.
[ARTHUR chops the BLACK KNIGHT's left arm off]
ARTHUR: Now stand aside, worthy adversary.
BLACK KNIGHT: 'Tis but a scratch.
ARTHUR: A scratch? Your arm's off!
BLACK KNIGHT: No, it isn't.
ARTHUR: Well, what's that, then?
BLACK KNIGHT: I've had worse.
ARTHUR: You liar!
BLACK KNIGHT: Come on, you pansy!
[clang]
Huyah!
[clang]
Hiyaah!
[clang]
Aaaaaaaah!
[ARTHUR chops the BLACK KNIGHT's right arm off]
ARTHUR: Victory is mine!
[kneeling]
We thank Thee Lord, that in Thy mer--
BLACK KNIGHT: Hah!
[kick]
Come on, then.
ARTHUR: What?
BLACK KNIGHT: Have at you!
[kick]
ARTHUR: Eh. You are indeed brave, Sir Knight, but the fight is mine.
BLACK KNIGHT: Oh, had enough, eh?
ARTHUR: Look, you stupid bastard. You've got no arms left.
BLACK KNIGHT: Yes, I have.
ARTHUR: Look!
BLACK KNIGHT: Just a surface wound.
[kick]
etc.
Shamelessly ripped off from here: http://www.mwscomp.com/movies/grail/grail-04.htm
What makes you think he'll have to run in an election?
The Bush administration doesn't obey the will of Congress. It doesn't heed the Constitution in the everyday matters of the executive. What makes you think it'll heed the Constitution when it comes time to let go of the reins?
All it'll take is a conveniently timed, sufficiently bad terrorist attack and the elections can be postponed indefinitely. Historical precedent means nothing here -- this presidency doesn't heed historical precedent any better than it heeds the Constitution.
I know it sounds paranoid and all, and I think the chances of it happening are small, but then the idea of the U.S. actually holding people indefinitely without access to counsel or trial sounded paranoid not too long ago, too. It happened anyway.
Given the Bush administration's apparent lust for power, I wouldn't entirely rule that out...
Hmm...well, there are what, several hundred million users? So that means there are several hundred million vulnerabilities!
So instead of one exploit every 45 minutes, it's actually one exploit every second!
Because you told this administration that scientists play with models, and the administration thought you meant plastic toy models?
Shame on you for misleading this administration that way!
But do you turn over laptops every 18-24 months because they don't last much longer than that, or for some other reason?
Suppose your laptop were built like and tank (but didn't weigh as much as a tank, of course) and upgradeable so that you could keep up with technology, and each upgrade cost you about $400 (on average), but the initial expense was $2000 instead of $500, with all of that extra money going into the build quality. Would you go for that?
Think hard about that. The extra expense would get you a unit with a really solid keyboard (not the crap keyboards they have today), a rugged chassis, and a touchpad/stick that would never fail. It would also allow you to keep using your software without requiring a reinstall every 12-18 months. You'd be able to upgrade the OS on your schedule. That might be every 12-18 months, but it wouldn't have to be. It'd take you 20 years to break even financially, but during that entire period of time you'd have a machine that was much better built than the one you're using now.
Would that be worth it? In my opinion, it would be, in the long run. But that's how I tend to think about things: long term.
That said, laptops are probably the hardest computing devices to use this strategy on, because of the extra requirements of portability and miniaturization.