If the person could save $80 per month for a TV set, now that he/she has bought the TV set, that person now has $80 in disposable income to spend on movies and TV shows. I don't think that argument works too well. And even if the student saved $80 a month by eating nothing but Ramen noodles, there's still clearly some financial flexibility there.
A better example would be a student whose parents bought him/her a laptop and uses it for watching movies. That student might legitimately have to choose between buying a DVD and buying lunch.
Having webmail provide encryption has one obvious problem: you have to give the webmail provider your secret key, implying a level of trust you probably do not have for them.
There's a second option. The webmail service could generate its own public and private key pair, and you can sign that pair with your personal key. You could then separately revoke the webmail key. Nothing says that a person can only have one PK crypto key pair.
There's a third option, too. The webmail service could use a secure callback to your home computer, and that computer could do the signing on your behalf, using "Back to my Mac" or similar so that you don't have to leave your home machine running all the time. You could then revoke permission for the webmail service to do so at any time.
...an awful lot of customers are amateur musicians...
Yes, they are an awful lot, aren't they.
Ba-da-bump.
Either way, it strikes me that the fair dealing laws in the U.K. probably cover this in effect, albeit not in letter. I'd be curious to see where this leads, particularly given the decade of de facto precedent set by iTunes and what I assume is a lack of challenges to that....
Where the hell did you get that idea? Do you have any concept of how much it costs to hire employees?
I guess it depends on whether any large companies care about the product.
Finally, what do you do when you don't need them any more?
Have them work on something else? It's not like programmers only know how to work on one piece of software....
Why would a bunch of engineers up and quit their stable, salaried jobs to be freelancers?
Because working for a startup is anything but stable. Been there, done that. When it comes to companies that provide support for OSS, the vast majority are startup-sized companies. Becoming a contractor certainly isn't for everybody, but I do know a lot of people who have made that call over the years. It's not nearly as rare as you think. And it is even more common when you're talking about people working at a startup who know that a single bad quarter could mean that they're looking for work anyway.
Obviously, you have zero experience in business.
I've been working in the software business for over a decade. I've watched companies that I've worked for hire the lead coders for open source projects because it's easier and cheaper than trying to work with the companies that support those projects. What I'm describing does happen, and it happens often.
How so? The company makes money, and the employees get paid.
Not after the company who needs the work done realizes that it's cheaper to hire those programmers directly than to pay the middleman.
What you're also failing to understand is that many of those folks who want extra features are likely to want more than you as the original author can provide in the time allotted.
How so? We're talking about modifications here, not a whole new application program. I think this is a red herring.
Not bug fixes. Features. It's not at all uncommon for a feature request to require significant redesign. If that feature isn't broadly beneficial, the project team is going to roll its eyes.
And even when it is broadly beneficial, in many cases you get situations where... say 10% of your users want something to be done one way and the other 90% want something done the other way. It may or may not be easy to support both. This happens quite often.
Finally, many of the companies who want new features would want exclusivity for those features, or would want specific tie-ins to their own internal systems, which is work that isn't inherently useful to the community as a whole.
So what? If it brings in money for the company, what's the problem? No one said that everything open-source companies do has to be beneficial to the community as a whole, or their entire userbase. If Company X wants to buy certain features that are only useful to it, in order to integrate the program into their processes, then great; that makes money for the OSS company that wrote the program.
That's only true if that OSS company has an engineer that they are willing and able to part with full-time for weeks or months at the customer site to get the job done. That's not always possible, and that was my point. Otherwise, the company that needs the work finds an independent contractor, and learning the software enough to get the work done is the contractor's problem.
Again, not true. Smaller companies don't have "hordes" of in-house staff.
Again, you missed the point. Every company doesn't have to have that. It just takes a handful. A couple of companies need the work done and the Free software support company can't provide it right then due to limited resources, so those companies hire people on a contractual basis. When that company no longer needs those people, they're now freelancers who know the technology.
After just a handful of companies do this, the demand for the Free software support company's services dries up because there is now a glut of freelancers out in the field who need work and will undercut them. The company adds an unnecessary layer of bloat that costs money to operate, which means that hiring freelancers will always be cheaper unless there simply aren't enough freelancers who are willing/able to do the job.
Now I'm not saying that this always occurs—there are cases where it won't (embedded Linux development is a good example because pretty much 100% of the clients need custom bring-up, which is an area of skill that's well beyond what the average software engineer understands how to do), but again, those are the exceptions that prove the rule, not the rule itself. It is highly unlikely for any of those exceptions to apply to a team of programmers working on a typical end user application (unless it is huge like OpenOffice, and to some extent, not even then).
And even the market for Linux bringup could dry up if universities started pumping out people with actual operating systems programming backgrounds instead of Java/C#/Python programmers. Fortunately for those of us who either work in or have worked in that field (*raises hand*), it has a limited job market, which means that most people aren't willing to spend the effort to learn it.
It is currently against federal law for any union or corporation to contribute money from their organizational budget to a federal political campaign. This has been the law for decades, but it is striking how few people know that, including people like yourself who are clearly passionate about the subject.
The distinction between the campaign fund and a candidate PAC is little more than a technicality, and since the recent SCOTUS ruling, corporations can contribute money to the operating budget of PACs so long as the PAC's efforts are not explicitly coordinated with the campaign. As I understand it, that money can be spent on advertising, which represents the bulk of political spending.
Sure, you can say that those PACs might harm the candidate by running ads on their own, but when they do, the candidates are quick to distance themselves from the ads. Thus, the attack part of the ad against their opponent does harm to the opponent while the half-truths do not do harm to the candidate, making PACs the perfect vehicle for corrupting an election.
So in effect, the corporations have thoroughly worked around the laws you speak of at this point to such a degree that they are meaningless. PACs should have the exact same rules as political campaigns. Wherever I said campaigns in my post, insert the words "and PACs and any other organization whose principle purpose is to A. elect or defeat a specific candidate or group of candidates for office or B. promote or defeat a specific referendum, bill, or law".
Let's be clear, I would want PACs to be covered under the same contribution rules as the actual campaign committees. There's no good reason that they should not be. Either one amounts to people with money exerting undue influence and effectively buying an election. That said, it would take some work to craft a law that overturns the folly of "Citizens United v. F.E.C." without getting overturned in court.
Why waste time with individual consumers who are fickle, stupid, and above all, cheap, and are going to copy everything on BitTorrent anyway?
Because if you depend on corporate use to sustain your business, you're going to be very disappointed unless your product is in the IT space or is something very generic like a word processor. For other products, you can't make enough money that way to cover your costs.
Diving into someone else's codebase and trying to get a handle on it and start making nontrivial improvements on it is pretty hard, and time-consuming. It's a lot easier, faster, and probably cheaper to just hire the people who wrote it to make changes you want.
And that's great for the employees of the open source software company. Not so great for the company itself.
What you're also failing to understand is that many of those folks who want extra features are likely to want more than you as the original author can provide in the time allotted. Thus, they're going to end up bringing in people to do some of the work anyway. Once they cross that threshold, the incremental cost for them to do all of the work they need is noise.
Finally, many of the companies who want new features would want exclusivity for those features, or would want specific tie-ins to their own internal systems, which is work that isn't inherently useful to the community as a whole. And that work is almost never easier to contract out than to do in-house. It's often not even feasible to do without being on-site. Over time, this results in hordes of in-house staff at dozens of companies who all understand your code base and can add other features as needed, making your support contract unnecessary overhead for those companies.
Eventually, this leads to those employees realizing that they can make more money as consultants, and now you have hordes of consultants out there making money off your code instead of the original programmer.
They want the user to have the four freedoms over this code. They also want an unobfuscated copy. Right now you sure could copy the JS and modify it yourself, but you would be in violation of the license google has placed on it.
Isn't that somewhat moot? Unless they have restored offline support in the last few weeks, Google could take away the service at any time just by shutting down their servers, and it wouldn't matter at all if you had the client-side code cached locally because it won't function without the server.
Further, the code changes frequently. This would make it pretty fragile for even sophisticated users to maintain a patched version of code for sites like Gmail.
Who do they think they are going to help with this, and under what conditions would their request help? Because it seems like a stretch to me.
Actually, free is a proper superset of Free. By definition, all Free software is free, but not all free software is Free. The freedom to redistribute freely ensures this. Even without that freedom, however, it would still be largely true in practice.
Yes, "free" as in the concept of freedom or liberty, not software at no charge or profit.
That's a nice theory, but it doesn't work in practice. There is no way to make software that can be easily bug fixed by the end user that cannot also be easily enhanced by the end user, and commercial software fundamentally relies on being able to get money from the consumer for new features.
This basically leaves support contracts as the only practical revenue stream. That works fine if you are writing software for businesses (who want someone to sue). That also works fine if your software is so poorly written that you can make money on technical support, at least up until the point that somebody writes new software that doesn't suck or releases patches that fix your mess.
In general, though, once you give up the source code, you've lost control. From that point on, if you don't make the improvements that the customers want, they can go to someone else for improvements, and you no longer have a revenue stream from upgrades.
Thus, in practice, "Free" software is almost inherently "free" as in beer. The alternative is simply unsustainable, no matter how much the propagandists try to claim otherwise. RedHat and a handful of others are simply the exception that proves the rule.
True. Now those same sorts of corporations still inflict it on people; they just do it in other countries. Instead of actually helping the workers here, they just shifted the problem around.
The employees in the United States owe far more to OSHA and government oversight than to unions. They owe far more than that to the free press for exposing the working conditions and causing public outrage.
And they owe far more than that to the increased mobility of workers brought by the 20th century. That, in turn, was caused by two things: the invention of the automobile (allowing faster, easier commutes over longer distances) and increased numbers of corporations competing for the same employees.
And there's also serious question about whether unions actually benefit the employees except in the short term. They're great for fixing egregious problems when people first unionize, but if you look at the long term picture, you find that after the first few years, collective bargaining doesn't buy you much. It may well be in the best interest of the workers to form a union to obtain a redress of grievances, and then dissolve that union after the first three or four years.
What we need, of course, is to ban political contributions by all groups of people working together. If individuals want to donate money and indicate that they are donating money on behalf of an organization, that's fine, but it should have to be the individual writing the check from his or her own bank account.
It should be illegal for any organization—union or corporation—to take money entrusted to them by shareholders or members and use it for political contributions. This small change would significantly reduce the ability of corporations to buy votes, and would do so in an evenhanded manner.
Next, we should make it illegal for someone to accept money in exchange for lobbying. Paid lobbyists unfairly elevate the voices of a small number of individuals (corporate CEOs) over the public as a whole in a way that cannot effectively be countered except with an outright ban on the activity.
People should be free to lobby for their employers' positions on their own time if they choose to do so, of course, but paid lobbyists are an affront to democracy, and it should be illegal to do so on company time. Similarly, it should be illegal to punish a worker for not lobbying on their own time.
Finally, we should cut the salaries of everyone in Congress to levels comparable with those of people in their districts, provide members of Congress with free paid government housing in D.C. so that they can afford to come up there to work, and mandate that politicians spend a minimum of two-thirds of their time in their districts to be eligible for reelection. This would ensure that politicians continue to understand what's happening on the ground in their districts.
When our government was originally conceived, Congresspeople were supposed to meet for a couple of weeks out of the year. It is the perversion of Congressional duties into a year-round job that has done more harm to our government's ability to represent the people than probably any other mistake in its history. Imagine if lobbying firms had to send lobbyists out to a hundred, two hundred, three hundred different towns across the United States instead of sending a couple of people to Washington D.C. You get the picture.
You have two people. We'll call them Billy Anair and Yuni Anist. Billy Anair offers to pay ten billion dollars to sit on the right. Yuni Anist offers to pay half a billion dollars to sit on the left. Which seat do you take?
However I think you are right that there needs and can be done more. E.g. having a thermo electric converter (reverse peltier element, not sure how this is named in english) would very likely produce enough power to run pumps.
That's an interesting idea. I have no idea about the feasibility of that. The biggest question is probably whether it would be possible to limit water flow sufficiently so that it produces enough power without melting the Peltier junction.:-)
When my back light is burned through my front light is much brighter.
That probably means the ground path is poor (high resistance), but that's just a guess.
The resistance of the "two circuits" is not doubling, it is halving! Hence the remaining bulb draws twice the current. Or other way around, its not really a resistance problem only.
Resistance doesn't work that way. If you have two 1k resistors and wire them in parallel, the circuit has about 500 ohms resistance. If you take one of them away, the circuit goes back to having 1k resistance. Taking away one side of a parallel set of resistors always results in an increase in the circuit's resistance, not a decrease.
If you have 2 bulbs in parallel they cause a voltage drop,
Voltage drop occurs across resistance. The two bulbs thus cause a voltage drop on the other side of the bulbs as a result of their resistance, not on the source side. Nothing happens when one bulb in a parallel circuit blows.
Now if you have a significant inline resistance in the wire between the battery and the bulbs, that's a different story, but unless you're dealing with LEDs (which should always have a separate resistor per LED), if you have high resistance between the battery and your bulbs, it means that your wires are way too small, and you have much bigger problems than a bulb burning out.
However in such situations the reactor *and* the main generator has to be shut down. So I can not see from where you want to get the power.
Again, you're making the assumption that those must be shut down completely. As I understand it, the only reason that the main turbine gets shut down is because it would experience an overspeed turbine trip anyway due to the lack of external load. However, that turbine shutdown could be avoided by adding a flow bypass and, optionally, a dummy load to drain additional power. Emphasis should be on doing most of the work with a flow bypass because a dummy load in the MW range is probably infeasible.:-)
The lowest power output of the reactor would still be ten times the amount you need for the pumps.
That should be solvable by either more precisely bypassing the flow around the turbine or by using a larger dummy load (or both). Alternatively, a secondary turbine could be added as you suggest. The only reason I suggested the main turbine is that a secondary turbine, unless run and tested regularly, could fail when you need it just as the diesel generators did.
Either way, the point was that under most auto-scram conditions, it seems like it would usually be safer if the reactors did a partial scram into a low-power, low-reactivity interim state in which they can still produce a small amount of emergency pump power on their own in one way or another. Then, the reactor engineers could take a look at each reactor, see which ones appear to be operating safely, and fully scram the others while continuing to use the semi-working reactors for pump power.
And again, as I've said several times, there are more than two possible states. A nuclear reactor does not have to run full tilt at all times. They are usually operated that way because it takes an insane amount of time to slow the reaction down to the point where it isn't producing too much heat, but that doesn't mean you couldn't (in principle) disconnect the outside power, enable a turbine bypass to cut the flow rate way down, and scram the reactor to the 98% or 99% mark, making it highly unlikely that things would fail so catastrophically that they would prevent a full scram if necessary (manually after inspection), but at the same time, leaving just enough reaction going to allow any one of those turbines to be used for local generation.
A reactor system that requires an outside generator in a scram situation is one that does not fail safe, and is thus inherently a bad design, period. Now you can certainly argue that we should abandon this design in favor of one that can cool itself passively, and I would agree with that, but in the interim, it seems to me that it would make sense to come up with a shutdown procedure that allows it to be self sufficient whenever possible. Maybe do the 99% scram, then require someone to do an inspection, and fully auto-scram the reactor after half an hour if nobody is alive to reset a countdown clock or something (at which point you're screwed no matter what, I suppose)....
Lol... if the two bulbs would be wired in series, regardless which bulb burns through, the other one would go off.
Go back and reread what I said. I said if they were wired in series and there were some sort of failover that shorted across the bad bulb if it goes bad. You know, like most modern Christmas tree lights do.
If one part burns away, resistance is dropping, so current is rising, so the other part has higher chance to burn away soon as well.
What are you talking about? I thought we were talking about two bulbs wired in parallel here. The voltage is constant, the resistance of each bulb is constant, so the resistance of the whole circuit doubles as the resistance of one of the two parallel paths becomes infinite. Thus, the current drops in half, exactly as you would expect when you have half as many bulbs drawing current....
When they are wired in series with a failover as I described, then they do what you describe. Another way to word the same statement is to say that they pop rather rapidly because they're effectively seeing twice their rated voltage.
Don't get me wrong: yes, you could do something like the thing you proposed. But for that you would need a small helper turbine to create the power for sustaining the plant. You can not use the main turbine and the main current lines for that.
I don't see why not. The power output just has to be matched with the flow rate so that the turbine remains spinning at an appropriate speed. Oh, and you need a sine wave source to maintain turbine synchronization, but I think I mentioned that in my previous post.
As some other people pointed out, in such a scenario however the power plant is designed to shut down completely. That means the helper turbine would only work a limited time.
Unless you do what I suggested, which is to not do a 100% scram. I'm saying, "Yes but you could fish with live worms instead of rubber bait," and you're saying "Yes, but that won't work because I'm using rubber bait." See the non sequitur here?
In that case, s/drop/raise/g, or better yet s/drop/insert/g. Now that you mention it, I remember reading that a couple of weeks ago and had completely forgotten about it.
The direction of the control rods shouldn't be all that important. I mean, sure, gravity assisting the control mechanism rather than working against it is a good idea, but it's a good idea in much the same way that having brake calipers hung from above rather than coming up from below is a good idea. The amount of force needed to do the job just has to be a little higher in one case.:-)
BTW, which reactor are we talking about here? There were something like three or four of them that were having problems at one point, and I don't think they're all the same design....
Slashdot Mirror
If the person could save $80 per month for a TV set, now that he/she has bought the TV set, that person now has $80 in disposable income to spend on movies and TV shows. I don't think that argument works too well. And even if the student saved $80 a month by eating nothing but Ramen noodles, there's still clearly some financial flexibility there.
A better example would be a student whose parents bought him/her a laptop and uses it for watching movies. That student might legitimately have to choose between buying a DVD and buying lunch.
There's a second option. The webmail service could generate its own public and private key pair, and you can sign that pair with your personal key. You could then separately revoke the webmail key. Nothing says that a person can only have one PK crypto key pair.
There's a third option, too. The webmail service could use a secure callback to your home computer, and that computer could do the signing on your behalf, using "Back to my Mac" or similar so that you don't have to leave your home machine running all the time. You could then revoke permission for the webmail service to do so at any time.
Oddly enough, I didn't. Guess they've lost my contact info.
Seriously. I mean, I bought the book-on-tape version of this, and it was way more than 15 minutes. And no Q&A. I mean, seriously, WTF?
:-D
Yes, they are an awful lot, aren't they.
Ba-da-bump.
Either way, it strikes me that the fair dealing laws in the U.K. probably cover this in effect, albeit not in letter. I'd be curious to see where this leads, particularly given the decade of de facto precedent set by iTunes and what I assume is a lack of challenges to that....
My guess is they'll make you go out to the parking lot and burn a Mazda.
Ba-dump-ching. Thanks. I'll be here all night.
I guess it depends on whether any large companies care about the product.
Have them work on something else? It's not like programmers only know how to work on one piece of software....
Because working for a startup is anything but stable. Been there, done that. When it comes to companies that provide support for OSS, the vast majority are startup-sized companies. Becoming a contractor certainly isn't for everybody, but I do know a lot of people who have made that call over the years. It's not nearly as rare as you think. And it is even more common when you're talking about people working at a startup who know that a single bad quarter could mean that they're looking for work anyway.
I've been working in the software business for over a decade. I've watched companies that I've worked for hire the lead coders for open source projects because it's easier and cheaper than trying to work with the companies that support those projects. What I'm describing does happen, and it happens often.
Not after the company who needs the work done realizes that it's cheaper to hire those programmers directly than to pay the middleman.
Not bug fixes. Features. It's not at all uncommon for a feature request to require significant redesign. If that feature isn't broadly beneficial, the project team is going to roll its eyes.
And even when it is broadly beneficial, in many cases you get situations where... say 10% of your users want something to be done one way and the other 90% want something done the other way. It may or may not be easy to support both. This happens quite often.
That's only true if that OSS company has an engineer that they are willing and able to part with full-time for weeks or months at the customer site to get the job done. That's not always possible, and that was my point. Otherwise, the company that needs the work finds an independent contractor, and learning the software enough to get the work done is the contractor's problem.
Again, you missed the point. Every company doesn't have to have that. It just takes a handful. A couple of companies need the work done and the Free software support company can't provide it right then due to limited resources, so those companies hire people on a contractual basis. When that company no longer needs those people, they're now freelancers who know the technology.
After just a handful of companies do this, the demand for the Free software support company's services dries up because there is now a glut of freelancers out in the field who need work and will undercut them. The company adds an unnecessary layer of bloat that costs money to operate, which means that hiring freelancers will always be cheaper unless there simply aren't enough freelancers who are willing/able to do the job.
Now I'm not saying that this always occurs—there are cases where it won't (embedded Linux development is a good example because pretty much 100% of the clients need custom bring-up, which is an area of skill that's well beyond what the average software engineer understands how to do), but again, those are the exceptions that prove the rule, not the rule itself. It is highly unlikely for any of those exceptions to apply to a team of programmers working on a typical end user application (unless it is huge like OpenOffice, and to some extent, not even then).
And even the market for Linux bringup could dry up if universities started pumping out people with actual operating systems programming backgrounds instead of Java/C#/Python programmers. Fortunately for those of us who either work in or have worked in that field (*raises hand*), it has a limited job market, which means that most people aren't willing to spend the effort to learn it.
The distinction between the campaign fund and a candidate PAC is little more than a technicality, and since the recent SCOTUS ruling, corporations can contribute money to the operating budget of PACs so long as the PAC's efforts are not explicitly coordinated with the campaign. As I understand it, that money can be spent on advertising, which represents the bulk of political spending.
Sure, you can say that those PACs might harm the candidate by running ads on their own, but when they do, the candidates are quick to distance themselves from the ads. Thus, the attack part of the ad against their opponent does harm to the opponent while the half-truths do not do harm to the candidate, making PACs the perfect vehicle for corrupting an election.
So in effect, the corporations have thoroughly worked around the laws you speak of at this point to such a degree that they are meaningless. PACs should have the exact same rules as political campaigns. Wherever I said campaigns in my post, insert the words "and PACs and any other organization whose principle purpose is to A. elect or defeat a specific candidate or group of candidates for office or B. promote or defeat a specific referendum, bill, or law".
Let's be clear, I would want PACs to be covered under the same contribution rules as the actual campaign committees. There's no good reason that they should not be. Either one amounts to people with money exerting undue influence and effectively buying an election. That said, it would take some work to craft a law that overturns the folly of "Citizens United v. F.E.C." without getting overturned in court.
Because if you depend on corporate use to sustain your business, you're going to be very disappointed unless your product is in the IT space or is something very generic like a word processor. For other products, you can't make enough money that way to cover your costs.
And that's great for the employees of the open source software company. Not so great for the company itself.
What you're also failing to understand is that many of those folks who want extra features are likely to want more than you as the original author can provide in the time allotted. Thus, they're going to end up bringing in people to do some of the work anyway. Once they cross that threshold, the incremental cost for them to do all of the work they need is noise.
Finally, many of the companies who want new features would want exclusivity for those features, or would want specific tie-ins to their own internal systems, which is work that isn't inherently useful to the community as a whole. And that work is almost never easier to contract out than to do in-house. It's often not even feasible to do without being on-site. Over time, this results in hordes of in-house staff at dozens of companies who all understand your code base and can add other features as needed, making your support contract unnecessary overhead for those companies.
Eventually, this leads to those employees realizing that they can make more money as consultants, and now you have hordes of consultants out there making money off your code instead of the original programmer.
Isn't that somewhat moot? Unless they have restored offline support in the last few weeks, Google could take away the service at any time just by shutting down their servers, and it wouldn't matter at all if you had the client-side code cached locally because it won't function without the server.
Further, the code changes frequently. This would make it pretty fragile for even sophisticated users to maintain a patched version of code for sites like Gmail.
Who do they think they are going to help with this, and under what conditions would their request help? Because it seems like a stretch to me.
Actually, free is a proper superset of Free. By definition, all Free software is free, but not all free software is Free. The freedom to redistribute freely ensures this. Even without that freedom, however, it would still be largely true in practice.
That's a nice theory, but it doesn't work in practice. There is no way to make software that can be easily bug fixed by the end user that cannot also be easily enhanced by the end user, and commercial software fundamentally relies on being able to get money from the consumer for new features.
This basically leaves support contracts as the only practical revenue stream. That works fine if you are writing software for businesses (who want someone to sue). That also works fine if your software is so poorly written that you can make money on technical support, at least up until the point that somebody writes new software that doesn't suck or releases patches that fix your mess.
In general, though, once you give up the source code, you've lost control. From that point on, if you don't make the improvements that the customers want, they can go to someone else for improvements, and you no longer have a revenue stream from upgrades.
Thus, in practice, "Free" software is almost inherently "free" as in beer. The alternative is simply unsustainable, no matter how much the propagandists try to claim otherwise. RedHat and a handful of others are simply the exception that proves the rule.
True. Now those same sorts of corporations still inflict it on people; they just do it in other countries. Instead of actually helping the workers here, they just shifted the problem around.
The employees in the United States owe far more to OSHA and government oversight than to unions. They owe far more than that to the free press for exposing the working conditions and causing public outrage.
And they owe far more than that to the increased mobility of workers brought by the 20th century. That, in turn, was caused by two things: the invention of the automobile (allowing faster, easier commutes over longer distances) and increased numbers of corporations competing for the same employees.
And there's also serious question about whether unions actually benefit the employees except in the short term. They're great for fixing egregious problems when people first unionize, but if you look at the long term picture, you find that after the first few years, collective bargaining doesn't buy you much. It may well be in the best interest of the workers to form a union to obtain a redress of grievances, and then dissolve that union after the first three or four years.
What we need, of course, is to ban political contributions by all groups of people working together. If individuals want to donate money and indicate that they are donating money on behalf of an organization, that's fine, but it should have to be the individual writing the check from his or her own bank account.
It should be illegal for any organization—union or corporation—to take money entrusted to them by shareholders or members and use it for political contributions. This small change would significantly reduce the ability of corporations to buy votes, and would do so in an evenhanded manner.
Next, we should make it illegal for someone to accept money in exchange for lobbying. Paid lobbyists unfairly elevate the voices of a small number of individuals (corporate CEOs) over the public as a whole in a way that cannot effectively be countered except with an outright ban on the activity.
People should be free to lobby for their employers' positions on their own time if they choose to do so, of course, but paid lobbyists are an affront to democracy, and it should be illegal to do so on company time. Similarly, it should be illegal to punish a worker for not lobbying on their own time.
Finally, we should cut the salaries of everyone in Congress to levels comparable with those of people in their districts, provide members of Congress with free paid government housing in D.C. so that they can afford to come up there to work, and mandate that politicians spend a minimum of two-thirds of their time in their districts to be eligible for reelection. This would ensure that politicians continue to understand what's happening on the ground in their districts.
When our government was originally conceived, Congresspeople were supposed to meet for a couple of weeks out of the year. It is the perversion of Congressional duties into a year-round job that has done more harm to our government's ability to represent the people than probably any other mistake in its history. Imagine if lobbying firms had to send lobbyists out to a hundred, two hundred, three hundred different towns across the United States instead of sending a couple of people to Washington D.C. You get the picture.
You have two people. We'll call them Billy Anair and Yuni Anist. Billy Anair offers to pay ten billion dollars to sit on the right. Yuni Anist offers to pay half a billion dollars to sit on the left. Which seat do you take?
I'm so glad you didn't swap those fruits. "The perp shot me with his banana..." would be a plot suitable for a porno movie.
That's an interesting idea. I have no idea about the feasibility of that. The biggest question is probably whether it would be possible to limit water flow sufficiently so that it produces enough power without melting the Peltier junction. :-)
That probably means the ground path is poor (high resistance), but that's just a guess.
Maybe. Or that could just be what he wanted you to think. Just saying.
Resistance doesn't work that way. If you have two 1k resistors and wire them in parallel, the circuit has about 500 ohms resistance. If you take one of them away, the circuit goes back to having 1k resistance. Taking away one side of a parallel set of resistors always results in an increase in the circuit's resistance, not a decrease.
Voltage drop occurs across resistance. The two bulbs thus cause a voltage drop on the other side of the bulbs as a result of their resistance, not on the source side. Nothing happens when one bulb in a parallel circuit blows.
Now if you have a significant inline resistance in the wire between the battery and the bulbs, that's a different story, but unless you're dealing with LEDs (which should always have a separate resistor per LED), if you have high resistance between the battery and your bulbs, it means that your wires are way too small, and you have much bigger problems than a bulb burning out.
Again, you're making the assumption that those must be shut down completely. As I understand it, the only reason that the main turbine gets shut down is because it would experience an overspeed turbine trip anyway due to the lack of external load. However, that turbine shutdown could be avoided by adding a flow bypass and, optionally, a dummy load to drain additional power. Emphasis should be on doing most of the work with a flow bypass because a dummy load in the MW range is probably infeasible. :-)
That should be solvable by either more precisely bypassing the flow around the turbine or by using a larger dummy load (or both). Alternatively, a secondary turbine could be added as you suggest. The only reason I suggested the main turbine is that a secondary turbine, unless run and tested regularly, could fail when you need it just as the diesel generators did.
Either way, the point was that under most auto-scram conditions, it seems like it would usually be safer if the reactors did a partial scram into a low-power, low-reactivity interim state in which they can still produce a small amount of emergency pump power on their own in one way or another. Then, the reactor engineers could take a look at each reactor, see which ones appear to be operating safely, and fully scram the others while continuing to use the semi-working reactors for pump power.
And again, as I've said several times, there are more than two possible states. A nuclear reactor does not have to run full tilt at all times. They are usually operated that way because it takes an insane amount of time to slow the reaction down to the point where it isn't producing too much heat, but that doesn't mean you couldn't (in principle) disconnect the outside power, enable a turbine bypass to cut the flow rate way down, and scram the reactor to the 98% or 99% mark, making it highly unlikely that things would fail so catastrophically that they would prevent a full scram if necessary (manually after inspection), but at the same time, leaving just enough reaction going to allow any one of those turbines to be used for local generation.
A reactor system that requires an outside generator in a scram situation is one that does not fail safe, and is thus inherently a bad design, period. Now you can certainly argue that we should abandon this design in favor of one that can cool itself passively, and I would agree with that, but in the interim, it seems to me that it would make sense to come up with a shutdown procedure that allows it to be self sufficient whenever possible. Maybe do the 99% scram, then require someone to do an inspection, and fully auto-scram the reactor after half an hour if nobody is alive to reset a countdown clock or something (at which point you're screwed no matter what, I suppose)....
Go back and reread what I said. I said if they were wired in series and there were some sort of failover that shorted across the bad bulb if it goes bad. You know, like most modern Christmas tree lights do.
What are you talking about? I thought we were talking about two bulbs wired in parallel here. The voltage is constant, the resistance of each bulb is constant, so the resistance of the whole circuit doubles as the resistance of one of the two parallel paths becomes infinite. Thus, the current drops in half, exactly as you would expect when you have half as many bulbs drawing current....
When they are wired in series with a failover as I described, then they do what you describe. Another way to word the same statement is to say that they pop rather rapidly because they're effectively seeing twice their rated voltage.
I don't see why not. The power output just has to be matched with the flow rate so that the turbine remains spinning at an appropriate speed. Oh, and you need a sine wave source to maintain turbine synchronization, but I think I mentioned that in my previous post.
Unless you do what I suggested, which is to not do a 100% scram. I'm saying, "Yes but you could fish with live worms instead of rubber bait," and you're saying "Yes, but that won't work because I'm using rubber bait." See the non sequitur here?
In that case, s/drop/raise/g, or better yet s/drop/insert/g. Now that you mention it, I remember reading that a couple of weeks ago and had completely forgotten about it.
The direction of the control rods shouldn't be all that important. I mean, sure, gravity assisting the control mechanism rather than working against it is a good idea, but it's a good idea in much the same way that having brake calipers hung from above rather than coming up from below is a good idea. The amount of force needed to do the job just has to be a little higher in one case. :-)
BTW, which reactor are we talking about here? There were something like three or four of them that were having problems at one point, and I don't think they're all the same design....
So in other words, IE's idle performance sucks. That's usually an easy thing to fix.