Threads share a virtual memory setup, so in theory you don't have so many misses in your TLBs and L1 caches when switching threads, as compared to processes. Ie. it's not how much resources they consume, it's how much slowdown you incur when changing contexts.
My understanding is that over the last X years (where X is about 10) the cost of changing instruction streams of any sort has grown relative to the savings permitted by threads, thereby reducing the overall rationale to choose threads over processes. Meanwhile, forked copies of the same process which are designed to work together will *probably* have roughly the same amount of private data as threads in a single app would have, especially as the size of apps overall grows.
Atheists in a given culture demonstratably have huge amounts of common morality. Clearly morality thus exists outside of the religious context you seem to think it has to. Single exceptions do not disprove a pattern outside a religious context.
So you think if people can violate our privacy on sensitive matters that we should expect everyone to do so. And if our privacy is violated at any time that is possible, there is no sympathy possible.
Maybe they had web access at one time but not another? Maybe it wasn't an opt-in system in the first place? Maybe you can subscribe to the list.. via.. email?
I've definitely subscribed to mailing lists via email that then demanded web access to unsubscribe. Mailing lists should always provide the unsubscribe address in the header, and it should never require web access. It's not hard to provide this functionality, given that basically all mailling list software does it with no special configuration settings. There's no excuse for not providing it. Failing to do so is irresponsible.
1 - 1998-ish? I deliberately signed up for moveon. 2 - I read it for years, but it got more screechy.
3 - 2001-ish - I tried to unsubscribe, twice. Tis failed twice. 4- I began using "mark as spam" on moveon mail because it was UNWANTED bulk email, which is basically spam.
5- 2002ish - Bored of marking their mail as spam, I tried unsubscribing again and it worked.
So your major stance here is "I've had some lousy users, therefore I have lost interest in seriously investing in my software."
Well, I can understand that. It doesn't surprise me. But it isn't a terribly useful position for discussing how to better improve usability. You already think submitters of usability issues are stupid morons and don't want to help them or deal with them. Maybe they deserve it. But with this attitude you are actively shutting out potential contributors. There's no need to debate it even; you're wearing it on your sleeve.
In short, I think your situation is not salvagable. Where are the developers who are not yet convinced their users are jerks?
Don't drag me down the path of saying "high profits means we shouldn't drill" that's not my view. I'm resigned to the idea that oil reserves will be tapped, regardless of any possible ecological costs. I don't even know a lot about the costs in this case, maybe they're low! The main issues of when to enable oil fields to be "developed" are the matter of the balance of conservation for the future vs the need for the energy now, and the total costs (ecological, economic, etc) that are incurred by the activity. The option to never drill I think realistically will not be taken perpetually.
As for profits, big oil stands to make big profits whether the oil reserves are developed or not. That's not really a bad thing. Energy companies, especially the ones OTHER than Exxon-Mobil are highly aware that they need to diversify into other energy sources, and their profits will be invested with some amount of reason.
But as for your "you don't know the difference about net vs gross". It's a completely nonsense argument.
You should certainly do all these things. However, some amount of focused, possibly manual, application-specific investigation can also be worthwhile. I *think* this is what the original poster was referring to.
Investigate the tool conceptually. Identify how it works, what it trusts, how it safeguards against problems. Essentially do your own black box security review from what you know about the program.
Consider asking the vendor to comment on steps they take to ensure security. You may get useless answers from the wrong employees, but they may give good data.
A static analysis tool which operates on binaries (usually) won't uncover conceptual design mistakes, but it will tell you if they bothered to do some basic stuff right. This type of tool can identify that the code has definite buffer overflow exploit points by following the flow of input to potentially problematic system and library calls (eg strcpy). Veracode sells tools of this nature, I'm not sure who else.
Consider whether it's reasonable to fuzz-test (send random input to) the tools. Tools that crash on garbage are probably not safe vs a malicous agent.
The most important thing of course is what everyone else is saying: this is just dilligence. I don't particularly like the term "tested" in the security context, since that implies a comprehensive style of exercise similar to what the team developing the tool might use. Comprehensive security testing is probably not achievable, and certainly not without a very large amount of time and is obstructed by not having source code, insight into the project, and so on. I'd prefer some phrase like "sanity checked" or "passed due dillegence efforts".
I think it's pretty clear. If you want an organiation which will protect your anonymity while under legal challenge, you have to pick an organization with deeper pockets. And a strong business reason not to back down.
When I talk to my mother she says things to me that I hear and understand and go into my brain. Short of punching her in the face or putting my ears over my hands and screaming as loud as I can, I cannot really stop the fact that I will process the datastream.
I dunno.. *craaazy* debian notices if you've changed the config file and gives you a chance to decide what to do. I guess that's too... unprofessional?
All of the responses don't disagree with me. They say "hey, energy is getting more expensive, things wil change". I agree.
The point I was making is simply a great deal more change needs to occur than my original parent benwaggoner believed. To make this gloomier, think about the energy costs involved in our population distribution as a while attempting to increase density over a relatively short time period. This involves significant infill construction, all of which will take.. significant energy, which will be expensive and mildly scarce. Also infill construction tends to be filled with red tape, and thus is accomplished slowly.
Basically density increases will be hard fought and will not come rapidly. Our current scales and distances will be with us for some time.
Things that may happen:
- greater focus on pooled transportation. Full busses are a great deal more efficient than cars, and you can sometimes get work done while not driving. If the popularity of car transport goes down due to energy costs, the time efficiency of shared transport will go up.
- telecommuting is very cheap compared to driving, the popularity may soar for jobs where it works well
- offices may move to where people live. For example the silly-rich google has offices in the bay area in Mountain View as well as San Francisco, but many people have small local offices closer to where they work which may be under special arrangement or simply not widely publicized. As the cost of transport continues to rise, this practice may become more common.
I do agree, infill construction will go up in popularity, the populations of our cities will likely rise. However they are not in a position to accomodate a fraction of the population who require energy efficiency gains as the cost of energy rises.
Some people won't like any given thing X. If you insist on thinking of them as a single body, they will seem irrational, borderline insane. And this serves no useful purpose.
Really a fair bike fee would be that the state pays us.
What do i mean? the fees for car registration etc are intended to pay for things like road maintenance and ancillary costs. However, these costs are not covered by the car-fees, nor trucking fees, and so must be significantly covered via general funds.
Well what incurs these costs that must be covered? Primarily road wear which is primarily caused by vehicular use as a function of weight and distance travelled. Given that my bicycle (loaded) weighs under 200 lbs, and goes a much smaller distance, the tiny fraction of road wear caused by my usage is more than covered by my contributions to the general fund.
There are a lot of languages that already target the JVM. This isn't a hack or anything, it's perfectly normal, and reasonable. It just wasn't an explicit design goal.
The advantages of the CLR over the JVM are in details, not general goals. The disadvantages are in the realm of trust and stability of interfaces.
What percentage of the population can live in areas which support car-free life. I don't mean car-free commuting, I mean car free errands, car free food buying and so on.
Yes, areas in cities such as Boston, New York City, and Philadelphia do support this, but the vast majority of these metro areas only have frequent transport availability during commute times, with non-commute tasks accomplished primarily via car.
FlexCar/ZipCar etc are smart. Bicycles are smart. But even these require a certain level of density, such as that of towns relatively near the center. For example I live in Oakland, California, the less-dense neighbor and bedroom community to San Francisco. The walking transportation service is poor, but the density is sufficient to support ZipCar service, carpools, commuter transit, and effective living via bicycle self-transport.
The majority of the population, however, lives in towns like Walnut Creek, Dublin, Fremont, Lafayette, Milpitas, Hercules, Kensington, Richmond, and Novato which have even less density, even poorer public transit and are not friendly to bicycle-transportation living.
Add in smaller city areas such as those in California's central valley -- Merced, Modesto, Lodi, Stockton -- where proportionally much more growth is happing, and public transit worth using exists at all. On top of that, look at how the state government is planning to drastically cut funding for public transit. Consider that this will only continue as our economic troubles deepen.
The possibility per-capita to achieve a car-free lifestyle is actually shrinking.
Slashdot Mirror
Threads share a virtual memory setup, so in theory you don't have so many misses in your TLBs and L1 caches when switching threads, as compared to processes. Ie. it's not how much resources they consume, it's how much slowdown you incur when changing contexts.
My understanding is that over the last X years (where X is about 10) the cost of changing instruction streams of any sort has grown relative to the savings permitted by threads, thereby reducing the overall rationale to choose threads over processes. Meanwhile, forked copies of the same process which are designed to work together will *probably* have roughly the same amount of private data as threads in a single app would have, especially as the size of apps overall grows.
Does this include the disallowing of cacheing memory writes?
The problem with TCL: eval, upvar.
It may not be an advantage compared to your direct competitors, but it may well grow your market overall.
Atheists in a given culture demonstratably have huge amounts of common morality. Clearly morality thus exists outside of the religious context you seem to think it has to. Single exceptions do not disprove a pattern outside a religious context.
What is making you so blind?
If that is your idea of wooing a lady, I'm not shocked that the result corresponds.
So you think if people can violate our privacy on sensitive matters that we should expect everyone to do so. And if our privacy is violated at any time that is possible, there is no sympathy possible.
Are you a robot?
Maybe they had web access at one time but not another? Maybe it wasn't an opt-in system in the first place? Maybe you can subscribe to the list.. via.. email?
I've definitely subscribed to mailing lists via email that then demanded web access to unsubscribe. Mailing lists should always provide the unsubscribe address in the header, and it should never require web access. It's not hard to provide this functionality, given that basically all mailling list software does it with no special configuration settings. There's no excuse for not providing it. Failing to do so is irresponsible.
1 - 1998-ish? I deliberately signed up for moveon.
2 - I read it for years, but it got more screechy.
3 - 2001-ish - I tried to unsubscribe, twice. Tis failed twice.
4- I began using "mark as spam" on moveon mail because it was UNWANTED bulk email, which is basically spam.
5- 2002ish - Bored of marking their mail as spam, I tried unsubscribing again and it worked.
That's the end of my story.
So your major stance here is "I've had some lousy users, therefore I have lost interest in seriously investing in my software."
Well, I can understand that. It doesn't surprise me. But it isn't a terribly useful position for discussing how to better improve usability. You already think submitters of usability issues are stupid morons and don't want to help them or deal with them. Maybe they deserve it. But with this attitude you are actively shutting out potential contributors. There's no need to debate it even; you're wearing it on your sleeve.
In short, I think your situation is not salvagable. Where are the developers who are not yet convinced their users are jerks?
You have made the classic mistake of assuming the person your child comment poster is the same as your parent comment poster.
Oil companies' net profits are also up. Next?
Don't drag me down the path of saying "high profits means we shouldn't drill" that's not my view. I'm resigned to the idea that oil reserves will be tapped, regardless of any possible ecological costs. I don't even know a lot about the costs in this case, maybe they're low! The main issues of when to enable oil fields to be "developed" are the matter of the balance of conservation for the future vs the need for the energy now, and the total costs (ecological, economic, etc) that are incurred by the activity. The option to never drill I think realistically will not be taken perpetually.
As for profits, big oil stands to make big profits whether the oil reserves are developed or not. That's not really a bad thing. Energy companies, especially the ones OTHER than Exxon-Mobil are highly aware that they need to diversify into other energy sources, and their profits will be invested with some amount of reason.
But as for your "you don't know the difference about net vs gross". It's a completely nonsense argument.
Certainly agreed.
You should certainly do all these things. However, some amount of focused, possibly manual, application-specific investigation can also be worthwhile. I *think* this is what the original poster was referring to.
Investigate the tool conceptually. Identify how it works, what it trusts, how it safeguards against problems. Essentially do your own black box security review from what you know about the program.
Consider asking the vendor to comment on steps they take to ensure security. You may get useless answers from the wrong employees, but they may give good data.
A static analysis tool which operates on binaries (usually) won't uncover conceptual design mistakes, but it will tell you if they bothered to do some basic stuff right. This type of tool can identify that the code has definite buffer overflow exploit points by following the flow of input to potentially problematic system and library calls (eg strcpy). Veracode sells tools of this nature, I'm not sure who else.
Consider whether it's reasonable to fuzz-test (send random input to) the tools. Tools that crash on garbage are probably not safe vs a malicous agent.
The most important thing of course is what everyone else is saying: this is just dilligence. I don't particularly like the term "tested" in the security context, since that implies a comprehensive style of exercise similar to what the team developing the tool might use. Comprehensive security testing is probably not achievable, and certainly not without a very large amount of time and is obstructed by not having source code, insight into the project, and so on. I'd prefer some phrase like "sanity checked" or "passed due dillegence efforts".
I think it's pretty clear. If you want an organiation which will protect your anonymity while under legal challenge, you have to pick an organization with deeper pockets. And a strong business reason not to back down.
"Gives your browser information to display."
"Controls what your browser does."
These are not equivalent.
When I talk to my mother she says things to me that I hear and understand and go into my brain. Short of punching her in the face or putting my ears over my hands and screaming as loud as I can, I cannot really stop the fact that I will process the datastream.
However, she does not control what I do.
Perhaps you can see the difference?
I dunno.. *craaazy* debian notices if you've changed the config file and gives you a chance to decide what to do. I guess that's too... unprofessional?
Because development is illegitimate personal use?
Right. I'm sure on mainframes SYS_MGR or equivalent cannot edit files.
All of the responses don't disagree with me. They say "hey, energy is getting more expensive, things wil change". I agree.
The point I was making is simply a great deal more change needs to occur than my original parent benwaggoner believed. To make this gloomier, think about the energy costs involved in our population distribution as a while attempting to increase density over a relatively short time period. This involves significant infill construction, all of which will take.. significant energy, which will be expensive and mildly scarce. Also infill construction tends to be filled with red tape, and thus is accomplished slowly.
Basically density increases will be hard fought and will not come rapidly. Our current scales and distances will be with us for some time.
Things that may happen:
- greater focus on pooled transportation. Full busses are a great deal more efficient than cars, and you can sometimes get work done while not driving. If the popularity of car transport goes down due to energy costs, the time efficiency of shared transport will go up.
- telecommuting is very cheap compared to driving, the popularity may soar for jobs where it works well
- offices may move to where people live. For example the silly-rich google has offices in the bay area in Mountain View as well as San Francisco, but many people have small local offices closer to where they work which may be under special arrangement or simply not widely publicized. As the cost of transport continues to rise, this practice may become more common.
I do agree, infill construction will go up in popularity, the populations of our cities will likely rise. However they are not in a position to accomodate a fraction of the population who require energy efficiency gains as the cost of energy rises.
Some people won't like any given thing X. If you insist on thinking of them as a single body, they will seem irrational, borderline insane. And this serves no useful purpose.
Really a fair bike fee would be that the state pays us.
What do i mean? the fees for car registration etc are intended to pay for things like road maintenance and ancillary costs. However, these costs are not covered by the car-fees, nor trucking fees, and so must be significantly covered via general funds.
Well what incurs these costs that must be covered? Primarily road wear which is primarily caused by vehicular use as a function of weight and distance travelled. Given that my bicycle (loaded) weighs under 200 lbs, and goes a much smaller distance, the tiny fraction of road wear caused by my usage is more than covered by my contributions to the general fund.
In effect, bicyclists subsidise car drivers.
There are a lot of languages that already target the JVM. This isn't a hack or anything, it's perfectly normal, and reasonable. It just wasn't an explicit design goal.
The advantages of the CLR over the JVM are in details, not general goals. The disadvantages are in the realm of trust and stability of interfaces.
User visible regressions are really cool.
What percentage of the population can live in areas which support car-free life. I don't mean car-free commuting, I mean car free errands, car free food buying and so on.
Yes, areas in cities such as Boston, New York City, and Philadelphia do support this, but the vast majority of these metro areas only have frequent transport availability during commute times, with non-commute tasks accomplished primarily via car.
FlexCar/ZipCar etc are smart. Bicycles are smart. But even these require a certain level of density, such as that of towns relatively near the center. For example I live in Oakland, California, the less-dense neighbor and bedroom community to San Francisco. The walking transportation service is poor, but the density is sufficient to support ZipCar service, carpools, commuter transit, and effective living via bicycle self-transport.
The majority of the population, however, lives in towns like Walnut Creek, Dublin, Fremont, Lafayette, Milpitas, Hercules, Kensington, Richmond, and Novato which have even less density, even poorer public transit and are not friendly to bicycle-transportation living.
Add in smaller city areas such as those in California's central valley -- Merced, Modesto, Lodi, Stockton -- where proportionally much more growth is happing, and public transit worth using exists at all. On top of that, look at how the state government is planning to drastically cut funding for public transit. Consider that this will only continue as our economic troubles deepen.
The possibility per-capita to achieve a car-free lifestyle is actually shrinking.
Of course, the billion threads design doesn't solve the "how do n cores efficiently share x amount of cache" problem at all.