It's not absurd at all if you think about the different workflows that could be used.
The AC's choice of the word "absurd" may be a mild hyperbole (if you pardon the oxymoron), but it certainly fails the Occam's Razor test. Which is more likely: that Wikipedia's editors aren't into videos, or that WP's editors really love video editing but don't understand transcoding?
The best explanation for the lack of video in Wikimedia Commons is that it's heavily tied to Wikipedia, and web video simply isn't compatible with the way Wikipedia works. You can't re-edit videos ad infinitum the way you can edit a WP article or a.SVG graphic -- all the web video standards are delivery formats, not editable archive formats. There's no collaboration, no iterative improvement, no refinement -- it's like it or lump it, which is an alien design philosophy to WP types.
In fact, now that I mention SVG... notice that Wikimedia has ditched officially ditched bitmaps for pretty much everything except JPEG photos, officially favouring SVG vector images as editable source formats. Adopting a delivery format for an archive operation is completely against what they stand for.
I'm surprised they based their designs on linear slides.... it looks like the next generation of RepRap will do away with them entirely:
You're forgetting that the main purpose of this project is to produce something durable and reliable. The RoboBeast design is based on RepRap designs that have been tried and tested to destruction, and then improves on them. Linear actuators are also far more reliable than non-linear ones, and far easier to stabilise (remember, this is resistant to a high degree of movement).
Besides, traditional manufacturing has had non-linear robots for ages, so they are a known factor -- if it was that easy, first-gen 3D printers would have used them.
In that case it's up to Facebook to sue, not the photographer; he already "gave" it to FB.
Not true, he gave them a non-exclusive license. He did not ascribe the copyright to them. Facebook could have licensed it to them, but in the lack of such a license, they have absolutely no say in the matter. Where no license is in place, it is only the copyright holder who has the right to sue.
Actually willful infringement is worth quite a bit in the court of law. Its well within his interests to pursue this and if he doesn't it sets the example that this sort of behavior is acceptable.
The problem is that this is quite plausibly a genuine mistake -- it happens all the time that someone within an organisation lifts a graphic from one resource and dumps it straight into another thinking "it's on our page, therefore it's ours" and doing no background checks. So in theory, it's very difficult to prove willful infringement.
The question that the legal profession should be asking is more interesting: as this type of case is pretty common, it is clear that most companies do not have systems in place to check these things, and crucially that they are aware that this is an issue. This is currently considered negligent, but there comes a point where even negligence can be considered willful: if you refuse to fix a known problem which allows you to continue to act in a way that prejudicially benefits your company, that's willful.
I don't think this case will set a precedent (because the guy doesn't appear to be negotiating reasonably), but there will be a case sooner or later that will put the onus on the company to audit their copy text and marketing IP properly. Only once the company has a central data bank of resources and a published policy of "only ever draw collateral from the data bank" should the company be considered non-negligent. Once that's in place, the occassional employee ignoring the policy would be accepted as unintentional, as long as it the employee was officially reprimanded.
As I was saying earlier: without trying to build a full-blown Watson-like text parsing engine (which is WAY beyond the scope of this project), it simply isn't possible to anticipate all the possible errors. ...
Regardless of whether it is a "first rule of programming" or not, it is only possible to account for the errors you can anticipate.
And I said, you're not expected to anticipate what the error is, just that this section of the program is prone to various errors regardless of type.
Having said that: I DO trap errors. When I said the program "crashed", I just meant it stopped running and, spewed out a runtime-error message. Anticipated errors are all logged. Only unanticipated errors cause the program to halt. And even those are trapped and give me valuable debug information.
Next run, that error will be anticipated and (we hope) dealt with in the code so it doesn't happen again. But that doesn't preclude another unanticipated error from happening after another 10,000 or so documents.
Sorry, but you're still making too much work for yourself by letting one faulty page halt the entire job.
You asked the question (and I quote): But when I am actually doing a run, and tens of thousands of pages are being processed, and ONE causes the program to crash: is that a bug?
Yes it is. A batch run of tens of thousands of pages should have the code that handles an individual page wrapped in an exception handler that traps unknown errors, logs information for debugging, marks the missing page in the output (for manual intervention) and then moves on to the next page. That way you get (tens of thousands - 1) pages processed and you have a perfectly acceptable error rate in the region of 0.01%
You should not stop the entire batch of tens of thousands of pages for an unanticipated problem in a single solitary one of them. It is trivially easy to prevent this happening -- unless the unanticipated fault jams your scanner.
Indeed, and when dealing with B2B software suppliers, contracts will typically quote high investigation rates for bug reports, to be charged if and only if the "bug" is no such thing (most are user errors or problems with the underlying platform).
Perhaps the OP should suggest the same thing to his boss...? I'll investigate in my own time, but if I determine the bug was A) a specification problem, B) a platform problem or C) someone else's bug, I'll be billing $200 an hour....
That's yet another terrible analogy! Dynamiting a bridge is akin to an IT administrator sabotaging a system from within. That's also a terrible analogy, but at least it's closer than your comparison.
It's a perfectly good analogy. A bridge is on public land and you can get to it dead easily, and you don't have to be an insider. His point is that you don't have to design impenetrable fences to prevent people accessing the bridge stancions, and you don't have to build in dynamite detectors just in case the impenetrable fence fails, and you don't have to make the bridge extra strong in case the dynamite detectors fail to alert you in time to stop the attack. All the integral security that you have to factor in makes a computer system very complex indeed....
Then again there are those folks that insist on being treated as "contractors" instead of employees so they can set their own hours, moonlight for multiple companies, and deduct expenses. Perhaps those one-man/woman companies can deduct the cost of fixing their bugs on their own time?
That would need to be specified in the contract; and as noted by other posters on this thread, a contractor factoring in a big-enough margin for 99.999% bug-free code is going to be multiplying his hourly rate by about 100....
Functional languages, for instance, rule out entire classes of bugs present in imperative languages. People complain that they're hard to understand. Maybe. I argue that they're hard to understand if you're the kind of person who does not care about whether your program is correct or not.
Actually, I think the resolution to this old argument is simple: FP as a subsystem of standard procedural and OO programming.
FP alone is useless because interactive programming is often nothing more than a string of side-effects bound together by code. However, there is no imaginable program of non-trivial size that does not contain sub-tasks that fall under the definition of a mathematical function. By coding the distinction between a procedure and a function (FP style) into the language, you could eliminate many of the most troublesome bugs in a single stroke: the "oh-god-which-procedure-is-changing-this-effing-value" bugs.
Consider the Kotaku article The Exceptional Beauty of Doom 3's Source Code -- one of the things the author comments on is the conventions used by iD Software to denote whether a procedure's argument is input, output, or both; and even that they almost never use a both-ways variable -- it should be either input or output, not both, for the sake of clarity and debugging. A heck of a lot of what goes on inside the Doom 3 engine is nothing more than churning through 3D vectors: that's maths, so that's a prime candidate for functional programming. Inputs and outputs would then be rigidly enforced at the software level, and no two-way variables would be allowed. The most complex parts of the code would be eliminated from the most complex debugging tasks.
And to think, all these benefits from adding a single keyword, function or deffn....
But when I am actually doing a run, and tens of thousands of pages are being processed, and ONE causes the program to crash: is that a bug? If you had no way to anticipate that one particular, strange bit of text that was different from all the rest?
Yes, that's a bug. You may not be able to anticipate the nature of problem cases, but you have to assume they exist. Each individual task should be isolated by an exception handler so that the failure of one job in a batch doesn't cause the failure of the whole batch. That's one of the first rules of programming, that is.
The point is that you don't have to throttle the volume -- you can just block the frequencies that cause the problem, and these frequencies are either inaudible or noise.
Besides, others on this thread have identified the components and the Dell laptop is defective by design, having speakers that are underrated for the output of the the sound board.
Such a system would cost a few more cents, because it's just a matter of the right rating of filtering capacitor, but even a couple of cents adds up when you're shipping thousands of units...
The HDD on most modern laptops has it's own cover that is not warranty sealed. Same goes for memory. This lets them offer more configurations of memory and HDD upgrades without having an exponential growth in stock sizes.
I don't think you understand the difference between peak and average volume. A solution which limited you from pushing peak all the time would decrease the overall quality of the product.
Not true -- it would improve the audio quality, because it would eliminate the higher order noise partials, and unmask the natural harmonics in the signal. There would be a loss of low-end, but the perceived audio would be clearer and higher fidelity.
That is asinine. It is the speaker that draws power; it is not up to some "rating" to determine how much power is given to the speaker. If you plug a 200W speaker into a 100W amplifier and open the amplifier up to full, that 200W speaker will try to draw 200 watts of power, likely overwhelming and destroying the amplifier.
Erm... that makes no sense, you know. The speaker doesn't know what the volume control is set at, so if it wanted to draw 200W regardless, your volume control would be useless. Furthermore, you only get a sound signal when the current changes. As the impedance of the speaker is approximately constant (yes, the magnetic field does increase the impedance above the plain electrical resistance of the speaker coil) and as P = I-squared R, you wouldn't get any audible sound at all if the speaker was attempting to draw constant 200W (or perhaps you get one-bit digital audio, which wouldn't be much good to anyone.
The chips, the designs...we are talking about INSANE complexity folks, it is just not something "a couple of guys banging away in their basement" is gonna be able to do. What you have to have is dozens of highly skilled, highly trained guys working on this stuff 8-12 hours a day every day...the requires funds folks, no way you can get around that.
Don't disagree that is how it is or seems now, but that is defeatist fantasy talk. There is no reason people have to play the games that corporations play. There is no reason everyone has to follow along with what our "leaders" tell us we have to do.
There is no reason we need the "latest and greatest" (full of backdoors) because that is what is selling (being shoved down everyone's throat) at the moment.
In that case, I have a C64 in my loft I can see you for $300 bucks -- guaranteed free of backdoors.
You want more projects like OpenDarwin, based on Apple "opening" "their" code? They closed shop after wasting a few years because Apple was just using them as unpaid labor without giving them enough to result in a useful whole, and dragging their feet even doing that.
...
The goose is laying golden eggs on the terms of the GPL and it's not letting itself get slaughtered like the teethless BSD goose.
Sorry, but those are two different things. It doesn't matter what the license is if all you've got is part of the code -- a GPL code fragment is no more a complete package than a BSD code fragment.
LLVM is a complete package originating in and maintained by academia. Different different different.
The wonderful thing about the GPL is the code doesn't just disappear when a company goes under, or decides it doesn't want to make a program anymore, or decides that some other program is more profitable, or decides to buy a competitor and halt both products and focus on their cash cow instead.
Neither does code written on a BSD-style license...
You think it's bad when you're asleep? I'm one of those people who sometimes gets my dream-state overlapping with my waking. I remember waking up when I was in the middle of cramming for an Artificial Intelligence exam, and I found myself trying to "instantiate" sitting up and getting out of bed. (Goddamned Prolog!)
The problem with your idea about Stallman's belief system is that Stallman is actually advocating against the idea of all proprietary software;
That makes no sense. I know what Stallman's belief system is, and I disagree with it. There is no "problem with [my] idea about Stallman's belief system".
Slashdot Mirror
It's not absurd at all if you think about the different workflows that could be used.
The AC's choice of the word "absurd" may be a mild hyperbole (if you pardon the oxymoron), but it certainly fails the Occam's Razor test. Which is more likely: that Wikipedia's editors aren't into videos, or that WP's editors really love video editing but don't understand transcoding?
The best explanation for the lack of video in Wikimedia Commons is that it's heavily tied to Wikipedia, and web video simply isn't compatible with the way Wikipedia works. You can't re-edit videos ad infinitum the way you can edit a WP article or a .SVG graphic -- all the web video standards are delivery formats, not editable archive formats. There's no collaboration, no iterative improvement, no refinement -- it's like it or lump it, which is an alien design philosophy to WP types.
In fact, now that I mention SVG... notice that Wikimedia has ditched officially ditched bitmaps for pretty much everything except JPEG photos, officially favouring SVG vector images as editable source formats. Adopting a delivery format for an archive operation is completely against what they stand for.
I'm surprised they based their designs on linear slides.... it looks like the next generation of RepRap will do away with them entirely:
You're forgetting that the main purpose of this project is to produce something durable and reliable. The RoboBeast design is based on RepRap designs that have been tried and tested to destruction, and then improves on them. Linear actuators are also far more reliable than non-linear ones, and far easier to stabilise (remember, this is resistant to a high degree of movement).
Besides, traditional manufacturing has had non-linear robots for ages, so they are a known factor -- if it was that easy, first-gen 3D printers would have used them.
The article refers to it as "the Chuck Norris of printers," which is odd, because it's not wooden at all....
In that case it's up to Facebook to sue, not the photographer; he already "gave" it to FB.
Not true, he gave them a non-exclusive license. He did not ascribe the copyright to them. Facebook could have licensed it to them, but in the lack of such a license, they have absolutely no say in the matter. Where no license is in place, it is only the copyright holder who has the right to sue.
Color Run never claimed to have obtained a license from Facebook. That they could have is therefore irrelevant.
Actually willful infringement is worth quite a bit in the court of law. Its well within his interests to pursue this and if he doesn't it sets the example that this sort of behavior is acceptable.
The problem is that this is quite plausibly a genuine mistake -- it happens all the time that someone within an organisation lifts a graphic from one resource and dumps it straight into another thinking "it's on our page, therefore it's ours" and doing no background checks. So in theory, it's very difficult to prove willful infringement.
The question that the legal profession should be asking is more interesting: as this type of case is pretty common, it is clear that most companies do not have systems in place to check these things, and crucially that they are aware that this is an issue. This is currently considered negligent, but there comes a point where even negligence can be considered willful: if you refuse to fix a known problem which allows you to continue to act in a way that prejudicially benefits your company, that's willful.
I don't think this case will set a precedent (because the guy doesn't appear to be negotiating reasonably), but there will be a case sooner or later that will put the onus on the company to audit their copy text and marketing IP properly. Only once the company has a central data bank of resources and a published policy of "only ever draw collateral from the data bank" should the company be considered non-negligent. Once that's in place, the occassional employee ignoring the policy would be accepted as unintentional, as long as it the employee was officially reprimanded.
As I was saying earlier: without trying to build a full-blown Watson-like text parsing engine (which is WAY beyond the scope of this project), it simply isn't possible to anticipate all the possible errors.
...
Regardless of whether it is a "first rule of programming" or not, it is only possible to account for the errors you can anticipate.
And I said, you're not expected to anticipate what the error is, just that this section of the program is prone to various errors regardless of type.
Having said that: I DO trap errors. When I said the program "crashed", I just meant it stopped running and, spewed out a runtime-error message. Anticipated errors are all logged. Only unanticipated errors cause the program to halt. And even those are trapped and give me valuable debug information.
Next run, that error will be anticipated and (we hope) dealt with in the code so it doesn't happen again. But that doesn't preclude another unanticipated error from happening after another 10,000 or so documents.
Sorry, but you're still making too much work for yourself by letting one faulty page halt the entire job.
You asked the question (and I quote): But when I am actually doing a run, and tens of thousands of pages are being processed, and ONE causes the program to crash: is that a bug?
Yes it is. A batch run of tens of thousands of pages should have the code that handles an individual page wrapped in an exception handler that traps unknown errors, logs information for debugging, marks the missing page in the output (for manual intervention) and then moves on to the next page. That way you get (tens of thousands - 1) pages processed and you have a perfectly acceptable error rate in the region of 0.01%
You should not stop the entire batch of tens of thousands of pages for an unanticipated problem in a single solitary one of them. It is trivially easy to prevent this happening -- unless the unanticipated fault jams your scanner.
Indeed, and when dealing with B2B software suppliers, contracts will typically quote high investigation rates for bug reports, to be charged if and only if the "bug" is no such thing (most are user errors or problems with the underlying platform).
Perhaps the OP should suggest the same thing to his boss...? I'll investigate in my own time, but if I determine the bug was A) a specification problem, B) a platform problem or C) someone else's bug, I'll be billing $200 an hour....
Also, "syntactica" is not a word.
No, but it does sound like a great name for an RTS based on programming cyber-attacks...
That's yet another terrible analogy! Dynamiting a bridge is akin to an IT administrator sabotaging a system from within. That's also a terrible analogy, but at least it's closer than your comparison.
It's a perfectly good analogy. A bridge is on public land and you can get to it dead easily, and you don't have to be an insider. His point is that you don't have to design impenetrable fences to prevent people accessing the bridge stancions, and you don't have to build in dynamite detectors just in case the impenetrable fence fails, and you don't have to make the bridge extra strong in case the dynamite detectors fail to alert you in time to stop the attack. All the integral security that you have to factor in makes a computer system very complex indeed....
Then again there are those folks that insist on being treated as "contractors" instead of employees so they can set their own hours, moonlight for multiple companies, and deduct expenses. Perhaps those one-man/woman companies can deduct the cost of fixing their bugs on their own time?
That would need to be specified in the contract; and as noted by other posters on this thread, a contractor factoring in a big-enough margin for 99.999% bug-free code is going to be multiplying his hourly rate by about 100....
Functional languages, for instance, rule out entire classes of bugs present in imperative languages. People complain that they're hard to understand. Maybe. I argue that they're hard to understand if you're the kind of person who does not care about whether your program is correct or not.
Actually, I think the resolution to this old argument is simple: FP as a subsystem of standard procedural and OO programming.
FP alone is useless because interactive programming is often nothing more than a string of side-effects bound together by code. However, there is no imaginable program of non-trivial size that does not contain sub-tasks that fall under the definition of a mathematical function. By coding the distinction between a procedure and a function (FP style) into the language, you could eliminate many of the most troublesome bugs in a single stroke: the "oh-god-which-procedure-is-changing-this-effing-value" bugs.
Consider the Kotaku article The Exceptional Beauty of Doom 3's Source Code -- one of the things the author comments on is the conventions used by iD Software to denote whether a procedure's argument is input, output, or both; and even that they almost never use a both-ways variable -- it should be either input or output, not both, for the sake of clarity and debugging. A heck of a lot of what goes on inside the Doom 3 engine is nothing more than churning through 3D vectors: that's maths, so that's a prime candidate for functional programming. Inputs and outputs would then be rigidly enforced at the software level, and no two-way variables would be allowed. The most complex parts of the code would be eliminated from the most complex debugging tasks.
And to think, all these benefits from adding a single keyword, function or deffn....
But when I am actually doing a run, and tens of thousands of pages are being processed, and ONE causes the program to crash: is that a bug? If you had no way to anticipate that one particular, strange bit of text that was different from all the rest?
Yes, that's a bug. You may not be able to anticipate the nature of problem cases, but you have to assume they exist. Each individual task should be isolated by an exception handler so that the failure of one job in a batch doesn't cause the failure of the whole batch. That's one of the first rules of programming, that is.
2009.
The point is that you don't have to throttle the volume -- you can just block the frequencies that cause the problem, and these frequencies are either inaudible or noise. Besides, others on this thread have identified the components and the Dell laptop is defective by design, having speakers that are underrated for the output of the the sound board.
Such a system would cost a few more cents, because it's just a matter of the right rating of filtering capacitor, but even a couple of cents adds up when you're shipping thousands of units...
The HDD on most modern laptops has it's own cover that is not warranty sealed. Same goes for memory. This lets them offer more configurations of memory and HDD upgrades without having an exponential growth in stock sizes.
I don't think you understand the difference between peak and average volume. A solution which limited you from pushing peak all the time would decrease the overall quality of the product.
Not true -- it would improve the audio quality, because it would eliminate the higher order noise partials, and unmask the natural harmonics in the signal. There would be a loss of low-end, but the perceived audio would be clearer and higher fidelity.
That is asinine. It is the speaker that draws power; it is not up to some "rating" to determine how much power is given to the speaker. If you plug a 200W speaker into a 100W amplifier and open the amplifier up to full, that 200W speaker will try to draw 200 watts of power, likely overwhelming and destroying the amplifier.
Erm... that makes no sense, you know. The speaker doesn't know what the volume control is set at, so if it wanted to draw 200W regardless, your volume control would be useless. Furthermore, you only get a sound signal when the current changes. As the impedance of the speaker is approximately constant (yes, the magnetic field does increase the impedance above the plain electrical resistance of the speaker coil) and as P = I-squared R, you wouldn't get any audible sound at all if the speaker was attempting to draw constant 200W (or perhaps you get one-bit digital audio, which wouldn't be much good to anyone.
The chips, the designs...we are talking about INSANE complexity folks, it is just not something "a couple of guys banging away in their basement" is gonna be able to do. What you have to have is dozens of highly skilled, highly trained guys working on this stuff 8-12 hours a day every day...the requires funds folks, no way you can get around that.
Don't disagree that is how it is or seems now, but that is defeatist fantasy talk. There is no reason people have to play the games that corporations play. There is no reason everyone has to follow along with what our "leaders" tell us we have to do.
There is no reason we need the "latest and greatest" (full of backdoors) because that is what is selling (being shoved down everyone's throat) at the moment.
In that case, I have a C64 in my loft I can see you for $300 bucks -- guaranteed free of backdoors.
You want more projects like OpenDarwin, based on Apple "opening" "their" code? They closed shop after wasting a few years because Apple was just using them as unpaid labor without giving them enough to result in a useful whole, and dragging their feet even doing that.
The goose is laying golden eggs on the terms of the GPL and it's not letting itself get slaughtered like the teethless BSD goose.
Sorry, but those are two different things. It doesn't matter what the license is if all you've got is part of the code -- a GPL code fragment is no more a complete package than a BSD code fragment.
LLVM is a complete package originating in and maintained by academia. Different different different.
The wonderful thing about the GPL is the code doesn't just disappear when a company goes under, or decides it doesn't want to make a program anymore, or decides that some other program is more profitable, or decides to buy a competitor and halt both products and focus on their cash cow instead.
Neither does code written on a BSD-style license...
Actually I believe the goto languages are Scheme and Haskell.
Nah, the GOTO language is Basic....
You think it's bad when you're asleep? I'm one of those people who sometimes gets my dream-state overlapping with my waking. I remember waking up when I was in the middle of cramming for an Artificial Intelligence exam, and I found myself trying to "instantiate" sitting up and getting out of bed. (Goddamned Prolog!)
The problem with your idea about Stallman's belief system is that Stallman is actually advocating against the idea of all proprietary software;
That makes no sense. I know what Stallman's belief system is, and I disagree with it. There is no "problem with [my] idea about Stallman's belief system".