Again the flippant comparison of a non crime with a crime. By the way, Swatz is 26 years old and been legally an adult for over 8 years. He is far beyond a kid.
Your basic point seems to be that since you think the items stolen should be in public domain makes getting at them by any means OK. Sorry but breaking and entering, breaching computer security and making copyright material publicly available is very different from talking in class. There are no known prison sentences for talking in glass but there are for the crimes Swartz committed. If you are going to do the crime be prepared to do the time.
What would you consider a punishment that would have fit the crime?
What I was more thinking of is a longer chain for example; 1. Geothermal heat converted to electricity. 2. The electricity combined with the waste heat to run greenhouses to produce sugar rich biomass. 3. The biomass combined with more heat and electricity to make fuel. Even at very low rates of return it is still viable because the geothermal energy is useless in the state that is is in at the start.
Those considerations don't matter in this case as there is no question Swartzwhat he was accused of. All he wants the trial for is the chance a jury nullification regardless of his actual guilt or innocence.
I am usually very concerned with EROEI but there is one instance where and EROEI of less than 1 is not a problem. The is in converting the energy into something much more transportable. For example geothermal heat does not travel well or store well. We currently are very good at converting it into electricity. That travels better but still has limits and storage is very expensive. We can convert the energy into hydrocarbons that store very well and transport very well. It does not matter if we only get half the energy out that we put in if the energy we put in is not usable where it is now.;
It is psychological warfare but I see no problem with sending someone to prison for six months for doing what Shwartz did. I see no problem with saying "If you are going to make use spend all the time and money to go to trial we will make it worth our while. On the other hand plead guilty to something we all know you did and you'll be out in six months". Sorry but I don't believe in "He threatened suicide so we go light on him". Allow that and everyone will start doing it.
Then there is the question of the defense attorney. If he was so concerned that his client was going to commit suicide then why didn't he have him committed for evaluation?.
Where does the 35 years number come from. That is the maximum sentence not the minimum There is also differences between consecutive and concurrent sentences. On one end of the scale, that people keep pointing to, with maximum consecutive sentences the years add up fast. On the other end with minimum concurrent sentences, early parole for good behavior, etc he could have been out in a few years. One valid tactic is to pile on the charges and plea bargain for a much shorter concurrent term.
The issue is that it sends a bad message to everyone else "I can break the law if I can convince the injured party it is OK". That is the difference between a civil action and a criminal action. It comes down to the fact that Swartz did not have permission when he did the actions. Perhaps the reason JSTOR wanted to drop the charges was to stop the publicity. Maybe they did it to make themselves look good knowing full well that the persecutors would not drop the case.
You seem to think that the plastic bag is inside the stomach. Not true. The water is just injected into the stomach through the tube that was being used to pump the juices out. It probably also acts as a cleaning agent so the tube does not become clogged.
1. No alcohol sensor. The cube will react the same way if one is drinking water or Everclear. All it is doing is counting the number of times the drinks are taken not the strength of the drink. 2. No idea how much volume is consumed. All it does is count tips and not how fast the liquid is consumed. I have taken 40 sips to drink a pint or one when in a drinking competition. 3. Not useful for beer drinkers. Few people will put ice in a can of beer. 4. Does not work with a straw. No tipping no ice movement no consumption recorded.
When the programmer who fixes the bug tells the dev manager who put the bug in and should have seen it, the original programmer gets the blame for making the project late and being a liar or incompetent. It is hard to trust someone who lies.
"I'll fix that bug later" is legit when you're already having trouble meeting a deadline, better to meet it with a buggy product and fix it during QC than not deliver.
I agree completely that a bug report is sufficient in many cases. What the past poster was advocating was allowing known buggy code to go through needless testing cycles to make it appear that the dev team met their deadline when they really did not. Notice that he said nothing about recording or reporting the bug. Most QC departments will not accept a build that has certain kinds of bugs.
There is a big difference between "I will analyse the situation and decide whether I can quickly fix the bug or do I need to report the bug and someone will fix it before sending it to QC" and "I'll ignore the bug and QC will catch it". The former is sound time management. The latter is delusion.
I am glad you are not on my dev team. You can't ship a product that you know will fail in the field. To a customer "works most of the time" is not acceptable. The "it compiles, kick it to QA. They'll fix it" mentality is why some devs have a bad name. QA is there to fix issues missed by devs not cover up dev incompetence. If you can't write code without obvious bugs you are incompetent.
All of the above. The point I was trying to make is that whether one fixes it now or fixes it later it will take at least as much time to fix it now. Fixing it later does not save time at all; in fact is adds a lot mote time to fix the issue. It is always faster to fix a bug when one has been working on the code for a while than to come back later and fix it when one's memory is stale. All delaying the fix does is shift to a bigger time cost of a later phase.
So when the QA guy goes to the boss and shows him how you passed an obvious bug to make yourself look good don't you think that would be a threat to your employment? I have worked in QA and have done just that. I have then seen the PM and the dev lead jump down the programmer's throat. QA is not extra dev time. Not only are you a programmer who did not complete work on time but you are a programmer who did not complete work on time and lied about it. Companies don't usually keep people around they can not trust.
Egotistical programmers who firmly believe that their way is always the best no matter the history of procedures of the company. They do things without regard to how they effect other people and cause others a great deal off wasted time trying to figure out their 'optimized" code is doing. It is about project productivity not individual productivity. If an individual's excellent productivity leaves such a mess behind that it delays others it is not a good thing.
A perfect example of this is code format haters. They will use their own preferred format and ignore the company standard. They may work faster but the next person who reads the code will work much slower. The code will also be modified in code reviews wasting time. Short term gain for long term loss. Had they buckled down and accepted the code format they would be back to their original productivity in a short time and not be a continual drain on overall productivity.
There are other similar issue. I will use package A when it everything else uses Package B because I know Package A better. This neglects the fact that everyone else knows Package B and not Package A and will have to waste time going through the learning curve. The same goes for design patterns, scripting languages, etc.
There are two strategies to deal with bugs; i'll fix it now or ill fix it later.
Cost for i'll fix it now' X number of hours of developer time.
Cost to fix it later. Time for QA to find bug. Time for QA to document bug in replicatable manner. X number of hours to fix bug y number of hours to re-equant with code surrounding the bug. QA time to test bug and verify it is fixed.
In effect by not fixing a known bug while trying to meet a deadline all you are ensuring is that the next stage will be late and the whole project will be even later. There is no time saved a a lot of time wasted. There is an applicable saying "you can pay me a little now or a lot later". Burying issues is never a good idea.
This article revolves around 4 statistics. US male like expectancy (75.6), Switzerland male life expectancy (about 79.6), US female life expectancy (80.8) and Japan`s female life expectancy (about 85.8). The numbers they do not include are the confidence intervals. Note that the US male life expectancy is within 5% of the highest and the US female life expectancy is within 6% of the highest. If the confidence interval was 3% they would be statistically equal. In something as fuzzy as life expectancy a confidence interval of 3% is pretty small.
An issue with reusable launch vehicles is that, due to the stresses of launch, parts have a tendency to bend and break. It can be quite difficult to find and diagnose these issues. Things can even become fuses and need to be replaced. It is quite similar to a drag racer. After each run the entire engine is re-built and they don't last many runs. One can build an item much lighter if it is tuned to almost destroy itself while doing it's job. A single use rocket has to hold itself together just long enough to get it's payload into orbit. A reusable vehicle must survive the stresses of getting to orbit, Survive the heat and stresses of reentry. Then land safely all with as little damage as possible so the whole vehicle need not be re-built.
I disagree completely with the "all or nothing" bent of your post. I agree that employers can not demand everything they want but they can demand reasonable things. Sure you can come up with bad things that have been required in some countries but that has nothing to do with immunization. To me, getting a flue shot, something done by millions of people every year, is a reasonable precaution when dealing with people who have compromised immune systems.
Sorry but according to article from the CDC here are the "Fundamental Elements to Prevent Influenza Transmission";
The core prevention strategies include: administration of influenza vaccine implementation of respiratory hygiene and cough etiquette appropriate management of ill HCP adherence to infection control precautions for all patient-care activities and aerosol-generating procedures implementing environmental and engineering infection control measures.
Slashdot Mirror
Again the flippant comparison of a non crime with a crime. By the way, Swatz is 26 years old and been legally an adult for over 8 years. He is far beyond a kid.
Your basic point seems to be that since you think the items stolen should be in public domain makes getting at them by any means OK. Sorry but breaking and entering, breaching computer security and making copyright material publicly available is very different from talking in class. There are no known prison sentences for talking in glass but there are for the crimes Swartz committed. If you are going to do the crime be prepared to do the time.
What would you consider a punishment that would have fit the crime?
What I was more thinking of is a longer chain for example;
1. Geothermal heat converted to electricity.
2. The electricity combined with the waste heat to run greenhouses to produce sugar rich biomass.
3. The biomass combined with more heat and electricity to make fuel.
Even at very low rates of return it is still viable because the geothermal energy is useless in the state that is is in at the start.
Those considerations don't matter in this case as there is no question Swartzwhat he was accused of. All he wants the trial for is the chance a jury nullification regardless of his actual guilt or innocence.
I am usually very concerned with EROEI but there is one instance where and EROEI of less than 1 is not a problem. The is in converting the energy into something much more transportable. For example geothermal heat does not travel well or store well. We currently are very good at converting it into electricity. That travels better but still has limits and storage is very expensive. We can convert the energy into hydrocarbons that store very well and transport very well. It does not matter if we only get half the energy out that we put in if the energy we put in is not usable where it is now.;
It is psychological warfare but I see no problem with sending someone to prison for six months for doing what Shwartz did. I see no problem with saying "If you are going to make use spend all the time and money to go to trial we will make it worth our while. On the other hand plead guilty to something we all know you did and you'll be out in six months". Sorry but I don't believe in "He threatened suicide so we go light on him". Allow that and everyone will start doing it.
Then there is the question of the defense attorney. If he was so concerned that his client was going to commit suicide then why didn't he have him committed for evaluation?.
Where does the 35 years number come from. That is the maximum sentence not the minimum There is also differences between consecutive and concurrent sentences. On one end of the scale, that people keep pointing to, with maximum consecutive sentences the years add up fast. On the other end with minimum concurrent sentences, early parole for good behavior, etc he could have been out in a few years. One valid tactic is to pile on the charges and plea bargain for a much shorter concurrent term.
The issue is that it sends a bad message to everyone else "I can break the law if I can convince the injured party it is OK". That is the difference between a civil action and a criminal action. It comes down to the fact that Swartz did not have permission when he did the actions. Perhaps the reason JSTOR wanted to drop the charges was to stop the publicity. Maybe they did it to make themselves look good knowing full well that the persecutors would not drop the case.
You seem to think that the plastic bag is inside the stomach. Not true. The water is just injected into the stomach through the tube that was being used to pump the juices out. It probably also acts as a cleaning agent so the tube does not become clogged.
Here are some issues;
1. No alcohol sensor. The cube will react the same way if one is drinking water or Everclear. All it is doing is counting the number of times the drinks are taken not the strength of the drink.
2. No idea how much volume is consumed. All it does is count tips and not how fast the liquid is consumed. I have taken 40 sips to drink a pint or one when in a drinking competition.
3. Not useful for beer drinkers. Few people will put ice in a can of beer.
4. Does not work with a straw. No tipping no ice movement no consumption recorded.
When the programmer who fixes the bug tells the dev manager who put the bug in and should have seen it, the original programmer gets the blame for making the project late and being a liar or incompetent. It is hard to trust someone who lies.
To be completely pedantic "fix it if reasonable report it if not".
Go back to the second post in this thread;
"I'll fix that bug later" is legit when you're already having trouble meeting a deadline, better to meet it with a buggy product and fix it during QC than not deliver.
I agree completely that a bug report is sufficient in many cases. What the past poster was advocating was allowing known buggy code to go through needless testing cycles to make it appear that the dev team met their deadline when they really did not. Notice that he said nothing about recording or reporting the bug. Most QC departments will not accept a build that has certain kinds of bugs.
There is a big difference between "I will analyse the situation and decide whether I can quickly fix the bug or do I need to report the bug and someone will fix it before sending it to QC" and "I'll ignore the bug and QC will catch it". The former is sound time management. The latter is delusion.
I am glad you are not on my dev team. You can't ship a product that you know will fail in the field. To a customer "works most of the time" is not acceptable. The "it compiles, kick it to QA. They'll fix it" mentality is why some devs have a bad name. QA is there to fix issues missed by devs not cover up dev incompetence. If you can't write code without obvious bugs you are incompetent.
Exactly and with a very high interest rate that all must be paid back before the project is complete.
All of the above. The point I was trying to make is that whether one fixes it now or fixes it later it will take at least as much time to fix it now. Fixing it later does not save time at all; in fact is adds a lot mote time to fix the issue. It is always faster to fix a bug when one has been working on the code for a while than to come back later and fix it when one's memory is stale. All delaying the fix does is shift to a bigger time cost of a later phase.
So when the QA guy goes to the boss and shows him how you passed an obvious bug to make yourself look good don't you think that would be a threat to your employment? I have worked in QA and have done just that. I have then seen the PM and the dev lead jump down the programmer's throat. QA is not extra dev time. Not only are you a programmer who did not complete work on time but you are a programmer who did not complete work on time and lied about it. Companies don't usually keep people around they can not trust.
Egotistical programmers who firmly believe that their way is always the best no matter the history of procedures of the company. They do things without regard to how they effect other people and cause others a great deal off wasted time trying to figure out their 'optimized" code is doing. It is about project productivity not individual productivity. If an individual's excellent productivity leaves such a mess behind that it delays others it is not a good thing.
A perfect example of this is code format haters. They will use their own preferred format and ignore the company standard. They may work faster but the next person who reads the code will work much slower. The code will also be modified in code reviews wasting time. Short term gain for long term loss. Had they buckled down and accepted the code format they would be back to their original productivity in a short time and not be a continual drain on overall productivity.
There are other similar issue. I will use package A when it everything else uses Package B because I know Package A better. This neglects the fact that everyone else knows Package B and not Package A and will have to waste time going through the learning curve. The same goes for design patterns, scripting languages, etc.
There are two strategies to deal with bugs; i'll fix it now or ill fix it later.
Cost for i'll fix it now'
X number of hours of developer time.
Cost to fix it later.
Time for QA to find bug.
Time for QA to document bug in replicatable manner.
X number of hours to fix bug
y number of hours to re-equant with code surrounding the bug.
QA time to test bug and verify it is fixed.
In effect by not fixing a known bug while trying to meet a deadline all you are ensuring is that the next stage will be late and the whole project will be even later. There is no time saved a a lot of time wasted. There is an applicable saying "you can pay me a little now or a lot later". Burying issues is never a good idea.
This article revolves around 4 statistics. US male like expectancy (75.6), Switzerland male life expectancy (about 79.6), US female life expectancy (80.8) and Japan`s female life expectancy (about 85.8). The numbers they do not include are the confidence intervals. Note that the US male life expectancy is within 5% of the highest and the US female life expectancy is within 6% of the highest. If the confidence interval was 3% they would be statistically equal. In something as fuzzy as life expectancy a confidence interval of 3% is pretty small.
An issue with reusable launch vehicles is that, due to the stresses of launch, parts have a tendency to bend and break. It can be quite difficult to find and diagnose these issues. Things can even become fuses and need to be replaced. It is quite similar to a drag racer. After each run the entire engine is re-built and they don't last many runs. One can build an item much lighter if it is tuned to almost destroy itself while doing it's job. A single use rocket has to hold itself together just long enough to get it's payload into orbit. A reusable vehicle must survive the stresses of getting to orbit, Survive the heat and stresses of reentry. Then land safely all with as little damage as possible so the whole vehicle need not be re-built.
Sorry but coughing on a patient is not a basic human right but having children is.
Nurses with egg allergies could use the egg free vaccine
I disagree completely with the "all or nothing" bent of your post. I agree that employers can not demand everything they want but they can demand reasonable things. Sure you can come up with bad things that have been required in some countries but that has nothing to do with immunization. To me, getting a flue shot, something done by millions of people every year, is a reasonable precaution when dealing with people who have compromised immune systems.
Sorry but according to article from the CDC here are the "Fundamental Elements to Prevent Influenza Transmission";
The core prevention strategies include:
administration of influenza vaccine
implementation of respiratory hygiene and cough etiquette
appropriate management of ill HCP
adherence to infection control precautions for all patient-care activities and aerosol-generating procedures
implementing environmental and engineering infection control measures.